Defining the Project Goals

Overview

We're off and running! The Initiation process is complete, and we're ready to start the project Planning process.

The Planning processes are probably the most important in the project life cycle. I think most project managers will contend that a well-documented plan that's managed expertly will drive the project to a successful completion almost all by itself. Almost. Don't forget that you're the one who is responsible for developing the plan, with help from the project team, and later monitoring the project for adherence to the plan. But most of the work in project management is in the planning phase, and so we'll spend many of the remaining chapters of the book discussing planning documents.

This chapter kicks off planning with a definition of goals and project deliverables. From there, we break down these elements into requirements and wrap it all up with the creation of a scope statement. In this chapter, you will learn:

Agreeing on the Deliverables

Scope definition is the first thing you'll want to tackle in the Planning process. Scope definition starts with the goals or objectives of the project and continues to refine them, breaking them down into smaller components until at last the deliverables and requirements are defined. The end product of scope definition is the publication of the scope statement, which spells out each of the things I just mentioned plus a few others we'll cover in the coming sections.

Goals, objectives, deliverables, requirements…what's the difference? These terms sometimes get used interchangeably, but there are some differences. We'll spend the next few sections examining what makes up each of these components and what their differences are.

Goals and Objectives

The title gives this one away. Goals and objectives are very closely related and probably can be used interchangeably without a lot of confusion. I like to think of objectives as having a little broader definition than goals. Goals, on the other hand, are more precise and are stated in tangible terms. But let's not get too hung up on goals versus objectives because objectives are subject to the same criteria as goals if you're using the terms interchangeably.

Let's suppose you've been appointed the project manager for the Logan Street Move project. Your company has purchased a new building and made some extensive renovations, and you're ready to move the existing staff, currently in two different locations in your city, to the new building. The objective for this project might read something like this, "Move the existing staff to the Logan Street location with no disruption in service to our customers."

While that's a good objective statement, it really doesn't qualify as a goal. Goals describe what you're trying to do or accomplish or produce by way of this project. When the goals are completed or accomplished, the project is complete. Goals must spell out exactly what's needed to accomplish the project. That means they must be specific enough to use as the criteria to determine whether the project was a success.

From here on out, I'm going to use the term "goal," but know that you could use "objective" just as easily as long as you follow the guidelines outlined in this section for defining them.

Project goals are the heart and soul of your project. Without a clear, written understanding of what the goals are, folks might take off in all different directions and, before you know it, you have a project disaster on your hands. At best, you'll find a lot of disgruntled team members and stakeholders mumbling their version of the project goals under their breath (or to your boss) and not understanding why you didn't understand that their version of the goals was the correct version. You don't want to go there.

  Note 

Goals describe the what your project is going to accomplish or produce.

The Logan Street Move project needs some further definition. Suppose I'm a team member on this project, and I'm working from the objective statement given in the opening of this section. I understand that the move is taking place on two separate days, and I've planned my tasks with this understanding in mind. But you, the project manager, know that the move from our two existing locations must occur on the same day. The first problem with this scenario is a lack of communication between the project team and the project manager, but that's another chapter. The second problem is that the goal is not stated clearly enough; it probably wasn't written down nor was it communicated to everyone involved on the project. So, let's fix it.

SMART Goals

SMART project managers document the goals of the project and communicate them to all the team members and key stakeholders. You may have seen this acronym before, but it's one that we should review again. Goals should be SMART: specific, measurable, accurate and agreed to, realistic, and time bound. Each of these is explained in a little more detail below.

S = Specific Goals should be specific and stated in clear, concise terms. This means that if you were to leave the company somewhere in the middle of the project (not a recommended career move), another project manager would be able to read and understand what the goal is without confusion.

M = Measurable Goals are measurable. The results of the goal are verifiable through some means. This could include everything from complicated formulas and measurements to a simple determination that yes, the result occurred, or no, it did not.

A = Accurate and Agreed To The goal should be stated accurately so that you don't end up measuring the results incorrectly. (This also ties to the goal being specific.)

Goals should be agreed to. You'll want to gain consensus and agreement from the key stakeholders on the goals of the project. This assures that everyone understands what the final outcome is and will work toward that end.

R = Realistic Goals must be realistic. If both of the existing offices need to move on the same day to the new facility and there is only one moving van available, the goal is not realistic. (You would discover this problem during the Planning process and as a result would have to come back and revise your goals and thus the scope statement.)

T = Time Bound Goals must have a time frame that they're completed within, that is, an established end date. Just as projects have a definite end date, so do goals.

Now let's take another stab at writing a goal statement for this project using the criteria we just learned. "Move the existing staff from the Third Street location and from the Washington Street location on March 4 to the new Logan Street location with no disruption in services to our customers."

This statement meets all the requirements of a goal. It's specific because it states who, when, and where, and it's written clearly and concisely. It's measurable because the move will either occur or it will not. The service-disruption part of the goal statement is measurable also. It's accurate, attainable, and agreed to by all the key stakeholders. The goal is realistic, and it's time-bound by the March 4 date.

I like having one, over-arching goal for the project like the one stated in the previous paragraph. In one sentence, this statement conveys exactly what the purpose of the project is and what we hope to accomplish. It's concise and clear. This is a great motivator to print on attractive paper and hang in prime locations where team members, stakeholders, and management will see it often.

  Note 

A single goal statement keeps the team focused on the end result of the project. It's the reason they're assigned project activities—and all project activity should ultimately concern meeting the project goal.

Now that everyone understands the goal of the project, it's time to move on and establish the deliverables.

Deliverables

deliverables

The specific items or services that must be produced in order to fulfill the goals of the project.

Deliverables include measurable results, measurable outcomes, or specific products or services that must be produced in order to consider the project complete. Deliverables, like goals, should be specific and measurable.

You can apply the same SMART criteria to deliverables as you do to goals. The clearer and more specific you make the deliverables, the easier it will be to plan and estimate project activities and communicate assignments. Deliverables are like mini-goals in that they describe what it is you're producing or going to accomplish. When all the deliverables are completed, the goal of the project is accomplished.

Now back to the Logan Street Move. Knowing that our goal is to move the staff on a specific day, we can start to document some of the more obvious deliverables needed to make the move happen. Here are a few:

Each of these deliverables requires some type of action, and each has a completion date. They are measurable and verifiable and have specific results that will allow us to determine whether the deliverable was completed. Keep in mind that this list does not contain all the deliverables you'd have for a project like this. I've listed only a few of them here to give you an idea of what they may look like. An actual deliverables list for a project like this would be much more extensive.

You may be thinking that the deliverables for a project like this look fairly easy to come up with, but what about very large, complex projects? Are they all lumped in together or somehow segmented? I'm glad you asked. That leads us right into the next discussion of project phasing.

Phasing Multiple Deliverables

Suppose the executive management team decides that the upcoming move is the perfect opportunity to reorganize the departments and reporting structures, one of their favorite activities (but don't tell them I said that). They're convinced that this activity is part of the overall project, but you as project manager are convinced that it's a separate project. What should you do? Well, you can compromise.

Consider structuring the project, and the project plans, as a project with two phases. The completion of phase one, the reorg project, becomes a deliverable and an input into phase two, the move project. Therefore, phase one must be completed prior to the activities beginning in phase two. (But we're getting ahead of ourselves as these are scheduling issues, and we'll cover those in Chapter 8, "Developing the Project Plan.") I'd recommend having two goals in this case, one goal for the reorg phase of the project and another goal for the move phase. Deliverables should be associated with the appropriate goals as well.

Many large, complex projects have phased deliverables. For instance, phased projects are very common in the Information Technology arena. Users might decide that new programs are needed to capture data that's produced as the result of new business processes and equipment. However, due to resource limitations or budget constraints or both, only the most critical pieces of programming can be completed in phase one. The users, or stakeholders, and the project manager will work through each deliverable, determining which ones are critical to accomplishing the goals of the project and which ones can be delayed to phase two. If money and resources were no object, the project could be completed all at once, but this is rarely ever the case.

  Note 

Excellent project management techniques applied to the wrong goal or deliverables will result in an unsuccessful project.

Keep in mind that no matter how good you are at applying project management techniques and managing your team, if you're working toward the wrong goals or the wrong deliverables, your project will not be successful. It's very important that you spend the time to define the project goals, deliverables, and requirements and then get agreement and sign-off. Our goal for the Logan Street Move project would not be successful if employees arrived on Monday morning and found that they had no computers or telephones to work with. The project couldn't be considered successful because the lack of computers and phones would definitely cause an interruption in customer service.

Discovering Requirements

requirements

The specifications of the deliverables broken down to their most basic components.

Requirements are different than goals and deliverables. That is, they help define how we know the goal or deliverable was completed successfully. If our project involved building a new car model, for example, one of the requirements might be body style or paint color.

As you might have guessed, requirements are a further breakdown of the deliverables that describe very specific details regarding the deliverable. One deliverable could have multiple requirements, while another deliverable may not need a further breakdown since its description is adequate on its own. As the project manager, you'll have to determine whether you have enough information in the deliverable description to produce the product or service or you need more information to make certain you meet the project requirements.

Defining requirements, and defining deliverables as well, should not be done in a vacuum. This is not the sole responsibility of the project manager. In fact, requirements-gathering is primarily a user or stakeholder function. The project manager should facilitate the process, but you really need your customer or stakeholder to tell you what you're building.

Requirements Gathering Process

Requirements-gathering should be a group effort. Sometime shortly after the project kickoff meeting, set up a meeting or series of meetings to determine and document the project requirements. Primary stakeholders and key team members are the folks who should attend. Reserve a conference room with a white board and give yourselves plenty of room to spread out.

Remember to set an agenda for the meeting. I'd also recommend sending a copy of the project charter to all the people who will be attending several days prior to the meeting. This will give them a chance to review the project objective and begin thinking about requirements. At this point, ask whether other stakeholders need to be identified and included in the process. Now is not the time to forget someone important. There's nothing more frustrating than to have progressed a third of the way through your project activities only to discover that you forgot an important stakeholder back in the beginning and now have a new set of deliverables to deal with and squeeze into the project schedule.

Conducting the Meeting

Once the meeting has begun, review the project charter with the group. Ask for questions and clarify any concerns up front. Make certain, to the best of your ability, that everyone has the same understanding of the goals of the project.

Next, examine the deliverables (if they were defined prior to this meeting). Provide everyone a printed copy of the list you've compiled so far. If deliverables were not identified prior to this meeting, this is your starting point. Ask the participants to name the major deliverables for the project (or identify missing deliverables from the current list) and start writing them down. This is a simple brainstorming session where everyone is encouraged to participate and say anything that comes to mind.

You can use several other techniques, in addition to or in place of brainstorming, to get the requirements process rolling. (These techniques are applicable to determining the major deliverables as well.) One technique is to send surveys to the key stakeholders prior to the meeting, asking them to list their requirements. Or you could use an interview process if there are only a few key stakeholders involved. One of my favorite techniques is the sticky note process. Everyone in the room is supplied with a sticky notepad and a marker. Ask the participants to place one, and only one, requirement or deliverable per sticky note, being as precise as they can. You'll act as facilitator and gather the sticky notes, placing them on the white board as they're turned in. Eventually, a pattern will emerge, and you can group similar requirements together, eliminate duplicates, and so on. Tell the stakeholders to not hold back anything. They should list everything they could ever want or dream regarding this project at this stage. We'll discuss more information-gathering techniques in Chapter 7, "Assessing Risk."

  Note 

Requirements are the lowest common denominator and cannot be broken down further.

Requirements are the last stop in describing the deliverables and cannot be broken down further. For instance, a requirement for one of the deliverables in our move project might read something like this, "All moving cartons must contain labels on the top and one side."

Some other examples of requirements for the Logan Street Move are shown below:

When you're defining requirements, make certain to take into account business rules and policies. A business rule is something that must occur in a specific fashion or is a result of a policy or regulation. As an example, a business rule for a financial institution might state that all loan requests over a specific amount must be approved by a vice president. A business rule for the building move project might say that only the IT contract employees may move the computers.

Here's where the lines begin to blur between deliverables and requirements. Deliverables may already be broken down to the lowest level, in which case you could consider them either deliverables or requirements. For example, the deliverable we listed earlier called "Connect and test all telecomm and network equipment by 6 A.M. March 4" really can't be broken down any further. The "Provide boxes and labeling instructions to all employees by February 7" deliverable, on the other hand, may have requirements associated with it including, "All labels must list the owner's last name and room number in the new building."

Again, don't get too hung up on deliverables versus requirements. The main point is that you document what needs to be done in order for the project to be successful. Remember that deliverables are the specific items or services that must be produced in order to consider the project successful, and requirements are the specifications of the deliverables or project goals. As long as you've diligently tried to uncover all the deliverables and requirements and then recorded them, you're well on your way to creating better project planning documents. Believe it or not, I've seen projects kicked off and conducted on nothing more than verbal requirements. Should I tell you all the gory details about what happened to those projects and the project managers working on them? No, I don't think so. Document the deliverables and requirements even if the project is going to take you only a day or two to complete. It eliminates misunderstandings and saves your bacon when the stakeholder comes back and says, "That's not what I wanted." We'll talk more about that in a coming section.

Save Good Ideas for Phase Two

business rule

Constraints to the project that are determined by company policy or institutional regulation.

You may discover new deliverables during the requirements-gathering phase or requirements that are considered "nice to haves" but not necessary for the completion of the project. You probably do not have an unlimited budget or unlimited resources, so the next and last step in the requirements-gathering process is to determine which requirements are necessary to meet the goal of the project. All others should be weeded out. But don't throw them out the window. Document these requirements as the phase two portion of the project, or ask the stakeholders to keep them on hand and request a new project when this one's completed. You went through a lot of hard work to flesh out everything desired for the project, so don't let those efforts go to waste. You could also consider filing a copy of the additional requirements in an appendix of your project notebook. This is not something I'd necessarily publish on the intranet, but the additional requirements should be kept somewhere for future reference. Now on to more critical issues.

Critical Success Factors

critical success factors

The project deliverables or requirements that absolutely must be completed and must be completed correctly to consider the project a success.

You have one more thing to document regarding your deliverables and requirements, and those are the project's critical success factors. Critical success factors include project deliverables, but not all deliverables are critical success factors. You should gain consensus among your requirements-gathering team and the stakeholders regarding which deliverables and/or requirements are critical success factors and then either document them separately or somehow indicate which ones are the critical success factors.

Some of the things I consider critical success factors for all projects include the following:

Critical success factors should not be overlooked. If circumstances come up later during the project that are outside of your control, forcing a schedule, scope, or quality change, it's important for you to understand which deliverables must be completed and which ones could move to phase two if necessary. This is where your critical success factors list comes into play. When you're faced with this circumstance, review the critical success factors with the key stakeholders and project team to make sure they still are critical to the project, and begin making project plan adjustments and taking corrective action from there.

Some of the critical success factors for the Logan Street Move might include those shown in the list below. Keep in mind that this is not a complete list, just a sample to give you an idea of why these elements were chosen as critical success factors.

The deliverable below is not a critical success factor. Here's the reason:

Now, suppose the floor plan mentioned in the noncritical deliverable above was also being used by the computer specialists moving and hooking up the computers. In that case, this deliverable now becomes a critical success factor because the specialists are relying on the floor plan to determine where each computer gets placed. I think you're getting the hang of it. Don't, however, make the mistake of assuming that the computer specialists have a network diagram with all locations marked. And that brings us to one more piece of documentation for the scope statement: assumptions and constraints.

Identifying Assumptions and Constraints

assumptions

An event or action believed to be true. Project assumptions should always be documented.

Remember the old saying about assumptions? Well, throw it out because in project management you want to make assumptions, but here's the key. Are you ready? You should document all project assumptions. You'll want to document assumptions regarding people, resources, places, things, or anything that you presume is going to perform in a certain way, or be available at a certain time, and so on. This is a critical step that's often missed in the project planning process. That's too bad because misunderstanding assumptions, or believing something to be true that isn't, can kill your project.

This is an often missed step because we tend to take things for granted, thus assuming business as usual. When you leave work for the evening (assuming you're driving a car), you walk out to your car, put the key in the ignition, and assume that the car is going to start. It's not really something you think about because the car starts every day—that is, until the day you put the key in and nothing happens when you turn it. Then the diagnosis process begins…battery, starter, alternator…or crisis mode sets in. "Oh my, little Sweet Pea is at day care and I have to be there in twenty minutes!"

Project assumptions work the same way. We're so used to operating a certain way or expecting the A team to drop what they're doing and lend a hand whenever we need it that we don't think about it, until the day they're not available. Don't skip this step—be certain to define and document your assumptions and communicate them to the project team and stakeholders.

Defining Assumptions

Assumptions presume that what you're planning or relying on is true, real, or certain. For example, your project might require someone with special programming skills from the IT department. Your assumption is that this person will be available when needed and will exercise their skill on the activity you assign. Document the assumption that this person will be available when needed. (Oh, it's a good idea to check with that person's functional manager ahead of time to make certain that they will be available when needed.)

Discovering and documenting assumptions works just like the requirements-gathering process. Designate one of your project meetings, or a portion of one of the meetings, to discuss and document project assumptions. Use brainstorming techniques in the meeting to get the juices flowing. You could also interview key stakeholders, the project sponsor, and key members to uncover as many assumptions as you can. We'll revisit these assumptions again when we get to the risk planning process in Chapter 7. Risks are associated with assumptions in many cases, so if you do a good job defining the assumptions, you'll have a good head start on risk identification. Sometimes it's helpful to have someone outside of the project help with this step because they are not as focused on the details as you are. They may see something you wouldn't.

Assumptions might include any of the following:

Okay, let's assume that you've documented your assumptions. The next step is to validate and verify them. This means that if you're assuming that a key resource is going to be available to work on the project, you must verify with that person's functional manager that they'll be available at that time.

If you're working with vendors or suppliers on your project, make sure that they document and verify their assumptions as well. In fact, if a vendor delivery is one of your critical success factors, make sure that they document assumptions concerning that delivery. In the Logan Street Move project, we're relying on a moving contractor to show up on the right day with three trucks at each location and enough workers to load everything and get it moved in one day. Consider putting a clause in the contract that says the moving contractor will pay the cost of hiring temporary laborers or leasing rental trucks if for any reason their own trucks are not available (due to mechanical problems, etc.) or their regular work force is not available (a strike, sick-out, etc.). We'll discuss more situations like this when we talk about risk and risk response plans.

Assumptions should be documented in your project notebook. They will be incorporated into the scope statement, as you'll see shortly, but it wouldn't hurt to copy and paste them into their own document and keep them handy. You will want to verify and validate these assumptions throughout the course of the Planning process and whenever necessary during the project Executing and Controlling phases.

Defining Constraints

We talked about constraints in Chapter 1, "Building the Foundation." Remember that constraints are anything that restricts or dictates the actions of the project team. That can cover a lot of territory. The triple constraints—time, resources, and quality—are the big hitters, and every project has one or two, if not all three, of the triple constraints as a project driver. Many projects in the Information Technology area, for instance, are driven by time. Projects in the pharmaceutical industry are driven by quality but may have time or resources as a secondary constraint.

The Logan Street Move project is constrained by time. We must move on March 4. The secondary constraint for this project is budget—there is a limit to how much we can spend. What you want to do now is to document the project constraints. And yes, you can use the same techniques we've already discussed for deriving project requirements and assumptions.

Besides the triple constraints, don't overlook constraints like these that can cause problems on your project:

Constraints, like assumptions, are also documented in the scope statement. These should be updated as you progress through the project to make adjustments to the constraints you've listed, add new ones that may come up along the way, or delete those that are no longer a constraint. Sometimes you'll find that constraints are also project risks and may need risk response plans. We'll talk more about risks in Chapter 7.

Creating the Scope Statement

scope statement

Documents the project goals and deliverables and serves as a baseline for future project decisions.

Everything we've talked about in this chapter so far, including goals and objectives, deliverables, requirements, constraints, and assumptions, goes into the scope statement. The purpose of the scope statement is to document these items, particularly the goals, deliverables, and requirements, to use as a baseline for the project. As you proceed through the project life-cycle phases, you'll be faced with decisions and changes that you'll want to monitor so that they conform to the original scope of the project. In this way, the scope statement is your map, or baseline, that you use to determine where you're going. If questions come up or changes are proposed, the scope statement is the first place you're going to check to make certain that what's requested is in keeping with the original request.

Creation of the scope statement is one of your most important duties as a project manager. Accurately quantifying the deliverables and detailing the requirements of the project and then getting agreement and sign-off on these deliverables helps assure project success. Creating the project schedule, which we'll cover in Chapter 8, probably ties in importance with creating the scope statement.

  Note 

Creating the scope statement and project schedule are two of the most important duties a project manager performs.

The scope statement establishes a common understanding of the project's purpose among your team members and stakeholders. It contains the criteria you and the stakeholders will use at the end of the project to determine whether the project was completed successfully. The scope statement will assist you later in determining project cost estimates, resource estimates, activity definition, and project schedules.

Contents of the Scope Statement

You'll use the project charter and the product description to help you write the scope statement document. It's interesting that this is called a scope statement when in fact several elements actually make up the scope statement. It isn't a single statement but several pieces of information contained in one document. If you've followed this chapter in order, most of the work for your scope statement is already done. You understand the product of the project (from the project charter), you know the goals and deliverables, and you have the assumptions and constraints documented. Now it's a matter of putting it all together in one document.

The components of a well-documented scope statement include the following:

We've covered most of these items in detail. We'll talk about time estimates in Chapters 5 and 8 and we'll cover cost estimates in more detail in Chapter 9. At this point, if you have high level information regarding time and cost estimates, include it in the scope statement with a note explaining the estimates are not final. These will be refined later when we more clearly define the work of the project. The list of exclusions from scope and roles and responsibilities needs a little more explanation.

List of Exclusions

Exclusions are the deliverables or requirements the team identified as not essential to completing this portion of the project. Exclusions from scope for the Logan Street Move project might include setting up the executive management team's office decoration and furnishings, reorganizing the IT department as a centralized service unit, etc. It's important to note what's not included in the project so that there's no misunderstanding later on when those particular deliverables don't show up or don't get done.

Roles and Responsibilities

The roles and responsibilities section in the scope statement is much more detailed than what you defined in the project charter. Here you'll want to identify who is responsible for what. You'll document who has signing authority, who should review, who should create, etc. A sample portion of a responsibility chart is shown in Table 4.1 below.

Table 4.1: Roles and Responsibilities Chart

Activity

Assigned

Responsibility/Approval Level

Scope statement

Project manager

Create
 

Stakeholder

Approve
 

Sponsor

Approve
 

Project team

Review
 

Functional managers

Review

WBS

Project manager

Create
 

Stakeholder

Approve
 

Sponsor

Approve
 

Project team

Review
 

Functional managers

Review

Project schedule

Project manager

Create
 

Stakeholder

Approve
 

Sponsor

Approve
 

Project team

Review
 

Functional managers

Review

Scope Statement Template

The following graphic pulls everything together. You can use or modify this template for your future project scope statements. It contains all the elements we've talked about so far plus an area for signatures.

statement of work (SOW)

Contains the details of items purchased on contract and includes the project objectives, a description of the work of the project, and concise specifications of the product or services required.

The scope statement also gets filed in your project notebook and should be published on the project intranet site if you have one.

When your project work is done on contract, the scope statement can serve as the statement of work (SOW). The statement of work is part of the contract. The SOW contains the same details as the scope statement and is used to describe the work of the project in clear, concise terms. You'll specify the product or service required here (the goals of the project) and the deliverables and requirements. I would consider adding a list of key stakeholders, an organization chart, time frames or deadlines, and an initial project schedule to this template if you're using it as a SOW.

The contractor will use the SOW to determine whether they're able to produce the product or service of the project, so it should be as detailed and clear as possible. Either the buyer or the seller can prepare the SOW, but both parties must review and approve it.

Obtaining Sign Off

Does there seem to be a recurring theme throughout the project documents so far? Yes, you're right, there is—describe the nature of the project, the goals, what we hope to accomplish, and obtain sign-off.

The scope statement, like the project charter, should be signed off. This assures that stakeholders, key management team members, and the project sponsor are all in agreement on the deliverables and requirements of the project. I've witnessed many projects (none of them mine, of course) where the project manager failed to obtain sign-off on the scope statement. And, you guessed it, as the project progressed, memories became very fuzzy and stakeholders thought for sure that requirement X was part of the original plan, while the project manager swore up and down it was part of phase two. If you cannot resolve this situation and end up having to include the new requirement in this project, it usually means that you're going to miss the original planned deadline or run over budget or both. Don't let that happen to you. Document the deliverables and requirements. When a stakeholder comes to you and tries the very famous "I thought that was included," line (most of them could win an Oscar for their performance delivering this line to you), you can politely point them back to the scope statement and remind them that, in fact, that requirement is not part of this project.

The next line you'll likely hear is something like this, "Well, requirement X has to be included. It's essential to the success of the project." One of two things are happening here—okay, maybe three. First, the project manager didn't do a thorough enough job gathering requirements and the stakeholders failed to point out the missing requirements when they reviewed and signed the document. Second, the stakeholder is purposely being a troublemaker and withheld the information during requirements gathering…just because. Third, the stakeholder really never thought about this particular requirement until now. This means that you now have a scope change on your hands, and that brings us right to the next section—the scope management plan.

Creating the Scope Management Plan

scope management plan

Describes and documents how changes to project scope will be managed.

The scope management plan describes what process requestors must go through to request changes and how the changes will be incorporated into the project. The scope management plan also tries to determine the probability of scope changes, their frequency, and their impact. This process will get easier as your experience in project management grows. You'll begin to know what types of changes may occur because of the experience you gained working on projects where change occurred. Don't forget to file a copy of the scope management plan in your project notebook.

As you progress through the project, changes to project assumptions, scope, schedules, and so on make it necessary to repeat some project processes, particularly the planning processes. That's not a bad thing; it's part of applying good project management techniques to your project. One thing that will most certainly occur on your project is change. How you manage and communicate those changes will determine project success. We'll discuss more about scope changes and the change control processes in Chapter 11, "Controlling the Project Outcomes."

We have one more document to cover in this chapter and that's the communications plan. Let's take a look at what that entails.

Creating the Communications Plan

communications plan

Documents the types of information needs the stakeholders have, when the information should be distributed, and how the information will be delivered.

We've done a quite a bit of documentation already, so it's probably a good time to talk about the communications plan. The communications plan describes who gets what information and when. The who includes stakeholders, project team members, customers, management staff, and others who may have a specific interest or role in your project. The what includes the project documentation, project plans, status reports, status review meetings, scope statement and scope statement revisions, performance measures, acceptance criteria, change requests, and more. And, of course, the when describes how often the communications are produced, when status review meetings are scheduled, and so on.

The communications plan is documented early on in the Planning process. You want to identify all the people who need to know and understand the project progress as early in the project as possible. The communications plan also documents how to collect, file, and archive project communications as well as the distribution methods you'll use to get the information to the stakeholders. This includes how stakeholders can get access to project communication between the established publish dates.

You can create the communications plan in a simple document format listing the who, what, and when like the example template below. Distribute a copy of the plan to everyone listed in the document. This document is a good place to note the location of the intranet site and the types of information people can access there. Figure 4.1 provides a template for such a document.

List all the project communications on this template such as status reports, minutes, change requests, the project planning documents, etc. Identify the people who will receive copies of the communication and how the document will be published. Some information might be distributed via e-mail, others posted to the intranet site, etc. Note how often the information will be distributed and who is responsible for preparing the information. Post the communications plan to the intranet site or file a copy in the project notebook.

Now that we've created the scope statement, we're off to the next stop in the Planning process, which is the identification of tasks and activities. We'll cover that and related topics in Chapter 5, "Breaking Down the Project Activities."

Terms to Know

Review Questions

1. 

What criteria should you use to define project goals?

____________________________________________________________

2. 

Describe project deliverables.

____________________________________________________________

3. 

How are requirements different than deliverables or goals?

____________________________________________________________

4. 

What are critical success factors?

____________________________________________________________

5. 

Why are assumptions often overlooked in the project planning process?

____________________________________________________________

6. 

Name three potential constraints for projects other than the triple constraints.

____________________________________________________________

7. 

What is the purpose of a scope statement?

____________________________________________________________

8. 

What is the purpose of the scope management plan?

____________________________________________________________

9. 

Why is it important to obtain sign-off of the scope statement?

____________________________________________________________

10. 

What does the communications plan document?

____________________________________________________________

Answers

1. 

The acronym SMART describes the criteria for defining project goals. That is, goals should be specific, measurable, accurate and agreed to, realistic, and time bound.

2. 

Deliverables are the specific items or services that must be produced in order to fulfill the goals of the project. Deliverables must have measurable results and measurable outcomes, or they must detail specific products or services to be produced. Deliverables, like goals, should be specific and measurable.

3. 

Requirements are the specifications of the goal or deliverable. They describe the characteristics of the deliverable. Requirements cannot be broken down further, whereas goals and deliverables can.

4. 

Critical success factors are the things that absolutely must be completed correctly in order to consider the project a success.

5. 

Assumptions are often overlooked because we presume that things will continue to operate in the future as they have in the past. We assume that key team members will be available or vendors will deliver on time because they have in the past. These items should be documented so that you can develop a plan to deal with the assumptions with severe impacts later on in the project Planning process.

6. 

Lack of commitment from the executive team or project sponsor, poor communications, and unrealistic expectations of project outcomes can also hamper a project.

7. 

The purpose of the scope statement is to document the goals, deliverables, and requirements of the project. The scope statement will be used as a baseline for future project decisions and as the criteria for determining project success when the project ends.

8. 

The scope management plan documents how changes to project scope will be requested, processed, and implemented on the project.

9. 

Sign-off of the scope statement ensures that all the stakeholders are in agreement of and support the goals, deliverables, and requirements of the project. It also serves as a handy reminder when memories get foggy later in the project. The project manager can refer back to the scope statement to determine whether the request is a change or is part of the original requirements.

10. 

The communications plan documents who will receive project communications, how they will receive them, when they will receive them, and how to access project information. It also describes how project information will be collected, stored, filed, and archived.

Related

Категории