February 27, 2007 – Deliverable-based Project Schedules: Part 3

[NOTE: For more information, please sign the Guest Book.]

I teach an intermediate level MS Project class that focuses on building a deliverable-based schedule. This concept is foreign to many project managers. They tend to develop and use the schedule solely as a checklist, which is unfortunate because they miss out on both the scheduling capabilities and the reporting information available from the tool. In this next section walks through creating a schedule that will set your project up for success.

Creating the Schedule. There is a certain order to the creation of the schedule. The steps are Enter All Tasks, Determine Predecessors, Estimate the Work, Estimate Duration, Assign Resources and Add Constraints.

But before you begin putting tasks to schedule you need to decide the most appropriate way to lay out your schedule. The answer to this depends on what your reporting needs are. Set the schedule up so that it minimizes the effort needed to extract the information for status and other reporting.

The two main ways to put a deliverable-based project schedule together are (1) by Phase or (2) by Product. You can set up your schedule to switch between the two but it is far too complicated for this venue.

Phase structured schedules follow a standard development lifecycle (Requirements, Analysis, Development, Testing, UAT, Implementation and Support) and divide the main deliverables into pieces that are accomplished in each phase. From our example of the new Home Page, the deliverable for Section 1 would have requirements, analysis, development, testing and implementation. These pieces would be combined for each of the deliverables and called out in each phase. So the Requirements Phase would produce a Requirements Document that would have a part describing the needs of Section 1. The Requirements Document would, in fact, be a separate deliverable as would the Technical Design Document, Test Plans and other combined efforts.

Product structured schedules are strictly set up based on the deliverables identified in the WBS. Each deliverable would be self-contained with Requirements, Development, etc. baked into it. This method is also useful if the deliverables are really unrelated and have no overlapping phases. A simplistic example of this would be scheduling a conference. There are many aspects (ex. Location, Entertainment, Speakers, Catering) that run parallel and are self contained. Each of these deliverables would have milestones along the way to track progress against.
So, although it is tempting to start typing tasks down, it helps to take a look at the structure before you add the substance.