Finding the Goldilocks Process
Lessons from Cover Oregon, Part 2
Part 1 of this article is here.
Mama Bear’s Process — Too Little
Projects with too little process can look a bit like the Wild West. The project hells that result tend to be paved with the good intentions of a desire to avoid wasting project members’ time with too much process. The smaller the project team, the less risk imposed from too little process, especially if documentation and approvals are replaced with frequent standups to communicate status, approach and dependencies. As the size and number of systems involved in the project grow, so too, does the risk from not enough process.
Projects that lack the appropriate level of process can result in lost time from situations arising out of ineffective sequencing of deliverables. It is important to know what components need to be completed such that sub-projects can have time to be completed and tested in time for the overall project to deliver. Inadequate planning and lack of cross-team communication, both of which are risks from too little communication can extend the overall project past deadlines due to blocked teammates. In the Cover Oregon example, Deloitte Digital’s efforts to combine multiple enrollment systems into a streamlined, user-friendly online system proved more difficult and time-consuming than anyone expected. When they completed their scoping exercise in March 2013, they touched 80% of the project. The project plan had not anticipated the new requirements and significant new risk had been introduced.
Even worse in a project with too little process, components may be developed that do not work with one another, or do not deliver the experience the overall project requires. This can result from murky roles and responsibilities and project governance that lacks authority. The lack of an authoritative set of documentation from which to work against was troubling to Cover Oregon’s Quality Assurance contractor. (http://www.oregon.gov/DAS/docs/co_assessment.pdf)
As late as January 2013, Maximus continued to report that there was no clear authoritative document that defined the expectations for all the programs, authority/delegated authority, governance and detailed functional roles and responsibilities. The report also stated that there was a “lack of common or functional governance processes and limited overlap among inter-agency processes with dissimilar priorities and goals among independent state agencies.”
Maximus continued to raise risks on a monthly basis reporting the project as Red in the table below, but project leadership became de-sensitized to Maximus’ crying wolf. Even more troubling was that many team-members reported being unaware of the Maximus QA role and reports, and were thus unable to address the concerns being raised.
Similarly, when Maximus called out risks about their contractor, Oracle, those warnings were not heeded. Two excerpts from among many listed include
“Software releases into test from development are being implemented daily/weekly. The releases are not stable and fixes and features are appearing randomly in the releases. In addition, more items are breaking then are being repaired. This is indicative if too much concurrent Oracle development in an uncontrolled development environment. “
“It is likely that scope will continue to be trimmed if issues arise with the current plan or if development (Oracle) continues to under deliver.”
Yet, because the project had a conflicting decision-making structure, and decisions were not promptly made to mitigate identified risks. Combined with brimming confidence from the lead contractor, the decisions were missed until it was too late to rescue the project. For its part, Oracle called out the lack of stable requirements and the lack of a systems integrator who would manage the various factions and their processes to deliver the end project resulted in undisciplined behavior and missed timelines.
