The people at Ranch Hand Games have been working hard for over a year on the sequel to their most successful title, Cows Gone Wild. It seemed like the project would never end...

Since it took so long to get this version out, it’s already time to start working on the next version. But nobody wants to see that project spin out of control the way it did last time.

Brian: The project rocked in the beginning. We brought in some really talented programmers so that we could handle all of the technical challenges that might come up. We spent all that time whiteboarding and working our way through the technical issues in design. It really felt like this game was going to be amazing and fun to build. What went wrong?

Amy: We got sidetracked all over the place. Remember what happened with the website? We spent months making that site look just like the game. It got to the point where it actually looked a lot better than the game did.

Brian: Yeah, you’re right. And there were all these changes along the way—the story got updated like a thousand times. It was nuts.

Amy: I remember that. What a mess.

Brian: Totally. Oh man, and that time we realized you had to redraw all the artwork for the Haymaker level? We all slept in the office for like a week!

Amy: Right...um, so what’s gonna keep that from happening this time?

Exercise Solution

Here are some answers that are good for dealing with these scenarios.

All of the major problems on Cows Gone Wild II were scope problems. The website was bloated with features that were added on late in the project. The creative team kept realizing that they had to do a lot more work. These are classic scope problems.

You always want to know exactly what work has to be done to finish your project before you start it. You’ve got a bunch of team members, and you need to know exactly what they’re going to do to build your product. So how do you write down the scope?

That’s the goal of the six Scope Management processes. They’re about figuring out how you will identify all of the work your team will do during the project, coming up with a way to make sure that you’ve written down what work will be done and nothing else!, and making sure that when things change on your project, you keep its scope up to date so that your team is always building the right product.

That’s a good idea. But what happens if they miss something?

It often seems like you should just be able to get everyone in the same room when the project starts and just hash all this stuff out. But it’s really easy to miss something, and it’s even easier for a team to get sidetracked.

It’s way too easy for people to go off track and start doing things that don’t really contribute to the project—like building the website for a video game instead of building the game itself.

When you take control of your project’s scope, you’re doing more than just planning. It turns out that when projects have scope problems, the results are actually pretty predictable. Take a look at these problems that the Ranch Hand team ran into. Do any of these sound familiar to you? Many project managers run into similar problems on their own projects.

Each of the Scope Management processes was designed to help you avoid the kinds of scope problems that cause a lot of projects to go off track. One of the best ways to remember these processes for the exam is to understand why they’re useful, and how they solve the kinds of problems that you’ve seen on your own projects.

Project Management plan

Plan Scope Management

Here’s where you write down the subsidiary plan for the project management plan that we talked about in the last chapter. You plan out all of the work you’ll do to define your scope, make sure the team is planning to do the right work, and control it.

Requirements documentation Change requests

Collect Requirements

In this process, you find out all of the stakeholders’ needs and write them down so that you know what to build and your requirements can be measured and tracked.

Project scope statement

Define Scope

Here’s where you write down a detailed description of the work you’ll do and what you’ll produce.

Work breakdown structure

Create WBS

The work breakdown structure (WBS) organizes all of your team’s work into work packages—or discrete pieces of work that team members do—so that you can keep the momentum of the project going from the start.

Change requests

Control Scope

We already know how important it is to control changes on your project. When scope changes aren’t controlled, it leads to the most frustrating sort of project problems. Luckily, you already know about change control, and now you can use it to manage your project’s scope.

Accepted deliverables

Validate Scope

Once the work is complete, you need to make sure that what you’re delivering matches what you wrote down in the project scope statement. That way, the team never delivers the wrong product to the customer.

Here’s where you figure out how you’ll approach defining and validating the scope of your project. The Plan Scope Management process is where you lay out your approach to figuring out what work you’ll do and what’s out of scope. All of the other processes in the Scope Management knowledge area are defined and described in this document. It’s the blueprint you’ll use for everything else you’ll do to manage scope through the project.

Planning process group

Outputs

There are two outputs of the Plan Scope Management process: the Scope Management plan and the Requirements Management plan. Both of them help you define the scope of your project and make sure that you and your team are focused on only the work that will help you satisfy your customers’ needs. The Scope Management plan keeps you on track by detailing the processes you and your team will follow as you document your scope, figure out your work breakdown structures, and validate and control your scope for the rest of the project.

Requirements Management plan

Here’s where you’ll find a description of the approach the team will take to planning, tracking, and reporting on requirements. You’ll use this document to describe the prioritization process for requirements, and how you’ll build a traceability matrix for your requirements as well.

Scope Management plan

Here’s where you write down the subsidiary plan for the Project Management plan that we talked about in Chapter 4. You plan out all of the work you’ll do to define your scope, with the right work planned for the team, and control it.

Brian: So we finally hired a project manager. Welcome aboard!

Amy: I’m glad they brought you in to help fix this mess.

Brian: So what are you gonna do to help us? Because I don’t see what you can really change.

Mike: Thanks for the vote of confidence. Look, I might not be able to fix everything, but we should be able to keep this scope under control.

Brian: Sure, you say that now. But we all thought the last project would go fine too, and that one was a real pain!

Mike: Well, did you gather the requirements for your last project?

Amy: No, but we’ve built video games before and we knew basically what we needed to do when we started out.

Mike: It sounds like that wasn’t enough.

Planning process group

Gathering requirements is all about sitting down with all of the stakeholders for your project and working out what their needs are, and that’s what you do in the Collect Requirements process. If your project is going to be successful, you need to know what it will take for all of your stakeholders to agree that your project has met its goals. You need to have a good idea of what’s required of your project up front, or you’ll have a tough time knowing whether or not you’re doing a good job as you go. That’s why you need to write down all of your project and product requirements with enough detail that you can measure your team’s progress.

The Collect Requirements process involves talking to the people who are affected by your project to find out what they need. All of the tools in this process are focused on getting your stakeholders to tell you about the problem that the project is going to solve. Sometimes that means sitting down with each of them one-on-one, and other times you can do it in a group setting. One of the most important things to understand about requirements is that every requirement fulfills a specific stakeholder need. Lucky for you, a lot of those needs are already written down—in your business case document.

But that’s not the only place you’ll find requirements, so here are three really useful tools and techniques to help you gather requirements:

Interviews are important ways to get your stakeholders to explain how they’ll use the product or service your project is creating. By talking to people one-on-one, you can get them to explain exactly what they need so that you can be sure that your project can meet its goals.

Focus groups are another way to get a group of people to discuss their needs with you. By letting a group discuss the end product together, you can get them to tell you requirements that they might not have thought of by themselves.

Facilitated workshops are more structured group conversations where a moderator leads the group through brainstorming requirements together. In facilitated workshops, misunderstandings and issues can get reconciled all at once because all of the stakeholders are working together to define the requirements.

Requirements Up Close

A big project usually has a lot of stakeholders, and that means a lot of opinions. You’ll need to find a way of making decisions when those opinions conflict with each other. There are four major decision-making techniques you can choose from. These are referred to as group decision-making techniques on the test.

Exercise

You’ll need to know the difference between the four different decision techniques for the exam. Here are the minutes from a facilitated workshop that the CGW team held with all of its stakeholders. Identify which decision-making technique was used in each case.

1. The group voted on the CCG (cud-chewer gun) five times, but decided not to include it because they couldn’t get everyone to agree on it.

	Unanimity		Plurality
	Majority		Dictatorship

2. The VP of Engineering told everyone that they had to come up with a new character for Team Guernsey. Since he’s the highest-ranking person in the room, nobody argued with him.

	Unanimity		Plurality
	Majority		Dictatorship

3. There were 10 new scenery suggestions up for approval, but only 5 could make it into the game. The team chose the top 5 in a general vote.

	Unanimity		Plurality
	Majority		Dictatorship

4. Over half the group wanted to see a new story that involved Farmer Ted. So that requirement was recorded as an absolute necessity.

	Unanimity		Plurality
	Majority		Dictatorship

Answers: 1. Unanimity 2. Dictatorship 3. Plurality 4. Majority

Getting your team to think creatively can help you create a better product from the start. Group creativity techniques are all about getting those creative juices flowing while you gather your requirements.

Idea/mind maps are a good way to visualize the way your ideas relate to each other. When you’ve finished working through an idea, it sometimes helps to create a map of how you got there and show which ideas can be grouped together.

The Delphi technique is a way of letting everyone in the group give their thoughts about what should be in the product while keeping them anonymous. When you use the Delphi technique, everybody writes down their answers to the same questions about what the product needs to do and then hands them into a moderator. The questions could be about specific features that the product should have.

When the CGW team used the Delphi technique, here were a few of their questions:

The moderator keeps everybody’s names to himself, but shares the ideas so that everyone can learn from them and think of new ones. After everybody discusses those ideas, they’re given a chance to adjust their original answers to the questions and hand them back in to the moderator. These iterations continue a few times until the group settles on a list of requirements for the product.

Affinity diagrams are great when you have a lot of ideas and you need to group them so you can do something with them. A lot of people make affinity diagrams using Post-it notes on walls. That way, you can move the ideas around and change the groupings when you think of new areas to explore. Sometimes just putting requirements in categories will help you to find new ones.

The nominal group technique is a form of brainstorming where you write down the ideas as you find them and have the group vote on which ones they like the best. You then use the votes to rank all of the ideas and separate the ones that aren’t important from the ones you want to delve into deeper.

Context diagrams help your team show the way all of the processes and features in your product scope relate to each other. It’s a picture of the scope of your product that shows how users will interact with it.

Brainstorming is one of the most commonly used ways of collecting requirements. Whenever you sit a group of people down to think of new ideas, you’re brainstorming.

Benchmarking is a way of comparing the processes and practices used in building your software with the practices and processes in other organizations so you can figure out the best ideas for improvement.

Document analysis is a way of collecting requirements by reading through all of the existing documents for your product.

The Cows Gone Wild development team needed to talk to the people who play their games to figure out what would make the gamers happy in the next version. The team obviously couldn’t go around to every customer’s house asking questions, so they wrote a questionnaire about new possible features for the game that they sent to gamers who had registered the game.

When it was time to start collecting requirements for the new version, the team started with all of the data they’d gathered from those surveys and did some analysis to figure out which features were most important to the gaming community. Here’s an excerpt from their survey results:

Cows Gone Wild II Registration Survey Results

The Cows Gone Wild series released Cows Gone Wild II three months ago. Since then, we’ve sold 500,000 copies of the game. Of those sales, 350,000 have been registered and 100,000 have responded to the CGW III requirements collection survey. Here are the results:

Artwork:

Which new environments would you like to see included in a follow-up to the game?

Sometimes observing the people who will use your product while they work with it will give you a better idea of how to solve their problems. People don’t always know what to say when you ask them for requirements, so watching them deal with the problem your product is going to address can help you to find requirements that they might not tell you about on their own.

Sometimes the best way to get your stakeholders to give you an opinion on what your product should be is to show it to them in a prototype. Prototypes are models of the product that you’re going to build that give your stakeholders a better idea of what your team is thinking. Sometimes users who are experimenting with a prototype will come up with a brand new requirement that they never thought of before. If you can get them to find it in the prototype, it’s a lot easier to deal with than if you wait until the end of the project to show to them. When you’re making a really complicated product, it can make sense to prototype it as part of the requirements collection process so that you can find changes that your users will ask for early on.

Prototypes are a great tool if you’re developing your project using iterative techniques. If you’re using agile software development processes or defining requirements in phases, prototypes are a great way to keep your stakeholders involved in the project and get their feedback on changes that might be needed.

The outputs of the Collect Requirements process are the requirements document and a requirements traceability matrix, which allows you to follow the requirements from the document through implementation and verification.

Outputs

The requirements document needs to list all of the functional and nonfunctional requirements of your product. Functional requirements are most of the kinds of things that you think of right away: new features, bug fixes, and new or different behavior. Nonfunctional requirements are sometimes called quality attributes because they’re things that you expect from your deliverables, but aren’t specific features. Some examples of nonfunctional requirements are performance, reliability, error handling, and ease of use.

Planning process group

Now that the Ranch Hand team has a project manager, everything will go smoothly, right? Well, not exactly. Just assigning a project manager isn’t enough to get the scope under control. That’s why you need the Define Scope process. Even the best project managers need to rely on things from the company and the people around them. That’s why the inputs to Define Scope are so important. They contain everything you need to know before you can begin to break the project down into the work that the team members will do.

These are the four tools and techniques of Define Scope.

You already got a head start on defining the project scope when you wrote down the requirements. But now you need to go a lot further and write down all of the work that you and your team are going to do over the course of the project. Luckily, the Define Scope process tools and techniques are there to help guide you through creating the project scope statement (which you’ll learn about in a minute).

Facilitated workshops

Note

You need to figure out what the stakeholders need so you can deliver it to them.

When you do facilitated workshops with your stakeholders, figure out what they need, and write it all down. The reason you do this is because you need to make sure that what you’re delivering really meets the needs of the stakeholders. This keeps the team from delivering a poor product.

An important part of stakeholder analysis is doing your best to set quantifiable goals. That means writing down specific project goals that you can measure, which makes it a lot easier for the team to plan for the work they have to do.

Product analysis

Remember product versus project scope? People naturally think about the product they are making when they start to define the scope. This tool is all about turning those things into project work that needs to be done.

Once the work is complete, you’re going to have to make sure that what you’re delivering matches what you put in your requirements. The better your product analysis is at the start of the project, the happier your stakeholders will be with the product, and the less likely it is that you’ll discover painful, last-minute problems at the end.

Expert judgment

You’ve seen this one before! Bring in an expert to help you figure out what work needs to be done.

Expert judgment

There are no Dumb Questions

Q:	Q: Is product analysis the same as requirements gathering?
A:	A: Not exactly. When people gather requirements, they’re trying to understand what needs the product should fill. Requirements are the contents of the product. When you use product analysis to define the scope of the work to be done, you’re figuring out what deliverables the team needs to work on in order to build your project scope statement. So product analysis is concerned with how the work will be done, not what’s in it.
Q:	Q: What if there is only one way to do something? Do I still need to do alternatives identification?
A:	A: There aren’t too many things out there that can only be done one way, but if you happen across one, then you don’t have to spend much time on alternative identification because there aren’t any alternatives to identify.
Q:	Q: What if a stakeholder can’t tell me how to measure his needs?
A:	A: That can get kind of tricky. Sometimes stakeholders know that they want things to get better, but they don’t know how to tell when they’ve succeeded. You need to work with them to find something that can be measured in their ideas about project success. Without a way to measure your success, you won’t know whether or not you are accomplishing your goals.

After you have done your scope planning, figured out as much as you could using stakeholder and product analysis, and identified all of the possible ways of doing the work, you should be ready to add any new findings to the project scope statement.

Outputs

Planning process group

The Create WBS process is the most important process in the Scope Management knowledge area because it’s where you actually figure out all the work you’re going to do. It’s where you create the work breakdown structure (or WBS), which is the main Scope Management output. Every single thing that anyone on the project team—including you—will do is written down in the WBS somewhere.

You’ve already seen all of the inputs that you need to create the WBS. It shouldn’t be too surprising that you need the requirements document, project scope statement, and organizational process assets before you create the WBS. When you’re developing these things, you’re learning what you need to know in order to decompose the project work.

That’s what they’re there for!

On the next page, you’ll see what a WBS looks like. When you go to build one yourself for your next project, you don’t need to start from nothing. You’ll usually start with a template that you get from the organizational process asset library.

One way to get a clear picture of all of the work that needs to be done on a project is to create a work breakdown structure. The WBS doesn’t show the order of the work packages or any dependencies between them. Its only goal is to show the work involved in creating the product.

A WBS can be structured any way it makes the most sense to you and your project team. The two most common ways of visualizing the work are by deliverable or by phase. Breaking down the work makes it easier to manage, because it means you are less likely to forget work packages that need to be included. This is the same project as the one on the left, but this time, it’s broken down by deliverable.

Creating the WBS is all about taking deliverables and coming up with work packages that will create them. When you do that, it’s called decomposition, and it’s the main tool you use to create a WBS.

Project Scope Management Magnets

Understanding how to build a work breakdown structure is very important for the exam—it’s one of the most important parts of the Scope Management knowledge area. Here’s your chance to create a WBS for Cows Gone Wild III: The Milkening. There are two ways you can break down the work. See if you can use decomposition to do it!

On this page, create a work breakdown structure broken down by project phase.

More Magnets

Oops! Looks like the magnets fell off the fridge. Here’s your chance to practice breaking down the work to create a different WBS using the same magnets as before. But this time, instead of decomposing project phases into work packages, break the project down by deliverable.

On this page, create a work breakdown structure broken down by deliverable.

Project Scope Management Magnets Solutions

You’ve probably noticed that the work breakdown structure only shows you the name of each work package. That’s not enough to do the work! You and your team need to know a lot more about the work that has to be done. That’s where the WBS dictionary comes in handy. It brings along all of the details you need to do the project work. The WBS dictionary is an important output of the Create WBS process—the WBS wouldn’t be nearly as useful without it.

As the project goes on, you will want to compare how you are doing to what you planned for. So, the project scope baseline is there to compare against. It’s made up of the project scope statement, the WBS, and the WBS dictionary. When work gets added to the scope through change control, you need to change the baseline to include the new work packages for that work, so you can always track yourself against the plan.

Yes. When there’s a change you need to take a new snapshot.

Whenever a change is approved through change control, the project scope baseline needs to be updated. Approved changes are changes to the Scope Management plan also, so it’s important that you re-baseline your project when they are approved. That way, you’ll always be comparing your performance to the most updated plan.

The Create WBS process has three major outputs: the work breakdown structure, the WBS dictionary, and the baseline. But there are others as well. When you create the WBS, you usually figure out that there are pieces of the scope that you missed, and you may realize that you need to change your plan. That’s what the project document updates are for.

Outputs

Make sure you finalize the WBS

Before your WBS is done, you need to finalize it. You do this by establishing a set of control accounts for the work packages. A control account is a tool that your company’s management and accountants use to track the individual work packages. For example, Mike gets a list of control accounts from Ranch Hand Games’ accounting department, so they know how to categorize the work for tax purposes.

Everything is great. The project is rolling along, and there are no problems with the scope...until something goes wrong.

Brian: At first I thought we could use the same five backgrounds over and over, but it’s starting to look really stale.

Amy: Huh, I guess you’re right. It looks like we need to create more scenery.

Mike: Why were we trying to limit the backgrounds in the first place?

Amy: I think they were worried about disk space.

Brian: Yeah, but that’s not so much a concern right now.

Amy: Great! Let’s just change the artwork, then.

Mike: Not so fast, Amy. There are a couple of things we need to do first...

Sometimes something completely unexpected happens. Say, a really important customer asks for a new feature that nobody saw coming and demands it right away. Or a design for a feature just isn’t working, and you need to rethink it. Or new stakeholders come on board and ask for changes.

The scope can change while you are working for a lot of reasons. Some changes are good for your project, while others will definitely reduce your chance of success. Change control is there to help you to see which is which.

Good change

A good change makes the product better with very little downside. It doesn’t cost more time in the schedule or more money from the budget, and it doesn’t destabilize the product or otherwise threaten its quality.

Note

Good changes happen pretty rarely, and nearly EVERY change has some impact that should be fully explored before you go forward.

Bad change

A bad change is one that might seem from the outside like a good idea but ends up making an impact on the project constraints. Here are a couple of examples:

Gold plating

Sometimes people think of a really great improvement to the product and go ahead and make it without even checking the impact. In software, this can happen pretty easily. A programmer thinks of a way to make a feature better, for example, and just implements it, without talking it over with anybody. This may sound good, but it’s not—because now you have to pay for these features you never asked for.

Note

Be on the lookout for examples of scope creep and gold plating on the exam. Both are considered very bad and should never be done.

Exercise

Here’s the WBS that you created for the Cows Gone Wild III project, and below that are some changes that the team has asked Mike to make since the work started. All of them are bad changes. Check either scope creep or gold plating for each one.

1. We need to create a screensaver to market the game. Let’s kill two birds with one stone and test out a brand new graphics engine on it. Oh, and we’ll need a story for the screensaver, so we should write that too. Of course we have to recruit some killer voice talent for the screensaver. Memorable names sell more games.

   Scope creep

   Gold plating

2. Testing the most recent build, I just noticed that if the player presses x–x–z–a–Shift–Shift–Space in that order, Bessie does the Charleston—it’s really funny.

   Scope creep

   Gold plating

3. We should add a calculator for tracking gallons of milk collected in the game. It will be really easy. We could even release the calculator as a separate add-in, and we could probably make it full-featured enough for the folks developing the game down the hall to use it too.

   Scope creep

   Gold plating

4. The printer just told us that she could also do silk screen T-shirts for everybody as a ship gift. Let’s get our design team to do some special artwork for them. We can have everybody’s names written in cows!!! Then we could use the same artwork on posters that we put around the office—oh, and coffee mugs for new people, too

   Scope creep

   Gold plating

Answers: 1, 3, and 4 are Scope creep. 2 is Gold plating

There’s no way to predict every possible piece of work that you and your team are going to do in the project. Somewhere along the way, you or someone else will realize that a change needs to happen, and that change will affect the baseline. That’s why you need the Control Scope process. It’s how you make sure that you make only those changes to the scope that you need to make, and that everyone is clear on what the consequences of those changes are.

Monitoring & Controlling process group

Let’s take a closer look at what happens when you need to make a change. You can’t just go and change the project whenever you want—the whole reason that you have a baseline is so you can always know what work the team is supposed to do. If you make changes, then you need to change the baseline...which means you need to make sure that the change is really necessary. Luckily, you have some powerful tools to help you manage changes:

One of the most important tools in any Monitoring and Controlling process is the change control system. Let’s take a closer look at how it works.

Since the folks at Ranch Hand need a change to add more scenery to Cows Gone Wild III, Mike takes a look at the Scope Management plan to understand the impact before forwarding it to the change control board. Once they approve the change, he updates the Project Management plan, checks it into the configuration management system, and changes the WBS and WBS dictionary to include the new work packages.

There’s just one tool/technique in the Control Scope process. It’s pretty intuitive: take a minute and think of what you would need to do if you had to make a change to your project’s scope. You’d need to figure out how big the change is, and what needs to change. And when you do that, it’s called variance analysis.

There’s no “right order” for the Control Scope and Validate Scope processes

If you’ve got a copy of the PMBOK Guide handy, take a look at how it presents the Scope Management processes. Did you notice how the section on the Validate Scope process comes before Control Scope? We’re putting these processes in this book in a different order, and it’s the only time we deviate from the order of the PMBOK Guide. That’s not because the PMBOK Guide is wrong! We could do this because there is no “right” order: Control Scope can happen at any time, because project changes can happen at any time. Validate Scope (the next process you’ll learn about) is usually the last Scope Management process that you’ll do in a project. The trick is that sometimes you’ll find a scope problem while you’re verifying the scope, and you’ll need to do Control Scope and then go back and gather new requirements, rebuild the WBS, etc. So the Control Scope process can happen either before or after Validate Scope.

So why did we change the order? Because thinking about how the two processes relate to each other will help you remember this for the exam!

Brain Power

A lot of things can happen along the way during a project, especially when you have a lot of changes. What happens if the deliverables you and the team build don’t quite match up to what your stakeholders expect?

There are no Dumb Questions

Q:	Q: Is Control Scope always about work and project scope? Can it ever be about deliverables and product scope?
A:	A: No. The Control Scope process is always about the work that the team does, because the whole Scope Management knowledge area is about the project scope, not the product scope. In other words, as a project manager, you manage the work that the team is doing, not the things that they’re making. Now, that doesn’t mean you should never pay attention to deliverables. You still need to pay attention to the scope of the product, too, since the two are pretty closely related. For example, in the CGW III project, any time somebody wants to add a new feature to the game, a programmer will need to program it, an artist will need to make new artwork, and a tester will have to test it. Any time you make changes to the project scope, it affects the product scope, and vice versa.
Q:	Q: What if a change is really small? Do I still have to go through all of this?
A:	A: Yes. Sometimes what seems like a really small change to the scope—like just adding one tiny work package—turns out to be really complex when you take a closer look at it. It could have a whole lot of dependencies, or cause a lot of trouble in other work packages. If you don’t give it careful consideration, you could find yourself watching your scope creep out of control. Each and every change needs to be evaluated in terms of impact. If there is any impact to the project constraints—time, cost, scope, quality, resources, or risk—you HAVE to put it through change control.
Q:	Q: How can you do variance analysis without knowing all of the changes that are going to happen?
A:	A: You do variance analysis as an ongoing thing. As information comes in about your project, you constantly compare it to how you planned. If you’re running a month behind, that’s a good indication that there are some work packages that took longer than your team estimated—or that you missed a few altogether. Either way, you need to take corrective action if you hope to meet your project objectives. Waiting until all possible changes are known will be too late for you to actually meet your goals. So you need to constantly check your actuals versus your baseline and correct where necessary (after putting your recommended actions through change control, of course!).
Q:	Q: I thought the configuration management system was part of the project management information system from Chapter 4. What does that have to do with change control?
A:	A: When you write and modify documents throughout your project, you need to make sure that everybody is working with the same version of them. So you check them into a configuration management system, and that way everybody always knows where to go for the latest version. Since you are checking all of your documents in, that’s where you will keep your work performance information also. The most recent version of the schedule, any reports you have gathered on defects, and individual work performance should all be there. So, when you want to figure out what’s going on in your project, you look there first. It follows that you would modify your documents and check them back into the CMS after any change has been approved too.

Every scope change goes through the Control Scope process.

Control Scope Process Magnets

Whenever you make a scope change, you need to go through all of the steps of change control. So what are those steps? Arrange the magnets to show the order that you handle changes to the scope.

1. ______________________

2. ______________________

3. ______________________

4. ______________________

5. ______________________

6. ______________________

7. ______________________

8. ______________________

Control Scope Process Magnets Solutions

Arrange all of the activities you do to control scope in the right order.

Ask the stakeholders.

You need to go back to the stakeholders and get formal acceptance. That’s what the Validate Scope process is for, and it’s coming up next.

Monitoring & Controlling process group

When the team is done, what happens? You still have one more thing you need to do before you can declare victory. You need to gather all the stakeholders together and have them make sure that all the work really was done. We call that the Validate Scope process.

As you deliver the stuff in your scope statement, you need to make sure that each of the deliverables has everything in it that you listed in the scope statement. You inspect all of your deliverables versus the scope statement, the WBS, and the Scope Management plan. If your deliverables have everything in those documents, then they should be acceptable to stakeholders. When all of the deliverables in the scope are done to their satisfaction, then you’re done.

Once the deliverables are ready for prime time, you inspect them with the stakeholders to make sure that they meet acceptance criteria. The purpose of Validate Scope is to obtain formal, written acceptance of the work products. If they are found to be unsatisfactory, the specific changes requested by the stakeholders get sent to change control so that the right changes can be made.

Scopecross

Take some time to sit back and give your right brain something to do. It's your standard crossword; all of the solution words are from this chapter.

Across

Down

2. Bob used an _______ diagram to get a handle on all of the ideas he collected from stakeholders. 4. The details of every work package in the WBS are stored in the WBS _____________. 5. The process where you write the project scope statement is called ___________ Scope. 7. Figuring out how big a change is by comparing it to the baseline is called ____________ analysis. 8. When one change leads to another and another and another, it’s called scope _____________. 10. Getting work packages out of deliverables. 12. Exploring all of the ways that you can do the work so that you can find the best way to do the work in your project is called ______________ identification. 13. A quantified and documented need or expectation of a sponsor, customer, or other stakeholder.

1. A JAD session is an example of a _________ workshop. 3. Looking closely at the product to see if you completed all of the work is called _________. 4. When you’re making a WBS, you can break the work down by phase or ____________. 6. A version of the Scope Management plan, work breakdown structure, and product scope that you will compare your project to is called the scope ____________. 9. ____________ scope means the features or functions of the thing or service that you are building. 11. A good way to gather requirements is to _________ how the people who will use your deliverables perform their jobs.

Answers in Scopecross.

There were a few unexpected changes to the scope along the way. But, for the most part, everything went according to plan. The stakeholders and the CEO got together with the team and went through everything they did—and it’s ready to go. Great job, guys!

What’s my Purpose

Here are a few things that Mike left out of the CGWIII project scope statement. Can you figure out where each of them should go?

Scopecross

Take some time to sit back and give your right brain something to do. It's your standard crossword; all of the solution words are from this chapter.

Exam

1. Answer: C

The work breakdown structure is all about breaking down the work that your team needs to do. The WBS is graphical and hierarchical, not linear and unstructured. Did you notice that answer B was about product scope, not project scope?

2. Answer: A

There are two ways you can get to the right answer for this question. You can recognize that the WBS dictionary, change requests, and accepted deliverables are all Scope Management process outputs. (You’ll see change requests in every knowledge area!) But you can also recognize that the business case was created by the Develop Project Charter, which is part of the Initiating process group.

3. Answer: A

Did you recognize that answer A was describing the Scope Management plan? Once you know what the WBS is used for and how to make one, questions like this make sense.

4. Answer: C

You’ll need to know what order processes come in, and one good way to do that is to think about how the outputs of some processes are used as inputs for another. For example, you can’t create the WBS until the scope is defined, which is why A is wrong. And you can’t do change control until you have a baseline WBS, which is why B is wrong.

Note

Take a minute and think about how there’s no “right” order for Validate Scope and Control Scope. You could have a scope change at the beginning of the project, so Control Scope would come first. But a change could happen late in the project, too! If there’s a major change to the project after the scope’s verified, you need to redo it.

5. Answer: B

An important tactic for a lot of exam questions is to be able to recognize a particular tool, technique, input, or output from a description. What have you learned about that tells you who is responsible for a work package, tells what control account to associate with it, and describes the work associated with it? That’s a good description of the WBS dictionary.

6. Answer: B

There are some questions where you’ll just have to know what a process is all about, and this is one of them. That’s why it’s really helpful to know why Validate Scope is so helpful to you on a project. You use Validate Scope to check that all of the work packages were completed, and get the stakeholders and sponsor to formally accept the deliverables.

Note

Inspection isn’t just done at the end of the project. You do Validate Scope on every single deliverable made by you and the team.

7. Answer: A

It’s easy to forget that organizational process assets is more than just an input. It’s a real thing that’s part of your company. Take a second and think about what assets are in your organization that help you carry out each process. Get it? Good! So what is historical information, anyway? It’s stuff like reports and data that you or another project manager wrote down on a previous project and stored in a file cabinet or a database. That’s an asset you can use now! What are lessons learned? Those are lessons you wrote down at the end of a previous project and stuck in a file cabinet or a database. And now those lessons are another asset you can use.

Note

The PMBOK Guide says this stuff is stored in a “corporate knowledge base,” but that’s just another word for a file cabinet or a folder on your network.

8. Answer: C

One thing to remember about change control is that if you want to make the sponsor and stakeholders happy with the project in the end, sometimes you have to tell them “no” right now. When you’re doing Control Scope, the most important tool you use is the change control system. It tells you how to take an approved change and put it in place on a project, and there’s no other way that you should ever make a change to any part of the baseline. That means that once everyone has approved the scope statement and WBS, if you want to make any change to them, then you need to get that change approved and put it through the change control system.

9. Answer: C

The requirements traceability matrix is a tool that you use to trace each requirement back to a specific business case, and then forward to the rest of the scope deliverables (like specific WBS work packages), as well as other parts of the project: the product design (like specific levels in Cows Gone Wild) or test strategy (like test plans that the Ranch Hand Games testers use to make sure that the game works).

Note

The idea is that you’re tracing a deliverable from its initial description all the way through the project to testing, so that you can make sure that every single deliverable meets all of its requirements.

10. Answer: B

When you’re getting the sponsor and stakeholders to formally accept the results of the project, you’re doing Validate Scope. There’s only one tool for it: inspection. That means carefully checking the deliverables (in this case, what the workers built on the highway) to make sure they match the WBS.

11. Answer: B

Note

Answer D is a good idea, but it’s not as important as creating a new WBS.

This question is a little tricky. The most important thing about a WBS is that if your Scope Management plan says it should be there, then your project absolutely cannot be done without it. And a general rule is that if you ever find that there is no WBS, you should always check the Scope Management plan to find out why.

12. Answer: B

This is another question that is testing you on the definition of a specific document, in this case the Scope Management plan, which is one of the subsidiary plans of the Project Management plan. Think about what you use a Scope Management plan for. It gives you specific procedures for defining the scope, breaking down the work, verifying the deliverables, and managing scope changes—which is what this question is asking. All of the other answers don’t have anything to do with managing changes.

13. Answer: A

Here’s another example of how there are two correct answers but only one BEST one. Answer C is true—you are doing scope definition. But is that really the best way to describe this situation? Alternatives analysis is part of scope definition, and it’s a more accurate way to describe what’s going on here.

Note

When you look at a few ways to create a deliverable and then decide on the best one, that’s alternatives analysis.

14. Answer: A

This question is an example of how you need to rely on more than just common sense to pass the PMP exam. All four of these answers could be good ways to handle a terminated project, but there’s only one of those answers that corresponds to what the PMBOK Guide says. When a project is terminated, you still need to complete the Validate Scope process. That way, you can document all of the work that has been completed, and the work that has not been completed.

15. Answer: B

Are you starting to get the hang of how this change control stuff works? The baseline isn’t etched in stone, and you need to be able to change it, but you can’t just go ahead and make changes whenever you want. You need to document the change request and then put that request through change control. If it’s approved, then you can update the baseline so that it incorporates the change.

Note

You definitely can’t just make the change and inform the sponsor later. All changes need to be approved.

16. Answer: A

When a question asks you about what a particular document, input, or output contains, be on the lookout for answers that talk about a different document. What document do you know about that gives the project manager authorization to do the work? That’s what the project charter is for.

17. Answer: C

Sometimes Control Scope is easiest to think about as a kind of machine that turns approved changes into updates. It sucks in the approved changes and all of the other Scope Management stuff (the scope statement, WBS, and WBS dictionary), does all the stuff that it needs to do to update those things, and then spits out updates. And sometimes it spits out new requested changes because when you’re making changes to the WBS or scope statement you realize that you need to make even more changes.

18. Answer: A

Scope Identification is a made-up process. It didn’t appear in this chapter, and even though it sounds real, it’s wrong.

19. Answer: B

WBS templates are a great way to speed up creating the WBS, and the easiest way to create a template is to use one from a previous project.

Note

You can also use a template for the Scope Management plan.

20. Answer: C

This question asked you about the Define Scope process, but all of the answers describe various outputs. Which of these outputs matches Define Scope? Well, the main output of Define Scope is the scope statement, and answer C is a good description of the scope statement.

21. Answer: A

Note

Did you guess “Create WBS” because it was a Scope Management process and the question mentioned decomposing deliverables into work packages?

This question asked you where you defined the procedures for doing all of the Scope Management processes. Where do you find those procedures? You find them in the Project Management plan—specifically, the Scope Management subplan. And you build that in the Develop Project Management Plan process.

22. Answer: C

There’s only one document you’ve seen that shows you details of individual work packages and contains a control account, a statement of work, and a resource assignment. It’s the WBS dictionary.

23. Answer: D

When you read the question, it looks like the team really helped the project, right? But think about what happened: the team abandoned the plan, and then they made a change to the project without getting approval from the sponsor or stakeholders. Maybe they discovered a useful shortcut. But isn’t it possible that the shortcut the team found was already considered and rejected by the sponsor? That’s why change control is so important.

Note

Did you notice how the question made it sound like the team did a good thing by ignoring Control Scope and making changes that were never approved?

24. Answer: D

Some questions are just definition questions. When that definition is a “which-is-BEST” question, there could be an answer that makes some sense, and it’s tempting to stop with it. In this case, answer A sounds like it might be right. But if you read answer D, it’s much more accurate.

25. Answer: A

The question asked about the tools and techniques for Collect Requirements, and answer A is the only answer that has to do with the Create WBS process. The rest of the answers were descriptions of Collect Requirements tools and techniques: interviews (answer B), prototypes (answer C), and observations (answer D).

26. Answer: A

The outputs of Collect Requirements are requirements documentation and the requirements traceability matrix. “Requirements Observations” isn’t really an output.

Note

The easiest way to make sure you get questions like this right is to think about how each of those outputs are actually used later in the project.

Keep an eye out for questions that describe an input or output and then ask you to name it. Look at each answer and think up your own descriptions for them—one of them will match the question.