Section 9.9. Summary

9.9. Summary

The project plan is your roadmap to success and in this chapter we stepped through creating the needed details that will help guide your project once work begins. The Work Breakdown Structure is one of the most key elements of any project plan because it delineates, in a very detailed manner, the work that must be done to accomplish the project's objectives. Some might argue that if you were only going to implement one project management process it would be the creation of the WBS and task details. The WBS defines the scope of the project. If work is not in the WBS, it's not in the project. The various task details including task owner, entry/exit criteria, and completion criteria round out the WBS and give you and your project team a very clear picture of the work to be accomplished. Remember that quality is managed, in part, through completion criteria (which may include quality metrics), so keep your quality plan front and center as you create your WBS.

The network diagram is a great way to help your project take shape and form. By using a network diagram, you can begin to chart out your critical path and identify potential scheduling problems. Most project management software programs will generate a network diagram automatically once you've entered your tasks based on your WBS. The network diagram is a useful way of sequencing your tasks as a precursor to creating your project schedule. Create your project schedule from your ideal or best-case sequence, not the other way around. Using both duration and float, you can create a more detailed network diagram that helps you see where you have opportunities to modify your sequence (or later, your schedule) to manage constraints.

The schedule must take into account resource conflicts and constraints at several levels, which is where having a project management software program can be quite helpful. You and the IT project team will have to evaluate these various constraints and make choices about how to sequence and schedule project tasks to meet the project's objectives, including deadlines and timelines. We introduced the concept of reserves, which are added at top-level phases or tasks, not to each individual task. It is important for a variety of reasons to add reserves rather than padding estimates, whether they are time or cost estimates. The most important reason is so you and your team have an accurate estimate, not a wild estimate based on everyone's individual padding methods.

The project budget is developed based on the cost of each task, which can be generated based on historical results or on calculations. Again, we used the concept of reserves to provide flexibility in the budget while maintaining clarity about costs. A cash flow projection is often needed (or required) and can help you and your company manage large project expenditures. Cost control measures should be put in place for a project of any size, but more attention should be given to this process if the project is long, complex, expensive, or if cost is the least flexible element of your project.

Identifying and managing project risks is an important undertaking and one that is often skipped in IT project management. Risks to the project as a whole or elements of the project (scope, time, cost, or quality) should be identified. These risks should be sorted according to two criteria: likelihood of occurrence and impact to the project. Using a weighted rating system may be helpful if there are numerous risks to be evaluated. The risks with both the highest likelihood of occurrence and the highest impact to the project should be evaluated. It's a bit of a judgment call as to where to draw the line, but that's where you, your IT project team, and your subject matter experts come in. Once the list of risks is defined, you and the team should identify alternatives. Alternatives provide you a means to either avoid the risk altogether or minimize it to an acceptable level. Sometimes alternatives that are identified in this step are great ideas that improve the overall project. Once risks and alternatives (also called mitigation strategies or contingency plans) are developed, you should identify triggers that allow you and your team to know, in no uncertain terms, when a risk has occurred and what steps should be taken. As the IT project manager, you can then respond to these "emergencies" with preconceived plans.

Also as part of your project planning, you should add detail to your communications plans. You should have developed communications plans as part of your project processes and procedures, but now that you have added project detail, you can modify your plan as needed. Ensuring that project information is communicated regularly and to the right people in the right way will help avoid rumors that tend to crop up with no real information is available.

The final project plan should be a comprehensive plan that includes all the work and detail we've discussed up to this point in the book. You should review project elements in light of the project detail created as a result of this planning phase. Check that the requirements match the scope and the WBS. Check that your processes and procedures are still adequate for the project. The finalized plan should be brought to the project sponsor for final approval prior to initiating project work. The project sponsor may want to make changes at this point, but if you've regularly brought portions of the project plan to the sponsor for review, discussion, and approval, there should be few, if any, changes at this point. Keep in mind that one possible outcome of this step is to have the project delayed, put on hold, or cancelled altogether. While disappointing, this does happen and it's better to have the project cancelled before project work commences than afterward. Finally, keeping a final copy of the project plan saved in a secure location can be helpful for later review. This establishes your baseline for the entire project and can be used to compare plan to actual. The "active" final project plan should be a living, breathing document that is updated as approved changes occur.