By Preben Ormen
A lot of projects are launched with plans based on essentially arbitrary deadlines. By arbitrary deadlines I mean the finish dates were set by decree, which may or may not have been accompanied by a rigorous feasibility analysis of the plan dates themselves. This may sound bad, but arbitrary deadlines can be your friend.
Quite often, the process is as simple as someone saying that, OK – I get we need this so have it in by X date. The X-date could be end of the year, end of the quarter or some other date that has meaning to the executive irrespective of what the project actually require. System implementations are commonly in this camp.
If you were to do a Monte Carlo simulation for such a project, you would find the plan has little or no theoretical chance of actually meeting the target. Yet, lots of these projects still do. So what’s going on?
The main thing that’s going on is that active project and risk management causes intervention at every twist and turn so that very little is actually left to chance. This means that the probabilities you assigned to the simulation just became totally irrelevant. You have moved out of a random universe and into something entirely more deterministic.
What you are then left with are true uncertainties – all the things that you do not know and that are essentially unforeseeable. In shorter projects, say 3-6 months, these are usually a lot less of a concern than for, say, multiyear projects.
The nice thing about totally unexpected events is that they are usually not all that hard to negotiate around to get budget or time extensions.
Of course, things get murkier, harder and a whole lot less clear as projects increase in size and complexity. There are risk models like Shenhar and Dvir’s Diamond Model that go a long way to help you find a suitable management model to go with the project risk and uncertainty profile.
This is important because my whole point here is that we are not complete and helpless hostages to risk, even though we may end up hapless victims of uncertainty.
For uncertainty, the main management tool is to plan for robustness and preserving options for making changes underway.
Here’s how this works in a nutshell (well, make it a coconut shell).
You can’t predict the future exactly, but you can have an opinion about the two or three most likely directions the future may take you. So make a choice and start with one option in mind, but have exit strategies to change gears if anything important shifts. Then monitor your internal and external operating environments and confirm what direction you’re actually trending towards. Now you can make a decision about whether to continue or to adjust.
While we can argue about ways to plan more perfectly, it is important to understand that you can’t plan for uncertainties. You have to go with work-arounds like most likely scenarios.
Once you start thinking about this, you will realize that very few projects are ever allowed to run according to probabilities. The reality is massive intervention whenever possible to nip delays in the bud and pull things back on track.
Monte Carlo simulations can help identify the effects of the risks (i.e., probabilities) you assign throughout the project plan, but this should only be a first step. After that analysis, you can create a plan with the hard deadlines you think are most appropriate and use intervention to mange and reduce risk from there on.
Every project needs a target date. I am usually in favour of making that deadline as early as possible, because it creates a sense of urgency and protects against unnecessary slippages cause dby people thinking they have lots of time, starting later than they should, wasting the slack and then running into problems that make you late.
This sequence is the cause of most slippages because you never get any early finishes and get hit with a delay from almost every problem due to the late start and wasted slack.
Arbitrary deadlines protected beyond reason are usually very bad all around. These are the kinds of projects that go down in the lore as ‘death marches’ or ‘Siberian salt mines.’ They invariably come in at a high cost in terms of money and grief, even though it’s not uncommon for much of that money and grief to be expended only well after the project is officially over.
It’s not for nothing that seasoned project managers will say (only half in jest) that the first estimate is usually the most accurate.
The subsequent polishing to fit personal, internal or external political agendas often just cuts schedule without addressing any of the underlying fundamentals that drove the estimate in the first place. This makes for a bad arbitrary deadline.
If, on the other hand, the fundamentals are addressed and off-ramps and switching criteria are laid out, the still somewhat arbitrary deadline can be quite useful to minimize overall cost and slippage.
Preben Ormen has over 35 years experience with a wide range of businesses, teams and cultures from around the world. He has experience in SAP, IT Governance, procurement, system selection and integration, and performance and process improvements. You can read more from Preben on his blog, you can follow him on Twitter, and you can contact him via LinkedIn.
Powered by Facebook Comments