Complex IT Project Management: 16 Steps to Success

6.12 Pulling it all Together

Now you can turn on the computer and launch your project planning application. That seemingly innocuous move has been discouraged to this point because the preparatory work is critical and best done manually. Also, I have never been convinced that these automated tools are all that intuitive. Having said that, it is now time to talk about how to use the tool to get your plan documented and ready to use as a management aid as the project progresses. To summarize our scheduling accomplishments thus far:

• We have identified the master project's critical path, which consists of roughly 6 to 12 milestones.

• Each milestone has a fixed date and a finite number of contributing events that are important to us.

• We have become familiar with subteam key tasks that we choose to document and track, whether or not these events contribute directly to the master project critical path. Examples of these would be risk-sensitive events or key subteam dependencies.

Many excellent books are available regarding use of the popular scheduling applications, so the only value I can add is the following remarks. These tools are excellent for documenting tasks and tracking progress, as long as you do not make them too comprehensive or take the process too literally. This is not so much to disparage the excellent products out there as it is to say that it is virtually impossible to use all their powers in a complex project. Quite frankly, if you are adept at doing things such as "date math" in spreadsheets, those tools can be equally useful for plotting out the tasks once you have followed the process espoused in this chapter.

I personally find the Gantt tool most useful for validating assumptions about durations and dependencies, as long as I restrict the work to the milestones and down only two or three levels from there. In general, these programs work best when a project has a lot of sequenced, repetitive tasks not unlike the manufacturing environment where a "cookie cutter" process (i.e., repeated over and over) is used. Server upgrades, relocations, and large wiring or infrastructure upgrade projects are best suited for these types of programs. Projects that have a plethora of "one-off," seldom repeated, and largely unlinked deliverables are not so well suited, particularly if you choose to capture and track a lot of scheduling detail. In the final analysis, however, it is a matter of what works for you. As long as you follow the scheduling process outlined in this chapter and use any applications as documentation tools instead of planning tools, you will find that the focus on manual work can lead to superior results.