PMI RMP – PMBOK GUIDE – FAST REVIEW part 2

3. SCOPE MANAGEMENT

Hi and welcome to the second knowledge area the project scope management. As we are preparing for the Risk Management Professional exam, I’m not going into deep details of the project scope management processes. I just want to pass through the 6th scope management process processes and I’m going to highlight important topics in scope management. You might not be asked directly in the PMI Rmp exam about this lecture content but you might see terms like the Wbs, like the work package, like the product analysis in the exam questions. So it’s good to know. So what are the processes within the scope management knowledge area and what is project scope management? It includes the processes required to ensure that the project includes all the work required and only the work required to complete the project successfully.

This is our objective performing the scope management. We want to ensure that the project includes only the work required in order to produce the product or result or service of this project. Successfully managing the project scope is primarily concerned with defining and controlling what is in and is not included in the project. In scope and out of scope. Scope must be clearly defined and formally approved before the project starts. For predictive life cycle, scope must be clearly defined from day one for the whole project. But for Agile or adaptive life cycle it’s good to define the scope before each iteration. Now, what is the difference between the product scope and the project scope? The product scope, the features and functions that characterize a product result or service? It’s a description of the product itself.

An example building a 500 rooms, five stars OT this is the product scope. It is the features and functions of the final product. While the product scope the work performed to deliver a product, service or result with specified features and functions. What is the work you are going to perform in order to reach the final product scope? An example for the same project the work includes the design, the excavation, the foundations, the concrete finishing scope and furniture. This is the product scope describing the features and functions of the product and this is the project scope describing the work performed to deliver the product. So this is the difference between the product scope and the project scope. Now, what are the six processes of the project scope management? First of all, we have planned scope management as part of the Planning Processing group.

We have collect requirements as part of the Planning Processing group, define scope and create the Wbs. The four processes are within the Planning Processing group. We have the control scope and validate scope as part of the Monitoring and Controlling Process group. So overall we have six processes within the project scope management four in Planning Processing group and two in the Monitoring and Controlling. As shown in this diagram, the scope knowledge area falls into the Planning process group and the Monitoring and Controlling processing group we have no processes of the scope management within the initiating, executing or closing process groups. Here are the six processes as taken from the PM book plan scope management collect requirements, define scope, create WPS, validity, scope.

And control scope now what are the considerations of the scope management for the agile environment? If you are dealing with predictive life cycle or water pool or traditional life cycle the project deliverables are defined at the beginning of the project and any changes to the project are progressively managed. This is why we call the predictive life cycle or the traditional one change resistant as any changes to the project are progressively managed. So when you are dealing with a predictive life cycle, the project deliverables are defined from the beginning. The scope management processes, collect requirements, define scope, creates WPS, control scope, and validates scope are all performed toward the beginning of the project and updated as necessary.

Usually all these processes are performed once at the beginning of the project. Now, when dealing with adaptive life cycles or agile life cycles, the deliverables are developed over multiple iterations where a detailed scope is defined and approved before the start of each iteration. There is no need to define the scope of the whole project from day one. It’s enough to define the scope and have a dictate description of the scope. Before the start of each iteration. When dealing with agile lifecycles, adaptive life cycles are intended to respond to high level of change. The overall scope and adaptive project will be decomposed into a set of requirements and ought to be performed, referred as the product backlog. All the features, the requirements of each iteration are recorded in the product backlog.

The scope management processes, collect requirements, define scope, create wbs, control and validate. The scope are repeated and they are performed before the start of each iteration here they are performed once in the adaptive late before the start of each iteration now, what is the scope creep and what is the gold plating? Key activities in project scope management includes first of all you need to avoid the scope creek the scope creeve is the uncontrolled expansion to product or project scope without adjustments to time, cost and resources it’s uncontrolled expansion and you should avoid scope free while you are managing the project and you should prevent gold plating what’s the gold plating? It’s intentionally adding extra features or functions to the products which were not included in the scope statement.

You might perform gold Plating to please the client to get a good repetition or you think so that you will get so. This is the scope creep, it’s uncontrolled expansion while the Gold Plating is intentionally adding extras. Your activities also shall ensure consistent monitoring to make sure all project work is being completed. Scope Creep and Gold Plating two concepts of the scope management the scope creep is the uncontrolled expansion while gold plating adding extra features with any attention. Now the first process is the plan scope management process which is part of the planning process group. It’s the process of creating scope management plan that documents how the project and product scope will be defined, validated and controlled. Here we will think in advance.

We will document how we are going to define the project scope, how we are going to create the work breakdown structure, how we are going to control and validate the scope. We will think in advance about all these things in the plan scope management process. The key benefit of this process that it provides guidance and direction on how scope will be managed throughout the project. This process is performed once or at a predefined point throughout the project life usually is performed once and the scope management plan is a component of the project or program management plan that describes how the scope will be defined, developed, monitored, controlled and verified. Now we have four inputs.

First of all we need the project chapter as the project chapter includes the high level project and product description. You will need the project management plan with the project lifecycle description. How many fields do you have in your project? The quality management plan as the required equality standards and policies will affect the project scope. What is the development approach you are using? Are you following an agile life cycle or you are following a waterfall life cycle? You will need also few enterprise environmental factors and few organizational process assets. Now when it comes to the tools and techniques, first of all the expert judgment, you will need also data analysis techniques like the alternative analysis to perform alternative analysis between the alternatives you have on how you are going to create the WPS or how you are going to define the scope.

You will also perform some meetings to plan for the scope management and the outputs you will have of this process are the scope management plan and the requirements management plan. So the scope management plan is a component of the project management plan that describes how the scope will be defined, developed, monitored and validated. Why the requirements management plan is a component of the project management plan that describes how the project requirements will be analyzed, documented and managed. We have no separate knowledge area for dealing with requirements. All the requirements management efforts will be performed as part of the plan scope management process or the scope management knowledge area in general.

Now, the second process of the scope management will be the requirements collection. It’s also part of the planning process group. It’s the process of determining, documenting and managing stakeholder needs and requirements to meet the project objectives. So before we start defining the project scope, you need to collect the requirements from the sponsor, from the key stakeholders, from the senior management to be able to define the scope of the project. The key benefit of this process is that it provides the basis of defining the product scope and the project scope which we are going to do in the successor process. Define Scope this process is performed once or at the predefined points in the project and requirements should really solve problems or achieve project objectives outlined in the project charter.

Any requirements you are going to collect shall either solve a problem or achieve a project objective and the collect requirements efforts also include eliciting stakeholders expectations, beliefs or mental pictures about how the project will be turned out and it’s your responsibility to translate these expectations into documented requirements. So it’s not about only collecting the requirements, you need to know what are the expectations or beliefs or mental pictures of the stakeholders about the project in order to document these expectations as requirements for this process, we have seven inputs the project charter, which is an output of the developed project charter process. The project management plan with a subsidiary plan, scope management plan, requirements management plan and stakeholder management engagement plan.

You will need also some project documents like the assumption lock, the list lane register, the stakeholder register you will need the business case as part of the project business documents. Any agreement or contract will be a useful input to collect requirements process, few enterprise environmental factors and few organizational process assets. So before you start the requirements collection, you need these inputs. What are the tools you are going to use? The most commonly one is the expert judgment. You will need also a few data gathering techniques like the brainstorming to collect large number of ideas in a short period of time. This is the value of using the brainstorming questionnaires and surveys, arrival set questions to collect information.

Focus groups where you have a conversation with subject matter experts and key stakeholders to discuss one aspect of the project and you will perform some interviews. These are the data gathering techniques. For the data analysis techniques you will perform only the document analysis. You will bring any useful project document like the project charter in order to perform data analysis and get deeper information about this document. The decision making techniques like the voting in order to have a conclusion. The multiclasseria decision analysis when you are comparing between alternatives or decisions based on more than one criteria. Data representation techniques like the affinity diagrams where you are going to group the requirements into three or four or five categories depending on similarities between them.

Mind mapping to translate what’s in your mind into a map. It’s a data representation technique. Interpersonal and team skills like the nominal group techniques, the facilitation and the observation or conversation. The context diagram in order to show a system or a business system and how this business system will interact and how it will take inputs from the actors around and will give outputs to these actors. This will be useful to collect the project requirements. At the end you would have the proto type which is at the end you would have the proto types. They are very useful when I’m managing an ordeal project, let’s say with 300 or 400 rooms, it’s very useful to have one room early in the project and get the stakeholders to take all the requirements based on this sample.

This is what we call the prototype. What are the outputs of the collect requirements process? You will have the requirements documentation and the requirements traceability matrix. The requirements documentation describes how individual requirements meet the business needs for the project. Requirements need to be measurable, testable traceable, complete, consistent and acceptable by the project’s stakeholders.While the requirements traceability matrix it’s a grant that links product requirements from their origin to the deliverables that satisfy them. These are the outputs of the collect requirements process, the requirements documentation and the requirements traceability matrix and here is an example of the requirements traceability matrix.

Here is the requirement ID and here is the requirement type, the requirement description and the source of this requirement or who requested this requirement. It’s very useful for replacing and linking the origin of the requirement with the status along the project life. Now you are ready. You collected the project requirements from the key stakeholders. It’s the time to clearly define the project scope process. Number three define scope as part of the planning processing group. It’s the process of developing a detailed description of the project and product scope. The key benefit of the process is that it describes the product service or resolve boundaries and acceptance criteria how you are going to accept this product at the end of the project. Also this will be stated in the defines core process.

It selects the final project requirements from the requirements documentation then develops additive description of the project product result or service. Defines core process can be highly iterative depending on the project development lifecycle. If you are using a predictive lifecycle, you will perform defined scope process towards the beginning of the project and maybe once you are using an adaptive or an agile life cycle, you need to perform the defined scope process before the start each iteration. Now what are the inputs of the defined scope process? We have five simple inputs before we start the project charter the scope management plan from the project management plan as we stated in the scope management plan how we are going to define the project scope you will need new project documents like the assumption log.

The assumption log is a key output of that develop project charter process. You will need the requirements documentation and the risk register. The risk register as it contains all the risk response plan and few risk response plans might affect the project scope. This is why the risk register is an important input to the defined scope process. You will need also few enterprise environmental factors and few organizational process assets. Now, the tools and techniques I’m going to use while defining the project scope tools and techniques I’m going to use while defining the project scope. First of all, the expert judgment data analysis techniques like using the alternative analysis decision making techniques, the multi criteria decision analysis, interpersonal and team skills like the Facilitation and the product analysis, which is the most important tool of defining the project scope.

I’m going to explain in the next slide and the outputs and the major output actually for which we are performing the defined scope process is to have the project scope statement. Also, few project documents might be updated like the assumption log, the requirements, documentation requirements, traceability matrix and the stakeholder register. So what is the product analysis? It’s a tool performed to analyze the objectives and description of the product as stated by the customer or the sponsor. This information is then used to define tangible deliverable. Product Analysis for a project that have a product as a deliverable, it’s a tool to define scope. That generally means asking questions about a product and forming answers to describe the use characteristics and other relevant aspects of what is going to be built or manufactured.

Work of product analysis includes using techniques such as engineering, value analysis or value engineering. So the product analysis is about meeting the customer or the sponsor of the project and asking few questions about what does this customer request for the project to have what is the final product of the project as per the customer perspective and then translating these requirements of the customer into tangible deliverables and objectives of the project. This is exactly what we do in the product analysis. It includes techniques like the value analysis or value engineering. Value analysis or value engineering means finding alternatives to perform the work with less budget or less scores while keeping the same scope and having the same quality.

This is the value analysis or the value engineering. Now, what are the outputs? The major output of the defined scope process will be the project scope statement. So what’s the project scope statement? It’s a description of the project scope major deliverable assumptions and constraints. It documents the entire scope, including the project and product scope. Detailed scope statement includes first of all the product scope description, characteristics of the product, service or result described in the charter and requirements documentation. So we will have a detailed description of the product scope. We will have also a detailed description of the project scope. Deliverables any unique and verifiable product development capability to perform a service that is required to be produced to complete a process phase or a project deliverables.

Now, your project might contain five or six deliverables, not only the final product. When I say a deliverable, I don’t mean it’s the final product. Your project might have four, five, six deliverables until you reach the final product acceptance criteria a set of conditions that’s required to be met before the revobles are accepted project exclusions or out of scope includes what is excluded from the project assumptions and constraints. These are the six components of a detailed project scope statement and this is the reason why we perform the defined scope process to have a detailed project scope statement which will be a part of the scope baseline. The first process of the scope management will be the work breakdown, structure creation trade Wbs, which is part of the planning process group.

It’s the process of subdividing project developers and project work into smaller pieces, more manageable components. This is what we are going to do in the creator Wbs process. And the key benefit of the project is that it provides a framework of what has to be delivered through the project. This process is performed once or at three fine point in the project. It’s a hierarchical decomposition of the total project scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. It’s a hierarchical decomposition. Here you will put the final product or deliverable of the project and then you will start dividing and subdividing until the work package level. Here’s an example of the sample Wbs. The final product you will have is the value management system project.

The lower level would be the needs assessment, standards development, systems engineering and project management. You will go one more level down. You will have the current system audit, the requirements determination, alternative development, system requirements development and so until you reach the lowest level, which is called the work package. Now, what are the inputs of the KWBS process? First of all, the project management plan. The scope management plan has how we are going to create the WPS and what are the tools. We will follow our own stated in the scope management plan you will need few project documents like the project scope statement, which was the output of the predecessor process, the requirements documentation, which was an output of the collect requirements process.

You will need also few enterprise environmental factors and few organizational process assets, tools and techniques. You will need the expert judgment and the decomposition. It’s the most important tool in order to create the Wbs. And the decomposition tool is only used in the KWBS process and in the defined activities process in the schedule management, while we are performing the KWBS to have the approved version of the scope baseline. So the scope baseline, which is the first performance measurement baseline, is a key output of the creative UBS process. Few project documents might be updated like the assumption log and the requirements documentation.

Now, what is the decomposition? It’s a technique used for dividing and subdividing the project scope and deliverables into smaller, more manageable parts. This is what we mean by decomposing the project deliverables. We want to divide and subdivide the total scope of the project into smaller, more manageable parts. The work package, which is the lowest level of the Wbs for which cost and duration can be estimated and managed. The lowest level in the Wbs is called the word package and the word defined in this work package for which cost and duration can be estimated and managed more easily. The level of detail for work packages will vary with the size and complexity of the project.

You will have some work packages with 800 hours of work and you will have other work packages with 20 hours of work. It depends on the size of the project. The WPA structure may be created using different approaches. Some of the popular approaches will be using top down or bottom up, starting from the top and going down or starting from the bottom and going up. Now, what is the scope baseline? The scope baseline is the approved version of the scope statement, WPS and Wbs dictionary which can be changed only through formal change control procedures and it’s used as basis of comparison. It’s a component of the project management plan.

The scope baseline, cost baseline and schedule baseline are all part of the project management plan. It’s the approved version, the latest approved version which contains the scope statement, the Wbs and the Wbs dictionary. The project scope statement, which was an output of the defined scope process, includes the description of the project scope, major deliverables assumptions and constraints. The Wbs or the work program structure is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish project objectives and create the required deliverable. The Wbs dictionary is a document that provides detailed deliverable, activity and schedule information about each component in the WPS.

Most of information included in this dictionary is created by other process and added to this document in later stage. This is why you will have the Wbs dictionary updates as an output for a lot of the coming project management processes. Now you saw the sample of the Wbs. Each component has its own number and it’s mentioned only the name of the component or the name of the work package. Where I can find all the details of this component, you will find it in the Wbs dictionary. So these are the three components of the scope baseline. Now you define the project scope. You have the latest version of the scope baseline. You need to validate the scope of the project each way.

The scope validation is part of the monitoring and controlling processing group. It’s the process of formalizing acceptance of completed project deliverables. Key benefits of the process is that it brings objectively to the acceptance process and increases the probability of final product result or service acceptance by validating each deliverable from day one. If you are validating each deliverable with the customer or sponsor, this will increase the probability of final product acceptance. Verified deliverables obtained from the control quality process are reviewed within the customer or sponsor to ensure they are completed and have received formal acceptance of the deliverable by the customer or sponsor.

So the control quality process is an internal process. You perform it by your controlled quality department and the output of the controlled quality process will be validated deliverables or Verified Deliverables. Then you will take these Verified deliverables into the validate scope process and meet the customer or sponsor in order to review these Verified Deliverables and the output will be accepted deliverable. The validate scope process differs from the control quality process in that the former is primarily concerned with acceptance of the deliverables. This is the validity scope process. It’s concerned with acceptance of the deliverables.

Why? That control quality process is concerned with correctness of the delivery problems and meeting the quality requirements specified for the deliverables. The inputs you will need to validate the project scope will be the project management plan with the subsidiary plan scope management plan requirements, management plan scope baseline. You will need also a few project documents like the license range registered the quality reports from the quality management knowledge, area requirements, documentation and requirements traceability matrix. You will need the work performance data and the verified deliverable. Validated or Verified Deliverables are outputs from the control quality process.

It comes here as an input to the validate scope process and whenever you have the work performance data as an input, you will have the work performance information or reports as an output. So the inspection is the tool you are going to use to validate the project scope. Inspection includes examining, measuring, testing all these activities falls under the inspection tool you will use also voting as a decision making technique and the primary output you will have are the accepted Deliverables verified Deliverables as an input, accepted deliverables by the customer as an output you have the work performance information change request. If there is any deliverable which was not accepted, you might issue a change request.

You will need also project management or you will have sort of project management plan updates and project documents updates like the reasons they entered the requirements, documentation and requirements feasibility, maintenance the last process of the scope management will be the control scope process, which is part of the monitoring and controlling the process of monitoring the status of the project and product scope and managing changes to the scope baseline. Here we are going to monitor the status of the project and project scope and compare the actual performance of the scope to the scope baseline.

The key benefit of the process is that the scope baseline is maintained throughout the project and this process as the majority of the monitoring and controlling processes is performed throughout the project life. Controlling the project scope ensures all requested changes and recommended corrective actions and preventive actions are processed through the performed integrated change control process. The inputs of the control scope process are the project management plan you will need the scope management plan, requirements Management Plan change Management Plan Configuration Management plan, scope baseline and performance measurement baseline.

All these are components of the project management plan, the project documents you will need to control the project scope, decent length register requirements, documentation and requirements, traceability matrix, the work performance data, and the organizational process assets. All these are inputs to control and monitor the project’s scope tools and techniques you are going to use includes the data analysis technique, the variance analysis to compare the actual performance of the scope to the plan in the scope baseline, and the trend analysis to forecast the future of your project. The output of the control scope process includes world performance information. You might issue some change requests as well.

You will have few project management plan components updated like the scope management plan, the three project baseline, scope schedule and cost baseline and the performance measurement baseline. You will have few project documents updated like the lessons learned, registered requirements documentation and the requirements tastability matrix. This is all for the control scope process and this is all for the scope management knowledge area. As you are preparing for the PMI Rmp exam, you don’t need to have more information about the scope management. It’s important to know what is the Wbs for, what is the Wbs dictionary, what is the product analysis or the decomposition and what’s the difference between the value scope and control quality process? Thank you so much. Looking imports you at the next list.