Ever been asked in the hallway for a "rough estimate" of how long it might take you to finish a particular bit of software? (Other phrases might be "wild guess" or "pull a number out of your ...") Did you throw out a certain number of weeks or months? Did this number later appear on multiple versions of a development schedule? Were you later accused of missing a deadline because "you said you could do it in three weeks?" This is an example not of schedule negotiation, but of an ambush.
So that I can save time on long explanations in the hallway, here are some issues that must be discussed first.
According to Steve McConnell in "Rapid Development" and cited studies, your estimate of the product schedule is accurate within only a factor of four, AFTER you have an approved product definition. You drop to a factor of 1.5 only after you have a product design specification that details the implementation. In the hallway your estimate is worse. You aren't sure what you're being asked to build, and you don't know yet how you're going to build it.
Why do developers always underestimate development time? Because we are being asked to estimate the effort for one specific feature at a time. But features do not live in isolation. Features work together in a framework with many assumptions about what constitutes reasonable behavior. If you naively try to implement only features that are listed on paper, you will later hear questions like "Doesn't it dynamically update and save the results? Why can't I use this data in the other dialog? Of course that's required! Otherwise, what good is it?" We may be accurately estimating times for anticipated features, but we do not attempt to quantify times for unknown or implied features. Nor do we allow time to correct our original design. As soon as a feature is implemented, we realize the first specification was ambiguous and meant something different to everyone.
In short, the interaction between features increases your effort non-linearly as the number of features increases. Five interdependent features may need to be counted as fifteen new features, with extra work for each new interaction.
So let's assume we've figured out how to give a reasonable range of delivery times after having a product definition approved. We visualize all the known features. We try to quantify the magnitude of the implied features. We estimate a range of delivery dates within a factor of four, like 3-12 weeks or 2-8 months. We can't be more accurate at this point in our project without violating causality and other physical laws. We can imagine making the low estimate maybe 10% of the time. We can imagine making the high estimate 90% of the time. We're still in trouble.
According to "Death March" by Edward Yourdon, a typical software project now begins with a hard deadline and big expectations of what it can do. The deadline is the least flexible parameter. What about other parameters of features, staffing, and quality?
During early negotiations (and yes they are negotiations), your customers, management, and marketing are going to play hard-ball when it comes to features. Your product must do everything. No, they can't rank the features because they are all essential. So you put this parameter aside for the moment.
There might be some flexibility on the staffing. The company might be willing to throw money at your product manager. According to Yourdon, staffing follows some kind of inverse-square law. If you halve the amount of time for a project, you need to quadruple the number of programmers. The bigger the team, the longer it will take for them to work together well. Increasing staff shows diminishing returns. You can only add the developers early. According to "The Mythical Man Month" by Frederick Brooks, adding developers to a late project will delay the project further. Staffing is not easy to adjust, and staffing always has an upper limit.
Software quality, maintainability, robustness, stability, and usability, also can be degraded to improve your schedule -- to a point. If you overshoot your tolerance for poor software, you will also take too long to test and stabilize your product. Feature upgrades can be fatal. Better not push this parameter too far.
You can delude yourself. You can pretend that some magic silver-bullet technology will make you vastly more productive. You can pretend that your team walks on water, that 18-hour days can be sustained for months without burn-out, that the project will never change scope again. But let's assume you're not on drugs.
You have the classic inflexibility matrix. The few parameters you can adjust, staffing and quality, are also the riskiest. Given all your hard constraints, you may find that the outer bound of your estimate well exceeds the acceptable delivery date of the project. What can you do? You can try to refuse the assignment, but you probably missed that opportunity. The rules changed when you were not paying attention.
Yourdon recommends triage of features, against the wishes of your sponsors. Divide features into "must have," "should have," and "could have." Don't let too much fall into the "must" category. If your users and managers wanted everything in the "must" category, then it's their lost opportunity. You'll have to prioritize for them. Give unequal scores to these features, such as 9 points for "must," 3 for "should," and 1 for "could."
Try to identify components that allow you to implement these features. Components should be parts of development that can proceed independently. The more you sub-divide your components, the better you can scale your productivity with more developers. Set the score of a component to the sum of scores of features it supports. Try to appraise the difficulty of implementing and testing each component. Don't worry about high scores that are easy to implement, or low scores that are hard to implement. These will survive or die on their own.
When you start coding, begin with high scoring components that are hard to implement. These components represent the riskiest part of your development. Reduce your biggest risks quickly, and guarantee the most useful features. The last few panic-stricken weeks should be for easier components, not the riskiest ones. When you inevitably run out of time, you still might have something you can ship. Don't leave too much wasted code behind.
Of course you still need sensible development practices such as described in "Dynamics of Software Development" by Jim McCarthy. Nightly builds, source/configuration management, risk monitoring, and benchmarks are still important. You won't speed up your project by abandoning previous good practices.
In short, you probably can't negotiate your development schedule. But you can prepare your sponsors for reality. Don't make it easy for them to ignore realistic schedules. You must find flexibility somewhere, so prioritize features for them. Those who set your constraints will have to make hard decisions eventually. Most likely they'll prefer having fewer features rather than nothing. Or they'll decide extra features are worth a delay, after all.
This essay was written at a time when requirements were always imposed before development began. Extreme Programming insists instead on involving your clients in your triage of features. Short iterations allow users to see what you have done and adjust priorities accordingly. You must get your client to see the advantages of tracking your actual progress at all times, and of having the choice to change requirements at any time with minimal cost. On the other hand, they may still want the delusion of control in an upfront plan with an inflexibility matrix.
Start coding while your sponsors are waiting to launch the project, preparing presentations and strategic documents. According to Steve McConnell, this "fuzzy front end" wastes the greatest opportunity to improve the delivery date.
Insist that your sponsors describe WHAT problems they want solved, not necessarily HOW. It's your job to think of solutions they haven't. Users will often describe new features as variations of existing features. Ask questions that clarify the goal, not the mechanics of one particular solution.
During planning, you may be required to prepare "white papers" on technical decisions. The conclusions will be controversial, or your study wouldn't be necessary. Do not merely list the pros and cons of all alternatives. Organize your presentation around a recommendation. Address risks and compare alternatives. Emphasize information that helped you make a decision. If you prefer to avoid a decision, then say so. A neutral report, on the other hand, can be cherry picked and support any decision. Others will rely on an anecdote or gut feeling and claim you agree. After a study, you are qualified to draw your own conclusions. Do not delegate the last most important step.
Bill Harlan, 1999
Return to parent directory.