Finding the Goldilocks Process
Lessons from Cover Oregon
On April 25, Oregon made the decision to shutter its $248 million exchange and join Healthcare.gov. Oregon’s experience with rolling out its own health care exchange as part of the Affordable Care Act was a microcosm of the national experience with Healthcare.gov itself. Both offer opportunities to criticize IT project management processes. A number of explanations have been offered, but no clear ownership over the end-to-end vision and user experience, lack of communication between groups regarding both the way systems would interface and realistic timelines are two that rise to the top of the list. Similar problems occurred in Oregon where the site’s launch was delayed, and ultimately never shown to the public before deciding to shut down.
These projects were larger than your average bear, but that doesn’t mean they couldn’t have benefited from more appropriate processes that work on smaller projects. It would be easy to claim the agile ideal works for every situation — write stories as needed to ensure your backlog is full and prioritized; score stories within a sprint to target an appropriate number; have a daily(ish) standup to ensure everyone is on track for their tasks for the sprint; sit back and deliver things. The reality, in my experience, is a bit more complex. Process includes a number of product and project management tools that should be employed to suit the particular situation rather than a prescribed set of activities used in all situations. Finding the right mix can look a bit like Goldilocks activity swinging from too much to too little to just right. Unfortunately, without understanding process’ role, the search for the right process can begin again on the next project.
Papa Bear’s Process — Too Much
The Product Manager who finds themselves going down the path of too much process will experience projects that have difficulty getting off the ground or making headway. Too much process can include being forced to adopt a rigid Software Development Life Cycle with very strict gateways before projects can move to the next stage in the process. As a result, Product Managers sometimes find themselves creating documentation that is divorced from the reality of the project in its execution. In some instances, the documentation created is neither digestible nor enforceable.
An almost farcical example of this occurred in the Cover Oregon debacle according to the official report: (http://www.oregon.gov/DAS/docs/co_assessment.pdf)
A number of formal management plans, including project/program plans, communication plans, a governance model, decision matrix, scope/change management plans, schedule management plans, risk and issue management plans, budget management plans and escalation processes were created. Although these plans were created, several stayed in draft form (were not approved or defined as master files) and many were duplicated by different agencies. A total of twenty-seven management plans were created, with four plans as duplicates. Twelve of the fourteen management plans listed in the Program Management Plan were created, with exception of the Operational Plan and Vendor Performance Management Plan.
Due to the many duplicated and draft management plans, it was unclear which management plans were in effect and for what period of time. Based on the assessment interviews and an analysis of the RID Log and other project documents, it appears that the many of the management plans were used to some degree by the project teams, but to what extent remained unclear.
In other words, each of the groups involved were going through the motions of their development processes. The documents checked a box, but they were never fully executed, nor did they take hold in the project. In effect, they were process for process sake rather than a critical structure around which the project would be built and managed. The documentation was either not maintained properly, or not actionable, but the check box on a document review gave everyone comfort that the project was moving.
Additional symptoms of too much process can include meetings that cover parts of the project that are not central to the current sprint or milestone. If you find yourself reviewing every step of a project plan in every meeting, STOP and ask yourself what work should currently be in process and what comes immediately after this sprint / milestone. Similarly, if you find yourself reviewing the same items in multiple consecutive meetings without the status having changed, cancel the next two meetings and see what happens when you come together again. Meetings for meetings’ sake make people feel comfortable that they’re working, but it doesn’t mean that work is getting done.
