by Kathleen Austin & Gerald Kendall
Part 1 provided an introduction to projects and the need to plan a project. Part 2 discussed how to ensure the correct level of detail in a project network. Parts 3 – 11 detailed Steps 1 – 9 of the 10 steps to building an executable project plan. Basis for this post: Advanced Multi-Project Management: Achieving Outstanding Speed and Results with Predictability, by Gerald I. Kendall and Kathleen M Austin, J. Ross Publishing, 2012, Chapter 22.
Step 10: Complete a final, overall project risk assessment (fifth risk avoidance)
You now have the final perspective of all work required to accomplish the project’s scope goals, objectives and deliverables, with task notes detailing activities within the tasks, significant assumptions about each task, and specific task completion criteria for each task. You have identified the risks to each task individually through the task notes and task time variability estimates. Durations have been adjusted / corrected where appropriate without compromising on completion criteria, budget, or timeline.
Given the overall understanding of the project stakeholder needs, the goals the project is intended to meet and the work outlined in the project plan, the project team is now prepared to take one final step. Are there other significant risks posed by this project, which would endanger meeting its goals, in spite of all of the preceding work in building a robust plan?
Holistic Risk Mitigation
It is time to look at the project as a whole in terms of risk mitigation. The final project risk mitigation should be done with the original planning team, sponsor(s), key stakeholders, and experts who have provided resource skills and quantities, expert scrutiny, and task time estimates.
This review should go over, in detail, all of the project details and open discussions as to missed risk mitigation. If any significant risks at the task level have been missed, that information should be added appropriately and documented in the task notes.
There are also risks that can occur during the project, but cannot be assigned to a specific task or series of tasks. Examples:
- Some series of tasks are performed by external resources who do not always reliably deliver. You do not know in advance which external resources this will happen with, but experience has shown that in projects like this, it’s likely to happen at least When it does happen, delays of at least 10 days occur. Make a note that a project-level risk adjustment (upward or longer in time) needs to be considered.
- Some of the equipment being used on the project has significant scheduled maintenance down time every 500 hours. That scheduled maintenance will happen at some time during the project, but there is no way to know when or the number of times it will occur. Document the number of times and the estimated down time as another project- level risk adjustment (upward or longer in time) that must be considered.
If there is iteration variability present in the project, look at the number of times it is estimated to occur. Typically, if there are one or two opportunities for iteration variability, no project level adjustment needs to be made; however, if there are more than two opportunities for iterations, consider whether the project is being “over-protected”. If so, document and note that a project-level risk adjustment (downward or shorter in time) must be considered.
Organizations have typically experienced so much project failure and underachievement, that they are prone to overlook one of the biggest generic risks of a project – the risk of success beyond expectations. In the ‘90s, when AOL launched their internet service with massive advertising, they lost tens of thousands of customers almost immediately after launch. These customers tried to dial up the free AOL telephone numbers to connect, and experienced busy signals for hours on end. (Yes, we understand we may be describing something that sounds like horse drawn milk trucks and wagon trains to the younger generation!). Similarly, we’ve seen many cases of product launches where the stock needed to satisfy initial customer requests was grossly underestimated, and the lead time to manufacture more was long. Customers waited months, by which time competitors had caught up and offered their own products. In these situations, it’s not just that the organization lost some sales – they made their customers so mad that they lost customers for life.
Another type of risk is what some insurance companies labeled the “front page” risk. This is the risk that their project results in customer complaints that are so severe, that the story ends up as a feature on the news.
The final conclusion of the group should be that all significant task and project-level risks have been addressed: the network as planned is sufficient (but not over-sufficient) to deliver the full scope of the project, at or below the budget, on or before the due date.
Conclusions
The final risk mitigation step is intended as a last, holistic look at the project, to mitigate or prevent any other previously unidentified risks from being realized. With the full team of
stakeholder, network builders, and other key players present, the project can be examined to determine if other tasks are needed for final risk avoidance. Most often, the outcome of this step is to proceed with the plan as is or with very slight modifications. However, in the rare case where a major risk requires rework of the entire plan, it is much better to find out before
Final Thoughts on Building Executable Project Plans
This concludes the 12-part series on building executable project plans. Please provide any feedback, comments, questions, concerns, or requests. Did you find this useful? Did it make a difference in how you build networks? Thanks for reading!
