Risk mitigation requires surfacing and identifying a broad range of possible risks and applying appropriate risk mitigation handling options based on potential consequences and impact, plus prioritization and implementing accept, avoid, control, transfer, or monitor approaches.
Strategy: Design the project organization early
• Consider all initial roles, how roles may change, or start work later in life-cycle
• Create visual to aid integration review and communicate scale, opportunity, and commitment
• Ensure everyone sees and acknowledges their part in the project early
• Is there sufficient definition of each role and responsibilities, criteria?
• Reduce risk of insufficient skilled labor, time, or inadequate competencies to complete tasks to meet quality and schedule requirements.
• Consider roles where there must be a single owner who must deliver a finished product as part of the project scope and deliverables.
• Benchmarking against similar organizations that execute this category or class of project
• Confirm future availability of resources at individual and management levels
• Contingency planning for critical resources/roles
This work is especially important if the current project is similar to past projects, and assumptions of how things will progress can be biased based from recent experiences.
Since hurricane Sandy hit the NY city area in 2012, devastated homeowners have been mired in an over designed process that was so poorly managed that not one of the 20,000 homeowners who applied for assistance rebuilding their homes had seen any work begin until very recently (almost two years later).
The obstacle to progress may be attributable to the design and execution of the program by the previous administration of Mayor Bloomberg.
More than one or two poor design and execution decisions were made (What processes should be put in place to reduce this risk?):
- Cinder Block Phenomenon: The administration hired external consultants at $400-$800/hr that created a housing damage assistance process so rigid and sequentially linear that it was almost unworkable (to reduce the risk of corruption seen in New Orleans after Katrina)-a painful example of waterfall failure?
- Dilution of Strategy: The administration reserved money for initiatives seen as strategic including long-term risk management for future disasters vs. money toward urgent individual family housing needs-design
- Training: the call centers were staffed with quickly hired temporary workers who received limited training-execution
- Deep Domain Knowledge: They ran the program without local municipal managers present and little meaningful oversight of the contractors they hired-execution
- Define the Problem Correctly: The well dressed consultants recommended focusing on lower-income applicants first, while admirable in principle, it created very long delays for moderate-income families including teachers and firefighters. It meant impacted residents would have to go to great lengths to document their incomes, on top of endless other documentation requirements (many these personal documents were of course lost in the storm damage)-design
- Automation Failure: Applications were intended to be stored in a custom computer program, but the software became best known for losing documents without a trace.
In the end, a new mayor was elected and put new leadership in place that began to change the dynamics; it was the only answer, and finally resulted in quantifiable progress and impact on housing, but still gravely behind what other state and local governments have delivered to date with better designed programs.
GM released the results of an internal investigation of ignition switch failures today. The CEO said that some GM employees looking at the problem believed the ignition switch flaw was only “a customer satisfaction issue, not a safety issue.” They did not understand that shutting off the car would disable critical safety features like airbags. They did not have the critical information need to change their framing of the problem. Shockingly, “Over time, the company learned that air bags could also be deactivated when the cars lost power.” It did take time, eleven years.
How could a sophisticated engineering organization not understand the relationship between the ignition switch and airbag power? Some tools and techniques that may help lead to a better outcome:
- Communication Plan: “Numerous individuals did not accept any responsibility to drive our organization to understandwhat was truly happening,” the CEO said. Project managers must demonstrate significant leadership responsibility.
- Project Management: As a practice is intended to facilitate cross-domain collaboration to surface and communicate important information in a timely manner.
- Risk Management: Was there insufficient risk analysis of one of the most important subsystems of an automobile?
- Behavioral Analysis: One can imagine that power to the airbag subsystem would be identified as needing a high level of resiliency given the absolute requirement to function in a worst-case scenario accident.
- Project Design: Employing system engineering tools such as interrelationship and interaction matrices during the design process and available as organization assets may have identified and communicated the ignition switch link and associated risk.
- Design Thinking: Apply divergent thinking to explore and validate the nature of a customer problem, have we asked the right questions? Are we solving the right problem? Are we delivering what our customers really need or require?
There are some painful similarities with the Challenger disaster. In this accident, the engineering staff correctly diagnosed the risk, made efforts to communicate the problem to senior management, but it was not handled effectively leading to another tragedy.
The French government ordered new trains for their national rail system. This is an expensive proposition, at nearly 3 billion Euros. It was disclosed just this week that the planners failed to consider that train stations in France had been built over many years, over decades, with different specifications over time. They only took measurements at newer stations. Many of the older stations are too small to accommodate the new trains, many approaching a thousand stations. Ouch.
The use of system engineering tools including forms of interrelationship, interaction, and interface matricies should be considered and examined in facilitated cross functional group exercises during project design.
One technique that can help stakeholders to think through and visualize what they are really looking for in a finished system is to define a set of acceptance criteria test scenarios. This is most effective after initial requirements elicitation has been completed, documented, and reviewed. This is essentially a form of prototyping, rehearsal, or exercising user stories by persona looking for greater insight.
A simple example is a website that provides various user services:
- Buy an item online with credit card or PayPal; see transaction confirmation in account(s) and via email.
- Register for an event; receive email confirmation, ticket information, ability to print ticket, etc.
- Sign-up for an email or newsletter service; receive email confirmation, integration with mailing service or CRM system.
For each user story scenario, we can ask a series of questions:
- What else? may include reporting, dashboard integration, inventory update, etc.
- Where can we improve? Frustrations that might be expected that we can work through to re-design?
This is a structured opportunity for divergent and open exploration of what the product, service, or change will look and feel like after implementation is complete. When we’re done, what will we really have done? It can also help identify issues that should be treated as a complete project or major WBS component. Many other test scenarios and questions can be devised enabling a detailed walk through of the end-user experience of the final product.
Other Potential Benefits:
- A more comprehensive procurement plan
- Deeper understanding of business processes
- Identify roles that exist or need to be created to support operational work
- Organization change
- Subject matter experts required to support new technologies