| Sooner or later in projects we have to commit. In doing this, we basically make a promise and then try to make that promise happen. If everything turns out as we predicted , then we are heroes; otherwise our name is mud. The first thing that should be said about committing is that you should try and leave it to as late as possible in the project. The longer you can get away with not having to make this promise, the better for all concerned . Each day that passes you find out more about the nature of the project, and all of these details, when fed into a model of your project, increase the likelihood that the promise you make will come true. Sooner or later, though, the fateful day will come and you will have to make the promise. It is both my belief and my experience that if you use the planning techniques described in Steps 1 “5, then there is a fair chance that the project will just run through to a successful completion. If so, then fair play to you and God bless us all. If this doesn't happen, however, if you find that you have eaten up all your contingency and that there is no way that your promise can now be met, then you've got to come clean. Our instinctive reaction is perhaps to do the opposite : to cover the whole thing up, pretend that nothing is wrong and hope it'll all be alright on the night. Not to put too fine a point on it, this is madness. Coming clean won't be pleasant. On my courses I liken it to exploding a 500 lb bomb around everybody. But again, what's the alternative? The alternative is that blackened smoking ruin we spoke of earlier. Think of it as exchanging a 500 lb bomb now for one of about 20 megatons later! So you come clean. You carry out Steps 1 “5 again. You make a new commitment, set a new expectation and off you go. Ultimately your conduct will be seen for what it was: professional project management. Some final thoughts on this subject. -
Know what your customer is expecting. What he is expecting will be based entirely on what you have led him to believe. Can you trim back from this without affecting him unduly? Sure you can. Check and see what he could actually put up with at a pinch . Be sure that your development schedule enables you to deliver this first. -
Build a number of demonstrations and/or prototypes into your schedule so that your customer can get her hands on the system early and you can verify that you have read her expectations correctly. -
See what is required to go beyond her expectations and plan to go there if at all possible “ that'll really wow her. But it will only wow her if you have given her all of what her basic expectations were. -
Don't spring surprises on your customer. Customers are very forgiving people once they are treated as intelligent human beings. It is only when they get the impression that you are not being straight with them that they react badly . -
Some things have no margin for error. Know which things on your project are like this, watch them like a hawk, and make sure they happen. -
A retreat to a fallback position need not be an ignominious thing; it can be presented as a master stroke of planning and forethought “ another example of managing expectations. CASE STUDY 6: MANAGE EXPECTATIONS Scott left England in a blaze of publicity. The British Empire was at its height. To any rational outside observer it was clear that the British would be first to the South Pole. Amundsen slipped quietly away, and it wasn't until he was long beyond anyone 's reach that his objective was made known to the world. If he failed, then he would disappear quietly into oblivion. If Scott failed, then it would be a very public failure. | CASE STUDY 7: ALLOW A MARGIN FOR ERROR Scott moved one ton of supplies out onto the path he would follow to the Pole. These depots were indicated by cairns of snow and single marker flags. Scott allowed just the amount of food and fuel that he needed. When at the last minute he switched the number of people in the Polar party from four to five, this put all his calculations awry. A hastily drawn up plan was put in place to offset this problem, but Scott and his companions were to die of starvation , scurvy (caused by vitamin deficiency) and exposure. Amundsen put four tons of supplies on his path. His depots were marked by sets of marker flags radiating out from the depot. Each marker flag had a note attached to it indicating the distance to, and direction of, the depot. On his return, Amundsen's men had put on weight and left two tons of food behind them in depots. | CASE STUDY 8: HAVE A FALLBACK POSITION We referred previously to the opening of the Battle of the Somme during the First World War, when the British launched an offensive which they hoped would end the war (Macdonald, 1983). The British commander's plan was admirable. Quite simply, he hoped to give his men a walkover. He would do this by submitting the Germans to the biggest artillery barrage of the war, or indeed of any war. It would last continuously for a week. At the end of that time, his men would quite literally walk across to what would remain of the German lines. Well, of course, there was no walkover. The German lines were very much intact and nearly 60,000 British soldiers were killed or wounded on that one day alone. Over 19,000 of them were killed , most of them in the first couple of hours of the battle. The British project plan was based on the premise that there would be a walkover. When that failed to materialize, there was no contingency plan. You are doing one of the most risky things imaginable if you take a project forward on the basis of no contingency plan, no fallback position. It's human nature: you tell somebody you're going to do something, you do it and they're pleased. You do more than what you said “ give them an added bonus “ and they're delighted . But fail to do what you said and your name is mud. Once you've made your plan you need to look at it and ask: -
What are people (you, the project team, your customer, your boss, your peers, the rest of your organization, people outside the organization) expecting to happen when the project completes? Can you deliver on what they are expecting? -
What if something goes wrong? Spend a while analyzing what can go wrong. Use brainstorming or some of the techniques discussed in Chapter 11, to see how well you are set up to deal with these eventualities. There are some things upon which you will have no margin for error, and these become crucial jobs for you. Many things, however, are less critical and you can perhaps live without them for a while. Identify the critical and less critical things. Do these cause people's expectations to be modified? -
Is there a fallback position? If something disastrous happens can you still save your skin and the project? If you can't then at least you go forward consciously knowing the risks you run; but often there are things you can do. | You should do this for the project as a whole and for each job in your job list. Try to categorize the risk associated with each job as high, medium or low. Then focus on the high-risk ones and make sure, if nothing else, that these have a margin for error and a fallback position. We have said that managing expectations, allowing a margin for error and having a fallback position are all facets of the same issue. There's an argument that says: -
define your goal -
identify a fallback position -
set expectations equal to the fallback position -
then your margin for error is everything between the fallback position and the real goal There is some merit in this approach. The big danger is that the fallback position now becomes the goal; so that you are still left with a situation where you have a goal and no fallback position. Here's a final example from history showing all three things “ manage expectations, allow a margin for error, have a fallback position “ as facets of the same issue. CASE STUDY 9 The "unsinkable" (expectation) Titanic was launched in 1912. She could carry 2,000 “ 2,500 passengers and crew and had lifeboat capacity for 1,100 (no margin for error). When she struck an iceberg on the night of April 14, 1912, over a thousand people lost their lives (no fallback position). | |
