In many organizations, saving failing projects is a regular part of the job of all project managers. Most PMs have had to rescue their own projects from time to time. In fact, one of the traits of superstar PMs is that they can bring their own projects back from the edge of defeat. So how should you do a project rescue? Enterprise Project Management Main Page
Let’s say that toward the end of your project’s planned time and budget your weekly monitoring of results shows a continuing slide toward overruns. You realize that continuing to hope for outstanding performances from a few team members will most likely not let the team catch up. Before you surrender and call the sponsor, there are a few things you can do to avoid failure.
Project Rescue: Continuous Monitoring
First of all, continuous monitoring of your project’s schedule and cost with estimates to complete (ETC) is an essential part of all effective rescues for turning your project around and managing expectations. Let me give you an example. One of my projects still had about four months in duration but from my control sheets, my personal opinion, and the history of change requests and challenges, I was pretty sure that we would not deliver the entire scope that was originally agree upon. Here is my point. Because I had monitoring tools in place, and because I kept a personal log on where we were in the project, I was able to come to that conclusion a lot earlier than I would have if I would have not had these statistics in place.
Project Rescue: Clarity on Project Scope
Second, as I pointed out in one of my earlier posts, (Project Failure Warning Signs) I had a visual representation of the agreed scope in place and the supporting high-level deliverables. This picture was another component in my planning and forecasting toolbox. Using this picture, I was able to mark those components that were in danger of failing. Combined with my statistics, I was able to draw a picture of what was still possible. Project Failure
You can usually see when things start to turn against you and try to steer against those tendencies. However, in my case, my actions did not result in total victory. At one point, I had to tell my stakeholders that we had a problem at hand. What I would like to encourage you to do is this: when things don’t work out, the sooner you raise your concern the more time you have for implementing workarounds. Furthermore, if you are able to visualize what you have already accomplished and what is feasible by your determined project deadline, you are in a much better position than if you just inform your sponsor via email. In my situation, I was able to point out why we were behind, what we would be able to accomplish and how that would improve the company’s overall situation. I can’t point out this action often enough: visualize your arguments. With a picture of the original scope and the “realistic” scope at hand, I was able to show that even though we would not complete everything, we would complete the most important components.
Project Rescue: Work through Alternatives
In addition, since we raised the red flag early enough, we had enough time to work out alternatives and refocus our development team. My project has not yet finished but I am pretty sure that we will produce a result that will be more than acceptable, even though we didn’t hit a bull’s eye.
Project Rescue: Summary
In conclusion, I encourage you to do the following:
- Have a clear project scope and supporting high-level deliverables
- Continuously track your project progress. Visualize what you have already accomplished and what is feasible
- Don’t just raise a red flag, visualize your arguments. Show what you can do and how this result will still improve your organization’s processes
- Start working on alternatives and a fallback solution as early as possible. Don’t wait for someone else to point out the problems.