Hold That Decision

in how successful projects satisfy their customers and users. When a decision can be deferred without hurting a project, we should do so. The decision should be deferred until we have learned more so that we avoid making a mistake. A few years ago I was involved in a project that rushed to make a decision about its user interface. We knew we needed to make a decision someday and thought today might as well be the day. We discussed the issue too briefly and decided that a browser-based application would be best. Were we ever wrong! The details of the situation aren't important except that we could have easily deferred that decision while gathering additional marketing information that might have saved us from making a mistake.

The knowledge we can gain on a project comes in two forms: knowledge about the product and knowledge about the project. Knowledge about the product provides insight into what the product should be, the features it should include (or not include), the likely customers and users, when the product should be released, the price of the product, and so on. We gain this type of knowledge by involving users in discussions about features, by frequently demonstrating the latest changes, by refining the product in small increments and getting feedback, by letting users get their hands on working software as often as they'll take it from us, and other similar techniques.

Knowledge about the project educates us about our technology choices, how well our engineering practices are working, the quality level of the code being produced, how individual team members are meshing, our rate of progress through the list of desired functionality, and more. We get this type of knowledge by working in short iterations with frequent deliverables, targeting frequent zero-defect milestones and seeing what it takes to meet them, by examining and measuring the team's progress, and by observing how well team members collaborate.

Without these areas of knowledge we cannot possibly hope to prioritize work in any meaningful manner. And because this knowledge is created while the project progresses we should defer any decisions that can be deferred until we know more. In fact, the amount of learning that will be generated by developing a feature needs to be an important factor in determining the priority of developing that feature.

There has long been debate about whether projects should prioritize based on risk (as advocated by Barry Above's spiral model) or based on immediate value to the organization, which Tom Gilb referred to as the "juicy bits." There is no single winning factor in that debate. Both risk and value to the organization are important. However, to risk and business value we also need to add the amount and significance of new knowledge that will be generated by developing a particular feature. Only by considering all three dimensions can project teams make proper prioritization and sequencing decisions.