Finally, we have reached the last chapter dealing with project planning. Critical data is generated from all of the planning processes we discussed in the first six chapters, and you must be wondering-what do you do with this information and how to track it. This is where an overall planning document comes into play.
At this point in the project, you are almost ready to start the project execution phase, and all of the planning output needs to be organized in a way that creates a handbook you can use to lead the completion of the project work.
The planning data is integrated into one comprehensive planning document that contains output from all of the applicable planning processes we have covered so far: Initiation, Scope, Time, Cost, Human Resources, Quality, Communications, Risk, and Procurement.
A typical project plan contains several categories of components such as administrative, planning, templates and checklists, references, and an appendix, all of which we ll discuss in more detail in this chapter.
The development of a project plan is more than just taking all of your planning documents and putting them in a binder. The development of a meaningful project plan requires time and input from your sponsor, project team members , and other stakeholders. A detailed outline or table of contents (TOC) and organization of your planning documents around this outline or TOC are key elements to writing a plan.
Finally, the review, formal approval, and distribution of the project plan signifies the transition of the project from the planning phase into the execution phase.
As you have learned from previous chapters, the project planning process commences with initiation and includes processes from the entire Guide to the PMBOK knowledge areas. A comprehensive project plan is a document that integrates all planning data into one document that the project manager can be use as a guidebook for moving the project into the execution phase and overseeing the project. The project plan uses the output from the planning processes to create a consistent end-to-end document covering all project phases. The project plan is maintained and updated throughout the life of the project.
Creating a comprehensive project plan is a very important component of project planning that is often overlooked. It may not seem important that all of your planning data is organized into one central document, but without it you will find yourself constantly fielding questions regarding the project requiring you to search for the file on the project charter, the scope statement, the WBS, or some other planning document.
Further, a lot of important data is created during the planning process. If this data is not clearly organized and distributed to the right people, it will be of little value.
The purpose of a project plan extends beyond just a collection of project data, and there are also benefits from a high-quality plan you will realize during project execution and control.
Purpose The final step in the project planning phase produces a formal, approved document that is used to guide project execution and control. It provides the basis for performing and managing all project- related activities.
The project plan is the document you will use during project execution and control as the foundation to track the performance of your project and take any needed corrective action. It is used to communicate key information to the project stakeholders.
Benefits The project plan is a single source of information regarding all key elements of the projectavailable to everyone associated with the project.
The plan is a reference source that can clarify questions such as what is or is not included in the scope of the project, who the key stakeholders are, and what the major deliverables are, along with many others.
The project plan is a guidebook that can be used during project execution to focus team members , thus keeping the project on course.
To better understand what the comprehensive project plan is all about, lets take a look at the components you will find in a typical project plan.
The comprehensive project plan should bring together information obtained from all the various planning processes you ve undertaken in an organized, cohesive fashion. You can organize data in a number of ways to produce an integrated project plan. Many organizations use a standard template for project plans. Although the format and structure may vary, the key components of a project plan, as we mentioned in the chapter introduction, usually include (but are not limited to) the following:
No standard sequence drives the order of the project plan components. Both the components themselves and the component sequence vary between organizations, and an abbreviated version may be used for small projects.
If your organization has a program management office (PMO), there is probably a standard project plan template. If you do not have a template, you can use examples of project plans from previous projects to develop your particular plan. (You could try visiting well-known websites such as www.gantthead.com or www.techrepublic.com for project planning examples or simply do a Google search for project plan template ). Communicating your project plan is much easier if you are using a format people are familiar with.
It is a good idea to review carefully the contents of any planning template you are expected to complete to determine whether your planning activities to date have produced all of the data required in the document. You may find your team has additional work to do to provide all of the information required in the template.
Let s take a closer look at the components of a typical project plan.
A comprehensive project plan can be a very lengthy document. To facilitate ease of use and ensure that updates are properly tracked, a project plan may include the following administrative components:
Document Information This section contains information regarding the update and maintenance of the plan. A document history lists the version numbers and revision dates, and contact information to obtain copies of the document.
Table of Contents The table of contents displays how the information is organized, so that the reader can access a particular component. If you do not have a project plan template to follow, find examples from other projects in your organization. It is helpful to the people who will be referencing the plan to have the data in a recognizable sequence.
The planning components are the main body of the document, and they appear as sequenced in the table of contents. The components listed below are typical of how a project plan is organized, although it is always best to determine if you are expected to follow specific standards.
Executive Summary An executive summary is included to communicate with executives who are responsible for corporate business strategy or funding decisions, and any managers whose personnel the project will impact. It should contain high-level information written in nontechnical terms.
The executive summary typically starts with a brief project description that explains the business need or problem that generated the project request. It should include the overall goal of the project as it relates to corporate goals or strategies, the targeted completion date, and overall budget. The goal of the Executive Summary is to give busy executives a quick high-level overview of the project so they can be knowledgeable about what s going on. It does not go deep into the nuts and bolts of the project.
Requirements The requirements section lists the functional, technical, and business requirements for the project, as defined during project initiation.
Scope The project scope defines the boundaries of the project based on the deliverables agreed to by the client.
Remember, this section describes both what is included and excluded in the product being produced by the project.
Stakeholders The stakeholder component identifies the people responsible for the success of the project. This includes the sponsor, client(s), project manager, and project team members , as well as other work groups whose assistance is required to complete the project (such as vendors ).
There is debate among project managers as to the amount of detail to include in this section. For large projects that will last over six months, it may not be practical to list all of the project team members, as the baseline resource list you create during planning may change significantly multiple times over the course of the project. (For example, Kimmie may be the programmer initially, but she resigns to pursue writing a novel so you replace her with Susan.) Rather than constantly updating the project plan, you may choose to list only the project manager, sponsor, and client(s), with a reference to how readers can obtain the current project team organization chart or directory. You may opt, for example, to publish this information on an intranet site.
Expected Resources The expected resources section lists non “human resources such as servers, software, etc., that you anticipate using. You may also list vendors in this section.
Assumption and/or Constraints The assumptions that were agreed on during the planning process and any known constraints that will impact the outcome of the project are documented in this section. These are outputs from your planning process. A typical assumption statement might read: The vendor will deliver on time.
Major Deliverables/Scheduled Tasks The major deliverables section lists the summary level achievements that make up the delivery of the product. You should include the major deliverables from each project phase. This information typically is obtained by using the highest level of the WBS or the summary tasks from the project schedule.
You may also be required to provide information on how to view the current version of the project schedule (e.g., intranet page or other electronic location).
A copy of the project schedule baseline may be included as an appendix.
Budget The project budget is discussed here. This section may be very high level with only a summary figure for the entire project budget or it may break the budget down into various spending categories. Some plans also detail the method used to purchase capital equipment and track project capital and expenses.
A copy of the budget baseline may be included as an appendix.
Racing to the Finish
One project we were familiar with (but did not work on) used a cute way to illustrate the project baseline. The project managers got foam board from the stationery store. They printed out clip art of different racehorses and cut them out. Then they glued the horses to more foam board and cut them out. Next, they attached Velcro dots to the horses and also to percentages to complete milestones along the baseline. When the final baseline board was done you had a lane for each racehorse ”each lane representing a phase or deliverable. As each phase or deliverable was worked on and progress was made, its horse was advanced one more step. The end result was that you had a very clear illustration of where we were at in the project, similar to the graphic shown below.
Unfortunately, the project was a flop ”but hey, the baseline board has stuck in our minds all these years .
Risks The identified risks that could affect the success of the project and plans to avoid or mitigate the risks are listed in this section.
Issues The method used to identify project issues, assign responsibility for resolution, define escalation procedures, and track and report progress is described in this section. This section can also include a discussion of the overall environmental issues the project could run into, including the overall computing environment as well as the political, geographical, and integrated systems environments.
Communications The communications component describes the method and frequency of communication with sponsor, clients , project team, and other stakeholders. For example, you might say something like this: Sponsor communications ”one-on-one meeting every Monday at 10:00 A.M. for the duration of the project, and Team communications ”biweekly team meeting every Thursday at 2:00 P.M.; email or one-on-one conferences as required for the duration of the project.
Implementation Plan The implementation plan is an overview of the methodology used to implement the project schedule. The plans you ve created for development, hardware, installation, securing, configuration, testing as well as other plans for correct implementation of the project schedule are included.
Support Plan The support plan documents how the new system will be supported once the project is complete. Support may be limited to the update and maintenance of a new system or piece of hardware, or it may include a technical group that will support the users of a new application.
Training Plan The training plan documents how training on the new system will be accomplished. This includes training for end users, help-desk staff, operations staff, or other groups, as applicable.
If you are using any existing checklists or have developed checklists during the planning processes, you can include copies in this section. Examples of checklists in this section are:
The reference section lists any sources used for project methodology, corporate standards, or best practices. A reference list may include:
An appendix can be used to provide a copy of detailed documents not normally included in the body of the project plan:
With all of these components to consider, writing a comprehensive project plan can overwhelm a new project manager. Don t worry, we can share a lot of tips on how to make this come together smoothly with all of the data you need to oversee the project.
The project plan can be created either by putting all of your critical data in a formal document or by organizing a series of existing documents, depending on what is expected in your organization. If your initial planning processes are thorough and involve the right participants , the revisions should be kept to those aspects of the project that are formally changed during the course of the project. If the up-front planning activities are shortchanged, the project plan will probably be inaccurate or important data will be missing.
In order to finish out project planning there are some final required steps:
Although you may be tempted to just jump in and start writing, it is much better to take time to review your documentation and organize it to match the outline or template you will be using. Otherwise you may find that you are moving data around, entering data multiple times, or omitting key points.
Real World Scenario ”After-the-Fact Plan
We can remember being on a project with a very large project plan binder that was updated on a weekly basis during project execution because most of the sections were created as the project work was being done.
This method of developing the comprehensive project plan created a scenario where the project manager, the project team members , and other stakeholders did not have a plan to guide execution of the project. What we received instead was a history of what was decided after the fact.
As you can imagine, confusion was rampant, and to no one s surprise, the project was quickly off track.
This is definitely not the way you want to transition into project execution. A project plan binder isn t a reflection of what has been done, but what has been planned to be done.
You also need to define a document control process if there is not a standard in your organization. How revisions are made, the version numbering system, and the placement of the version number and revision date are items that should be defined before even a draft project plan is distributed. Without a document control system in place, you cannot properly account for all updates to the plan.
With today s file-sharing technology, more project managers are taking advantage of distributing project data electronically . This eliminates a lot of the manual work involved in printing and distributing the original project plan and then distributing any changed pages as the plan is updated.
You should decide prior to starting the document whether you are going to distribute the plan via paper or electronically. A project plan accessed via a shared file has its own unique challenges. You need to determine the level of security required to access your documents, and make sure all stakeholders have access to the server where your project file is stored. All of the documents on the server should be read only to prevent any accidental changes. You do not want to start putting documentation out on a server until you have established the access and security procedures.
Once you have completed these up-front steps and have all of your planning output organized around your outline, you are ready to write the plan. Your plan will be read in part or in total by many people at many different levels in your organization, so make sure that you have checked grammar and spelling and that each section of the plan is complete and all of the data is correct. A plan that is thrown together without the proper review and editing will provide the impression that the project itself was not thoroughly thought out or properly planned.
Even as you are writing the initial version of the plan, you need to be developing change management processes for updating the plan.
Even after you complete the initial project plan document, reviewed the document with all the stakeholders, and obtained formal sponsor approval, your project plan may still change as you move into the project execution phase.
Updating the project plan is an iterative process; meaning that as key components documented in the plan change throughout the course of the project, various sections of the project plan will require updates. The scope may change, a new stakeholder may become involved, or an additional major deliverable may be added, to name just a few examples. The challenge of maintaining a project plan has always been the logistics of keeping the plan current and communicating updates to the project team, the sponsor, and other key stakeholders. Plans that are updated haphazardly will quickly become inaccurate and lose their usefulness as a road map for project execution.
To help alleviate these difficulties, you need a documented change process. Additionally, unless your PMO provides the updates , you will need to designate a person to actually make the changes and distribute the revised pages. The process for updating the plan needs to be communicated to all stakeholders.
Any change to project plan data that is controlled by a change process should only be made as a result of output from the corresponding process. A change to the scope should only include official scope changes that have been approved via the process established in the scope management plan. Budget or schedule changes should also be linked to the formal approval process for such changes.
Throughout the process of putting together your planning data, you will need to schedule ongoing reviews with the sponsor and other stakeholders.
A good project plan is a document that the project manager uses to drive the successful development of the project s product. The people involved with the project should have an opportunity to participate in the creation of the plan. The project plan is usually developed in multiple steps and evolves throughout the planning process. Ongoing review of the plan with both the sponsor and the other stakeholders is critical to the success of the project.
The sponsor review starts when you are developing your outline or table of contents. Review of a plan outline will provide the sponsor with an opportunity to comment on the content of the document. Even if you are following an approved template, it is your responsibility as project manager to confirm that the sponsor is familiar with the contents of the template.
Schedule periodic reviews with the sponsor as you add data to the various sections. The sponsor must sign off on the project plan to make it official. The end result should not be a surprise, merely the finished product the sponsor has seen through various stages of development.
Other Stakeholder Review
The creation of the comprehensive project plan is actually a great opportunity for the project manager to solidify involvement and commitment of the stakeholders. Your client, your project team, and other key stakeholders are key participants in the creation of the project plan. At a minimum, these people should receive a copy of the outline or TOC so that they are aware of what information is included in the plan. Even though the information being compiled in the project plan should not be news to the stakeholders, they may have different expectations for the project plan. Thus, up-front resolution of any issues or concerns will facilitate the writing of the plan.
Interim reviews with the stakeholder team may be appropriate for a complex and detailed project plan. In other situations it may be appropriate to meet with individual stakeholders only if they have questions.
The final review of the project plan is a formal process that signifies the end of the planning.
The completion of the comprehensive project plan signals the transition from the planning phase to the execution and control phases. When the initial project plan document is complete, the comprehensive project plan is circulated to all the stakeholders. The planning phase can be closed out with a formal stakeholder review meeting to transition to the execution and control phases.
Throughout the project, you will constantly be assessing whether the project should move forward. The meeting to close out the planning process is an excellent opportunity to obtain stakeholder concurrence regarding the viability of the project business case. If there have been any substantial changes in the business need that initially drove the approval of the project, now is the time, before the project work begins, to evaluate whether the project should move forward.
This review session should bring closure to any outstanding issues from the planning process. Hopefully, any issues that were raised earlier have been addressed and resolved throughout the planning phase. But don t assume that issues do not exist just because you are not made aware of them. Be sure to ask the stakeholders directly if anything regarding the planning phase is unresolved in their minds. It is much easier to resolve any planning disputes before the project work begins.
It might be helpful to remember that as project manager, in some people s eyes you are in a position of power. They may be reluctant to reveal a problem to you because they don t want to appear as non “team players or as troublemakers. It s important to try to foster open , honest, straightforward communication that supports a sense of security for people to be able to speak their minds about issues they see forthcoming. Yes, there are people who will freely speak their minds no matter what. But you know who those people are. It s up to you to try to get the information out of those who know, but won t tell.
Another key focus of the planning review is to assure that stakeholder expectations of the project are aligned with what is detailed in the plan. If any component of the plan was a surprise, find out what the real expectation was. It is the project manager s responsibility to make sure that everyone involved in the project understands and supports not only the end result of the project, but the road map to reach that end result.
After making any changes as a result of the review meeting, the plan is formally approved by the sponsor and, in some cases, by the client. The approved document is then distributed to all stakeholders.
As a transition into the execution and controlling phases, the planning close out meeting may also be used to discuss indicators used to monitor and control project performance as the project work begins. Project performance indicators are measures the project manager uses to determine whether the project is on track, such as any deviation from the baseline schedule or the baseline budget. For example, you should know that your development phase is scheduled to complete in 8 weeks and be tracking progress to meet that target. The use of performance indicators will be discussed in more detail in Chapters 8 and 9.
A successful transition from planning into execution should leave everyone clear about his or her individual role on the project and excited about moving forward to actually get the work done.
Case Study: Chaptal Wineries ”Finalized Project Plan
You re now ready to go forward and prepare your finalized project plan for presentation to Kim Cox, the owner of Chaptal. Following are the elements that you prepare:
Table of Contents
1. Executive Summary Chaptal Wineries recently purchased wineries in France, Southeastern Australia, and Chile. It is now necessary to electronically connect the wineries so that workers in each location can send and receive email, as well as look at one another s calendars. Additionally, it is necessary to set up a Chaptal intranet site so that critical information such as the numbers of cases of wine produced, vine health, winemaker notes, and other similar pieces of information critical to the business can be posted for corporatewide consumption. The IT manager at Chaptal s Sonoma, California location will be responsible for procuring the necessary hardware and software, telecommunications connections, and installation expertise.
A. Install T1 or E1 telecommunications circuits at each of the newly purchased sites, thus preparing the sites for WAN communications. Telecommunications companies and their third-party vendor representatives will be used for this work.
B. Set up an email system between the four sites. This will allow for all sites to email one another using an internal email system, thus preventing the possibility that someone outside the organization can get inside information via email regarding new vintages, wines, wine-making methods , case lots, or other business-critical information. There will be an email server at each of the four geographically disbursed sites. The Chaptal IT manager will be responsible for procuring the servers and installing and configuring them.
C. Set up an intranet. The intranet server will be hosted at the Sonoma location. This server will host web pages that perform such business-critical functions as corporate timekeeping, winemaker s notes, barrel-tasting notes, vintages, diseases encountered , vinekeeper notes, and other data relevant to the performance of our vineyards and the wine. The Chaptal IT manager will procure the server and install it. A contractor will be used for the programming work.
D. Test all connections and train users.
3. Scope This project includes the elements necessary to connect the four sites together by wide area networking. Additionally, the project accounts for setting up an email system that includes an email server at each site. As well, an intranet server and the programming of relevant intranet pages are included. Procurement of all necessary hardware and software, as well as installation configuration, testing, deployment, maintenance, and training are included. Not included in this project is a system for managing corporate finances, HR, or assembly-line/ manufacturing work (such as the actual bottling and labeling of the wine bottles). Our enterprise resource planning (ERP) software handles this function. A later project will bring all three new sites into utilization of the ERP.
4. Stakeholders Stakeholders include:
Kim Cox Project Sponsor and owner of Chaptal Wineries.
Guillaume Fourche A Bordeaux negociant specializing in fine red wines. Fourche s cabernet sauvignon wine will be re-branded as Les Chaptal Bordeaux Villages.
Metor Sanchez Owner of a Chilean winery in the Aconcagua valley. Sanchez s Syrah, cabernet sauvignon, and Malbec wines will be re-branded as Casa Sanchez Chaptal.
Jason Jay Proprietor of Roo wines. His Shiraz wines will be re-branded as Chaptal Roo.
Others Chaptal wineries employees to assist with UAT.
5. Expected Resources
Five Intel-based midrange class servers.
Carrier Sensing Units/Data Sensing Units (CSU/DSU) for demarcation connectivity.
One router and switch per location.
Telecommunications vendors and consultants (including demarcation installers and router and switch internetworking specialists).
Contractor to develop and test intranet pages.
6. Assumptions and Constraints
7. Major Deliverables
8. Budget It is projected that the total project, not including the Chaptal IT Manager s regular salary, will be $205,000. Kim Cox has agreed to subsidize the project with a $25,000 contingency fund.
T1/E1 circuit bandwidth not sufficient
Internetworking gear failure
10. Issues It is vital that the project be completed before the September crush of the grapes and preparation for new vintage wine making. Kim Cox has made it clear that no Chaptal employees are to be doing anything else but concentrating on the wine in September and October.
11. Communication Because the email and intranet servers are not up yet, all communications will be by phone or by free temporary Internet mail such as Hotmail. Kim Cox will be updated daily. Jason Jay, Metor Sanchez, and Guillaume Fourche will be updated weekly.
12. Implementation Plan Due to the requirements of the email software, procurement and installation of the WAN circuits must happen first, followed by installation of the internetworking gear. After that, server builds can take place following by intranet programming and testing.
13. Support Plan The Chaptal IT manager will be the primary support entity, assisted by a designated individual at each of the remote sites.
14. Training Plan The Chaptal IT manager will handle all of the training efforts at all sites.
The comprehensive project plan is your guidebook that will be used throughout the life of the project.
The project plan contains outputs from the various planning processes put together in one all-inclusive document. It should include the critical planning outputs for initiation, scope, time, cost, human resources, quality, communications, risk, and procurement.
Although a project plan has historically been a paper document, today there are more examples of project managers who distribute plans electronically in a shared folder environment.
The comprehensive project plan is created with ongoing input and review from the sponsor, the client, the project team, and other stakeholders.
A formal review, with official sign off and approval of the plan, marks the transition from project planning to project execution.
Explain the purpose of a comprehensive project plan. A comprehensive project plan is the document you will use during execution and control to track the performance of the project and take any needed corrective action. It is used to communicate key information to the project stakeholders.
Be familiar with the components of a comprehensive project plan. A comprehensive project plan contains components such as documentation revision control, a table of contents, executive summary, a list of stakeholders, project requirements, major deliverables, expected resources, environmental issues, and plans for implementation, support, and training.
Understand what is meant when project plan development is described as an iterative process. The planning process is repeated in cycles as more information is obtained or changes are made to the project.
Explain the importance of performance baselines. Baselines are a picture of what is expected to happen before the project work begins. They are used to measure the progress being made. Common baselines include the scope statement, the schedule, and the budget.
Demonstrate knowledge of the importance of a formal review of the project plan. A formal review is scheduled to assure a common understanding of the project plan by all stakeholders. Stakeholders have an opportunity to ask questions and provide feedback before the plan is finalized.
Identify the steps involved in creating a project plan. The project manager should create an outline or table of contents for review with the sponsor and other stakeholders. The writing of the plan involves bringing together and integrating all of the output from the planning processes. A review of the draft plan is held with all stakeholders. The project sponsor provides formal approval or sign off of the plan.
Before you take the exam, be certain you are familiar with the following terms:
comprehensive project plan
document control process
project performance indicators