PMI PMP Project Management Professional – Managing the Project Scope

1. Section Overview: Managing the Project Scope

Project scope management is one of the most important knowledge areas because without the scope, what are we doing in a project? We need the scope because it sets the vision for what the project is going to create. It’s how we move from our current state to that desired future state. So in this section, we’re talking about chapter five in the Pmbok I 6th edition on project scope management. A lot of important things to talk about. In this section, we’re going to look at planning, creating a scope management plan. We’re going to discuss the difference between a product scope and a project scope. We’re generally interested in just the project scope, but we need to understand the product scope because that helps us see into the requirements that will help us build and create the project scope. So there’s a symbiotic relationship there that we’ll look at coming up.

We’ll talk about the trends in scope management and how does scope management work in an adaptive environment. We’ll talk about collecting project requirements and managing those requirements and then creating the project scope statement. After we have the scope statement, then we’ll create the work breakdown structure, the WBS and the WBS dictionary. So some new terms there to watch for in this section. And I have an assignment for you in this section where you’ll create a work breakdown structure. So you’re going to do a little bit of hand, hands on activity that will help reinforce what you’ve learned or create some clarity into these processes. We’ll talk about validating the project scope. And then a little coaching session for you. I want to talk to you about controlling your scope. Okay, let’s hop in here and talk about managing the project scope.

2. Planning Project Scope Management

Welcome back. Now let’s talk about the first process in our scope management knowledge area and this is planning project scope management planning project scope management will create two subsidiary plans. Obviously we get the scope management plan but it will also create the requirements management plan. Let’s take a look at the EDOs for this process. Our inputs will be the charter, the project management plan because we’re looking at these other plans and remember this is iterative.

So the Quality Management Plan, the Lifecycle description, the development approach, those are all part of our project Management plan and that will affect our Scope Management planning and then of course, EEF and OPA tools and techniques here in plan scope Management expert judgment will do data analysis, so alternatives assessment or alternatives analysis and meetings our outputs. As I mentioned, the Scope Management Plan and the requirements management plan to go about creating the Scope Management Plan, we’re going to work with our experts, including our project team, and we’re going to define exactly how the scope how will you define the scope?

So the scope management plan doesn’t create the scope statement, it says how do you define the scope in order to create the scope statement so it defines how the scope will be defined, how the scope will be developed, how will you monitor, control and validate the project scope. So it’s a plan that defines how will you do this knowledge area the charter is a key input because it has the high level requirements any historical information we can use. So similar projects we can adapt to our current project, treat it like a template and then enterprise environmental factors are needed because you may have rules and requirements on how you define, develop, monitor control and validate scope. So you need to adhere to the governance within your organization part of our EEF, the project management plan input so you know that planning is iterative so don’t let that throw you that we needed the quality management plan, that it’s an Iterative process. So on day one, you don’t have a quality management plan. But as you work through the project, those other plans will affect your scope. Planning the project lifecycle description. We’re defining the phases of the project in a predictive. Or an adaptive. We’re defining our rules for the product backlog. And how does that work, and how long are our iterations and so on?

The development approach is just that. Are you using a waterfall approach? Are you using Iterative adaptive, Agile, Scrum, XP, some hybrid? So what’s your approach here? Because that will affect how you create the scope management plan. Let’s take a look at the details of the scope management plan. It’s not the project scope as you already know. It describes how will you create the scope. It also defines how are we going to create the work breakdown structure and the WBX dictionary and then how will you maintain the baseline, the scope baseline is almost always required. If change happens to that, you have to go through a change control. That’s what I’m trying to say, that the scope baseline always requires formal change control because the scope baseline is the scope statement, the WBS and the WBS dictionary. It also describes the formal acceptance of deliverables. So scope validation is a process we’ll see coming up in this section. The requirements management plan describes.

How will you plan, track and report your progress on requirements? Any and all configuration management. So how will you do configuration management identification, configuration status, configuration audits, and then maintaining configuration? Remember, configuration management is all about the features and functions. So it’s particularly interested in the product scope. So changes to scope will affect configuration management. We saw that in chapter four when we talked about integrated change control. What’s the process to prioritize requirements? What are the metrics that you’ll use? And then what about a requirements traceability matrix? We’ve not seen this yet. It’s coming up. I’ll give you a hint. It’s a table. That’s all it is, a list of requirements where they are in the different phases all the way to completion. So an RTM is a requirements traceability. You’re tracing it through all the phases of the project until it’s done. We’ll see one coming up, something to look forward to.

3. Project Scope Vs. Product Scope

In project management, there are two scopes that we need to focus on as the project manager. We have the product scope and the project scope. Let’s take a look at these and how they affect our planning and management of the project. So product scope is all about the features and functions. The project scope is all about the work that you’ll complete in order to create the product scope. So the product scope is a way to describe the things and the characteristics and the usability that the customer will receive as a result of our project. The project scope, though, is all of the required work and only the required work in order to satisfy the project objectives. So it’s about creating the product, but it’s also about maintaining the project objectives. Remember that project objectives can be your key performance indicators time, cost, scope, quality, managing risk, resources and so on. The product scope is only the features and functions.

So if we think of this, it’s really a symbiotic relationship here. The customers come to us and they describe their requirements, they describe the product scope, and we capture those. Requirements and document them and have a good grasp on what those requirements are. The product scope, then, will help us create the project scope. As we execute the project, we’re creating the project scope, which in turn creates the project scope. So the product scope and the project scope are symbiotic. They help each other exist. There is a concern, though, that we need to look at with the scope and the project life cycles when that product scope and project scope are created will be different in a predictive life cycle versus an adaptive life cycle. Recall that in a predictive life cycle we plan everything upfront. We want to know exactly what it is we’re going to create. So the project scope is defined at the beginning.

Well, in an adaptive life cycle, the project scope is really developed through these iterations. In an adaptive environment, we typically have a product backlog that’s prioritized before we go. Into each iteration. Or a sprint. I’ll say it into a sprint. So we have an adaptive which is different than predictive. Predictive. I predict the scope adaptive. I adapt my project scope to the changing product backlog. A predictive. We generally become change resistant that we want to nail down everything upfront and then once we have that approved, once we have a baseline I become very adverse to change an adaptive just by its nature becomes to expect change that we know requirements are going to change and the product backlog will be reorganized.

So we come to expect change. So there’s a difference in the scope and the scope management in predictive and in adaptive product scope. Let’s talk a little bit more about what are the characters and features of product scope. We’re really talking about what the customer receives as a result of our project work and the product backlog. As I mentioned, that’s the adaptive product scope, the requirements we’ll do requirements gathering here. We’ll talk about that a little bit more coming up. But requirements are where we get the product scope from at the end of a phase or at the end of a project before we actually close it out.

We need scope validation. Well, validate scope is confirmation that what we’ve created is the product scope. That what we promised to create and what we actually did create should be the same thing. Scope and project completion are activities that we do at the end of a phase and at the end of the project. We talked about this in project integration management. Well, the scope is important because the project scope will be measured against the project plan. Did you do what you intended? Do you have cost variances, schedule variances? What are the outcomes of your issues and risk? The product scope will be measured against those requirements. Requirements, just to be clear, they’re a condition or a capability that has to exist in what we create in the final product, in the service, or the result.

Throughout the Pinback, we know that we can tailor the processes well, scope management is no different. We can tailor scope management. So we need to think about when we tailor, how much knowledge and requirements management do we need? So knowledge management, requirements management we can tailor based on the size of the project, the type of requirements if we’ve done this project before, and just how big the project scope is. Validation and control that we want to do. Scope validation, is it a formal sign off? Do we do it at the end of each phase or only at the end of the project? So that’s tailoring and then scope control. How much control do we require for changes, for integrated change control, for the change control board. So that kind of business we can adapt and tailor based on how big our project is.

The development approach, of course, that’s being tailored here. We’re doing predictive or agile the stability of requirements that really affects how effectively we can manage the project or manage scope. If it’s high level requirements, it’s kind of a lot of things open to interpretation. So the more detail we have, the more control and the more exactness we can have when we create the scope and we actually execute the work to create the scope and then the of governance. What are the rules and requirements you have to have as it comes to scope management? All right, good job. Keep moving forward.

4. Trends and Emerging Practices in Project Scope Management

When we talk about gathering requirements or creating the project scope, or just understanding the product scope, chances are we’re going to be working with a Business Analyst. Now, in your organization, as the Project Manager, you may be the one that’s serving both as the Project Manager and a Business Analyst. A Business Analyst is an individual that can elicit requirements, gather requirements, package those up, and really help define what the project should be creating, what the project scope will be. So we need to know a little bit about the process, not a project management process, but just the process of what is Business Analyst. Business Analyst is all about gathering requirements and defining requirements and ensuring those requirements satisfy the business needs. So it defines, manages and controls requirements.

So in a Business Analyst world, requirements may begin with a needs assessment, with really understanding what the problem is, or what do we really need, or what we’re trying to solve. In the PMI world. There is a certification on Business Analysts. The PMI PBA Professional Business Analyst. So I think that’s part of the reason why we’re seeing more about Business Analyst in our PMP or CAPM exams, because it’s becoming more and more popular as a PMI certification. And certainly we see this in the pinbox. Let’s take a look at some emerging trends for scope here. When it comes to Business Analyst, often we partner or collaborate with Business analysts, and they’re going to help us to identify problems or help the organization identify problems. And that helps define the business needs.

What should the project aim to accomplish? So what are the business needs? And then they can make recommendations for solutions for those business needs or to address those problems. Business Analysts work to elicit, document, and then manage those requirements, so illicit manage and documentation, and they also can help facilitate the implementation. So often the BA will be involved with gathering requirements, and then the Project Manager steps in with the team and executes those. And then at the end, when we do an operational transfer, the BA comes back. Because the BA may be responsible for scope validation and that operational transfer, but it’s really not that segmented. In reality, we work with the business analysts throughout the project. So Project managers and Business analysts really work together.

We want a collaborative relationship. We don’t want a combative relationship. There’s no reason for that. We’re both of us on the same side of the table, as it were. We’re both on the same team. The BA has requirements responsibilities, the Project Manager has delivery responsibilities. So both the PM and the Business Analysts need to stay in their own swim lane that don’t cross over and get in each other’s way. And that’s part of that collaborative partnership. All right, great job. Know this information. You probably have maybe one or two questions about Business Analysts as it relates to requirements gathering and project management.

5. Considerations for Adaptive Environments

You will likely see a few questions on adaptive environments, especially in regard to scope management. So let’s take a look at the idea of adaptive environments and how does scope management take place? There what we know already in an adaptive environment the scope is not fully defined at the start, that the scope is defined, designed is elaborated through the adaptive environment. Emerging requirements happen in an adaptive environment. So what happens? Remember we have this product backlog and then we prioritize that backlog. The product owner really does that, prioritizes the backlog before each iteration of the project. So the requirements can change and shift and new requirements can come into that product backlog throughout the project.

A concept that we need to know when we compare a predictive life cycle to an adaptive life cycle is this inverted triangle. You know that the triple constraints of project management are sometimes called the iron triangle. It’s this idea that scope, time and cost are the three constraints that we have to balance in predictive we always not always, but we often have the mindset that scope, once it’s defined, is defined. So the scope is what we are going to create. And once the scope is created, I’m very adverse to change because change will affect my time and cost. Well, in an agile we have this inverted model where time and cost are fixed. You only have so much money and so much time and scope is what varies, whereas in triple constraints time and cost can vary in a predictive. Now, with all of this there’s some flux here, there’s a little bit of reasoning here. So the agile triangle of constraints is just a pyramid upside down that time, you only have so much time and so much money and that’s fixed. So your scope then is allowed to increase or decrease based on how much time and money you have as the project is in motion.

So it’s determining what’s a variable and what’s actually fixed. So that’s the inverted triangle model. A concept that we see in adaptive environments is to groom the backlog. Not groom your back, but groom the backlog. So grooming the backlog is where we have a product owner and this is a person that’s usually a representative of the stakeholders and they’re the ones responsible for prioritizing the list of backlog items and that’s called a refinement.

So you have this long list of requirements, sometimes called user stories. And these user stories or requirements are prioritized for most important all the way down to least important. Well, the project team or the development team will say we can do this much work in the next two to four weeks. So that becomes our backlog for this iteration, for this sprint, for this time period. And then while they’re working on those requirements, the product owner can add new requirements, reprioritize, shift things up and down. So that’s the idea of grooming the backlog, usually the project team and the project manager, they’re involved in that process. They’re involved in that conversation of grooming the backlog. There is a concept called the Scrum artifact. It’s things that Scrum creates, and it’s called one of them is the product backlog. So the product backlog is the source for all your requirements. Everything has to go through the product backlog.

In Scrum or in Agile, the product owner will sort and prioritize these backlog items. The development team, they always work on what’s the most important items that are prioritized in this backlog. So from most important to least important, some other facts here about the product backlog. You always prioritize it before the next iteration, before the next sprint backlog. Refinement is by the product owner and the development team, that they work in harmony of what’s most important and what’s feasible to get done in this iteration. In this sprint, the team will determine, okay, how much can we actually get done, what’s our capacity and capability based on these items in the product backlog? So sometimes I might only be able to do this much as the project team because those are very complex and they require a lot of effort. And at other times those are very easy. So I can knock out a whole bunch more in the next sprint or iteration. So the product backlog really determines what are the things that are important to the priority of requirements, how much can the team take on at any given time? And then before the next iteration, what’s important can change. All right, good job. Some insight here into adaptive environments and scope management. Keep moving forward.

6. Collecting the Project Requirements

It’s important to collect the project requirements because that tells you what you have to create in your project. So this is a project management process which is collecting project requirements. It’s how do you determine, document and manage requirements throughout your or project. Now you may be doing this as the project manager. You might also be doing this with a business analyst. So collecting the project requirements help you define the product scope and the project scope. Typically in a predictive environment, we’re collecting requirements upfront. You might be collecting requirements at each phase. Or if you’re in an adaptive environment, those requirements are going to fluctuate based on the product backlog. Let’s check out the EDOs for collecting project requirements. Our inputs, the charter because that’s our high level requirements. Some place to start the project management plan. We’ll need the scope management plan, requirements management plan, our stakeholder engagement plan, project documents, the assumption, log, lessons learned, register, stakeholder register, all of that.

Business was helping us to gather requirements. So these are places that we would look that we’re going to get requirements from. Same with our business case. Remember, the business case defines business value and how does this project meet business value? That’s a good place to look for requirements. And then EEF and OPA. As always, we see that over and over. Lots of tools and techniques to gather requirements. Expert judgment, data gathering. We’re going to do things like brainstorming, interviews, focus groups, doing surveys and benchmarking. New term for you we’ll see coming up data analysis. Look at your documents. Look at all the documents you have so far. That’s a great place to collect requirements. Doing some decision making with voting. Multicriteria analysis. Data representation are a way of making charts or visualizations of our requirements. So affinity diagrams, mind maps, having some interpersonal and team skills.

The nominal group technique, observation and conversation facilitation using a context diagram and prototypes. And don’t worry, we’re going to see that business coming up in detail. The outputs of collecting requirements will be the requirements documentation and that requirements traceability matrix. One of the best tools and techniques for gathering requirements is to do interviews with stakeholders. So use the stakeholder register because that identifies who our stakeholders are. And we’ll do a one to one conversation. It could be a one to many where it’s you and three or four stakeholders or a mini to many where it’s you and your project team and three or four stakeholders and you all are talking about the requirements. So asking questions and really understanding and learning about the requirements.

A focus group is a moderated event. We could have six to twelve people. We have that neutral moderator that will come in and kind of facilitate the conversation. So it’s not leading participants to a solution. One thing that we want to consider with requirements and focus groups is what’s the participant composition? If we are doing a new project and we’re gathering requirements. Do we only bring in participants from the sales group and then only participants from marketing and then only people from manufacturing and then only It. So we kind of isolate these groups of stakeholders to ask them specific questions about their area or do we mix and match? We bring in people from all of these groups, mash them all up together and then they can interact with one another. So that’s the idea of participant composition. Who should be involved in this and what’s the distribution of stakeholders? Of course you can do questionnaires and surveys, use web monkey or some survey tool or whatever you want to create surveys that are fast, especially when you have a lot of stakeholders, allows you to call the up results. Or people are distributed around the world. Not anything shocking there, right? Benchmarking the requirements is when we compare two or more systems or solutions or even businesses.

So I want to compare Agile to SQL or I’ve got soundproofing material for this house, so I want to do some tests, I want to build a booth and test the decibels of one and the other. So I’m benchmarking where I’m setting my requirements based on an external basis for performance. So how well they perform tells me how well this material should be in my project and that’s the one I’m going to select. And then comparing organizations so I can look how did they do it in it. That’s how we can do it here in manufacturing or how did a public company do it. And there’s an article we read or a white paper and that will set some goals for how we can do it in our organization. One of the best places to begin gathering requirements is through documentation. All of those brochures and proposals and blueprints and those early specs that you have, that’s great places to do requirements identification. So analyze project documents.

When you have all those folks together and they’re going to vote on requirements, you can do group decisions. Remember, unanimous, the majority more than 50%. That’s the way we go. The plurality, the largest block agrees. So you might have 100 people and you have 40 people are in favor of requirement A and then 30 people are in favor of requirement B and then maybe there’s 20 people and some people didn’t vote or they’re just mad and they don’t want to participate. So you’ve got some other people then here they want to requirement A. There’s more people against what the largest block is for. So that’s plurality. So even though more people may be not in agreement with what’s wanted, this is the group that wins because they’re the largest block. When there’s multiple choices and then dictatorship, one person decides.

Multi criteria analysis. We’ve seen this a couple of times already and we’re going to see it some more. It’s just where I have different factors to rank or prioritize or even eliminate project criteria. So we could say things like performance metrics in our testing, what risks were introduced, just the requirements themselves based on priority and the amount of time and money we have. So this is a decision matrix, this little table down here where we can give different scores and then do some math here as to how many points you get. And then from that we would choose the requirements that have the most points or any requirements above 50 points or whatever. But that’s a multi criteria analysis. A decision matrix to measure and score an identity diagram is very similar to brainstorming.

But what we do is we group ideas into these different clusters. So we could say, all right, we want to do a project with social networking. So on Facebook, basically, we want to have some little tips and tricks and create some publicity about our project. So we can say, well, what are some different ideas that we can do and how does that help our project and how does that help communication? And then as we brainstorm, we put little postit notes up into these different ideas. So it’s an affinity, affinity like ideas, like minded, that those go into these different categories. So with requirements gathering, it’s a way to decompose and to organize your different ideas. So in it we can always say you have hardware, software, data network, so it’s going to fit into one of those four. And then as we brainstorm, we would focus on hardware, software, network and data. Mind mapping is kind of fun to do. It’s a way of when you’re trying to generate ideas or brainstorm ideas, you just kind of draw it out. As you can see in this picture here, one thing leads to another, to another, to another. So it’s a way to visualize the brainstorming process, it’s a way to generate new ideas and to consolidate ideas.

And you’ve got a lot of people participating, you can have all these crazy branches and how do they touch each other and it’s just a way to visualize ideas, a term that we saw one of our tools and techniques was the nominal group technique. There’s five steps here for the nominal group technique. First off, you want to generate ideas, you kind of brainstorm ideas and then you vote and you’ll rank these ideas. Then each participant will brainstorm the problem or opportunity with their ideas. So everyone does this on their own. And then the facilitator will add each person’s ideas on a whiteboard and then you talk about each idea so everyone has a clear understanding. And then you will privately vote on each idea from one to five.

And then whoever gets the most points, you can reprioritize and start the process over or that will be the requirements you go with. So there is a sense of anonymous here as to do I like the idea or do I hate the idea even though it’s my boss, he gets a one. All right, so it’s a nominal group technique is a way of having these rounds of voting and brainstorming on ideas. Larger projects. You might do a facilitated workshop, and I say larger projects because generally you leave, you go off site somewhere and you’re going to spend two or three days and you’re just going to dig in and just hammer out all of the requirements that are unavailable for that time. So in it, you might call it a joint application design. That’s a software development. So SME’s and the developers meet and they just hammer out the requirements.

But it’s a long process. It’s a workshop, could be facilitated by a neutral moderator, probably have a very intense outline to follow or an agenda to follow. In manufacturing you might have a similar approach called the quality function deployment. It’s also known as the voice of the customer. And this is a workshop typically in manufacturing where you identify these characteristics and then you prioritize them based on what the customers are saying they want. And so that’s used for product development in an agile environment. We also have some requirements gathering. So we have these user stories. User stories are the entries in our product backlog. Well, the user story is a way of describing what happens with that event or with that requirement. And there’s typically three features in a user story that you have the user, which will be the role, that’s the person who benefits from the feature, the goal, what is the Stakeholder trying to accomplish? Why do we need that requirement?

Why do we need this thing? What’s the end result of what we are creating? And then the motivation is the why? What’s the benefit? Why do we need that? Why is the Stakeholder interested in doing this? So you have the role, the goal and the motivation. And those are the user stories in the backlog. And that’s how we can move through to create our requirements or to gather requirements. Stakeholder observation is where we have job shadowing. We have passive and active. Passive is where I just follow you around and observe. I don’t say anything. Active is where I follow you around. And not only do I reserve, but I might try to do some of the work. You might allow me to do some of the work or to try it out. Or I could interact and have a conversation with you and ask questions and so on.

So job shadowing, a context diagram shows the flow of data through a system or the flow of a process through a system. So an example here in the scope model is we’re looking at the different working components. So it would show all the servers, what are the workstations, or laptops, where are the databases, where’s the data stored? What’s the workflow, how does data get in, how do people retrieve it, how is it secured? And then who are the people.

And the people are sometimes called actors. So a context diagram takes a requirement and it puts it in context of how people will interact with that solution. Prototypes are another thing that we have prototypes. We have a throwaway prototype, like this sketch here. It really doesn’t do anything for us. We sketch it up and we show a picture and people oh, okay, I get it. Let’s go with that. A functional is where I actually create something that if you agree to it, it can become part of the solution. So sometimes, like a web mock up, I’m going to create a new website, you just kind of mock it up and test the colors and the look and feel.

 You don’t really put a whole lot of time into it, but if they like that one, you’ve already got it set up and you can begin building it out. Storyboarding is kind of like a throwaway prototype, but actually draw the story of how the requirement works in the solution. So it’s just like in the movies where you see, like, the storyboard of how Batman and Superman are going to fight. I watched that movie. So a storyboard is what happens there. Those little cartoons is a storyboard where in a movie, it shows the flow of the story or the narrative. So the prototype would be the same thing. It shows how do you interact with it and what happens. All right, good job. A lot of terms here about prototypes and about requirements and the requirements management plan as it relates to scope. Great job. Keep moving forward.