The Miniature Milestones practice is a fine-grain approach to project tracking and control that provides exceptional visibility into a project's status. It produces its rapid-development benefit by virtually eliminating the risk of uncontrolled, undetected schedule slippage. It can be used on business, shrink-wrap, and systems software projects, and it can be used throughout the development cycle. Keys to success include overcoming resistance of the people whose work will be managed with the practice and staying true to the practice's "miniature" nature.
Efficacy
Potential reduction from nominal schedule: | Fair |
Improvement in progress visibility: | Very Good |
Effect on schedule risk: | Decreased Risk |
Chance of first-time success: | Good |
Chance of long-term success: | Excellent |
Major Risks
None
Major Interactions and Trade-Offs
Especially well-suited to project recovery
Especially effective when combined with the Daily Build and Smoke Test practice
Works well with Evolutionary Prototyping, User-Interface Prototyping, Requirements Specification, and other hard-to-manage project activities
Trades increase in project-tracking effort for much greater status visibility and control
Imagine that you're a pioneer heading from the east coast to the west. Your journey is much too long to be completed in a single day, so you define a set of points that will mark the significant milestones on your journey. It's a 2500 mile journey, so you mark five milestones, each about 500 miles apart.
Major milestones 500 miles apart are great for setting long-term direction, but they are lousy for figuring out where to go each day—especially when you're traveling only, say, 25 miles per day. For that, you need finer-grain control. If you know that your big milestone is 500 miles away, north-by-northwest, you can take a compass reading, find a closer landmark that's roughly north-by-northwest, and then strike out toward that. Once you reach that closer landmark, you take another compass reading, find another landmark, and strike out again.
The close landmarks that you pick—the tree, rock formation, river, or hilltop—serve as your miniature milestones. Reaching the miniature milestones provides you with a steady sense of accomplishment. Since you pick only milestones that are between you and your next big milestone, reaching the miniature milestone also gives you confidence that you will eventually reach your larger objective.
Miniature Milestones' support for rapid development boils down to four factors: improved status visibility, fine-grain control, improved motivation, and reduced schedule risk.
Improved status visibility. One of the most common problems on software-development projects is that neither developers, project leaders, managers, nor customers are able to assess the project's status accurately. Say nothing about whether they can predict when the project will be done, they don't even know how much they've already completed!
Jim McCarthy cautions against letting a developer "go dark" (McCarthy 1995a). You believe that everything's going along OK. Why? Because every day you ask your developers, "How's it going?" They say, "Fine." And then one day you ask, "How's it going?" And they say, "Um, we're going to be about 6 months late." Wow! They slipped 6 months in 1 day! How did that happen? It happened because they were "working in the dark"—neither you nor they had enough light on their work to know that they had been slipping all along.
With Miniature Milestones, you define a set of targets that you have to meet on a near-daily basis. If you start missing milestones, your schedule isn't realistic. Since your milestones are fine-grained, you will find out early that you have a problem. That gives you an early opportunity to recalibrate your schedule, adjust your plan, and move on.
Fine-grain control. In Roger's Version, John Updike describes a diet plan in which a woman weighs herself every Monday morning. She is a small woman, and she wants to weigh less than 100 pounds. If on Monday morning she finds that she weighs more than 100 pounds, she eats only carrots and celery until she again weighs less than 100 pounds. She reasons that she can't gain more than 1 or 2 pounds in a week, and if she doesn't gain more than 1 or 2 pounds, she certainly won't gain 10 or 20. With her approach, her weight will always stay close to where she wants it to be.
How does a project get to be a year late? One day at a time. | ||
| --Frederick P. Brooks, Jr. | ||
The Miniature Milestone practice applies this same idea to software development, and it's based on the idea that if your project never gets behind schedule by more than a day or so, it is logically impossible for it to get behind schedule by a week or a month or more.
Milestones also help to keep people on track. Without short-term milestones, it is too easy to lose sight of the big picture. People spend time on detours that seem interesting or productive in some vague sense but that fail to move the project forward. With larger-grain tracking, developers get off schedule by a few days or a week, and they stop paying attention to it.
With Miniature Milestones, everyone has to meet their targets every day or two. If you meet most of your milestones just by working a full day—and meet the rest by working an extra full day—you will meet the overall, big milestones as well as the little ones. There's no opportunity for error to creep in.
Improved motivation. Achievement is the strongest motivator for software developers, and anything that supports achievement or makes progress more palpable will improve motivation. Miniature Milestones make progress exceptionally tangible.
CROSS-REFERENCE
For more on developer motivations, see Chapter 11, Chapter 11.
Reduced schedule risk. One of the best ways to reduce schedule risk is to break large, poorly defined tasks into smaller ones. When creating an estimate, developers and managers tend to concentrate on the tasks they understand best and to shrug off the tasks they understand least. The frequent result is that a 1-week "DBMS interface" job can turn out to take an unexpected 6 weeks because no one ever looked at the job carefully. Miniature Milestones address the risk by eliminating large schedule blobs entirely.
CROSS-REFERENCE
For more on detailed estimation, see "Estimate at a low level of detail" in Size Estimation.
You can apply the Miniature Milestones practice throughout the life of a project. You can apply it to early activities such as Requirements Specification and Evolutionary Prototyping; in fact, it is particularly useful in focusing those hard-to-direct activities.
For maximum benefit, the Miniature Milestones practice will be implemented at the project level by the technical lead or manager, whichever is appropriate. But individual contributors can implement it on a personal level even if their leaders don't.
The amount of detail required when implementing Miniature Milestones will give pause to whoever has responsibility for tracking those details, especially on large projects. But large projects are the projects that most commonly spin out of control, and it is on those projects that this kind of detailed tracking is especially needed.
Initiate Miniature Milestones early or in response to a crisis. Miniature Milestones provide a high degree of project control. Set them up early in the project or in response to an acknowledged crisis. If you set them up at other times, you run the risk of seeming Draconian. As with other aspects of project control, it's easier to overcontrol in the beginning and relax control as the project progresses than it is the other way around. As Barry Boehm and Rony Ross say, "Hard-soft works better than soft-hard" (Boehm and Ross 1989).
CROSS-REFERENCE
For more on initiating new measures in response to a crisis, see Timing in Recovery Plan.
Have developers create their own mini milestones. Some developers will view Miniature Milestones as micro-management, and, actually, they'll be right. It is micro-management. More specifically, it's micro project-tracking. However, not all micro-management is bad. The micro-management that developers resist is micro-management of the details of how they do their jobs.
If you let people define their own miniature milestones, you allow them to control the details of their jobs. All you're asking is that they tell you what the details are, which improves buy-in and avoids seeming like micro-management. Some people don't understand the details of their jobs, and those people will feel threatened by this practice. If you handle their objections diplomatically, learning to work to a miniature-milestone schedule will serve as an educational experience for them.
Keep milestones miniature. Make mini milestones that are achievable in 1 or 2 days. There's nothing magical about this size limit, but it's important that anyone who misses a milestone can catch up quickly. If people have done generally good jobs of estimating their work, they should be able to catch up on any particular missed milestone by working overtime for 1 or 2 days.
Another reason to keep milestones small is to reduce the number of places that unforeseen work can hide. Developers tend to view a week or weekend as an infinite amount of time—they can accomplish anything. They don't think about exactly what's involved in creating the "data conversion module," and that's why the job takes 2 weeks instead of the estimated one weekend. But most developers won't commit to tackling a problem in 1 or 2 days unless they understand what it involves.
To be sure you're basing your schedule on meaningful estimates, insist on further decomposing tasks that are above the "infinite amount of time" threshold for your environment.
Make milestones binary. Define milestones so that they are either done or not. The only two statuses are "done" and "not done." Percentages are not used. As soon as people are allowed to report that they are "90 percent done," the milestones lose their ability to contribute to a clear view of project progress.
Some people can't resist the temptation to fudge their status reporting with Miniature Milestones. "Are you done?" you ask. "Sure!" they say. "Are you 100 percent done?" you ask. "Well, uh, I'm 99 percent done!" they say. "What do you mean, `99 percent done'?" you ask. And they say, "Uh, I mean that I still need to compile and test and debug the module, but I've got it written!"
CROSS-REFERENCE
For another example of this, see "Track schedule progress meticulously" in Recovery Plan.
Be fanatic about interpreting milestones strictly.
Make the set of milestones exhaustive. Be sure that your list of milestones includes every task needed to release your product. The most common source of software estimation errors is omitting necessary tasks (van Genuchten 1991). Do not allow developers to keep a list of "off schedule" work in their heads; little "cleanup" tasks can add up fast. Such work can accumulate to a mass capable of sinking a project. Insist that every task be on the milestone list. When you mark the last milestone as complete, your project should be done, and you should be able to fold up the tents and go home. (Actually, folding up the tents should be on the milestone list too!)
Use Miniature Milestones for short-term (but not long-term) planning. The Miniature Milestones practice is appropriate for tracking short-term progress toward a larger goal. Mini milestones are the trees, rock formations, rivers, and hilltops that you travel to next. Don't overdrive your headlights. It is usually not practical or even possible to create a detailed milestone list for an entire project at the beginning of the project. You simply don't know enough before design is complete, for example, to be able to create mini milestones for construction.
CROSS-REFERENCE
For more on the way that visibility improves as a project progresses, see The Software-Estimation Story, "The Software- Estimation Story."
Keep the pioneer metaphor in mind. Periodically you want to find a vantage point that allows you to survey the surrounding terrain. That's what larger milestones are for. In defining mini milestones, you are planning out the route toward the next major landmark. You only map out a detailed route for the part of the terrain that you can see from your current vantage point.
Regularly assess progress and recalibrate or replan. One of the main advantages of using the Miniature Milestones practice is that it allows you to make frequent comparisons between your estimates and your actual progress. You can recalibrate your estimates based on your actual progress, and you can improve your estimating skills in short order.
If you find that you are missing milestones frequently, stop trying to catch up. You will get further behind. You have only two choices: (1) You can recalibrate your schedule, multiplying the rest of your schedule by the size of the schedule slip so far; (2) You can take corrective action to get back on schedule, which might consist of trimming the product's feature set, clearing away distractions so the developers can focus better, reassigning parts of the project to developers who seem to be meeting their milestones easily, and so on.
CROSS-REFERENCE
For more on recalibrating estimates, see Recalibration in Further Reading.
If a developer has kept to a schedule only by working extraordinary amounts of overtime, recalibrate that developer's schedule. That developer does not have any schedule cushion, and any task that's been underestimated more severely than the rest will blow the schedule out of the water. You also need to give that developer enough time to quit making rushed, stupid decisions that ultimately make the project take longer. Recalibrate the schedule so that it can be met by working normal, 8-hour days.
CROSS-REFERENCE
For more on the hazards of too much schedule pressure, see Overly Optimistic Scheduling, Overly Optimistic Scheduling.
If after recalibration you find that some milestones have grown to more than 1 or 2 days in size, have the developer break those milestones into smaller milestones and reestimate them.
When you recalibrate several developers' schedules, you'll probably find that some developers' schedules become longer than others. If those differences are large, shift some of their work around so that it comes out more evenly.