Chapter 5. Scope management: Doing the right stuff
Confused about exactly what you should be working on? Once you have a good idea of what needs to be done, you need to track your scope as the project work is happening. As each goal is accomplished, you confirm that all of the work has been done and make sure that the people who asked for it are satisfied with the result. In this chapter, you’ll learn the tools that help your project team set its goals and keep everybody on track.
Out of the frying pan...
The people at Ranch Hand Games have been working hard for a over a year on the sequel to their most successful title, Cows Gone Wild. It seemed like the project would never end...
... and right back into the fire
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.
Cubicle conversation
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 web site? 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?
It looks like we have a scope problem
All of the major problems on Cows Gone Wild II were scope problems. The web site 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.
For the exam, you need to understand both product and project scope.
Here are some attributes of Cows Gone Wild III. Which are project scope and which are product scope?
Programming
34 levels in the game
Graphic design
Four playable characters
Great graphics
Testing
Mac and PC compatible
A “boss battle” milk fight level at the end
Answers in Sharpen your pencil Solution.
You’ve got to know what (and how) you will build before you build it
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 five 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 web site for a video game instead of building the game itself.
Note
This is why the scope management plan needs to say how you’re going to keep unnecessary work out of the project.
The scope management plan describes how you write down the scope, make sure it’s right, and keep it up to date.
The power of scope management
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.
The team had trouble getting the project off the ground. Everyone on the team was good at their individual jobs, but it seemed like nobody knew how to get the project started.
There were a lot of false starts. Just when they thought they were getting the project under way, it seemed like something would shift and they’d be back to square one.
The sponsor and stakeholders were unpredictable. There were three different times that Amy and Brian thought they were done. But each time, a stakeholder found a problem that sent them back to the drawing board.
There were a whole lot of changes. They were always scrambling to keep up with shifting priorities and ideas, and they never knew for sure what they’d be working on each week.
The five Scope Management processes
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.
Collect Requirements
In this process, you find out all of the stakeholder’s needs and write then down so that you know what to build and your requirements can be measured and tracked.
Define Scope
Here’s where you write down a detailed description of the work you’ll do and what you’ll produce.
Note
When you do this right, the stakeholders are never unpredictable because you already understand their needs.
Create WBS
The work breakdown structure (or 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.
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.
Verify Scope
Once the work is complete, you need to make sure that what you’re delivering matches what you wrote down in the scope statement. That way, the team never delivers the wrong product to the customer.
Cubicle conversation
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.
Collect requirements for your project
Gathering requirements is all about sitting down with all of the stakeholders for your project and 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.
These two inputs were outputs from processes in the Initiating Process Group. Write down which process created each of them.
Project Charter: __________________________________________________
Stakeholder Register:______________________________________________
Answers in Sharpen your pencil Solution.
Talk to your stakeholders
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.
Make decisions about requirements
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 decsions when those opinions conflict with each other. There are four major decision-making techniques you can choose from.
Unanimity means everyone agrees on the decision.
Majority means that more than half the people in the group agree on the decision.
Plurality means that the idea that gets the most votes wins.
Dictatorship is when one person makes the decision for the whole group.
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 of decision-making technique was used in each case.
Help your team to get creative
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.
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.
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:
CGW III Delphi Questionnaire
What new levels would you like to see in the game?
What new abilites should Bessie have?
What should the story for CGW III be about?
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.
Note
The Delphi Technique can be used to estimate the work the team will need to do and how long it will take too!
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.
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.
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.
Use a questionnaire to get requirements from a bigger group of people
The Cows Gone Wild development team needed to talk to the people who play their games to figure out what would make them happy in the next version. They obviously couldn’t go around to all of their customer’s houses asking questions, so they wrote a questionnaire about new possible features for the game that they sent to gamers after they registered the game.
When it was time to start collecting requirements for the new version, they started with all of the data they’d gathered from those surveys and did some analysis on them to figure out which features were most important to the gaming comunity. Here’s an excerpt from their survey results:
Cows Gone Wild II Registration Survey Results
The Cows Gone Wild series has 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?
Observation can help you see things from a different point of view
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.
A prototype shows users what your product will be like
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 let your stakeholders get 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 your project is being developed 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.
You know your requirements are complete when you’ve got a way to verify each of them once they’re built.
Collect requirements outputs page
The outputs of the collect requirements process are the Requirements Document, the Requirements Management Plan, and a Requirements Traceability Matrix so you can follow them from the document through implementation and verification.
The Requirements Document needs to list all of the functional and non-functional requirements of your product. Functional requirements are most of the kinds of things that you think of right away; new features, bug fixes, new or different behavior. Non-functional requirements are sometimes called “quality attributes” because they’re things that you expect from your deliverables, but aren’t specific features. Some examples of non-functional requirements are: performance, reliablity, error handling, and ease of use.
Define the scope of the project
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.
How do you define the 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
When you do Faciliated 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 vs. 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.
Alternatives identification
Think of other ways that you could do the work. Exploring different ways to do the work will help you find the one that is most efficient for the project. It’s always possible that you might find a better way of doing things and need to change your original plan.
Designing the graphics: alternatives
The scope statement tells you what you have to do
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 scope statement.
Answers in What’s My Purpose.
The project scope statement tells what work you are—and are not—going to do to do in the project.
You’ll need to know the difference between defining the scope and collecting the project’s requirements for the exam. Which of these things is part of the Project Scope Statement, and which is part of the Requirements Document?
Question Clinic: The “Which-is-BEST” Question
Join the Head First PMP community at http://www.headfirstlabs.com/PMP You can add your Head Libs answer, and see what Head Libs other project managers came up with!
Create the work breakdown structure
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.
The inputs for the WBS come from other processes
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 organzational process asset library.
Breaking down the work
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.
Break it down by project or phase
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.
Note
These are the same phases we talked about in Chapter 3.
Decompose deliverables into work packages
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.
Note
You won’t find any solutions for this, because there aren’t any right or wrong answers! It’s your chance to take a minute to think things through—that’ll get it into your brain.
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.
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.
Brain Power
Can you think of a reason that Mike would break Cows Gone Wild III work down by phase? Can you think of why he’d break it down by deliverable?
Did you notice how the project management work packages are the same in both WBSes? You could break them down into more detailed project management deliverables, and then you’d see a difference.
Inside the work package
The WBS Dictionary contains the details of every work package. It’s a separate output of the Create WBS process.
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.
The baseline is a snapshot of the plan
As the project goes on, you will want to compare how you are doing to what you planned for. So, the scope baseline is there to compare against. It’s made up of the 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 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.
Anytime you make a change, you need to get it approved, and then update the baseline
The outputs of the Create WBS process
The Create WBS process has three major outputs: the Work Breakdown Structure, the WBS Dictionary, and the Scope 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.
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.
Cubicle conversation
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...
Why scope changes
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.
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:
Scope Creep
This happens when you think you know the impact of a change so you go ahead, but it turns out that that change leads to another one, and since you are already making the first change, you go with the next. Then another change comes up, and another, and another, until it’s hard to tell what the scope of the project is.
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.
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.
The Control Scope process
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 scope 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.
Anatomy of a change
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:
A change is needed
Every change starts the same way. Someone realizes that if the project sticks with the plan, then the outcome will lead to problems.
Create a change request
Before a change can be made, it needs to be approved. That means that it needs to be documented as a requested change. The only way to get a handle on a change is to write it down and make sure everyone understands it.
Get the change approved
Remember Integrated Change Control from the last chapter? That’s the process where the project manager takes a requested change and works with the sponsor and stakeholders to get approval to put it in place.
Take a look at the baseline and see how the change will affect it. This is where you decide whether you need to take some sort of corrective action. You compare the scope baseline against the change that you want to make, and figure out just how big the change really is.
Replan the work
Now it’s time to go back to the scope documentation and update it to reflect the change.
Create a new baseline
Now that you’ve figured out that you need to change the scope, it’s time to update the baseline. Go back to the scope statement, WBS, and WBS Dictionary, and update them so that they reflect the change that needs to be made.
The change is done!
Now you can move on with the project using the new baseline that you saved and distributed to the team.
A closer look at the Change Control System
One of the most important tools in any Monitoring & 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.
Just one Control Scope tool/technique
There’s just one tool/technique in the Control Scope process. It’s pretty intuitive: just 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.
The goal of Control Scope is updating the scope, plan, baseline, and WBS info.
Variance Analysis
This means comparing the data that can be collected about the work being done to the scope baseline. When there is a difference between the two, that’s variance.
This tool of Control Scope is all about analyzing the difference between the baseline and the actual work to figure out if the plan needs to be corrected. If so, then you recommend a corrective action and put that recommendation through change control.
There’s no “right order” for the Control Scope and Scope Verification 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 Verify 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. Verify 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 Verify 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?
Every scope change goes through the Control Scope process.
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.
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
Ask the stakeholders.
You need to go back to the stakeholders and get formal acceptance. That’s what the Scope Verification process is for, and it’s coming up next.
Make sure the team delivered the right product
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 Verify Scope process.
The stakeholders decide when the project is done
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.
Formal acceptance means that you have written confirmation from all of the stakeholders that the deliverables match the requirements and the project management plan.
Is the project ready to go?
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 Scope Verification 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.
EVERY deliverable should be inspected, including all project management documents and everything produced by the team.
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
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 onc 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.
Down
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.
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.
The project is ready to ship!
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!
Here are some attributes of Cows Gone Wild III. Which are project scope and which are product scope?
Note
This will help you on the exam. Knowing that one process’s output is another’s input makes it a lot easier to remember the order of the processes.
Here are a few things that Mike left out of the CGWIII scope statement. Can you figure out where each of them should go?
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.
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 Projct 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 Scope Verification 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, 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 Verify Scope is so helpful to you on a project. You use Verify 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 Scope Verification 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 with 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 through 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 scope verification. 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
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 Verify 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 if you think of it 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. It is not a good idea to cut out deliverables, skip important outputs like the WBS Dictionary, or make the sponsor do your job for you.
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
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 Plan sub-plan. And you build that in the Develop Project Management Plan process.
Note
Did you guess “Create WBS” because it was a Scope Management process and the question mentioned decomposing deliverables into work packages?
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
Here’s another question where you need to know how to describe an important tool. In this case, you need to know what the change control system is used for. Luckily, answer D is a pretty good description.
24. 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?
25. 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.
26. 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).
27. Answer: A
The three outputs of Collect Requirements are Requirements Documentation, the Requirements Management Plan, 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 own descriptions for them—one of them will match the question.