All PMI CAPM certification exam dumps, study guide, training courses are Prepared by industry experts. PrepAway's ETE files povide the CAPM Certified Associate in Project Management (PMI-100) practice test questions and answers & exam dumps, study guide and training courses help you study and pass hassle-free!

Manage the Project Scope for Project (and CAPM!) Success

1. Section Overview

Welcome to this section, where we'll talk about scope management. We'll begin our conversation by talking all about collecting requirements. This is a pretty important process where a lot of project managers spend some time because we want to get the requirements right at the beginning. So this means really understanding the types of requirements and what the stakeholders expect as a result of the project. So we'll talk about things like business requirements, stakeholder requirements, solution requirements, transition requirements, project requirements, and quality requirements. So a lot happens in just that one process. We'll talk about focus groups, which are extremely important not only for this section but also for your exam. You'll see this throughout the course in a couple of different areas. But focus groups will talk about what a focus group is and how you should moderate a focus group. Also, when gathering requirements, we'll look at a facilitated workshop. It's a way of working with customers in a very focused way.

So we'll spend some time talking about workshops. We're going to look at prototypes—or three different types of prototypes. So I'm not going to tell you now; you've got to watch the section to find out. So we'll look at prototypes. One of the most important processes will be defining the scope, and we want to create the scope baseline, which will be the scope statement, the WBS, and the WBS dictionary. So much essential information I've mentioned the WBS a few times, but it's in this section on scope management where we will really define what it means to create the work breakdown structure because this is a process of decomposing the project scope. So really pay attention to this process—it's a really important process, not only for your role as a PM but for your exam. I guarantee you you're going to have some questions about the work breakdown structure. As I mentioned, the WBS is part of the scope baseline, the scope statement, the WBS, and the WBS dictionary.

So look for that in this section as we complete activities and as we complete deliverables. I should say we'll work with our customer to validate scope, get approval, get sign-off, and get acceptance on what we have created. So that is to validate the scope. So, this is a really important process for your exam. Then, of course, we'll control scope to ensure that we capture changes before they happen and that they adhere to a change control process, and how does that change affect different baselines? So we will control the scope. In this section, we'll also look at variance analysis, which is the difference between what was planned and what was experienced. So we want to look at why it has happened and how we can prevent or correct it in the future. So variance analysis is an important activity that we'll look at in this section. There's a lot of information in this section, so focus, dig in, and knock it out. So let's get going right now. see you soon.

2. Plan Project Scope Management

Welcome to chapter five in the Pinbuck guide, all about scope management.

We're going to begin our conversation by talking about planning project scope management and creating the scope management plan. Planning project scope management or managing the project scope It all comes down to ensuring that we are only doing the necessary work to meet the project objectives and that we are not doing more or less than what is required of us to deliver to the customer. So we have to give exactly what was promised. Let's talk about planning the project scope. This process creates the scope management plan. Also, we're going to create a requirements management plan. Now, the scope management plan really defines three things. It communicates how you will create the project scope statement; how will you validate the scope? It's just assuring the customer that you delivered what was promised, and how will you control scope throughout the project?

Also, this plan will offer direction for scope management. So we're talking about scope change control, and it serves as a deterrent for scope creep. We call it "scope creep," or those tiny little changes that steal time and money. It's not in scope. We don't create it. You must adhere to the change control. Our etho here for planning scope has four inputs: the project management plan, the project charter, and then we have EEF and OPA. Just two tools and techniques here for planning scope management, expert judgment, and meetings. And then, as I mentioned, we have two plans. As a result of this process, we have the scope management plan and the requirements management plan. I want to go back and talk about OPA for just a moment. With planning scope management, every process—or every knowledge area, I should say—has a related plan. And you're going to see that these plans in the "Pin Box" aren't defining the scope.

The plan tells you how you'll go about defining scope or doing quality assurance, for example, or how you'll do risk identification. So when you think about planning scope management and creating a scope management plan, it's really defining how you'll do the other processes in this knowledge area. Well, how does this relate to OPA? You don't want to do this from scratch every time you have a new project. You don't want to create a scope management plan from scratch. So you're going to use those organisational process assets. You're going to take a similar project and adapt it to your current project. You're going to use that like a template, and then you'll adapt it, modify it, and make it work for your existing project. And we're going to see that idea over and over as we go into each knowledge area from this point forward. As a result, OPA will be a constant input to planning. So I just want to point out that little tip. Let us now discuss scope management for project and product scope. The product scope is all about features and functions. The project scope is the work to be completed.

So think about it this way: you want me to build you a home, and you say, "Okay, I want this home; it's going to be our summer home." So I have these particular ideas of mine, and I want a big porch, I want a Jacuzzi in my bathroom, and I have some ideas about the layout and about the kitchen. And you go on to describe how you're going to use the house. You tell me everything about the features and functions you want in this vacation summer home. So it sounds wonderful; it sounds great. What you see in your mind's eye when we talk about that home is all about the features and the functions. How will you use the house? You see yourself living there with your family in the summertime, or you have guests and friends, and how are you going to live in that home? Well, behind the scenes. My project scope is to create everything that you want for yourself. But you aren't really asking me about or interested in the plumbing or the electrical wires or how power will come into the house and go to every room.

Or you aren't really concerned about the blueprints and the permits. Or maybe you're concerned, but it's not really the features and functions. So the project scope is the work that I must complete in order to deliver the features and functions. So the product scope builds—or influences, I should say—the project scope. So your vision of using that home directly influences my project scope. But my project scope is more than just your features and functions. It is everything that allows you to have those elements behind the scenes that allow you to deliver and make that vision a reality. So the product scope and the project scope are so symbiotic that they rely on one another. This is true at execution as well; if I am executing the project and we're adding things or taking things away from your features and functions in your product scope, then I'm creating something that you didn't want. So that's poor quality. So the project and product scope are directly related. OK, good job. A brief discussion of planning and scope management follows.

3. Collect Project Requirements

When we talked about planning scope management in the last lecture, we also had a requirements plan. So that's what we're going to talk about now—collecting these requirements, and the plan will help guide us in how we do this. So the requirements are what the project must adhere to and deliver in order to be successful. So, as we collect project requirements, let's take a look at the different types of requirements we have to consider.

So I know there's a lot here on the slide, but these are all the different types of requirements that we need to know, not only for the PMP but also for your role as a project manager. Well, first off, we have business requirements. Does this project support the higher-level needs of the organization? Does it fit within our strategy and vision? That was one of the first questions we were asked during initiation.

So then, as we move here into planning, we're looking at, okay, I want to collect requirements. And these business requirements have to support the higher-level needs of the organization. Then we have stakeholder requirements. And these are the more specific requirements—the needs of a stakeholder or some type of stakeholder group. We have to acknowledge that and document it. Stakeholder requirements Solution requirements are more specific. We're looking at features and functions and the characteristics of the product or service as a whole. Within the constraints of the solution. We have functional requirements and nonfunctional requirements. Functional requirements are all about the behaviour of the product. How does this thing work, and what are your expectations as a stakeholder for how it should work?

So it has to be usable, reliable, and so on. And we want some quantitative measurements here to know if these functional requirements are working. Nonfunctional Requirements describe the environment or specific qualities. So things like security, reliability, uptime, and then just the implied needs that go with a requirement So you might have me develop an application for you, for your phone, but you might have the assumption that I'm going to develop it in English, and when I give it back to you, it's all in some foreign language you weren't expecting. That's a problem here. We didn't have a good understanding of one another. So we had a breakdown in our requirements, our functional requirements, and our nonfunctional requirements. If it isn't secure or reliable, and so on, then we have transition requirements. Now this is really important, especially in IT projects.

So we're developing a piece of software for you. And in this software, we have to move it from us creating it—my team creating it—and supporting it to operations. But at the end of my project, if my team just disbands and we all go off to other projects Now you have to support that, learn it, and so on. So that's not a good scenario. We need some transition requirements for how we transition this so that operations understands it and can provide help desk, support, and training. So there has to be some transition here. And often, you'll create an operational transfer plan. How do you transfer from the project into operations and then project requirements? What actions, processes, or other conditions do I have to meet as the project manager on my project? Quality requirements. This is the criteria needed to validate the successful completion of a project or the fulfilment of other project requirements.

So quality is all about conformance to requirements and fitness for use. It is an entity's ability, the thing we're recreating, that bears on its ability to satisfy the stated or implied needs of the stakeholder's customer. So what are the quality requirements? Basically? What constitutes quality? How do I know that quality is in the thing that I create for you? Now, let's talk about edo. Let's take a look at the eDo for gathering requirements. Right. Our edo here is the scope management plan, which is an input to the requirements management plan and an input to the stakeholder management plan. We must know who we are speaking with, who our customers are, who our stakeholders are, and we must maintain a stakeholder register. Now there are some tools and techniques—many tools and techniques—here are many different ways to go out and gather requirements. You are not required to do all of these, but these are your options for gathering requirements. Interviews.

You've got to go out and talk to your stakeholders. a focus group. A focus group is where you gather your customers, and you'll have an independent moderator, someone who isn't involved in the project. So they're going to ask questions and really try to understand what the stakeholders want as a result of this project. So it really takes away, like if a senior manager does it, people may change their opinion because the senior managers in the room often facilitate workshops called "joint application design," sometimes called "joint application development." It's where we'll go to an off-site facility, and we'll just cram and focus and really hammer out in a day or two all of the requirements that are going to be in this project. Group creativity techniques, things like brainstorming, group decision-making techniques So we all vote on it, and there are a number of different ways that we can vote on it. and we'll look at that in more detail in a moment. If you're on a very large project and you have a lot of stakeholders, you could do a survey.

So you could blast the electronic survey out to help build consensus on requirements. Observations: Can you go out and see the work? Especially if you're trying to solve a problem? It is beneficial to go out and understand and experience the problem in order to gain a better understanding of what the customer is going through. Prototypes: can you build a mockup or a working prototype? Or can you sketch out on a piece of paper what the solution could be? and that can help lead to requirements. Benchmarking. Benchmarking is just where I compare one system to another. So, Oracle vs. SQL, Excel vs. Google Sheets, or whatever the case may be Context diagrams are where I draw out a solution and see how all the different components interact with one another, including the people who are going to use that system. We've got a lot of that. Then we have document analysis. I'm going to go back and study the charter. I'm going to study any of the supporting details. I'm going to look at all the emails that have come in. So I'm really looking at the information I have available in the early stages of the project. the business case, the feasibility study, things like that. Now my outputs are here:

I have the requirements documentation that we nail down. What are the requirements for the project, and how do we know we're successful? by delivering these requirements. And then there's a new term for you: requirements traceability matrix, or RTM. This is a really valuable tool. I love an RTM. I list all of my requirements, and then I have all the different phases of my project, whether I'm doing it for training or app development, so I can trace that requirement through the whole project and see where it stands in the process and whether it has been created and is part of the product. And then, if not, what's the holdup or how are we going to get to that activity to begin creating that requirement? So an RTM is a really valuable tool. You'll probably see that on your PMP. All right, let's talk about some of these tools and techniques. You're interviewing stakeholders. Now, stakeholders, we're talking about the people who have a vested interest in our project. So, when they interview stakeholders, they go into detail about identifying individual stakeholders.

Remember, that's one of our initiation processes. They're identified and documented in a stakeholder register. The stakeholder register includes the individual's name, the group to which they belong, their concerns, threats, perceived threats, and requirements—everything you need to know about that stakeholder. So when I go out to interview stakeholders, that gives me some insight that will also help with stakeholder management and engagement. When we go to the interview, we could do a one-on-one where only you and I sit down and discuss requirements. We could do a one-to-many where it's just you and a few of your colleagues who are stakeholders, and you're discussing the project with just me. Or we could do a many-to-many where it's you and your colleagues and me and some of my project team members. And we'll have a big discussion to gather requirements.

So there are lots of ways to interview stakeholders. A focus group, as I mentioned, is where we have a neutral moderator, ideally about six to twelve people, and they come together and they talk about the solution or the project or what they want to see as part of the requirements. An important point here is participant composition. Participant composition is a way to describe if we're doing a large project, like a new piece of software that we're going to develop for our company do. We get a sampling of people from each department, and they come together so they can interact with one another and talk about their needs. Once we can compare and contrast how the different departments use the solution, that's a fine approach. Another approach, though, is to say, "Well, we're only going to talk to people in this group from sales, in this group from IT, in this group from marketing, or whatever the case may be." So, when considering participant composition, consider the dynamics they'll have interacting with one another, as well as how open or honest they'll be about the requirements in front of their peers or colleagues from across the organization. So the participant composition directly influences the conversation in the focus group and the outcomes you're likely to get from that focus group.

So we have to think about that in this approach. a facilitated workshop or a requirements workshop. As I mentioned, we bring everyone together: all of our key stakeholders, our project team members, often the project sponsor, and of course the project manager. And we go off site somewhere, and we're going to just hunker down for a day or two and really hammer out all the requirements. So we're looking for some consensus on what the requirements should be. I enjoy doing facilitated workshops because they are quick and easy. You just hammer it out. It can create some good teamwork and some good dynamics. People can understand where each other are; we're away from the office; there are no distractions. We're only focusing on requirements. And it really helps because we get a consensus on what's required. We don't put it off and say, "Do research." No, we're going to figure it out right now and get this thing done. And then that allows us to really tear off the project and get into executing. So facilitator workshops Sometimes it's called a "joint application design workshop." You might also see this as the voice of the customer.

If you're working with total quality management—this is a weird one—it's also called quality function deployment. So basically, you're defining what quality is by satisfying these requirements or identifying all the requirements that will give you quality in the end result of the project. Okay, another method for gathering requirements. You've got a lot of them here. Brainstorming. Get everybody together and just brainstorm. The nominal group technique is where you brainstorm and then sort those and vote on them. or prioritise mind mapping. Draw a big picture of your projects and begin What you draw can stimulate other ideas. Affinity diagrams are where you do brainstorming, but you sort it out by saying, "Okay, this is just hardware; this is just software; this is a network; this is data," or whatever the case may be. So you do brainstorming, but you kind of segment the brainstorming, whereas typical brainstorming could just come from all over. Now, a Delphi technique—this is a really important term that you need to know for your exam because we'll see it again in risk management. Here's the Delphi technique.

We send out a survey to all of our stakeholders with questions about the requirements they would like to see in the project. Stakeholders respond, and then based on their responses, we compile those based on some consensus or a trend in the requirements identified. Then we send out another survey, this one more specific, and then people can respond to that. And then we do it again and again. And eventually we will have consensus based on the responses and the interaction in the survey. Now, the reason why this is so good is, one, that it's anonymous. So it takes away the individual's or the fearor's fear of repercussions by identifying a requirement that might be in conflict with a manager or the highest-paid guide in the room. Because it's anonymous, no one knows who's saying what. And then it gives a chance for people to respond to that and say yes, I agree, or I don't agree.

And here's why: It's also really good for identifying risks, for the very reason that I may not want to identify a risk if it's going to make my boss look bad. So it's anonymous if I build consensus. It's called the Delphi Technique because the Oracle of Delphi, or the oracle at the Temple of Delphi, favoured reason and logic. It was used originally in the Cold War to determine the effect of technology on warfare. So go figure. But you'll probably see the Delphi technique on your exam. Group decision-making techniques It's unanimous. Everyone agrees. The majority, more than 50%, agrees. A plurality is where you have multiple factions and the largest bloc agrees. So this is what we often see in elections, right? where you might have more people against the party that wins. So there is plurality, but the largest bloc agrees, and then a dictatorship is where the power decides. It could be you, the project manager, or your sponsor—whoever has authority over the project. I mentioned questionnaires and surveys.

This is pretty straightforward. You distributed a survey, which is ideal for large groups. could be paper-based, more realistically, right? We're going to use internet technology to send out a survey. It also helps us overcome geographical concerns. We have people all over the world who are stakeholders. They can do a survey, but we have to take into consideration any language barriers that we may have to adapt to. so that other people who speak other languages can participate and their voices can be heard. important topic right here: stakeholder observation for requirements gathering. I'll go out for stakeholder observation and job shadow one of the stakeholders. And then we have two types: passive and active. Passive means I just sit back and observe. So I'm just watching what the stakeholder does. And so I'm not participating; I'm not interacting; I'm not talking; I'm just watching. Active is where I'm more involved, and I may even try out the work, especially if I'm trying to solve a problem as part of this project. If I can experience the problem, then I will have a better understanding of the requirement. So stakeholder observation is both passive and active.

Know that for your exam prototypes, you can have a throwaway prototype. It looks like you drew it on a napkin. A functional prototype is where you do a little bit of work and create a mockup that you can actually use when you go to create the solution. Let me go back to the throwaway prototype. A throwaway prototype is really a mockup. Like it's a piece of software, and they just mock it up on the screen with the colours and maybe a few buttons you can click on. But it doesn't actually do anything. So it doesn't have to be just on an app. I always go back to that idea. Storyboarding is where you draw out the solution, either in Visio, PowerPoint, or on a whiteboard. So you storyboard the solution—how you get from beginning to end in the solution. Then we benchmark the requirements. Benchmarking is where we compare two or more systems, businesses, or approaches.

We set an external basis for performance, and then we compare organisations for requirements. How does it work in the sales department? How does it work at company ABC? If they can do it, we can do it as well. a context diagram. As I mentioned, a context diagram is a scope model. It shows. It's a picture that shows how people called actors will interact with the system. So imagine an email system. I want to send you an email, so I'm going to send you the email. A context diagram would show the different servers that email moves through on the workstation, mine and yours, maybe your phone, or however you get that email. Is there a database involved? And then what's the workflow? How does it go all the way through the system to you, and do you acknowledge it or respond to it? That's a context diagram. It's really good to show requirements because it identifies all of the different pieces that I need in order to create the email solution.

If that's our project, I mentioned analysing project documents, looking at all the information that's available to me, the project plan, the brochures, the blueprints, and some of those early specs in the business case or feasibility study. As a result, gathering requirements is critical. Finally, we have management of the project requirements. So I mentioned the "requirements traceability matrix," which is a big table of requirements. It lists our business needs, the project objectives, the work breakdown structure, and deliverables, and we'll talk about the WBS coming up. Then, what is the status of that requirement? Is it currently in development? Is it in testing? Is it finished? So all of that business is part of the RTM. We typically have an RTM when we're doing software development. All right, good job. I know we covered a lot of information about managing project requirements. It's really important for your exam.

4. Define the Project Scope

In this lecture, we're going to talk about defining the project scope. Remember the project scope statement? It really nails down the objectives of the project. It really defines what we have to create in order for the project to be successful. The scope is a detailed description of the project, but it is also the product, all of the features and functions that the customer expects as a result of this work. The scope also identifies project boundaries. What we will not create as part of this project We'll build the house, but we're not including the swimming pool. So that's a boundary. The end result here is to create the project scope statement. The scope baseline will then be created based on this. And the scope baseline is actually comprised of three documents: the project scope statement, the work breakdown structure, and the WBS dictionary.

And we're going to look at all of those in this section. Consider the EDOs when defining scope. So to define scope, we're going to begin with the scope management plan, the one we talked about in the last lecture. And then we have the project charter, the requirements, documentation, and OPA, tools and techniques, expert judgment, a new tool and technique here, product analysis, where we take the product that the customer wants us to create and we really tear that apart and really understand what it is that we're trying to create for the customer. Alternative Generation: this is just a way of saying, do I have more than one choice?

So we want wood floors. Do they have to be oak, or do they have to be cherry? What type of wood floors are we after here? Or just flooring in general? We can have a wood floor, tile, carpet, or even stained cement. We can do a lot of different things for flooring. So we would trade off alternative generation with scope for time and money while still getting a good quality product. But we're discussing solutions, so what are some others? We have facilitated workshops, so remember that we did a workshop to define scope. That's what we discussed in terms of requirements and outputs. Here is the project scope statement, and you might have some updates to your project documents. Let's talk about the activity of defining the project scope.

As a result, consultants as well as stakeholders, including customers, may be involved. They are the people who are closest to the deliverable. Professional and technical associations So in your industry, you might have some different associations that you go to in the IT world or in healthcare or in learning and development that are going to help you define scope based on leading practises in your field. industry groups, same idea. And then there are the subject matter experts that we've seen. That means you're going to bring in someone smarter than you or closer to the deliverable to help you and the project team make the best decision possible to define the scope. A term that I mentioned was "product analysis." And there are a few terms here that you should be familiar with if you're doing product analysis. And all of these are pretty closely related. The idea is that we take the product, the thing that we're creating, and we blow it apart so that we really understand each component of what we're creating. As a result, we perform a product breakdown, a systems engineering value analysis, and engineering value estimation.

All of this is related to how the various components interact with one another, and how we can improve on that workflow by combining different components to produce a better end result at the lowest possible cost. Function Analysis How will all of the various functions and their various parts and components contribute to the end result? So what is the function of each individual component in this clicker I've been using, for example, or in the house or the car that you're designing? And then quality function deployment follows that same mindset here: how does each one of these components of the thing we're creating contribute to quality? And what can we change or modify slightly to save money or time, or to improve the overall outcome? So a good example of product analysis is when we're talking about improving a product. Perhaps that was one of the projects we could pursue. So we have a small engine that we use in yard equipment like leaf blowers and weed trimmers and things of that nature.

So we're looking at this engine, and our goal is to improve upon it and to improve our profitability. So we've noticed that out of about every thousand units that we ship in our company, about 25 come back because of a defect in a part. That cost us money and harmed our reputation. It affects our business value. So we do a product analysis on this small engine and come to the conclusion that if we were to change some of the plastic parts of this engine to metal or brass or whatever it is, the engine would operate better. It might cost us $50 more per engine, but our returns would drop to maybe two or three instead of 25 per thousand. So we spend a little more on the product, but it's worth it in the end because the number of sales returns and our reputation increase the business value. So that's a product analysis; any of those that you see there on your screen could be related or be used to get that solution. So product analysis So you might have one or two questions about product analysis on your exam, and it's just going to be something along those lines that I was just talking about. Let's move forward.

We have alternative generations. Alternative generation is just where you have more than one choice, so am I going to choose Oracle or am I going to choose Sequel? So I do benchmarking. I want to compare two different systems, so I want to compare a system of how we use automated procurement versus filling out all these forms. I wonder how that's going to turn out. I want to compare vendors based on past performance, reputation, references, and cost. So I want to look at vendors for two different types of materials. So are we going to use this particular drywall, or are we going to use another drywall that has soundproofing built into it? I don't know. So we do a test. We'll go out and buy some samples of materials and test them out. Whatever your industry, you're dealing with different types of network cables, different types of monitors, and different camera lenses.

Those are all materials with which we can do alternative generation, and then, of course, resources. We can generate alternative energy. Is it more effective to have a senior engineer do this activity? They can get done faster, but they cost more. Can I do a junior engineer? It will be less expensive, but it will take a little longer and may be less reliable. So I can compare resources as well. That's all part of alternative generation-facilitated workshops. This was evident when we discussed requirements gathering. It's simply a method of gathering those individuals, our stakeholders, and looking at stakeholder expectations, creating documentation, ensuring that we're communicating the scope and plan with our participants, and doing some verification that we're actually including in scope, what the requirements called for that we discussed in the previous lecture?

That requirements feed into the scope, that the product scope and the project scope are symbiotic, that they are linked. And then you may have business analysts involved because they were way back at the beginning when they did the business study for the business case. So what goes into a project scope statement? Well, we have a scope description. What is it that we're trying to create? Expound upon that and describe what we will do in this project and what we'll create. The product acceptance criteria How do we know we're acceptable? How do we know not only that we're acceptable, but that our project is acceptable? How do we know the end result is what the customer expects? What are the project deliverables? So what will the customer receive? What will the organisation receive? What will my team members receive? But wait a minute, what do team members receive? Member training. They have competence and experience. That's a deliverable.

That's something that can be created. The customer doesn't get it. You can't take away somebody's knowledge, but it's part of the project deliverable. So it increases business value or increases the competency level of your project team. So then you can do future projects more effectively. Project exclusions. What will we not create? We'll build a house, but you are not getting a swimming pool from us. So we don't build swimming pools. project constraints, a deadline, a predefined budget, and the scope. Any laws that you have to follow, those are all constraints. Anything that limits your options is a constraint. Also, as I mentioned earlier, if you assume that the app will be developed in English and we use Spanish, we will have a misunderstanding because I assumed you wanted it in Spanish and you assumed that I would develop it in English. So an assumption is what we assume to be true upfront.

An assumption is just that—anything that you believe to be true but that hasn't been proven to be true is an assumption. What's the difference between the charter and the scope? The project charter is all about authority. The scope is all about deliverables. So let's look at the components of the charter. First, we have the project purpose or justification and measurable project objectives. What you're going to receive as a result of this project: the high level requirements, the high level project description, the high level risk, the summary milestone schedule, the summary budget, the stakeholder list, the project approval requirements, who's the PM, and what's their authority level? And then who's the sponsor? What authority level do they have?

So the charter is really all about authority and kicking off the project. The project scope is all about deliverables—what's the project scope description? what's the acceptance criteria? what are the project deliverables? what's excluded?—and then constraints and assumptions throughout your project. If you haven't changed the scope, you have to update the scope statement. So when you update the scope statement, there'll be a trickle effect. Remember, from project integration management and integrated change control, that if I update the scope statement, then I have to update the product scope, and then that would cause the work breakdown structure, the WBS dictionary, and the project plan to be updated. As a result, the project scope statement was revised. You may have to update your stakeholder register and the requirements documentation, and if you're using an RTM, you would update that as well. Okay, a lot of information is in this lecture right now, but there is still some good stuff coming up in this chapter. So I'll see you in the next lecture, where we're going to talk all about the work breakdown structure. I'll see you in just a minute.

PMI CAPM practice test questions and answers, training course, study guide are uploaded in ETE Files format by real users. Study and Pass CAPM Certified Associate in Project Management (PMI-100) certification exam dumps & practice test questions and answers are to help students.