PMP Training: Define Scope
PMP® Exam Prep: The Process of Define Scope
The PM PrepCast is your complete PMP certification training. With over 50 hours of in-depth lessons it is one of the best PMP classes online. Please enjoy this free lesson:
The first minute of this free lesson is a quick preface about PrepCast features and functionality. Feel free to fast forward.
Summary
"Project Scope. The work performed to deliver a product, service, or result with the specified features and functions."
This definition is taken from the Glossary of Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK® Guide) - Sixth Edition, Project Management Institute Inc., 2017.
Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. And Define Scope is the process of developing a detailed description of the project and product.
This lesson differentiates between the project scope vs product scope, reviews the role of the scope statement, and emphasizes that we not only need to define what is in scope but also clearly have to state what is out of scope.
Until Next Time,
Cornelius Fichtner, PMP, CSM
President, OSP International LLC
Transcript
[00:00] [Introduction]
Hello, and welcome to this free lesson from The Project Management PrepCast™. I am Cornelius Fichtner and I am your lead instructor. And at this point, you probably expect I am going to tell you how great the PrepCast is, right? Well, don’t take it form me. Instead, here are the voices and testimonials from a number of our students so that you hear what they had to say.
First up is Sondra Rosenbauer who loved it because you can study anywhere. Shahrukh Cummins not only used it anywhere but also anytime! In particular, during his breaks several times a day. Gina Vu passed her exam on the first try calls the PrepCast a great investment and recommends it.
I particularly like this one here from Devie Kusuma because he said that I have a very engaging teaching style. Thank you, Devie! Furrukh Rao is completely satisfied with the course material and Jill felt completely prepared and so she passed the exam on her first try. And finally, here is Shadrack Baraka who says that the PM PrepCast™ is the most well thought out course that he has ever interacted with and that he would recommend it to any aspiring project manager.
There are hundreds more testimonials like these from our students on www.pm-prepcast.com for you to read. But now, it’s time for your free lesson. So on with the show.
[01:35] Lesson Overview
Hello and welcome to The Project Management PrepCast™ where the scope of your preparation to passing the Project Management Professsional (PMP)® Exam should include The Project Management PrepCast™. I am your instructor, Cornelius Fichtner.
In this lesson, we take a look at the Define Scope process. This is the process of cultivating a detailed description of the project and the product. It is in this process where the project requirements are selected and refined to create a detailed project scope statement, which is the basis for all decisions made regarding the scope of the project.
And we learn how important it is to analyze and discuss what is to be included or excluded from the scope. In this lesson, we discuss what you use tools and techniques and how to go about defining scope. Let’s look at where we are.
[02:33] You are Here
Not surprisingly, we are in the Project Scope Management knowledge area where there is a set of processes under the planning process group and we are on the third of these planning processes, which is Define Scope where we develop a detailed description of the project and product.
[02:54] Follow Along on Pages: 150-155
If you would like to follow along then please join us on page 150 to 155 of the PMBOK® Guide. Feel free to read those pages before or after you go through the lesson to reinforce the concepts in your mind.
[03:13] Main Concept
The main concept in the Define Scope process is that we have to draw a line in the sand. We have to answer the question: Is a requirement in or out in terms of scope.
We describe the product, service or result in sufficient detail so boundaries are clear on how the project and product are to be executed and delivered to meet the needs and expectations of the stakeholders. We define acceptance criteria for those requirements and make it clear what is to be included and we develop a detailed project scope statement. We build upon other work that has already been done in scope planning and collect requirements.
[03:59] Why Define Scope?
You may ask why you as a project manager need to care about defining scope. By the end of the Define Scope process, you would have a much more detailed scope statement available. A detailed scope statement allows for more realistic estimates for cost, time and resources.
Down the line, it helps to define a detailed scope baseline. And last but not least, it is useful to understand scope in a detailed level for purposes of assigning work. Of course, this assignment will not be done in this process here but instead over in schedule management. However, without a clear scope and defined deliverables, it would be difficult to assign activities to your team members.
[04:51] Iterative Nature of Define Scope
The Define Scope process can be highly iterative. How so? In iterative life cycle projects, a high-level vision is developed early on for the overall project because not enough information may be known and determining the detail of the scope is done one iteration at a time.
Another example you may all have experienced where despite your efforts to balance out all the project constraints, you find that what you have put together does not meet stakeholder requirements. For example, stakeholders may say how that cost way too much or that’s unacceptable. I can’t wait that long. If so, you are not alone. If that happens, well you may have to make further adjustments. One option is for scope for renegotiated and asked: Is X or Y in the original scope or is it out? Alternatively, is there another scope option Z that might be better in order to balance scope against other project constraints.
[06:01] Inputs
Let’s take a closer look at each of the inputs used in the Define Scope process in detail.
[06:08] Define Scope
But first a quick overview because there are only a few inputs for the Define Scope process that we have a handful, why is that? Well this process is one of the very early processes that should be executed. So at this point, we typically would only have the basic outline of the project and a few project documents, which means that the inputs to this process are the Project charter, the Project management plan, some project documents, Enterprise environmental factors, as well as Organizational process assets.
And so without further ado, let’s try to understand how and why these inputs are used to define scope.
[06:51] Project Charter
If you want to more fully understand something, it is often helpful to get to its origin or to try to learn more of how it came about. A project charter would be a good place to understand the basis for the project and its scope.
The charter formally creates the project and provides a high-level project description. It also includes product characteristics and approval requirements. If these details are not in a formal charter document, it may be necessary to perform an informal analysis to capture the overall goals of the project constraints and assumptions and identify any other content necessary to develop the scope. Knowing more about its starting point and high-level information about the project and product puts you in a better position to plan and define the scope further.
[7:48] Project Management Plan
When we talk about the project management plan, we want to call its subsidiary plans. In our case here, namely the Scope Management Plan. The Scope Management Plan provides the framework to guide how to manage the project scope. It reflects the iterative nature of scope management.
First, the scope needs to be defined. Then it is developed, monitored and controlled and finally validated where if necessary, the scope is refined further and the scope management plan describes the process for updating and maintaining the scope baseline.
[8:25] Project Documents
You also have to look at other project documents namely, the Assumptions log, the Requirements documentation and Risk register. Let’s see how these documents are relevant to defining scope.
[8:39] Assumption Log: Examples
An Assumptions Log contains assumptions, which are factors that you accept to be real or true without proof and constraints that limit the project in some way. They are restrictions that affect the project or process execution. Let us think of some examples of assumptions that relate to scope here.
For example your project assumes that you are to modify an existing healthcare related website to cater to young teens instead of adults. In a construction project, one assumption might be that you are to build a mix of commercial versus residential units. You can assume a particular format for a deliverable. It is to be written as opposed to an oral presentation.
On the other hand, some examples of constraints that impact scope are that you if you modify an existing healthcare website, you may be constrained by original design decisions. In construction, you may have to conform to specific requirements of types of commercial establishments according to local zoning laws. And final deliverable needs to be within the minimum or maximum length. You can see quite plainly from these examples that assumptions and constraints affect the project and product scope.
[10:09] Requirements
Our next project document input is the Requirements documentation that you gathered and documented in the Collect Requirements process. Requirements documentation describes how individual requirements meet the business need for the projects.
All requirements must be clearly defined. We saw this list here in the Collect Requirements lesson when we talked about what it means unambiguous requirements. You as a project manager will find it challenging to define the project scope that answers the needs of your stakeholders and meets the business goals without clearly defined requirements.
[10:50] Risk Register
And our final project document is the Risk register, which contains response strategies that affects scope. Your project may be avoiding or mitigating risk by either reducing the scope, perhaps opting not to build a feature or devote less effort to low priority work or changing the scope altogether in an aim to make an impossible possible for the project.
[11:18] Commonly Used EEFs
Next we consider commonly used Enterprise environmental factors that we have to learn to work with. Let’s give just one example of each: Culture may affect your project scope. Going back to the website example, different culture may interpret different colors in different ways. Would you need to implement the country-specific color palette or style guide?
If you need to build or add to an existing infrastructure to complete your project then work on infrastructure adds to your scope and effort. Personnel administration may help to define the ‘how’ to go about doing something as it relates to personnel. But it can also limit what you can and cannot do as part of your project.
And lastly, marketplace conditions. In an existing market, you may need to have a product that is better than others. On the other hand if it’s all green fields then part of your scope may be to create a new market for your product to begin with.
[12:28] Commonly Used OPAs
We also have to consider the organizational process assets that can influence how scope is defined. Some examples are that we have the policies and procedures that are predefined for the project and the client company as a whole. They aid to align the project goals with the high-level business strategies.
We can use the templates and project files from prior projects. Most companies have a central document repository for previous projects that can be accessed. It is often useful to refer to historical information in these documents or reuse existing templates.
We also have the lessons learned files from previous projects. The knowledge gained during a past project may shed light on how to best define scope for the current project.
[13:20] Tools & Techniques
Now, let’s consider the tools and techniques.
[13:24] Define Scope
They are Expert judgment, Data analysis, Decision-making, Interpersonal and team skills, as well as Product analysis. As always, let’s take a look at each one in detail and how to use them to define scope.
[13:41] Expert Judgment
Here we list some of the experts that should be involved when defining the scope. They are first of all Subject matter experts, SMEs. They would be familiar with the current product and can help us identify future product features. Consultants and contractors may have participated in similar projects and their expertise can help improve scope definitions.
You talk to stakeholders including customers or sponsors to make sure you include in scope the things that ultimately will satisfy their expectations. Professional and technical associations are also part of the experts that we want to look at and you should consider reaching out to industry groups if you need a hand in finding experts or in understanding other tools and techniques in depth.
Other units within the organization perhaps have executed other similar projects. They also may be stakeholders such that what you include or exclude from scope may impact their work. These technical functional and managerial experts provide judgment and expertise that are required during the Define Scope process of a project.
[15:03] Data Analysis
Our next tool and technique is data analysis. Teams often use techniques such as Alternatives analysis to consider and evaluate different options, approaches and paths that the project could take in executing the project work to meet the requirements and goals of the project.
[15:25] Decision Making
Another technique that we have at our disposal when we define scope is decision making. A commonly used decision-making technique is the multi-criteria decision analysis technique. In this technique, you create a matrix or a grid to analyze different criteria to refine project and product scope.
For example, you can consider requirements around resource, cost, schedule or risk. Using such a decision matrix helps guide you to ensure that you have thoroughly evaluated the scope against all the major criteria.
[16:01] Interpersonal & Team Skills
Just as it has been invaluable in other processes having excellent interpersonal and team skills is instrumental in defining scope and we highlight facilitation right now. The scope may not be an easy thing to pin down. So as project manager, you may need to hurt them a little bit like cattle. It can be a gargantuan task for your key stakeholders who may have various backgrounds and potentially different motivations to work together and reach an agreement on the scope.
You need to be efficient but thorough while ensuring that they completely understand the requirements and deliverables, as well as overall project objectives so they can delineate the project and product scope.
You need to foster good communications and build trust among stakeholders and use facilitation to help stakeholders resolve their differences in opinion about scope items. Scope by its very nature is a constraint on a project so stakeholders may be reluctant to give up on their expectations around the project or product so you use facilitation as well as other interpersonal and team skills to resolve issues around scope definition.
[17:22] Product Analysis
Product analysis is another important technique used in defining scope. For those projects that have a product as a deliverable versus a service or result, product analysis can be quite the effective tool for improving the project teams understanding of the product and helping to capture that understanding in the form of requirements and translate the descriptions into deliverables.
Let us look at more specific methods for analyzing the product. First, we have Product breakdown which involves identifying all the components and subcomponents that need to be delivered by the project.
Next is Requirements analysis or requirements engineering which is where you try to understand user requirements. Usually these would be new features or functions or modifications to existing features. Requirements analysis involves eliciting, analyzing, validating, taking account of any conflicting requirements, organizing and prioritizing and of course documenting your requirements.
System analysis is where you study a process, procedure or business so that you can create an effective system or procedures to carry them out. Defining that efficient system or set of procedures is essentially what the next item on the list is all about and that is System engineering. This is a structured development process to enable the design creation and management of potentially complex systems. It would consider aspects such as operations, performance, testing, manufacturing, training and the overall life cycle of the system including its disposal.
Value analysis and Value engineering are related and go hand in hand. You examine and identify alternatives for design material, processes and systems to try to provide necessary functions at the lowest cost. For example, you may choose to substitute materials perhaps use a strong plastic instead of metallic part that meets specifications but are not as costly. These alternatives should not affect required quality, effectiveness and customer satisfaction. This list is obviously not comprehensive. Different industries may employ methods or may have templates or systems that enable to more easily and effectively conduct this type of analysis to help define scope.
Let’s talk through the first Product analysis technique on the previous slide, the product breakdown where you create a product breakdown structure. This technique is similar but should not be confused with the work breakdown structure, the WBS. So let me well break it down for you.
A product breakdown structure contains a breakdown of the product in various components. So for example, Components 1, 2 and 3. You decompose down to the product elements, which could be product concepts, functional or physical features to better understand and define the scope. In this way, you can try to make sure that you have sufficiently defined the scope for each component.
A work breakdown structure on the other hand contains the corresponding work required to complete each of those product components. The work required to complete these components includes project management so you would not include project management as part of your product breakdown structure but it should definitely be part of your work breakdown structure.
[21:16] Work Breakdown Structure
So let’s go to our specific example in an airplane. The WBS and the product breakdown structure, they are very related. In a product breakdown, you would consider its different parts like the fuselage or the empennage, which in turn you could then decompose into lower level components.
But in a WBS, you would also include a work package for management because remember, the WBS is a hierarchical description of the all the project work with various work packages that include all effort in order to create the deliverables you specified in the product breakdown structure.
[21:59] Outputs
And now that we have applied all these tools and techniques, the outputs arise.
[22:06] Outputs
There are only two. But these two outputs are essential in defining the scope for the project in detail and documenting changes and updates that were made in the process of scope definition. The outputs are the Project scope statement and Project document updates. Let’s look at them in detail.
[22:29] Project Scope Statement
The most obvious output from the Define Scope process is the Project scope statement. The Project scope statement is a document that describes many details about the project and product scope. The Project scope statement builds upon the major deliverables, assumptions and constraints that are developed and documented during project initiation.
During the planning of the project, you define and describe the scope being more detailed and specific as more information about the project is established. It assists in managing stakeholder expectations around scope. It exposes existing and additional risk assumptions and constraints, which are analyzed for completeness and validity and added or updated as needed.
And last but not least, the level of detail of the scope is a factor in how well the team can subsequently control scope. It will be difficult to properly control something that you did not define. Developing and documenting a detailed project scope is critical to the success of the project and beneficial to the project going forward.
[23:48] Project Scope Statement
Typically included in the project scope statement are first of all, a deliverable, which is the unique and quantifiable product, result or service that is produced upon the completion of a process, phase or project which may be described at a summary level or in detail. When you think of a deliverable, it could be an object, or a function or aspect of the overall project.
It also includes a product scope description through progressive elaboration; the characteristics of the product, service or result are described. You also find acceptance criteria, which are those conditions that must be met in order for deliverables to be accepted. And don’t forget project exclusions, which identify and explicitly state what is out of the scope of the project and exclude it from the project. It helps to manage the expectations of the stakeholders.
[24:46] Project Charter vs. Scope Statement
The Project Charter and the Project Scope Statement are often believed to be redundant to a degree in their context. However, they are different in the level of detail that is contained in each.
So let’s begin on the left with the Project Charter, which contains a more high level and summary-type contents. Well since it is created at the beginning during project initiation and requirements are still being developed. You really don’t know that much. You have to stay high level.
So some of the key elements of the project charter are the project purpose, measure of project objectives and success and exit criteria; high level requirements and high level project description, boundaries and key deliverables. But as you know from the Develop project charter lesson, there is more in the project charter. So let me just continue here because we also have the overall risk and think about how that affects scope and development of scope, summary milestone schedules, summary budget; we have stakeholder list. We have approval requirements. All of these affect how scope is defined.
And last but not least, you yourself, the project manager, you may have personal style how you like to define scope that also is an influence on this. Don’t forget the charter also list the sponsor who is championing and authorizing the project. All of this affects how scope is defined.
Okay now we have to somehow compare this to the scope statement. I want to put this on the right side. So let me erase the right side again here and just replace this with ‘et cetera’ on the left-hand side and then move on to the scope statement because as you are developing the scope statement, you are not trying to reinvent the project charter. Instead the project scope statement simply contains a more detailed description of the scope and the scope elements that are progressively elaborated throughout the project.
And some of these key elements from the scope statement are a progressively elaborated project scope description, project deliverables, acceptance criteria and exclusions. So you can see they are not exactly matching. Some of these items do match but remember neither of this lists encompasses all of the contents of the project charter and the project scope statement but they provide sort of a good representation of what elements most likely contains. Somewhat similar but different level of detail.
[27:32] Project Document Updates
Our second and final output to the Define Scope process is Project Document Updates. Think about these four particular documents here. First the Assumptions log. It should reflect any new assumptions and constraints that you uncover through this process. Existing entries should capture any clarifications that we have gained.
The Requirements Documentation describes how individual requirements meet the needs of the project. Requirements typically start out at a high level but progressively become more and more detailed as more is discovered about the requirements.
The Traceability Matrix links product requirements from their origin to the deliverables that satisfy them and it provides a way of tracking those requirements throughout the project life cycle. As requirements change, the matrix also requires updating.
And lastly, the Stakeholder register would need to be updated with new information on new or existing stakeholders.
In summary, the iterative nature of the Define Scope process and the progressive emergence of the project scope means that project documents will require updates to reflect any new information that arises as you redefine or refine project scope.
[29:00] Review Question
Let’s review with this question here: The Define Scope process selects the final project requirements from what? Here are our potential answers: Is it (a) the scope management plan? (b) The requirements documentation, which we created during the Collect Requirements process? Is it (c) the project scope statement? Or is it maybe (d) the acceptance criteria?
As always, I am going to give you about 10 seconds. Please press ‘pause’ if you need more time.
Are you ready? The correct answer is B. The requirements documentation created during the Collect Requirements process and this question and answer hints at the fact that not all the requirements that we identify in Collect Requirements may actually end up to be included in the project. The requirements documentation delivered during the Collect Requirements process is from where the Define Scope process then takes these requirements and develops a detailed description of the project and product or service or result but not all of them.
[30:29] Takeaways
Let’s see the nuggets of wisdom on the Define Scope process that we can take away with us today. Firstly, Define Scope is the process of developing a detailed project and product description. The importance of this process is directly related to how important the requirements are. The scope of the project is what ultimately drives the execution of the project. It is essential in management stakeholder expectations because it includes items that are excluded from the scope.
The iterative nature of the Define Scope process means that this process will be revisited many times throughout the project life cycle to continue to develop a detailed scope. And the project scope statement documents the entire scope and it encompasses both the project and product scope.
And this concludes our look at the Define Scope process.
Until next time.
[Music]
[End of presentation]