Emergency projects challenge every PM’s professional discipline. When the emergency strike High ranking execs want fast action now… they don’t want thinking, or planning. If you are not moving at high speed… Get out of the way! Everyone else is frantic and if you don’t start responding franticly, they’ll think you don’t care. These hysteria enablers won’t be still until they have a to do list headed, “Start Work NOW!”
So give them the todo list and then use the resulting silence and calm to identify the decision makers who will judge the success of the emergency response. Let them define success then you can start the planing with a quantified deliverable which defines the scope.
What if people/property are in danger!
If the emergency is in the “Act of God” category (fire, flood, earthquake, tsunami, meteor strike), there will be law, public safety and political officials all over the place. They each will have their own goals want to be in charge of saving people and property. You won’t begin work until all the people and property are secure. But in the meantime, you can plan so once the people and property are secure you can start work with a developed and detailed plan for whatever type of emergency you face.
Another type of emergency is affects the organization’s:
- market positions
- product competitive positions
- systems integrity
- loss of prized human resources
There are many examples of these emergencies. In one of them a competitor might exclusively acquire a new technology that will allow them to profitably sell your #3 product for 35% less than you do. Resulting in a potential drop in your revenues of 23%.
Recovery Project Scope
The initial thinking about the scope of the recovery project is often focused on “getting back to where we were.” In other words, the recovery project should aim to make us just like we were before the emergency. But a better way to think through the planning is to recognize that we may
Often the best thing to do is take 5 minutes to assemble a todo ir only It doesn’t matter if you are the most experienced PM out there or if you just started your career in this field. There will be times when things don’t go your way and you have a crisis project. As a matter of fact, if things wouldn’t go wrong from time to time, we would not have an opportunity to learn from our mistakes. However, it is also important to remember that no matter what the situation, a good PM always turns to problem analysis and planning first, that’s good crisis management. Project Planning Main Page
Towards the end of last year, I was reminded of the importance of planning during times of crisis. We had just completed a smaller migration project. This project was a rather routine exercise, as we had done similar projects multiple times before. The objective of the project was to move a number of trading transactions from one book to another in our main trading platform. We had a standard plan for this kind of project, everyone had signed-off on the plan, we had a number of test rounds, and finally, we did the migration in our production system. And then came the crisis. During our initial analysis and throughout the implementation phase, we had overlooked a small, but rather important parameter, and as a result we had produced a little mess in our main general ledger. Needless to say that most of our users had a tendency to panic, and the first thought was to move into action immediately, and to just adjust the ledger manually. This would have taken a whole day, and it would have bound numerous resources.
So how do you convince a crowd not to just jump into action, but to first perform an analysis and a planning session? You remind them about the consequences if the quick fix doesn’t work. The reason we had been in this situation was that we overlooked something before; hence, I reminded them that we don’t want to do the same mistake twice. Obviously, not everyone agreed, but most users understood the importance of analyzing the error and planning the response. So we did our analysis and created a simple “project plan”. This was not an endless document, on the contrary, it was an email, but a structured one. The email had the following sections:
- Objective including a “business case”, which was the result of the error analysis
- List of Stakeholders
- Risks & Constraints
- Procurement (we concluded that we can fix the problem ourselves)
- A brief WBS
- Communications Plan
During this “crisis” planning phase we discovered a very simple method of fixing the error, so the fix was truly “quick” and required a lot less time and resources than the original quick fix. Once the fix was implemented, I produced a lessons learned document and adjusted our standard plan for procedures like this. By following the standard project management during a crisis situation, we had forced ourselves to think first and agree on the way forward. In our case, the analysis part revealed a better solution, but even if we would have had to manually correct the error, we would have brought everyone back into the boat.