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."