CHAPTER 3
Planning a Profitable Project

PROJECTS FAIL AT THE BEGINNING, not at the end. When you have poor planning, confusion as to what is to be created, and stakeholders who are hesitant to commit to project decisions, you’re going to have a project that’s late, expensive, and loaded with frustration. Examine any failing project within your company, and I’ll wager you’ll find that planning regarding the goal of that project has been poor. If you want a project to be successful, you must know exactly what it’s meant to achieve. The exactness, of course, is always the tricky part.

Stakeholders can be confused as to what they want the project to accomplish. It’s no secret in the project management arena that project managers and sales reps have to educate customers on what’s needed in the project and why. Customers don’t want to appear ignorant, so they rely on savvy guidance from your company. At the same time, customers don’t want to feel that they’re being oversold on a solution. There’s a balance between selling what’s needed and taking advantage of a customer who doesn’t know better.

The project manager, the business owner, the sales rep, and the customer should all be in agreement on what’s needed in a project solution, but this is contingent upon understanding what the customer actually requires. And how do you know what the customer really wants and needs? Listen. Customers want a solution to their problem, but they also want you to listen to make certain that you understand their actual need. And since they aren’t necessarily able to explain their project goals eloquently, they’re looking to your company to provide some coaching and some smart advice.

The initial conversation between you and the customer is at the beginning of the project—and it’s the first place where the project can fail. Projects are poised to fail when you talk over the customer, leave with a distorted vision of the project goals, or don’t ask enough questions to truly understand what the customer expects from your company. It’s important that you understand the purpose of the project: why it is being initiated, what the end result is intended to achieve, and how the project will affect the customer. If you’re unable to define the project’s purpose and intended outcome, you’re not doing a good job of gathering its requirements.

Customers can already have a false solution in mind for a problem that they’re experiencing—and that’s trouble. One of my clients wanted to replace a massive and expensive piece of equipment on his shop floor because it kept generating faulty product. The wasted materials and time spent redoing work infuriated the shop owner, and he wanted the machine ripped out and a newer, faster machine delivered. When I dug into the problem, I learned that the equipment hadn’t been balanced in more than two years, the people using the equipment hadn’t been trained properly, and, to make matters worse, the software controlling the equipment hadn’t been installed properly. By understanding the problem behind a customer’s perceived solution, you can help the client save money and time, and get the results that he really wants.

Once you understand what the customer actually wants and needs, the project team will be able to create an effective plan for achieving it. Planning ends only when the project ends. In project management for small businesses, there’s rarely time for long, drawn-out planning sessions, but accurate planning sessions are mandatory. This includes gathering the requirements and then planning for successful project implementation.

Gathering the Project Requirements

One of the most important parts of project management is gathering the project requirements. When requirements are subjective, sketchy, or ambiguous, the project manager can’t plan for precise project execution. Accurate requirements are the foundation for an accurate project plan.

There are many approaches to gathering project requirements, but the most fundamental, and most successful, approach is simply talking with the customer. Interviewing the customer helps you understand what is wanted. From the customer’s perspective, you’re the expert who can help her draft her requirements, and your company is the expert that can get the project done.

Interviews don’t have to be tricky; they can be completed one-on-one, with just you and the stakeholder, or they can involve multiple stakeholders and multiple people from your company. Be careful about how many people you invite to the interview, however. Keep the number of participants from both companies to a minimum—to only those who are essential. Small businesses can make the mistake of bringing their whole office staff to a requirements-gathering session. This is fine when there’s a need for all these people to contribute, but it can backfire when you’re trying to impress the client.

During the interview process, you want to have a conversation about what the project is to achieve. You and the other participants in the meeting will ask questions, create a dialogue about the problem and the solution, and educate one another on what the project is intended to accomplish. The most important takeaway from your meeting is the notes. Everyone on your team should be writing notes and comments. All participants should then type up their notes and submit them to whoever is in charge, whether it’s the project manager, the business analyst, or the sales rep.

The notes are then compiled, and your team and the project manager should review and organize them and develop a requirements list and/or a statement of work for the client’s approval. This is usually a straightforward process, although at times there may be rounds of refinements between the requirements that you’ve identified and what the customer wants. Bear in mind that it’s always easier and more cost-effective to make changes and updates to the requirements before any actual work on the project begins. Failure to identify the requirements then will mean wasted money, resources, and time later.

Another approach that’s useful for gathering project requirements is a workshop. Workshops bring the key stakeholders together for an in-depth examination of the project goals. They help the stakeholders work together on identifying the complete set of requirements, they foster good relationships, and they identify the project requirements quickly. While workshops may sound like interviews, the primary advantage is that a workshop is one intense, focused meeting rather than several intermittent meetings.

In both workshops and interviews, a good way to start the requirements-gathering process is to brainstorm. Brainstorming, popularized by Alex Osborn in his book Applied Imagination, calls for all of the participants to generate as many ideas as possible. There’s no judgment of the ideas generated at the time; they’re all collected for later consideration. Brainstorming is a good way to generate ideas, foster teamwork, and encourage participation by all the stakeholders. Once the ideas have been generated, the brainstormers will discuss the feasibility of each idea.

Although brainstorming doesn’t rank or sort ideas, the nominal group technique does. This approach, a variant on brainstorming, takes each idea and ranks the requirements based on priority, applicability, and need for the solution. Prioritization of requirements helps your stakeholders determine what’s affordable and what lower-level priorities can be removed from the requirements because of cost or time constraints.

When there are many ideas generated in the brainstorming session, it can be useful to create an affinity diagram, as shown in Figure 3–1. An affinity diagram is a way to organize ideas and requirements into similar topics. For example, a solution may have requirements for computer servers, workstations, databases, and Web interfaces. As requirements for each of these topics are noted, they are sorted into the appropriate category. You can even break down the categories into more detail; for example, in Figure 3–1, hardware is divided into more specific categories: workstations, servers, and printers. Each category in the affinity diagram can then be prioritized. It’s a quick way to focus on different segments of the project without going in too many directions at once.

Yet another way to establish project requirements is to create a prototype. A prototype is a mock-up of the finished deliverable that you and the customer can examine to confirm your understanding of what the project is to accomplish. For example, a Web design company may create several quick and rough samples of what the finished web site will look like, showing the color scheme, graphics, and feel of the site, to make certain that the designers understand the customer’s needs. The customer then can inspect the prototype and either make adjustments or give the green light for the project work to be launched. The intent is to create a visualization of what the project will create.

Figure 3–1. An Affinity Diagram. Affinity diagrams group similar ideas as part of determining the project requirements.

If your project team is to solve a productivity problem for a client by installing new equipment or new software, or even just designing a better workflow, it’s really mandatory that you observe the present conditions. Experts from the project team should visit and observe how the customer is doing the work. By experiencing the work firsthand, seeing the customer’s pain in the process, and tracking the outcomes, you can create solutions that solve the problem and also develop measurements for a baseline. A baseline captures current performance and allows you to measure changes as the project moves forward. It is needed to establish metrics for project performance and what the desired future state of your project should be.

No matter which approach you take to gathering project requirements, you’ll need to create requirements documentation. Requirements documentation defines the project requirements, the characteristics, and the expected outcomes so that all of the stakeholders are able to understand the purpose of each requirement and its significance for the project. Stakeholders, in particular the project customers, must approve the project requirements before the planning can continue.

In larger, more complex projects, you may find it beneficial to create a requirements traceability matrix. This is a table that lists all the requirements and their status in the project, and allows the project team to track them from concept to actual implementation as part of the project scope. If you’ve ever reached the end of a project, only to realize that some of the requirements weren’t completed, a requirements traceability matrix is for you. To create a requirements traceability matrix, you’d document and track these characteristics for each requirement:

Requirement description

Unique identifier

Prioritization of the requirement

Status of the requirement (completed, canceled, modified, in progress, or other status)

Date completed

Approval status

Gathering the requirements takes some time and effort at the launch of the project, but it’s critical to understanding what the project is intended to accomplish. If you have only a highlevel vision of what is to be achieved, you’ll end up managing a wandering, unfocused, and unrealistic project. Your project team and the project customer must be in agreement on what the project is to achieve in order to manage, control, and deliver the project scope.

Creating the Project Scope Statement

Much of the project scope can be tied directly to the project requirements that you and the project team have already invested a great deal of time in identifying. The project scope statement describes everything that the project is to create and is based on the requirements documentation. It defines what the project will and will not include, identifies everything that the project will create, and defines the metrics for its success. A project to create new software, for example, may define the purpose of the software, how the software will operate, and all the other details about the completed software involved in the project. The project scope defines the metrics for acceptance and success of the project software based on the requirements that have been gathered. In this instance, the scope may also state that the project is not responsible for packaging and distributing the software.

It’s important to define in the project scope what will and will not be included to remove any assumptions made by the project customer and the project team. Ambiguous statements in the project scope open the door for claims and complaints later. The project scope statement must define exactly what the customer will receive as a result of the project work. The customer is going to pay for what you’re creating, and your company, of course, wants to earn a profit from the work it’s doing for the customer. It’s easy, but wrong, to see this up-front definition and intense planning as a waste of time that could be spent on project execution, but planning and defining the exact details of the project delivery in the project requirements and in the project scope is the foundation for completing profitable projects.

Every project scope statement should define all of the following elements, either in the statement itself or through references to the project requirements, the contract, or other project documentation:

Purpose. The primary goals of the project should be defined. This can include the vision of the organizational change that the project will create, the problem that the project is to solve, or the opportunity that the project is to seize. The purpose is from the customer’s point of view.

Terms for acceptance. You and the customer must be in agreement on what constitutes project completion. Subjective terms like good and fast aren’t appropriate. This section needs performance metrics, conditions, and references to the requirements documentation for accurate identification of what the project must complete.

Project deliverables. Deliverables are what will be created as a result of the project. In the project scope statement, these are usually the high-level things that the project will create or purchase. Remember that deliverables aren’t only for the project customer, as your project may require the purchase of tools, materials, or software that you’ll need to do the work, but that you will also retain as part of your organizational assets.

Constraints. A constraint is anything that limits your options. Deadlines, budgets, and resources are common constraints that are defined in the project scope statement.

Exclusions. Anything that the project won’t include but that may be assumed to be included is considered an exclusion. It’s paramount that you clarify any assumptions about what’s not included.

Assumptions. Some projects have assumptions that affect project execution, such as weather, access to the site, compliance approval, or other factors that must be assumed to be true in order to plan and do the project work. These should be documented in the project scope statement in order to manage stakeholders’ expectations.

While the project scope statement is a formal document, it doesn’t have to be long or overly detailed. You can provide references to or copy details from the project charter, the project contract, the SOW, and the requirements list to help streamline the creation of the project scope statement. You may want to automate this process by creating a template for the project scope statement, but don’t allow the speed that the template offers to shortcut the process of determining the details needed for a good scope statement. This is part of project planning, and it does take time to do well.

Developing the Work Breakdown Structure

The work breakdown structure (WBS) is a visual breakdown of the project scope. Figure 3–2 shows a small portion of a sample WBS. The WBS is not a breakdown of the project activities—it’s a breakdown of the project deliverables. It’s everything that makes up the project scope, broken down into work packages. The process of creating the WBS is called decomposition because you and the project team are taking the project scope and decomposing it into smaller and smaller parts until you reach the smallest item in the WBS, which is the work package. Work packages are the smallest deliverable in the project, with time and costs that can be precisely estimated.

Figure 3–2. The Work Breakdown Structure. A WBS helps communicate what the project will create.

To create the WBS, examine the project scope and define the major elements, major phases, or categories of project deliverables. Then subdivide each category into slightly smaller elements, subdivide these elements further into smaller components, and so on. You don’t want to leave work packages too big, nor do you want them to be too small and granular. A good heuristic is to use the 8/80 rule: a work package should take no more than 80 hours of labor to create and no less than 8 hours of labor to create. Again, this is just a guideline, as some work packages may take only a few hours of labor, but you want to make certain to include each element.

When all of the work packages have been completed, the entire project is done. Creating a WBS helps you track all of the deliverables and ensures that everything promised has been created for the customer. The WBS can be used as a checklist to see each physical deliverable and prove that it does exist within the project. There’s no mystery as to what’s been completely created—just check the WBS against the physical deliverables.

In the WBS, you should also number each of the categories of deliverables to clearly identify the constituent components. For example, in Figure 3–2, you can see that the project code is 741. Each of the categories of deliverables will branch off from the project code of 741: 741.1, 741.2, 741.3, and so on. Within each of these categories, the project is further decomposed, and the numbering continues. This numbering system is called a code of accounts, and it’s beneficial to a project manager for several reasons:

Communication. There’s no confusion as to which WBS element is being discussed, tracked, completed, or analyzed, as everyone involved can refer to the code of accounts.

Tracking. Each work package equates to a physical deliverable for which the time and costs can be estimated and tracked against actual implementation. By tracking each deliverable with the code of accounts, the business owner can create a profit and loss statement (P&L statement) for what the project is to achieve. Some work packages will be more profitable than others, and the tracking of the work packages helps to control the project and create more accurate cost and schedule estimates.

Activity definition. The WBS defines the deliverables that the project will create; once you know what the deliverables are, then you can create an activity list. The activities are the tasks that require labor to create the work packages.

Cost estimates. The WBS can help you predict how much it will cost to create the project deliverables. It can be used to predict a duration estimate for each work package, the cost of each work package, and the labor requirements to complete the work.

Risk identification. Risks are uncertain events with outcomes that can help or hinder the project. By examining the WBS elements, you can identify where they may be lurking.

Quality. In project management, quality is achieved by satisfying the project requirements. The WBS is really a reflection of the project requirements, so by accurately creating the work packages, you’re achieving the requisite quality.

Planning. Having a detailed understanding of what you must achieve helps you and the project team plan on how to create the project work packages.

Once the WBS has been created, you may want to develop a companion document called the WBS dictionary. The WBS dictionary, as its name implies, defines everything in the WBS. For each work package in the WBS, it explains what the work package is, what resources are needed to create the deliverable, and any other pertinent information about the deliverable. This document can help clarify what the project deliverables are and what the characteristics of each deliverable are, and it allows the project manager to update the information as more details become available during the planning stage.

The WBS is a cornerstone of good project management. As with all elements of project management, if you’re completing the same type of projects over and over, you can use a WBS template to capture the elements of the project scope quickly. Again, be prudent with templates—they can save time, but it’s easy to overlook the elements that make each project unique. If you take nothing else from this book, take this one lesson: Always create a WBS.

The WBS can help the business owner because it allows him to quickly see what the project promises to create, what the project has created, and what’s left to be done. It helps the project manager because it provides input for other planning activities and it helps control quality, inspections of the work, and accuracy for the project deliverables. It also helps the project team, as it allows the team members to see what they’re creating and how the sum of their creations equates to the project scope.

There can be instances in the creation of the project’s WBS where insufficient information is known to decompose the project scope properly. Consider a home construction project where the customer hasn’t yet decided on the precise details of the kitchen. The customer knows that the kitchen will have flooring, cabinets, plumbing, and the usual kitchen appliances; the project manager knows the square footage of the kitchen; and there’s a budget of $40,000 assigned for the kitchen deliverable. In other words, the kitchen portion of the project is worth $40,000 of the total project budget, but the exact information doesn’t need to be known on Day 1 because there are other planning and execution activities to complete before the kitchen work can begin.

The decisions for the kitchen don’t all need to be made before the construction can begin, so there’s a window of opportunity to delay these decisions while the other project work continues. The closer the work gets to the kitchen activities, however, the more pressing it becomes to have the decisions documented. These windows of opportunity can become risks, as delayed decisions can affect procurement, lead time for materials, scheduling of resources, and other elements. The logistics of when decisions must be made and how each decision affects the project work must always be considered in project planning.

The kitchen in this scenario is called a control account. The items within the kitchen are planning packages. The control account has $40,000 to purchase the materials needed to complete the kitchen. If the cabinet decision is made and the complete cost of the cabinets is $15,000, then there’s only $25,000 left in the kitchen control account. As decisions are made for the kitchen deliverables, the money in the kitchen control account is consumed. This helps business owners see trade-offs and opportunities, and helps with project accounting, called job accounting, or creating P&L statements for each section of the project and the project as a whole.

Producing the Project Activity List

Once you have the WBS created, you can produce the project activity list. To be clear, the WBS and the activity list are two separate documents. Each work package in the WBS equates to at least one activity that someone will have to complete in order to complete the work package. Once all the activities have been completed, then all the work packages have been created, and the project scope is complete.

At this point of project planning, you’re not concerned about the sequencing of the activities. You’re just focused on identifying the activities that need to be completed during the execution of the project in order to create all of the work packages. This approach to the work does take time (something that small businesses begrudge), but getting the work documented now saves time, headaches, and communication problems later.

Project managers and business owners often want to bypass the WBS and the activity list and head directly into the execution of the project. They understand how the work should be done based on their years of experience and expertise with the product. Some project team members may feel the same way. However, jumping into the work instead of taking the time to create the WBS and identify the work packages is one of the main reasons that projects fail. Create the WBS, create the activity list, then order the activities, create the schedule, and get the project work done with less frustration, more control, and more profitability.

By creating the WBS first, followed by the activity list, you’re ensuring that you’ve captured all of the project requirements and the related work that needs to be done to complete the requirements. You’re also creating a methodology that will allow the entire business to run more smoothly and efficiently. This, in turn, allows your business to be more productive and creates a broader capacity for additional work and new opportunities. Productivity, efficiency, and capacity for work equate to higher profits, happier customers, and increased success.

To create the activity list, you will need to involve several stakeholders in the process: the business owner, the project manager, and the project team, and also any subject-matter experts in your company or vendors that will help you complete the project work. By involving the people who are closest to the activities, you’re communicating the purpose of the project and how the project team’s work contributes to the project as a whole rather than to individual elements, and you’re letting the members of the project team see how their work is integrated with one another’s activities.

The processes of creating the WBS and creating the activity list may be done in tandem with the same stakeholders involved. This approach to creating the list builds a sense of ownership among the members of the project team. Rather than asking, “What work do you need to do in my project?” project managers and business owners need to take the approach of asking, “What work do we need to do in our project?” Projects are completed by lots of people, and these people should own the work. Get out of the way, and give the project impetus to the people who are handling the responsibilities. People work better on projects when the project’s success is due to their work, their energies, and their contributions. Let your people own each project and you’ll find that there are more successful projects in your company.

Selecting Your Project Management Software

One of the most common questions that business owners and project managers ask me is: “What type of software should I use to help me manage my projects?” Technology can help you manage the project, streamline many of the project management activities, and lend control to the project management processes. I recommend Microsoft Project because it has the same feel and familiarity as other Microsoft products. There are, however, many other good project management software products available as well.

The idea that you will be able to manage a project just because you have project management software is a fallacy. Saying that you can manage a project because you have Microsoft Project is like saying that you can write a novel because you have Microsoft Word. Whatever the project management software, if any, that you use, always know that it is a tool, not a replacement, for the project manager.

My advice to business owners and project managers is to do as much planning and documentation as possible before you even open the project management software. It’s so easy to fall in love with software and its promises of perfect projects, and to have an immediate sense of accomplishment, that project managers skimp on real project planning. Because the WBS and the activity list should be done with team members, I find it’s easier to use a giant whiteboard for planning projects and then transfer the needed data to the project management software.

When you create the WBS on a whiteboard, everyone involved can see all at once what must be accomplished. If possible, leave the WBS on the whiteboard for a few days to let your thoughts and ideas cool. Bring the team back together and go over the content once more to see if you’ve forgotten anything, notice any errors, or need to break down work packages even more.

It’s always a good idea to get the project team together to review the deliverables and activities to make certain that you’ve captured everything. This also emphasizes the importance of what the project is about to do. Once you’re satisfied with the WBS that you’ve created, you can transfer it to your project management software. For the WBS image and structure, you might use Microsoft Visio, PowerPoint, or your favorite drawing program if you want to create the same mapping of ideas that you’ve sketched out. You can also use your favorite spreadsheet program, such as Microsoft Excel, to recreate your WBS as a listing.

Microsoft Project is a good software program for documenting your activity list. You can add all your activities, assign resources, determine start and finish dates, and even create the project schedule. Whatever project management software you elect to use, however, bear in mind that the data in the software needs to be maintained as the project progresses. As your project team completes activities, you need to record the status of each activity and the actual duration of the activity, and create reports that show the difference between what was planned and what was experienced in handling the project. You can track costs, monitor resource utilization, generate reports, and predict project performance with good project management software, but there will be a learning curve to use the software well.

Building a Project Management Plan

Project management planning isn’t about creating a document that you’ll review once and then toss aside. The project management plan communicates to the business owner, the project manager, the project team, vendors, and customers how the work will get done. It provides the framework for the project. It may not be fun to create (it’s tedious, time-consuming work), but it’s better than errors in the project work, time wasted, opportunities lost, and general unrest among your team members and customers.

Now here’s some good news: You do not need to create an exhaustive project management plan. While there has to be some defined governance for your project, you don’t need thick, obtuse plans to give structure and control to successful projects. As much as I love to write and talk about project management, I despise writing fluffy, meaningless plans that no one reads, uses, or relies on. Who has time for that? I don’t.

What a small business really needs is a documented project management approach that the entire company can live by and not deviate from. Creating and perfecting a project management plan does take some time, and there may be resistance from stakeholders, but by doing the work with the same quality-driven approach every time, you’ll get the same high-quality results.

There are always multiple ways to manage a project, but all projects within an organization must be governed with one goal in mind: profits. Imagine an organization that has 10 different projects happening at once, with each project being managed slightly differently from the other projects. If you’re the business owner, how will you know which project is performing well? How will you compare projects? How will you measure success in project performance as the project is in motion, rather than just at project completion? If each project is managed differently, there’s no common project management framework that you can use to compare projects, determine project priority, and know which projects can be paused and resources shifted to projects that may be off schedule or off budget. Consistency in project management across an organization ensures common approaches and better communication, and sets expectations for stakeholders.

If all 10 of these projects use the same approach, the same terminology, the same software, the same reports, and the same project management philosophy, you’ve created a uniform way of getting things done, opened better communications among the project managers, and created more effective control throughout both the organization and its projects. The project management plan that you create should be clear enough that everyone can understand the goals and intent of the project, but flexible enough that it can be adapted to each project that your organization launches. The project management plan is not one massive plan, but a number of individual plans and documents that can be adapted for every project. The size of the project scope directly influences the amount of detail needed in each of these project plans. Here are the 10 components of the project management plan and what you need to define in each of them for your projects:

1. Scope management. The scope management plan defines the techniques that should be used to gather the project requirements, the forms for documenting the project requirements, and the process for confirming stakeholder approval of the requirements. The plan also defines how your project manager and project team should break down the project scope into the WBS, the WBS dictionary, and the activity list, and it addresses the project’s scope change control system so that changes may be allowed into the project, managed, and planned for. In Chapter 6, you’ll learn all about controlling changes in your project.

2. Cost management. Project costs must be estimated, budgeted, and approved. This plan defines your organizational approach to cost estimating, any software or guidelines that should be used, and how the budget correlates with the project activity and internal expenses. Your cost management plan may identify software for estimating and tracking costs, a work authorization system, and forms that the project manager may have to complete. The cost management plan also includes information on how costs are to be controlled in the project. In Chapter 4, I’ll discuss everything you need to know about project cost management.

3. Schedule management. This plan defines how the project work will be scheduled and controlled, and how changes are to be managed. It may also define labor utilization, such as overtime, vendor coordination for labor, and collective bargaining agreements that affect when the project work can be completed. Your schedule management plan should address two calendars: the project calendar and the resource calendar. The project calendar identifies when the project work will take place, such as the operating hours, days of the week, company holidays, and any pauses in the project work for business reasons. The resource calendar notes when project team members are available to do the project work, time away from work, and the availability of resources like facilities and equipment. The resources required for each project should be scheduled for the days they are needed within an appropriate window. In other words, the resource calendar should coordinate the utilization of equipment, facilities, and people with enough time to allow other project managers and management to plan accordingly. I’ll cover the complete scheduling approach in Chapter 5.

4. Quality management. Quality is the conformance to requirements and the assurances that the finished project deliverables can actually be utilized by the project customer. Your industry may have regulations, standards, and compliance that all contribute to quality; these should be documented in this plan. Any programs that your company uses, such as Six Sigma, should also be documented and explained in the quality management plan. Quality in project management is delivering exactly what the customer expects based on the project scope statement.

5. Human resources. This boilerplate plan defines how the employees on the project are managed. Specifically, it identifies to whom the project team members report, who is managing the project team, and to whom the project manager reports. It should also explain how the project team members are brought onto and released from the project team. If the project team members are working on multiple projects at once, the plan should define the communication process among management and the project managers to determine project priorities, the shifting of resources, and the coordination of staffing. When there are changes in project work and changes to the requirements, scheduling of the project resources may change, too. Finally, if your business offers rewards and recognition, the details and goals should be defined in this plan as well.

6. Communications management. The communications management plan answers three important questions:

a. Who needs what information?

b. When is the information needed?

c. In what modality is the information expected?

If your company uses special forms, software, or communication devices, this plan should specify the rules and expectations for using the assets properly. The plan is tied to stakeholder management and the need for communicating with the stakeholders, the correct channels for doing so, and how stakeholders’ needs and expectations for project performance will be met. Project communications will be covered in Chapter 8.

7. Risk management. This plan addresses the approach utilized to identify project risks, and also how risks will be documented, analyzed, and responded to. It defines the process that project team members are to use to control risk events, document the outcome of risk events, and provide metrics on the effectiveness of risk management. In Chapter 7, I’ll discuss risk management in detail.

8. Procurement management. How your company purchases goods and services from vendors is defined in this plan. The project manager should understand how to complete the necessary forms for purchasing or whom she will need to work with in order to handle procurement. The plan should also define how vendors will be reviewed; how their invoices are to be approved; and where the documentation of the contracts, communications with the vendors, and related information will be kept.

9. Baselines. Baselines are used to measure project performance in the area of the project that they cover. You will compare actual project performance against the details of these baselines to see how well or how poorly your project is performing. There are three baselines that should be included in the project management plan:

a. Scope baseline. The project scope statement, WBS, and WBS dictionary serve as the scope baseline.

b. Cost baseline. The aggregate costs of the items that the project will create serve as the project budget and the cost baseline.

c. Schedule baseline. The planned and approved schedule for when key project deliverables are to be completed and when the project as a whole should be completed serves as the schedule baseline.

10. Supporting detail. In addition to these plans, each project is likely to have important supporting detail for the project work. This can include books, directions, technical drawings, implementation plans for specific project work, and anything else that the project will need in order to complete the activities, to create the work packages, and to satisfy the project requirements.

By creating these project plans, even simple, one-page documents to start with, you document the vision, control, and management approach that you see all the projects in your organization using. You’re building just the bones of your company’s project management approach and then allowing the project manager and the project teams to provide the rest of the structure that’s appropriate for each project.

This does not mean, however, that once this framework has been created, the project manager and the project team are done with planning. It means that you’ve streamlined the planning process by showing what each project must address so that all projects can be operated efficiently and uniformly across the organization. Planning must occur for each project because each project is different from any project that you’ve done before.