PMI PMP Project Management Professional – Managing the Project Scope Part 2

7. Managing the Project Requirements

Often when we think of requirements, we think of what are the things that the customer receives as a result of this project? So there are six different requirement types to look at. Let’s take a look here. First off, we have business requirements. These are the high level needs of the organization. Our business case and business value describes our business requirements. Then we have number two, stakeholder requirements. The needs, the stakeholder or stakeholder groups probably where most of us think of. Then we have solution requirements. So the product, so what are the features and functions of the thing we’re going to create? And then within those, we have functional and non Functional Requirements. A functional requirement describes the behaviors of the product. Non functional are all about the environmental conditions. So a functional requirement would be the click sound and the torque it takes to click that mouse button.

The non functional requirements would be the security and the safety, and the ability to transmit a certain amount of signal using a certain electrical pulse. So it’s more about the environmental conditions. We think about the qualities, the safety, the convenience, the ease of use that hurt my hand if I use it too much. Number four transition requirements. How do we get from current state to the desired future state? So, operational transfer. Number five, any actions, processes or other conditions in my project. So project requirements number six, what are the quality requirements? So what’s the quality management plan, the quality assurance? How do we ensure that what we’re giving a customer is correct? So, quality control. So these are requirement types. When it comes to managing requirement types, we also have to think about a requirements traceability matrix. That’s what we’re going to look at on this slide and on the next piece here.

But managing the requirements is first based on the collection of requirements, the documentation of requirements, so the actual requirements documentation and the characteristics of those. And then we create this requirements traceability matrix.

This is a document which defines the project, its characteristics, what’s the ID? If you’re using a work breakdown structure and a numbering system called the Code of Accounts, which we’ll see coming up, you could enter that associated ID. Then we could get into, okay, what is the assumptions, what are the requirements, and then what’s the status? And then the details of that. This would be all the different phases in this particular project. And this was just made in Microsoft Excel. And so you could enter that. And then as you move to each new phase, these items over on the right, those would be the phases that as you moved into it, you would just put an X or a check mark or you write a little note all the way through until it’s been delivered to the customer. So this is a requirements traceability matrix.

It’s a table that allows you to trace your requirements through the project. So it’s just that. So it tracks a whole bunch of different characteristics. Like we just saw in the example, the name, what’s the business and project objectives, the work breakdown, structure, entry. You could have extra data about coding, like that numbering system, the code of accounts, cost and schedule. And then what’s its status? You come up with some scheme for status. I typically just do like a rag rating red, amber, green. So you can just look at it. You want to see a lot of green, not red. But you could also things like active, canceled, deferred, added, approved, assigned, or completed, or whatever legend you’ll want to come up with. And then you can add comments and notes. So it’s a way of tracking where requirement is in each phase of the project as it moves through the phases. All right, that’s it. Great job. Keep moving forward.

8. Defining the Project Scope Statement

Now we’re going to talk about defining the project scope statement. This is a really important process. It’s going to be based on a lot of the things we’ve already covered. But we’re creating here the document, an actual document that defines what is the project scope. So defining the project scope statement is about this detailed description of what we’re creating about the project and the product scope. It describes what’s the output here, what’s the product, the service or results. So what are we giving the customer? And then it allows us to create some boundaries and acceptance criteria. So defining the project scope, what will be included and what will not be included. So that’s the idea of boundaries. The process of defining the scope is to create a scope statement.

The scope statement then will allow us to break that down and create a work breakdown structure and a WBS dictionary. And those three things kind of package up the scope baseline, the scope statement, the WBS and WBS dictionary. Those three things are the scope baseline. Adaptive environments, though they define more of a high level vision and then in each iteration that product backlog is refined and prioritized and that becomes the scope, the set of requirements to work on for this iteration. So it’s a little different and adaptive. Let’s check out our edo’s for defined scope. The inputs all need the project charter, the project management plan, and particularly the scope management plan which we just created. Project documents, the assumption log the requirements documentation makes sense, right? We need the requirements to say what’s in scope and the risk register.

We’ll also need the EEF and Opas that are relevant to scope in a project tools and techniques, expert judgment, data analysis. Decision making is one of those that we’ve not seen so far. Interpersonal and team skills, primarily facilitation and then product analysis. The outputs of defined scope is the project scope statement. Project documents we’re updating project documents, we’ll be updating things like the assumption log, the requirements documentation, the RTM and the stakeholder register. Let’s take a look at the enterprise environmental factors and opas for scope definition. So what enterprise environmental factors would we need? Well, your culture of where you work, the infrastructure, personnel administration, and marketplace conditions, those all affect how you define scope. For opas, it’s going to be things like policies and procedures and templates such as change control.

Historical information is always a good source of OPA and lessons learned is an OPA. In order to define the project scope, I’m going to rely on some experts here. I want consultants, stakeholders, even the customers because they’re close to the requirements. I want professional and technical associations. So the discipline I work in, or your application field, you’re going to call on the technical associations there to help you think about what kind of requirements are needed and that will help with time and cost as well. And then subject matter experts so SME’s can help you interact with the customer and think about requirements and to make sure you’ve captured everything that you want to create. Product analysis, product analysis. Here we got some new terms. So product breakdown. Product breakdown is where I take a product.

So this clicker, for example, and we break it down and we see what’s each component in here, what does it do, what’s it responsible for? Requirements analysis. I get my requirements from the BA and then I really study those and have a good understanding. Systems analysis is a way of studying how does the system work. Now, this could have a couple of different meanings here. One, how does it work? And we’re approving upon it, how should it work? And we’re creating a whole new system. So a system is a way of how does work get done? How do you get through the work? So system analysis is the study of a system. The next one is systems engineering, and that is the building of a system. Value engineering is a way of saying in our component here, our product, that each component, each thing here has to contribute to the value. And so what’s the minimum amount of engineering or design that we need in order to get that value?

 So can I change the thickness of this plastic and reduce cost but increase value? So those two go together? Value engineering is where I study the value of all these different components in the product. And then value analysis is, well, what is the real value? How does that contribute to the overall that nothing in this should cost more than its contribution to value. So it’s trying to find the minimum amount without affecting the value that it gives to the customer. So in other words, we don’t need this made out of gold in order to be functional. And then each button on here is a function. But what’s the minimum amount of mechanics and materials that I need in order to meet expectations of the customer? You might have one question on these for product analysis. When it comes to scope definition, alternative generation is a way of saying, all right, I’ve got multiple choices here, tile or carpet or wood.

So I can do benchmarking. This is how it works. The soundproofing work versus this soundproofing material works. So which one do I choose? Systems. So the way of getting the work done, order in, order out. I can do alternatives. Generation with vendors, lots of choices with vendors. What about different materials, of course, and resources? Senior engineer versus junior engineer. One costs more, can get done faster, one costs less, but will take longer. So that’s resources. Resources don’t have to be just people, though. It could be materials, equipment, facilities. You’re going to compare different airlines. That could be a resource. So let’s look at what goes into a scope statement. We know, we describe the product scope. It’s the thing you’re going to create. It also describes all the project deliverables. What’s the acceptance criteria? How do you know we’re successful? And then what’s excluded? We’re going to build a house, but we do not build a swimming pool. We’ll build a house, but we do not include the appliances. You got to buy your own stove and fridge and all that stuff.

The project charter versus the project scope. Let’s compare and contrast. I get a lot of questions on these. Generally, the charter is more high level and it’s about authority. The scope is much more specific and it’s about deliverables. So the charter is about why are we doing the project, what are the objectives, what are the high level requirements, the high level description, what are the big picture risk here in this type of work in our project? What’s the milestone schedule, the summary milestone. So it’s kind of a guess of where we should be based on starting today stakeholder list. So your general stakeholders who signs off on things, who’s the PM and how much authority they have, and then who’s the project sponsor. So it’s more about getting started and authorizing the project. The scope, though, is very clear. It’s the scope description. What are we creating? What do you get as a result of this thing? What are the acceptance criteria and then what’s excluded? So that’s the scope. So really know the charters about authorizing and starting things. The scope is getting very specific on what we will create. All right, good job.

9. Creating the Work Breakdown Structure

One of the most important documents that we’ll need in the project is the work breakdown structure. The WBS, the work breakdown structure. It’s a decomposition of the project scope. It really visualizes the project work. So you take the project scope and you decompose it. Which brings us to the worst joke in the whole course, and that’s the project work breakdown structure is a lot like Mozart. For a long time, Mozart was composing, but now he is decomposing. There you go. I told you it wasn’t a good joke. But now you’ll never forget. The WBS is decomposed from the project scope. It’s broken down. So you subdivide the project work. The smallest item in the work package, the smallest item in the WBS is called a work package.

A work package might be like the garage door or the window in the kitchen, or a particular function that a piece of software does. Or a particular function that a piece of software does could be a work package. Let’s take a look at the edo’s here to create a work breakdown structure. So our inputs for the WBS, the project plan, particularly the scope management plan, project documents, we have the project scope statement and the requirements documentation.

And of course, we have EEF and OPA are two tools and techniques to create the WBS expert judgment and decomposition. Our outputs will be the scope baseline. Remember the scope baseline, we need three components the WBS, WBS dictionary, and the scope statement. We’ll have project document updates, the assumptions, log, and requirements documentation. To create the WBS, we take the project scope statement and we decompose it. We break it down into smaller and smaller items. So it’s deliverables oriented. I’m building that house for you. So in my WBS, I would say this is the garage, the living room, the kitchen, the master bedroom, and so on. Then in the kitchen, I would say we have cabinets and break those down. And then we have appliances and those types of appliances.

We have a refrigerator and a stove and a microwave and a dishwasher. So it’s the decomposition of deliverables. This is not the activity list. We’re talking about things that you get if I finish the project. It’s a major component of the scope baseline, and it will help with project planning. We’re going to see the WBS and the scope baseline be an input to a lot of our planning activities. It really visualizes what’s in the project. It clearly defines what’s in scope and what’s out of scope. So it serves as a deterrent to change. Within the work breakdown structure, there’s a couple of terms that we need to know. We have control accounts and code of accounts. A control account are for work packages. So this idea of a control account plan, I’m building a house for you. And in the kitchen, we have set back, let’s say, $75,000 for the construction of your kitchen. So a control account plan is that $75,000 for the kitchen.

I don’t need to know today what type of cabinets you want and what type of countertops or appliances, but those things cannot exceed 75,000. Everything in the kitchen is up to 75,000. And that’s a control account plan, sometimes called a cap. But a control account plan is a way of segmenting. All right, that’s the kitchen. We have 75,000 for it. And these are the decisions to be made. Those decisions to be made are called planning packages. So you’ll see that again later on. So, like, what type of counters, what type of appliances, and so on. Those are part of the cap. And they’re planning packages, not work packages. They’re planning packages. A code of account, though, is much simpler. A code of account is just a numbering system. So the project is 107, and then the garage is 107 one, the kitchen’s, 107 two. The living room is 107 three.

And then you pin that numbering system to each deliverable. So it just gives everything in the WBS a unique identifier. You could do work breakdown, structure template, sometimes called the WBT. I take a similar project and I adapt it to this project. I’ve been in some organizations where they do the same type of works over and over and over. So they take a pre populated WBS for every project. They have these standard things they create, and then they just customize it and update it for the current project. I’ve mentioned the WBS dictionary a few times. The WBS dictionary is basically a dictionary. It describes each item that we’re creating. It gives information like that code of account identifier that numbering sequence talks about, well, what is this thing? What assumptions and constraints are tied to it? Who’s responsible for it? How does this contribute to the milestones? What activities are needed to create this thing?

What resources are needed? What are the cost? What are the quality? What’s the acceptance criteria? What technical references will go with these deliverables? And then if you’re working with a vendor, do you have contract information? So basically, the WBS is a way of taking each work package, each deliverable, and defining it. And so it’s going to help us when we get into cost estimating and we get into schedule duration estimating, because I need to know all this kind of stuff, because that’ll help me make a more accurate cost estimate and a more accurate duration estimate for the activities to create these things. Just to be clear, because you’re going to see this term a lot. The scope baseline are three documents the scopes statement, the WBS dictionary, and the WBS. All right, great job. You’re making good progress. Keep moving forward.

10. Validating the Project Scope

If I’m building a house for you, would you just trust me when I said we’re done and here’s the keys? Or would you want to walk around a little bit and inspect things before you write me that big check? Probably you’re going to want to inspect it because I don’t know much about construction. So you want to inspect it and make certain that what I’ve created is what you’ve asked for. In fact, you probably wouldn’t wait till the very end of the project. You would have these intermittent opportunities to inspect what I’ve created, and that is validate scope. Validate scope is an inspection driven process where the customer inspects the project deliverables. This is typically done at the end of each phase, but also at project completion. You might know this as a review or an audit or a walkthrough of what’s been created. The goal here is to get the customer to accept the work. So validate scope is all about acceptance. Let’s check out the Edo’s for validate scope.

Our inputs. We have the project management plan, specifically the scope management plan, the requirements management plan, and the scope baseline. Then we have some project documents, your lessons learned register quality reports, requirements documentation, and the requirements traceability matrix. And then you’ll have verified deliverables and the work performance data, tools and techniques to validate scope inspection. The customer or the recipient of what you’re creating, they have to inspect the work. This could also be like a city inspector is acting on the customer’s behalf. And then decision making. And you might have some voting as one way to make decisions. You might have multiple stakeholders that they vote on, acceptability your outputs will be the accepted deliverables work performance information change request. And then you have some project document updates like your lessons learned Register, the requirements doc and the requirements traceability matrix.

When it comes to inspecting the project work, we’re using the description like you’re measuring, you’re examining, you’re testing, you’re validating, you’re doing reviews, you’re doing a walk through, it’s any of these terms where the customer is inspecting the deliverable. So on your exam, when you see these types of terms, like I’m inspecting, I’m touching, I’m walking through, I’m testing, and I’m the customer and you’re the project manager, I’m inspecting the work. So I’m doing scope validation. So just know it can kind of leave some cues here as to this process. Scope validation is all about formally accepting the project work that I want the customer to sign off on what we’ve done. I want them to agree this is good and we met the requirements and they’re happy. So it’s acceptance and we’re signing off. You could have change requests so the customer may notice a mistake.

So you have to do a corrective or defect repair. So that could cause a change request. It could also be the customer says, hey, you did a great job, but I want to add a few things, so sure, we can do that. Let’s do a change request. We need more time and money to make it happen, and then we’ll go do it. Scope validation and quality control are very similar, so you’re going to be ahead of the curve here. Quality control chapter eight on quality is an inspection driven activity. However, the goal of quality control is I inspect the work before the customer does. So me, the project manager, or my project team, we inspect the work and our goal is to keep mistakes out of the customer’s hands. Scope validation is the customer inspection, the works. And the goal is for the customer to sign off and to say it’s good and they accept it. So QC is, I want to keep mistakes out of the customer’s hands. Scope validation, I want the customer to accept what we’ve been created. QC always precedes scope validation. You do it first. All right, good job. Keep moving forward.

11. Controlling the Project Scope

Of course we need to control the project scope. We can’t have the project team and stakeholders and vendors just making up stuff and adding stuff and removing stuff. It would be just a big mess. So controlling the project scope is where we want to keep everyone on track and in agreement that this is what we agreed to do and so we are doing it. And this is called maintaining the scope baseline integrity that we only create what was agreed upon and what’s in scope. If it’s out of scope, then it’s not something we’ve agreed to do. So if you want to do it, you being the customer, it has to go through integrated change control. So we want to keep the project in scope within the boundaries of what we’ve all agreed to do. The Edo’s to control scope.

Our inputs and our project management plan will be the scope management plan, the requirements management plan, change management plan, configuration management plan, the scope baseline and the performance measurement baseline. The project documents we’ll need to control scope lessons learned register the actual requirements, documentation, the RTM and then we’ll need some work performance data that raw data and OPA tools and techniques. Here data analysis. What we’re looking at is variance in trend. So are there variances between what was planned and what was created?

And then are we noticing any trends from a user, one of our project team members, that they’re adding things that shouldn’t be in scope so they’re doing some scope creep? Or are we noticing some issues when it comes to our scope validation? So we have to do some corrective action or preventive action. Our outputs here you get work performance information, you get change requests. There’s the preventive and corrective and defect repair. So change request updates to our PM plan. So you might be updating the scope management plan, the scope baseline, the schedule baseline, cost baseline, performance measurement baseline. So if I update the scope, I’m going to be reflecting cost, time and performance.

Kind of hard to add to the scope without affecting those other areas that very rarely can you add to the scope without needing more money and more time. It’s possible though that I could take things out of scope to meet the amount of time and money I have left. So it could work the other way too. You might have to update your project documents, so your lessons learned, the requirements documentation and your RTM. Let’s talk about some things in control scope. Some questions we want to ask are the changes agreed upon?

Do we need this change in scope? If the answer is no, then we have some conflict resolution, we have some analysis here we need to understand why they aren’t agreed upon. Has the change already happened? So we’ve already had some scope creep? Do we need to undo those changes or do we just live with it? But we say no more of that. How do we manage that existing change? That’s what I said. How will you incorporate and approve change? So, back to our kitchen scenario. I want this wall to go over 2ft. So how do I get that into the project? How do I get that into my plan? And then what baselines are affected by the change?

 So time cost our scope, obviously, and the performance measurement baseline. So are those affected because we’ve introduced a change here, variance analysis. So in scope, we’re talking about a variance in what was delivered versus what was requested. So we’re looking at deliverables. So the performance measurements, maybe we had specs on throughput for a network. So this is what we wanted for throughput and this is where we are. Obviously, there’s a variance in that performance. What about the magnitude of variation? So it’s real close. Is it within that range of plus or -3% for example if it is too big let’s do some cause and effect here. This is the throughput that we believe we could get. Why are we only getting this much throughput? Why aren’t we meeting what we thought we could get?

So let’s do some cause and effect analysis here and figure out what’s happening. And then can we do some corrective or preventive actions because of the variance? Trend analysis, though, is where we’re seeing things trending over time. We’re seeing a repetition and we can almost predict what’s going to happen based on past experiences. Earned value management, something we’ll look at in chapter seven of the Pinback on Cost is a suite of formulas to predict performance and to show current performance. So that’s trend analysis. Are we improving or deteriorating when it comes to how our project is performing? So, are we having all these random results or are we having a steady decline or we hopefully getting better a little bit at a time? What’s the degree of variance? So again you could say plus or -3% in regard to the throughput or to the accuracy or whatever the technical requirement is, and then you might have corrective or preventive actions as a result of trend analysis. All right, good job. I’ll see you in the next lecture.

12. PMP Coach: Control Your Scope

What’s your scope like? The scope for this course and for your current goal is to pass the PMP exam. So to pass the PMP exam, PMI does not tell us what the passing score is. You have 200 questions, 175 count, so you have to answer all 200. But of those 200, we don’t really know how many will go to your passing score. The goal is not to get 200 out of 200. Correct? The goal is to pass. It’s like the old joke, what do you call the guy who graduates last from medical school? Doctor. So it’s not a contest here, it’s a pass failure exam. Your goal, and my goal is to pass the exam. So your scope, as you study and as you work to this, it’s not to take this information and how do you apply it where you work?

Don’t try to bend this to your environment, your organization. You want to think about, I need to know this and understand this for passing the exam. So try to prioritize and don’t think about, that’s not how we do it where I work, because I believe you, it probably isn’t.

The goal is to think about how am I going to be tested on that information, or that’s going to be tricky to recall, or that term is a lot like this term. So as you move through the course and you move through these, think about how is this in scope or out of scope? When you start questioning or wondering, or wondering how to apply this, everything’s in scope here, if it’s concentrated on passing the PMP, and that’s our goal, right? It’s not to get a 100, it’s to pass. All right, keep moving forward. I have confidence you can do this.

13. Section Wrap: Managing the Project Scope

Great job. You did it. You finished this section on managing the project scope. I knew you would. If you’re not a quitter, you’re somebody. You’re going to start something, you’re going to finish it. So that’s great. So keep moving forward. In this section, we talked about planning the project scope scope, creating that scope management plan. We looked at project scope versus product scope. We talked about some trends and emerging practices in scope management. How does scope management work in an agile environment?

Creating the scope management plan, managing project requirements. We looked at the scope statement, creating the work breakdown structure, which you did an assignment on, and the WBS dictionary. And we talked about validating the project scope. Another process we looked at was controlling the project scope. And remember how that’s tied into project integration management, that those two are related. Okay, good job. You finished section eleven, which was chapter five in the pmbok for managing the project scope. Good job, keep moving forward. I’ll see you in the next section where we’re going to talk about schedule management.