People who have worked with me know that two of my biggest project principles are “No Surprises” and “No Rushing.”
Surprises are a sure sign of inadequate planning. When you do a project you have to anticipate what might go wrong as well as what might go right. Some of the things that can happen have a low probability, but you still have to develop at least a rough idea of what you’ll do when they occur. By planning for these surprises, you’ll eliminate — or at least reduce — the panic that’s human nature when these crazy things happen. Instead, when a “surprise” happens, you’ll just put in motion the contingency plan that you developed in advance.
Can you anticipate every possible surprise? No. But you should do enough contingency planning that true surprises are rare. When you do get a surprise, deal with it, then afterward ask yourself, “Could this have been anticipated? How can my planning process be changed to include the possibility of this sort of thing in the future?” Planning is an adaptive process: it gets better as you refine your technique to include the possibility of surprises.
Of course, it’s also possible to “overplan.” There’s a trade-off here: you need to do enough planning to prepare for all of the likely contingencies and most of the less likely ones, with maybe just a rough sketch of how you’ll deal with some of the unlikely contingencies. Then monitor the possible contingencies, and if some of the less likely ones become more likely, then beef up your plan for those areas. But overplanning can lead to overcomplexity, which in turn leads to a probable runaway project.
To me, rushing isn’t about speed — it’s about moving faster than your thinking. I’m all for speed: speed in decision-making, speed in planning, speed in implementation. But action without at least a little bit of thought is just reckless.
When you drive a car at night, you have to be careful not to overdrive your headlights — you have to stay at a speed low enough for you to stop your car in the distance your headlights illuminate ahead. I think there’s a parallel problem in projects: you have to move at a speed that allows you to make course corrections and to overcome obstacles, or you’re going to get a runaway project. Just as you drive slower at night on a curvy road, you should move slower in a project when there are a lot of unknowns and you’re feeling your way through. When you get through the slow patch, and you’re dealing with stable, known technology and a clear business direction, then you can move faster.
One of the biggest causes of project failure is doing the wrong project: putting a whole bunch of work toward a badly-defined objective. Rushing doesn’t get you a result faster if you have to throw things out and start over. So move at a slower pace when you’re getting things defined, pick up the pace when you know exactly where you’re going, and slow down again as you encounter roadblocks or obstacles.
Surprises and rushing are the sign of an inexperienced project manager. They can also come from an over-eager upper manager who is more interested in the appearance of action than in a good result. If you want to be successful as a project manager, then don’t let yourself be pushed into skipping planning steps and moving faster than you should on a project. Proper planning can save time and money on a project, even if the planning process seems overly time-consuming at the start.