The Project’s a Disaster! Were You Prepared?
I’m well known for using my favorite project management quote which comes courtesy of Napoleon Bonaparte, “A battle plan lasts until contact with the enemy.” This is also true of project plans. It’s a good thing too for those of us in the project management industry. After all, if there were no challenges to projects being completed on time, on budget and as expected, we’d have no need for project managers.
It’s always surprising to me however, that given that project managers are in the business of overcoming project problems, so few of us actually prepare for them. Disaster planning and disaster recovery are becoming more and more of a science from a number of perspectives. Governments now often maintain emergency preparedness organizations. In most federal, regional and municipal governments, there is some expectation that sooner or later disaster will need to be dealt with and organizations have been set up to prepare for that time.
In the IT industry, disaster recovery is a well known aspect of an IT environment. Having just recovered from a major server crash myself in the last few weeks, I know that the more prepared we are for the inevitable hardware failure, the quicker we are to recover and the less time lost to the emergency.
However, when I look at the vast majority of project schedules, this same level of preparedness is rarely present. Schedules are most often planned with the most optimistic perspective and dire consequences if they are a day late or a dollar over budget. When I talk about contingency, risk assessment, fall-back plans or alternate project plans, I’m most often greeted with a blank look.
So, how does a project manager prepare for the inevitable project disaster?
Did You Plan for It?
Every project plan when examined critically has weak spots. Every one! The experienced project manager knows to look at those areas of the project more stringently than others. If you know that a key aspect of design is of higher risk than the rest of the project, then thinking about how you’ll adapt if that part of the project is delayed or derailed will make your life infinitely easier later. For each risk element of the plan, it’s worth keeping “what-if” notes. What if that part doesn’t arrive? What if that resource isn’t available? What if we need to move ahead without this part of the project complete? Risk assessment usually isn’t required for the entire project so spending more time on the obviously riskier areas almost always pays off later. “Plans are nothing. Planning is everything,” said Eisenhower after the D-Day invasion. If the project is very complex you can use Risk Analysis software such as @Risk to get a Monte Carlo simulation of what elements of the schedule are more at risk than others.
Did You See It Coming?
Many people tell me that their project disaster snuck up on them without warning. It’s easy to understand how. Once the project is underway, the day to day frenzy of managing the project, putting out brush fires and keeping the natives from getting restless can consume your day. In retrospect, after a project is thrown off the rails, people often say they should have seen it coming. Well, you can. Think about the metrics you’d need to track in advance and it doesn’t require a 50 element dashboard to make a difference. A handful of project progress measurements can give you plenty of advance warning that things aren’t going as expected. If you know you have a high risk element of the project, then creating a “Tripwire” milestone in advance of that section so you will take pause and check on that upcoming high-risk area is easy to do and can save you mountains of grief. Major US defense contracts are using this “tripwire” term now in Earned Value processes as a way of talking about early warning for upcoming project problems. A “tripwire” (think of a string of wire with tin cans on it that will make a horrid sound if someone trips over it in the dark) in project terms is often a threshold or tolerance of a project measurement. For example, if task #20 is more than 10% late, we’ll do a project review.” A tripwire should be attached to some follow up action for it to be meaningful.
Did You Take Out Insurance?
The very first person I ever met in the project management business, now almost 30 years ago, was in the construction industry. He was a very experienced project manager and he never started a plan without some contingency hidden in his back pocket. Building Commissioning was his favorite spot to hide it as I remember. “The schedule says it will take us three weeks to finish painting the interior,” he’d said to me with a wink. “But, we know that if we’re in trouble, I can throw a hundred fellas in there and finish it in three days.” It’s a lesson I’ve remembered well.
Making a management contingency is a healthy practice and it’s done rarely by project managers. When you create the management reserve (which might be measured in dollars, in man-days or in duration) you often can’t hide it. In this modern day of transparency, hiding the management reserve may be easier said than done. If you can keep the contingency to yourself that’s great, but if not, go the other way. Be very public about using it. Have a sign-off sheet that the client or management must sign indicating that they know they’re now using the contingency. This may slow down spending the reserve casually or having multiple people thinking that they can each use all of the reserve for themselves.
People are told to keep three days of water, medication, first aid and other emergency supplies ready at hand just in case an emergency comes your way. Do you do the same for your project? If you know there are potential project challenges in higher risk areas of the project, then it makes sense to make a contingency plan for those areas. I’ve seen some remarkable project plans that include conditional branches of the plan just in case. Sometimes these contingency plans include pre-negotiated contracts with potential resources. Sometimes they include potential sub-contracting arrangements to split off a small piece of the project for another supplier to deliver. Sometimes the contingency plan is as simple as calculating the overtime that would need to be spent if something goes wrong in a particular area.
Emergency preparedness is great but it also comes with a law of diminishing returns. Let’s take a project with 20 major elements. If we go by the 80/20 rule, we can reasonable expect four of those elements to represent 80% of the risk. I know that’s a generalization but it’s amazing how often it’s true. If we do some contingency planning for those four elements, we’ve got fall-back plans for 80% of the major problems we’ll face. We can, of course, make contingency plans for all 20 elements but we’ll put more effort into those plans than they’re likely worth. So, picking and choosing what parts of the project to do emergency preparedness for makes a big difference to your overall efficiency.
Can you plan for every emergency? Of course not. But if you don’t prepare for disaster, then when it strikes the effects on your project, your organization and even you can be awful. Pretending that disasters never happen is just ostrich management. You can’t stick your head in the sand and hope that the problems will go away. Being prepared for a disaster will make you a better project manager whether disaster occurs or not.
Don’t forget to post your comments below!
Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected] .