Chapter9.Trade-Offs

Chapter 9. Trade-Offs

The biggest problem every project manager faces is explaining to his team members how they are going to get all that work done with the ridiculous deadline they have facing them. The same developers who were wildly optimistic ("No problem!") during the exploratory phases of the project suddenly become glum, even sullen, when management says, "Go ahead." The problem, of course, is that management always wants more. Yesterday.

As well they should. For if management doesn't set the bar high, they know they will get even less. The problem is that most software development managers take the following point of view: "Yeah, it's a stretch, but it's a good team. With a little bit of luck, we should be able to pull it off. And, so long as we come close, we'll be OK." The developers, on the other hand, know better. They know that lots of things will go wrong; people will quit, suppliers of critical components will fold their tents in the middle of the night and disappear, and so on. The emerging system will inevitably be too slow compared to the prototype. Things will just bog down.

Management, on the other hand, has a "contract view" of the situation. They have opened the corporate vault and funded this project. Elevendy-seven weeks later, to the minute, they expect a software product to be on the loading dock. When the product is late, all hell will break loose, because many other wheels have been set in motion that critically depend on this one deliverable.

How do we get this level of disconnect, and how does it happen over and over again? I have watched this scenario play out for the last 40 years or so. It is as though we never learn. The simple fact is this: We try to do too much in too little time. All our other problems stem from that fundamental error.

The software development manager is the person who always gets caught in the middle. He is the one who gambled on the "slightly optimistic" estimate and schedule which, having no margin for error, was doomed from the start. He is squeezed between his developers, who feel as though they have been signed up for yet another death march, and his management, who can't understand why these things are always late. Sometimes, in an effort to save the bacon, he agrees to ship a product roughly on time, with the usual consequences: the product is buggy, the customers are unhappy, and the support organization is badly overloaded answering the phones.

There are only two fundamentals every software development manager needs to keep in the forefront of his brain at all times. The first is scope management. If you cannot control the scope of what is being developed, you are destined to fail; "feature creep" will kill you every time. The second is the primacy of time. Of all the things that affect the outcome, time is the one that governs all else. After that, everything else is a question of trade-offs.