Certified Business Coach and Corporate Exit Strategist
This is the second part of a three part article discussing “how does a project manager intelligently handle delays in a project?”
Last article we focused on acknowledging the natural flow of a project which includes periodic speed bumps and roadblocks. In today’s article we’ll focus on using recovery protocol plans to assist with project management.
Agree to a Protocol Recovery plan at the start of a project:
All projects will hit some unexpected issues. By discussing a “protocol recovery plan” at the start of the project, the team will understand how to proceed when time is running out. A “protocol recovery plan” is like a “fire escape route”. At the start of the project, your project sponsors and stakeholder discuss the flexibility of the following: Add Resources, Remove Features, Change Schedule, Reduce Quality. The idea is to agree up-front (before the project starts) which order you will do them. For example, if/when you hit a snag does the team agree to first investigate adding more resources to the problem? At some point, adding resources will no long be an effective option. At that point, which is the next flexible item to adjust? Would it me to remove some features from the list or would it be acceptable to add time to the schedule?
Take a look at the below figure:
In this company, the group discussed and created the above protocol recovery plan. In their last release they were hit hard with client complaints; technical journals reported on their dismal quality; and they decided as a team that they were going to put out a high-quality product this release. As a result, the group agreed from the start that the QUALITY is the main priority and last to be modified. They also understand the order in which the other items will be attacked. Because the group agreed upfront that “QUALITY Standards” will be the last to change, there was no lost time in deciding how to proceed when an issue arose.
In this example, the team agreed to add resources (until it doesn’t make sense to add resources anymore). Once you have reached the point where more resources will not help, you agree that the next step will be to start removing features. This will only work if : at the start of the project, you understand the minimum set of features or services that make the project worthwhile to the client. You will have a set of many other “nice-to-have” features or enhancements on your list as well. This upfront knowledge allows you the flexibility to manage issues. If you understand the minimum MUST HAVE feature set, you can then start removing or rescheduling the “nice-to-have” items to the next release. Once you have removed all the “nice-to-have” items and are only left with the MUST HAVE, then you look back at your protocol recovery chart to find out what the team has agreed to do next.
If you have this outlined and approved at the start of the program, then you don’t have people complaining that you are cutting his/her features, etc. This is all understood before the project starts.
Conclusion:
A protocol recovery plan is much like a “fire escape” plan. It’s not something you scramble to put in place during the fire.
Once again, a good project manager doesn’t try to control a project. A good project manager adapts and manages the natural flow of things. The trick isn’t to stay on track. The skill is to seamlessly get back on track when we wax and wane.
The next feature will cover the idea of a critical path analysis.
