IT Project Management: On Track from Start to Finish, Third Edition

Based on the size of your project, your project plans will vary. The project plan is not one big plan, but rather a collection of plans that detail how different conditions, scenarios, and actions will be managed. It is a formal document that is reviewed and, hopefully, approved by management. The project plan is not a novel that tells the story of how the project will move along, but rather a guide that allows for changes to the project plan as more details become available.

While the project plan may evolve , there are some elements within the project that generally do not change ”or are protected from change. Of course, the foundation of the project is the project scope. Recall that the project scope is all of the required work ”and only the required work ”to complete the project objectives. The scope statement defines what the project will and won t accomplish. Once the project scope statement has been agreed upon, your change control system protects it.

Other elements of the project plan that should be immune to change are the project charter and the performance baselines. The project charter authorizes the project. It is a formal document that allows the project manager to manage the project work, resources, and schedule to deliver on the project scope. Performance baselines are time, cost, scope, and quality metrics that the project manager must meet within the project delivery. These baselines rarely change as they reflect the scope of the project. In other words, you re supposed to have enough time, budget, and obtainable quality metrics to meet the requirements of the project.

Project Plan Elements

When you and your project team create the elements of the project plan, you can start from scratch and build your plan or you can rely on historical information to lend a hand. Many times, project managers will find that their projects are similar, or even identical, to past projects they ve completed. Rather than reinventing the project management wheel, they ll rely on past project plans to serve as templates for their current projects. There s nothing wrong with this approach at all ”it s just working smart, not hard. Of course, when you use older plans as templates you ll update the older plan to reflect your current project.

Regardless of which approach you take to building your project plan, there are some common elements you should have for each one:

• Project charter This document comes from someone in a supervisory position that is higher in the organizational flowchart than the immediate management of the project team. This document authorizes the project.

• Scope statement This document is written to clearly define the project objectives for scope, schedule, cost, and quality. It also defines what will be delivered and what won t be delivered as part of the project. The project requirements help define the scope statement. This important document is the foundation for all future project decisions as it helps determine if requests , actions, or project work results are in or out of scope.

• Work Breakdown Structure The WBS is a deliverables-orientated decomposition of the project. The project components are decomposed to work packages, which are the smallest, most manageable elements within the structure.

• Time and cost estimates for each work package Recall that cost and time estimates reflect the labor and materials needed to deliver the project. This section of the project plan will also detail how the estimate was derived, the degree of confidence in the estimate, and any assumptions associated with the estimates.

• Performance measurement baselines These baselines are boundaries or targets the project manager and the project team are expected to perform within. For example, the cost baseline may predict the amount of budget that should be spent by a given milestone with an allowable variance.

• Milestones and target dates for the milestones Within your project there should be easily identified milestones that signal you are moving toward project completion. Associated with these major milestones are some target dates that you and management agree on. This allows you and management to plan on resource utilization, and adjunct processes within your business, and keeps all stakeholders informed ”of where the project should be heading ” and when.

• Required staff and their availability and costs There may be portions of your project plan that require procured resources or temporary specialized resources to complete a portion of the project work. The required personnel should be identified, their availability determined, and their associated costs documented.

• Risk Management Plan All projects have some degree of risk. This plan addresses the risks within your project, documents the assumptions and constraints of the project, and details how each risk is managed.

• Open issues There will often be open issues and pending decisions as the plan is first created. This section of the plan identifies and documents the issues to be determined and allows the project to continue. Of course, the decisions and issues in this section of the project plan should be addressed accordingly , which may cause other areas of the project plan to be updated.

• Supporting details The supporting details are any relevant documentation that influenced your project decisions, any technical documentation, and any relevant standards the project will operate under.

Adding Subsidiary Plans

While your project should have all the elements of the preceding section, there are additional plans that your project may warrant or your organization may require. As with the required elements in a project plan, you can use a project template for these subsidiary plans.

• Scope Management Plan This plan details how the project scope will be protected from change, where changes to the scope may be permitted, and how the management of approved changes will be handled.

• Schedule Management Plan Once the schedule has been created, which we ll discuss in a moment, the schedule management plan details how changes to the schedule may be allowed. This plan also details how the actual changes themselves will be managed and how the changes may affect other areas of the project.

• Cost Management Plan This plan details how changes to costs within the project will be managed and the procedure to report and document cost changes.

• Quality Management Plan This plan details the expected level of quality for the project and how the project must map to the quality expectations of the performing organization. This plan addresses any quality program your organization may participate in, such as ISO 9000 or Six Sigma, and how your project must operate within those requirements.

• Staffing Management Plan Your project may not require the project team members to be on the project for the duration of the project schedule. This subsidiary project plan determines how project team members will be brought onto, and released from, the project.

• Communications Management Plan This important plan details the expectations and requirements for communication across the project team, management, and stakeholders. It details the communication processes, forms, standard meetings, and any other pertinent communication management.

• Risk Management Plan This plan identifies the risks within the project, their probability and impact on the project objectives, and how they should be managed. The Risk Response Plan also includes risk owners, their responsibilities as risk owners , and what actions the project team will take if risk events are coming into fruition. This plan also includes contingency and fallback plans.

• Procurement Management Plan Projects often need to procure resources and materials. This plan details the procurement process and how it is managed according to the organizational policies of your company.