With the recent go-live of the ACA (Obamacare) website we saw another example of a complex project introduction go badly.  There are a host of reasons for the problems, requirements changing, insufficient testing, and no one person leading the effort.  And just the scope of a project required to meet the needs of millions.  One has to wonder if a risk management plan was done for this project and followed through the design process.   On a side note, where I live the Washington State website actually met customer needs and was easy to navigate.  So scope does have an impact.

Staying away from the politics, the ACA website joins a long list of complex projects that have had problems in their initial roll-out.  We can look at a list that covers of range of fields – the Boeing 787, three years late (and still having problems); the Central Artery/Tunnel Project – aka the Big Dig, in Boston, 9 years late and 190% over budget; and Microsoft’s Vista, 3 years late and soon replaced by Windows 7.0.

HOW PROJECTS GO OUT OF CONTROL?
How did these projects get so out of control?  Were there risk management plans?  Were they followed?  Were they too detailed?  Not detailed enough?  Did the risk management plan contribute to the problems, or help the project ?  Can we expect the risk management plan to help prevent projects from going out of control?  Or are some projects so complex that there is no way to successfully implement them within the planned schedule/budget?

A risk management analysis in the early stages of the project will identify risks, mitigations for the highest risks, and be resource through the project design phases.  But it needs to be an actively used  plan and not one gathering dust on a shelf or pulled out for reviews.  It needs to impact the systems design, architecture and the requirements

As we look at the growing complexity of systems, we also need to consider an approach that we use in systems engineering  to address complex systems is System of Systems (SoS) where we bring together multiple systems to address a larger scale problem.  In these cases risk is managed at both the individual system level and at the higher SoS level.  Integration still remains a challenge, but with each individual system verified and then integrated with the others we can improve performance.  If  SoS was applied on more projects we might not  be having these conversations about failed roll-outs.  But since we still have people involved we’ll still have challenges on projects.

Bio:

Paul J. Kostek is a Principal of Air Direct Solutions, a systems engineering/project management consulting firm. He works with companies in defining system architecture, system requirements, interface definition, verification planning, risk management and software development standards. Paul received his BS from the University of Massachusetts, Dartmouth.   Paul works in a range of industries including: aerospace, defense, medical device and e-commerce.

Paul is a long-time volunteer with several professional engineering societies including IEEE, AIAA, SAE, INCOSE and PMI.  He also writes for the CERM Risk Insights emagazine.