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.

Related

• Instagantt, cloud based,
  has free tier, gantt charting
• PMI/PMP
• SDLC
• Agile/Scrum
• Watson Glaser
• Microsoft Project
• Fast Track
• Open Workbench