Relationship between Product Scope & Project Scope
Product scope means the features and functions of the product or service that you and your team are building. The product scope is all about the final product—its features, components, pieces. When people talk about scoping out their products, a lot of times they’re talking about figuring out the features of the product, not the work that goes into it.
Project scope is all of the work that needs to be done to make the product. When we talk about scoping a project, we mean, figuring out all the work that needs to be done to make the product. THIS is a big part of what the project manager is concerned with and the work the team has to do.
A single product may include multiple projects and the work done in each of these projects are all part of the high level scope of the product.
Scope management means figuring out what’s OUT OF scope, not just what’s part of it
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 them 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. 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.
Gathering Requirements:
Three Useful Tools for Gathering 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
Making 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.
The Requirements Document:
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.
Defining the Project Scope:
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.
Creating the WBS:
Each of the entries in the WBS is called a work package. It’s a unit of work that you and your team use to organize the stuff you’re going to have to do to get the project done. The work package is the lowest level on a WBS; the higher levels are used to categorize the work packages. When you roll them all up into one big WBS, you get a complete picture of everything that the team will do over the course of the project.
The WBS Dictionary contains the details of every work package. It’s a separate output of the Create WBS process.
Important Points Reg. Creating the WBS Process:
1. The Create WBS process is a really important process on the PMP exam.
2. The WBS is created by decomposing large work products into work packages.
3. To finalize the WBS, control accounts are established for the work packages.
4. The WBS Dictionary is a description of each work package listed in the WBS.
5. The inputs to WBS creation are the outputs to the Define Scope and Collect Requirements processes: the Requirements Document, and the Project Scope Statement.
6. As you decompose the work, you find new information that needs to be added to the Requirements Document and the Project Scope Statement. That information is treated as a change and goes through change control. Once it’s approved, it can be added into the document, and that kicks off the planning cycle again.
Controlling Scope & Verifying Scope:
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? But, in real time, we may do Control Scope even before we do the Verify Scope. 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 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.
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. However, you need a formal acceptance to conclude that the Project is 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. Sometimes PMs try to close off a project just with the verbal confirmation of the key stakeholder. Though, the stakeholder may not go-back on his words and claim that you did not deliver things properly, the point here is, what if he does? What proof do you have to confirm that you have done all the work as per the scope of the project? This is where the Formal Signed Approval comes to our rescue. When a Stakeholder signs-off that he/she is happy with the deliverables, all they can do is request for some changes but not demand them because, they have provided their sign-off and that means you have delivered what you planned or promised.
Points to Remember - Other Topics:
Introduction to Projects & Project Management
Relationship Between Knowledge Areas & Process Groups
Project Integration Management
Project Time Management
Project Cost Management
Project Quality Management
Human Resource Management
Project Communication Management
Project Risk Management
Project Procurement Management
Ethics & Professional Responsibility
