(fredness), October 24, 2000 - updated May, 2002
This article focuses primary on planning for software development projects.
It is important to generate a Design Specification document before actual development starts. This document is important because it allows marketing and engineering to have a common reference point, Engineering can use the document as a guide to decide what specific development to undertake. Marketing and other teams can use the document for setting expectations for product capabilities and preparing plans for how to best launch the product.
It is important to not itemize too many tasks in a schedule. The details should be relegated to the Design Specification. Schedule tasks need only describe an accomplishment in general terms. It is a good idea to keep the number of tasks limited to as few as possible. A particular person or resource should not have more than a few tasks overlapping. If you keep the tasks as few as possible and minimize resource overlap the schedule will be easy to read and edit. Furthermore, the schedule is an aid to development, not a micro management tool to drive development. If more detail is needed about a certain task then simply consult either the design specification or the assigned resource for more information. A schedule filled with overly detailed implementation steps makes it unnecessarily unwieldy to update. If the document is too unwieldy it becomes a dead document. Software development without an actively updated schedule quickly degenerate into rudderless ineffectual effort.
The software development schedule should intimate the development effort not overstate it. A schedule can never obviate the need for a project manager with sufficient experience, skill, and flexibility to fine-tune the schedule during development. By definition software development is an attempt to codify functionality that has never been codified before (otherwise it would already exist as an application). A proficient project manager knows this and will always have ideal, probable, and worst case completion paths to hedge against inevitable unknowns that are endemic to software development (The Mythical Man Month by Frederick P. Brooks, Jr.).
Too much task linking is a sign of a schedule with too much detail. Schedules are the most useful when there is a lot of parallel/concurrent activity going on. Where linking is most useful is when several tasks complete and allow the start of another single task and visa versa. One to many, or many to one is the best reason to use a link. Linking a single independent task to another single independent task should be a sign that the a summary task should be used instead of the two linked tasks. One exception to this might be a single task that requires one resource being linked to a second single task that requires a different resource. In this case a single task with both resources assigned may be too general for resource allocation to normalize optimally.
Followups, Comments, ...
Raul Rodriguez, Santa Clara University
Tue Mar 18, 2008 10:15 pm (PDT)
I'm a program manager at Microsoft, but here's what a friend is product management had to say about the difference in product management and product planning: "product planning is ideally supposed to keep tabs on whether the features planned for the releases are in line with the overall strategy of the product. product mgmt ideally decides the product strategy from marketing perspective. program mgmt drives the feasibility of a technical featureset, which is used by planning to see whether it matches the overall direction set by prod mgmt. this division can easily be blurried and it totally depends on what group and also the personalities of the three different peers."