This article focuses
primary on planning for software development projects.
- Software Development phases
- Design Specification
functional requirements, external interfaces, internal design
- Development Tasks
assign ownership of development to key resources, plan for
resource conflicts and task dependencies
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.
| - Vendors of project management software
|
