MANAGE EXPECTATIONS

   

OK, you've built the model of your project using Steps 1 “4. You've built in contingency using Step 5a. Now you're ready to go to the powers that be, be it your boss or your customer, and tell him the answer. Typically, this is the point at which you announce the answer and your boss or customer does the equivalent of slapping their thigh and saying "you've got to be joking. It's going to be when? " Or "You want how many people?" And so on. I'm sure you've been there before; and, if not, if you've just joined this business, then it'll only be a short space of time before you will be.

So now what do you do? Well, for starters, let's be quite clear that the one thing you don't do is to agree to whatever he proposes. That is unless your model shows it is possible.

The way forward is conceptually simple. It may well, however, require plenty of guts on your part. Here's what you do.

The model shows one possible way that your project could work out. If you either (a) anticipate that the powers that be won't like that way, or (b) find out they don't like it when you tell them, then you can use the model to generate other possible scenarios. How do you this? Easy, by varying our four trusty parameters:

  • Functionality

  • Delivery date

  • Effort (cost)

  • Quality

So you might, for example, ask what the effect is of adding more people. Or see what (reduced functionality) can be achieved by the delivery date that Sales have already promised . Or see if you can get people to buy into an extension on the delivery date. Or you can try combinations of these. At all times you use the model you have developed to generate new possible scenarios “ think of them as flavors to the basic vanilla model. Using the model keeps you honest. It stops you from signing up for something that is patently impossible .

If you don't use the model “ if you merely succumb to pressure “ then you are doing precisely that. You are signing up for a mission impossible. You are opting for a quiet life now and trying to put out of your mind the certainty that a bomb is going to fall on you when the chickens come home to roost “ as they inevitably will, because your model says that they will.

The one thing you should not do in this game is to sign up for a mission impossible “ no matter how much and how severe the pressure that is applied to you. And, your model will act as your protection. Often, in the traditional way that this game is played , the negotiation becomes an emotive confrontation between two sides. Using the method we propose, it becomes a logical discussion of facts. The Roman writer Sallust said, ubi res adsunt, quid opus est verbis, "when the facts are at hand, what is the need of words?" People can be as emotive as they like in our version of the game and it doesn't matter. The models you develop will coldly and logically show what can and cannot be done. Hold your ground and ultimately the good guys should win.

Another stratagem that the powers that be may adopt will be to question your model, to try to chip away at the estimates contained in them. "It couldn't possibly take two weeks to do that," they will say, "you're overestimating everything here." Your answer to this is reasonableness itself. "They're only estimates," you will say, "so they're definitely not 100 percent right. They may indeed be too high." Pause for dramatic effect. "But they might also be too low. We don't actually know. We think there's a fair chance, because of the detail we've built in (via Step 2) that they're accurate, but they are only predictions . Why don't we run it for a couple of weeks and see how things turn out? Then, when we make our final decision, we've a better chance that it's the right one."

The key to all of this is discussion, negotiation, trying to keep the whole thing on a civilized level. Later in this chapter (see the application to software engineering section), we offer some additional tactics you can adopt to try to keep things on this civilized plane.

Ultimately, however, there may just be someone out there crazy enough to say "I don't care about models, figures or anything else. Just do it, or else." If that happens, you should take your courage in your hands and walk away from the whole thing. A glib statement, you may say, with mortgages to pay and families to support, but what's the alternative? The alternative is that somewhere down the line you're sitting in a blackened smoking ruin and you're being spotlighted as the person responsible for it all.

Come on, life is too short for that kind of unhappiness. And anyway, there are still enough unsuccessful projects out there that good project managers are still in demand. So let's just summarize the process:

  • Steps 1 “4 build the basic vanilla model

  • Step 5a adds contingency to the vanilla model

  • Step 5b creates a number of possible flavors of the model. It is one of these “ and only one of these “ that your boss or customer can buy

  • Once the boss or customer has chosen the one that he wants, this becomes the one that you try to make happen. This is the expectation you create

  • Finally, the chosen option is documented so that it is clear to everybody involved who signed up for what.

   


How To Run Successful Projects III. The Silver Bullet
How to Run Successful Projects III: The Silver Bullet (3rd Edition)
ISBN: 0201748061
EAN: 2147483647
Year: 2001
Pages: 176

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net