A Case for a "Deliverables Driven" Approach By Russ Finney Many system builders consider formal project deliverables to be a complete waste of time. They give the following reasons for holding this opinion: * Why produce something which will just eventually change and become out-of-date anyway? * Producing formal documents takes time away from the really important task: programming the system. * I like to leave my options open through each phase of the process, and producing a document may commit me to something which was wrong in the first place. * If it is not written down, I can't be held accountable for it （ and the way things go around here - you have to cover yourself every way possible!). Reasons for taking a deliverables based approach: * It forces decision making and issue resolution. * It creates tangible deadlines. * It encourages information completeness. * It provides a mechanism for feedback to the developers. * It records the state of the project at a moment in time. * It gives the team members a sense of accomplishment. Tom Demarco in his book, Controlling Software Projects, discusses the impact that a deliverables based approach should have on a manager's project planning and control philosophy. As a part of this discussion he refers to the Cardinal Rule of Project Modeling: * A project activity is defined by its deliverable. * There is one activity per deliverable. * The only work charged against that activity is work spent producing that deliverable. * The activity is complete when the deliverable is delivered and accepted. Deliverable-oriented project modeling may yield some overly large activities, at least by the arbitrary standards of common project control systems. But further dividing those activities into components that produce no discernible product is to invest precious effort into an illusion of detailed planning. Fred Brooks in his classic book, The Mythical Man-Month gives even greater insight into the value of taking a deliverables based approach: "Why Have Formal Documents? First, writing the decisions down is essential. Only when one writes do the gaps appear and the inconsistencies protrude. The act of writing turns out to require hundreds of mini-decisions, and it is the existence of these that distinguishes clear, exact policies from fuzzy ones. Second, the documents will communicate the decisions to others. The manager will be continually amazed that policies he took for common knowledge are totally unknown by some member of his team. Since his fundamental job is to keep everybody going in the same direction, his chief daily task will be communication, not decision-making, and his documents will immensely lighten this load. Finally, a manager's documents give him a data base and checklist. By reviewing them periodically he sees where he is, and he sees what changes of emphasis or shifts in direction are needed."
