Chapter 3 Project Scope Management PDF

Chapter 3 Project Scope Management What’s Coming Ahead… Managing Scope: Big Picture Collecting Requirements for the Project Defining the Project Scope Creating a Work Breakdown Structure (WBS) Before and After the WBS Controlling Scope Verifying the Scope of Project Deliverables Introduction As disc...

Chapter 3 Project Scope Management What’s Coming Ahead… Managing Scope: Big Picture Collecting Requirements for the Project Defining the Project Scope Creating a Work Breakdown Structure (WBS) Before and After the WBS Controlling Scope Verifying the Scope of Project Deliverables Introduction As discussed in the previous chapter, after the project has been initiated by issuing the project charter, you need to develop a project management plan, which becomes the primary source of information for how the project at hand will be executed, monitored and controlled, and closed. One significant component of developing the project management plan is the scope planning: If it’s not in the scope, it will not be done and should not be done. Before you start defining the scope, however, you need to know what the project and product requirements are. In other words, you need to collect requirements based on the needs and expectations of the stakeholders. Once you have defined the scope based on the requirements and the project charter, it needs to be broken down into concrete, manageable tasks that can be assigned and performed. This is accomplished through what is called the work breakdown structure (WBS). Planning and controlling the project scope is crucial to the success of the project. Without it, the project can easily go off the track. The primary purpose of project scope management is to ensure that the required work (and only the required work) is performed to complete the project successfully. If changes in the work requirements are made, they must be controlled—that is, the scope must be controlled. Also, before the outcome of the project is offered for acceptance, its scope must be verified with the customer or the sponsor, for example, to ensure the product has all the features that are promised in the scope statement. In a nutshell, the central issue in this chapter is managing the project scope. To be able to wrap your mind around this issue, you will explore three avenues: collecting requirements, defining the project scope and solidifying it into the WBS, and verifying and controlling scope. Managing Scope: Big Picture The project scope is defined as the work that must be performed to deliver the required products, services, or results with the specified functions and features. The scope of a project consists of the project scope and the product scope. The product scope is the set of functions and features that characterize a product, service, or result to be delivered by the project. It is about both what is included in the project and what is not. In other words, scoping a project means drawing boundaries around it. The importance of managing the project scope cannot be overemphasized, because it has a profound impact on the overall success of the project. Managing Scope: Big Picture CAUTION Project scope is not the same thing as the product scope. Project scope is the work required to deliver the product scope. STUDY CHECKPOINT 3.1 Among the following attributes, identify which ones are part of product scope and which ones are part of the project scope. A. B. C. D. E. Develop software modules to support a website. The user can only access this website after logging in. The drug should not have more than two side effects. The drug must be developed within one year. The drug must be tested in-house before it goes to the Food and Drug Administration. To start with, you must have a plan for how to manage the project scope, including defining the scope. Developing the Project Scope Management Plan Before starting to perform the five scope management processes, you develop the scope management plan. This work is recommended to be part of the effort of developing the project management plan. This plan will work as a guide for handling the following questions: ◆ How can you define the scope? To answer this question, the scope management plan includes the following: ◆ A process to prepare a detailed project scope statement based on the project charter and requirements. ◆ A process that will enable the creation of the work breakdown structure (WBS) from the detailed project scope statement and will establish how the WBS will be maintained and approved. ◆ How can you verify the scope? The scope management plan answers this question by including a process that describes how the formal verification and acceptance of the completed project deliverables will be obtained. ◆ How can you control the scope? The scope management plan answers this question by including a process that specifies how the requests for changes to the detailed project scope statement (which we also refer to as the scope statement) will be processed. 99 100 Chapter 3 PROJECT SCOPE MANAGEMENT Whether the project scope management plan is informal and high-level (without too much detail) or formal and detailed depends upon the size, complexity, and needs of the project. The project scope management plan, an example of a subsidiary plan, becomes part of the project management plan. CAUTION If you are familiar with the PMBOK Guide Third Edition, note that there was a process called scope planning to develop the scope management plan. There is no such formal process in the PMBOK Guide Fourth Edition. You develop the scope management plan as part of the effort of developing the project management plan. Project scope management is performed through scope management processes. Project Scope Management Processes The major goal of scope management is to ensure that the required work and only the required work is included and performed in the project. As shown in Figure 3.1, this goal is accomplished by the following processes of project management: ◆ Collect Requirements. Define the project and product requirements and develop a plan to manage those requirements. This will help clarify what needs to be done. ◆ Define Scope. Develop a detailed description of the project and the product that will determine what needs to be done. ◆ Create Work Breakdown Structure (WBS). Break down the scope into concrete, manageable components called work packages. The idea here is to decompose the project deliverables into manageable components that can later be organized into tasks that will eventually be assigned to team members. ◆ Verify Scope. Formalize the acceptance of the completed project deliverables—that is, determine how to verify with the customer that the project scope has been executed as planned. ◆ Control Scope. Determine how to monitor the status of the project and product scope and monitor and control changes to the scope. Managing Scope: Big Picture 101 FIGURE 3.1 A high-level view of interactions and data flow between different components of scope management. These functions are executed by performing the corresponding processes listed in Table 3.1. So the project scope planning specifies how to define, verify, and control the project. Before you can actually define the scope, you need to have a very crucial item in place: stakeholder requirements. 102 Chapter 3 PROJECT SCOPE MANAGEMENT Table 3.1 Processes of Scope Management Mapped to the Process Groups Scope Management Process Process Group Major Output Collect Requirements Planning Requirements management plan and other requirements documents Define Scope Planning Project scope statement Create WBS Planning WBS and scope baseline Verify Scope Monitoring and controlling Acceptance of deliverables and change requests Control Scope Monitoring and controlling Work performance measurements Collecting Requirements for the Project The project success is defined as the delivery of the planned outcome with full scope, on time, and within the schedule. To realize this success, it’s very important that there is an agreement on exactly what is being delivered with what requirements. A requirement is a condition, characteristics, or a capability that a specific outcome of the project must have. For example, an online banking website is an outcome of the project, and the condition that it must record the number of users who visited the site each day is a requirement. Requirements may come from different sources, such as from standards, specifications, and contracts. Stakeholder expectations and needs often materialize into requirements as well. NOTE Generally speaking, project requirements should include the product requirements. However, many organizations distinguish between project requirements and product requirements, in which case project requirements include strictly project-related requirements, such as schedule and delivery requirements, business-related requirements, and other project management requirements, whereas product requirements include product-related requirements, such as requirements related to performance, security, and defects. You need to do some requirements planning, which includes: ◆ Defining and documenting the project requirements ◆ Defining and documenting the product requirements ◆ Developing a plan to manage the requirements—the requirements management plan Collecting Requirements for the Project 103 You do all this in order to determine stakeholder expectations and needs and to fulfill them. TIP How effective you are in capturing requirements will determine how effective you will be in getting agreement on these requirements from the stakeholders and in managing the stakeholder expectations and needs. Also, these requirements go right into the foundations of the WBS along with the deliverables. Therefore, collecting requirements effectively is critical for the success of the project. You collect requirements by using the Collect Requirements process illustrated in Figure 3.2, in terms of input, tools and techniques, and output. During project initiation, you created the project charter discussed in Chapter 2 and the stakeholder register discussed in Chapter 7. These two documents are the input to the Collect Requirements process. Recall that the project charter contains the high-level product description and requirements. You get the information about the stakeholders from the stakeholder register to identify those stakeholders who can provide the information about requirements. Also, the stakeholder register contains information about the influence level of each stakeholder. That information will help in prioritizing the requirements. FIGURE 3.2 The Collect Requirements process: input, tools and techniques, and output. With these input items at your disposal, you use some tools and techniques to collect the requirements. Tools and Techniques for Collecting Requirements You collect the needed information about the requirements by using various techniques, such as observations, interviews, questionnaires and surveys, focus groups, facilitated workshops, group creativity and decision-making techniques, and prototypes. These tools and techniques are discussed in the following list. 104 Chapter 3 PROJECT SCOPE MANAGEMENT Observations. Observations are a technique in which the requirements about a product or process are gathered by directly observing the user using the product or performing the process. In other words, the process or product is observed in action in the real world with the people on the job. For that reason, this technique is also called job shadowing. Depending on the situation, the observer can simply observe the user doing the job or can participate in it. Interviews, questionnaires, and surveys. An interview is typically performed by asking predetermined and on-the-spot questions and recording the responses. Depending on the situation, interviews may take several forms, such as one on one, multiple interviewees, or multiple interviewers. For example, interviewing subject matter experts and individuals who ran similar projects before, you may identify and define some features and functions of the project deliverables. When you want to cover a large number of respondents quickly, questionnaires and surveys will be more appropriate. These are based on a written set of questions. Focus groups and facilitated workshops. A focus group is a set of prequalified stakeholders and subject matter experts that are brought together with the purpose of learning about their opinions, expectations, and attitudes about a product, service, or result that will be the output of the project. Generally speaking, a moderator facilitates the interactive discussion to make this experience more conversational than one-on-one interviews. A facilitated workshop is a session that brings together the cross-functional stakeholders to focus on defining product requirements. It generally proves to be an effective technique for quickly defining cross-functional requirements and reconciling differences among the stakeholders regarding the requirements. These workshops also help with developing trust and improving communication among the stakeholders and therefore fostering relationships that could help the project to succeed. Here are some examples of the facilitated workshops: ◆ JAD. In the software development industry, a commonly used type of facilitated workshop is called joint application development or joint application design, abbreviated as JAD. These workshops focus on improving the software development process by bringing together software users and developers. ◆ QFD. In the manufacturing industry, an example of a facilitated workshop is quality function deployment (QFD), a technique designed to help determine the critical characteristics of a new product that is to be developed. ◆ VOC. The QFD begins with collecting and understanding customer needs, known as the voice of the customer (VOC). Group creativity techniques. These are the group activities organized to identify project (including product) requirements. Here are some examples of such activities: ◆ Affinity diagram. This is the technique in which a large number of ideas are classified into different groups by using some criteria. This facilitates an effective and efficient review and analysis. Collecting Requirements for the Project 105 ◆ Brainstorming. This is a creative technique generally used in a group environment to gather ideas as candidates for a solution to a problem or an issue without any immediate evaluation of these ideas. The evaluation and analysis of these ideas happens later. Obviously, this technique can also be used to collect requirements. Here are examples of two specific kinds of brainstorming: ◆ Idea/mind mapping. This is an individual brainstorming technique in which a multitude of ideas is mapped around a central or key concept in order to expose commonalities and differences among ideas and generate new consolidated ideas. Mapping also helps with classifying ideas into groups by discovering relationships among them. In addition to project management, this technique is also used in other areas, such as personal, family, and education. It helps in summarizing, clarifying, and revising ideas. ◆ Nominal group technique. This is the brainstorming technique with voting. The voting process is used to rank the ideas generated by brainstorming for further brainstorming or for prioritization. ◆ Delphi technique. This refers to an information-gathering technique used for experts to reach a consensus while sharing their ideas and preferences anonymously. For example, a facilitator uses a questionnaire to solicit ideas on an issue to which experts on the subject matter respond anonymously. The facilitator summarizes and recirculates all the responses back to the experts. Consensus may be reached in a few rounds of this procedure without any bias added to it by a specific influential individual. Group decision-making techniques. Group decision-making is, in general, a process used to collectively assess and evaluate multiple alternatives in terms of expected outcomes. The decisions usually result in taking specific actions. This general technique can also be used to identify/ generate, classify, and prioritize project requirements, including the product requirements. To reach a group decision, multiple methods are available, including the following: ◆ Dictatorship. One person has the authority to make the decision. Although this expedites the decision-making, it may not be the most effective decision-making method. ◆ Unanimity. This is opposite to dictatorship: A decision is made only if everyone agrees. ◆ Majority. A decision must be supported by more than 50% of the members of the group. ◆ Plurality. The alternative supported by the largest number of members wins, even if this number does not make a majority. This situation arises when there are more than two alternatives. Plurality with two alternatives is simply a majority method. 106 Chapter 3 PROJECT SCOPE MANAGEMENT Prototypes. A prototype is a working model of a product put together without developing the actual product. Organizations usually make prototypes for developing proof of concept. Prototypes can also be used to collect requirements by experimenting with the prototype and by letting stakeholders experiment with it and offer feedback. It’s more tangible than the abstract idea of a product. Prototypes can be improved and modified based on feedback from the stakeholders. In this way, prototypes support the progressive elaboration process of developing requirements. You use one or more of these techniques to generate the output of the Collect Requirements process. Output of Collecting Requirements During this process of collecting the requirements, you will produce two important documents: the stakeholder requirements document and the requirements management plan. These and other output items of this process are discussed in the following paragraphs. Requirements documentation. Also called the stakeholder requirements document, this document consists of a list of requirements and any necessary detail for each item in the list. The details of the requirements and the format of the document depend on the project and the rules within the performing organization. Following are some essential elements of the requirements document: ◆ Sources of requirements. It describes the overall project outcome to which the requirements apply and the purpose of the project, such as the opportunity being seized or the business problem being solved. ◆ Types of requirements. For effective management, you can organize the requirements into different categories using some criteria. For example, all requirements can be broadly organized into two categories: functional requirements referring to the functionality of the project outcome and non-functional requirements, such as compliance, compatibility, and support. Furthermore, these broad categories can be subdivided into more specific types, such as the following: ◆ Quality requirements, such as not more than three bugs per software module. ◆ Support and training requirements, such as that the product will be released with a manual. ◆ Requirements that are based on assumptions and requirements that lead to constraints—for example, Phase 1 of the project must be completed before a specific date, or the project must be completed with a given set of resources. Resources, imposed dates, and schedule milestones are examples of common project constraints that give rise to requirements. ◆ Impacts of the requirements. This element describes the impact of requirements on the project and on entities external to the project, such as different groups in the organization. Collecting Requirements for the Project 107 CAUTION The requirements must be well defined and not vague. As a test, always ask this question: How will I be able to measure or test it? Also, make sure that a requirement is consistent within itself and with other requirements. The requirements that you collected will need to be managed. Requirements management plan. This plan documents how the requirements will be managed throughout the project life, which includes how they will be documented and analyzed. The requirements management plan includes the following elements: ◆ Prioritization. The process and criteria to prioritize the requirements. ◆ Configuration management. How the changes to the requirements will be processed: initiated, analyzed, tracked, and reported. ◆ Reporting. How, by whom, and to whom the activities related to the requirements will be reported. ◆ Traceability. What the traceability structure of the requirements will be. For example, which attributes of a requirement will be captured on the traceability matrix? Requirements are usually traced and tracked by using a tool called the requirements traceability matrix. Requirements traceability matrix. As its name suggests, the requirements traceability matrix is a table that traces each requirement back to its origin, such as a product or business objective, and tracks its progress throughout the project life. Linking a requirement to the business objective underlines its value. Tracking the requirement throughout the lifecycle of the project ensures that it will be delivered before the project is completed. So, this table becomes a very useful tool to remind the team how important these requirements are, when are they are going to be implemented, and how they are progressing in implementing them. The requirements traceability matrix includes the following links: ◆ Requirements linked to the origin of the project, such as the opportunity or business need ◆ Requirements linked to the project objectives and deliverables ◆ ◆ ◆ ◆ Requirements linked to the project scope and the product scope Requirements linked to the product design, development, and testing High-level requirements linked to their details The attributes linked to a requirement The key information about a requirement can be stored in the form of its attributes. Here are some examples of attributes of a requirement: a unique identifier, a description, an owner, a source, a priority, a status, and a completion date. 108 Chapter 3 PROJECT SCOPE MANAGEMENT With the definition of the project determined during project initiation and the requirements collected during planning, and with the project scope management plan in your hands, you are all set to begin defining the project scope. Defining the Project Scope The project charter developed during initiation and the stakeholder requirements document, also called the requirements documentation, contain enough information about the project and the product to start defining the project scope. Now that the project is in the planning stage, you have more information than you had in the initiation stage. Therefore, you are in a better position to analyze the needs and expectations related to the project and convert them into requirements. Furthermore, the assumptions and constraints can be revisited and analyzed at greater length, and additional assumptions and constraints can be identified. This will help to define the project scope with more clarity and specificity. NOTE When we say scope or project scope, it generally includes both the scope of the project and the scope of the product that the project will deliver, unless stated otherwise. The scope is defined by using the Define Scope process illustrated in Figure 3.3. FIGURE 3.3 The Define Scope process: input, tools and techniques, and output. Input to Scope Definition The project charter developed during project initiation presents a high-level project and product description. It also contains other information relevant to defining the scope, such as the project approval requirements. Project and product requirements listed in the requirements documentation described earlier in this chapter also contain critical information needed in defining the scope. Defining the Project Scope 109 Here are some examples of the organizational process assets that can be helpful in defining the scope: ◆ Template for the project scope statement ◆ Scope-related project files from previous projects ◆ Lessons learned from previous projects or from the previous phases of this project ◆ Policies and procedures relevant to defining the project scope TIP It’s critical to the success of the project that you determine the scope correctly: only the required features and functions for the product and only the required work to produce those features and functions; nothing less, nothing more. Once you have input for the scope definition, you apply the tools and techniques discussed next to define (or redefine) the project scope. Tools and Techniques for Scope Definition This section discusses tools and techniques used in the scope definition process. ◆ Identification of alternatives. This is a technique used to apply nonstandard approaches to perform project work—in this case, to define the project scope. A host of general management techniques can be used in this category; the most common ones are brainstorming and lateral thinking. Brainstorming, discussed earlier in this chapter, is a creative technique generally used in a group environment to gather ideas as candidates for a solution to a problem or an issue. The evaluation and analysis of these ideas happens later. Lateral thinking is synonymous with thinking outside the box. The idea is to think beyond the realm of your experience to search for new solutions and methods, not just better uses of the current ones. ◆ Product analysis. To hammer out the details of the project scope, you might need to perform product analysis, which might include techniques such as product breakdown, requirements analysis, system analysis, system engineering, value analysis, and value engineering. The goal is to translate the project objectives into tangible deliverables and requirements. Each application area has different product analysis methods to accomplish this. ◆ Facilitated workshops. Facilitated workshops, described earlier in this chapter, can also be used in defining the scope. ◆ Expert judgment. You can use help from relevant experts in the organization to develop parts of the detailed project scope. 110 Chapter 3 PROJECT SCOPE MANAGEMENT You apply one or more of these tools or techniques to the input to hammer out the output of the scope definition process. Output of Scope Definition Depending on the input, you may need to make some approved changes or updates to some project documents before you can produce the scope statement. Recall that the project scope statement is a component of the baseline used to manage the change requests to the project. The output of the Define Scope process is described in the following sections. Changes and Updates In the process of defining the project scope, you may end up modifying the existing requirements or adding new requirements. You may also learn more about the stakeholders. Accordingly, the documents that may be updated as a result of defining the scope include: ◆ Requirements documentation ◆ Requirements traceability matrix ◆ Stakeholder register Project Scope Statement The key output item of the Define Project process is the project scope statement, which is also sometimes called the detailed project scope statement or just the scope statement. The scope statement basically states what needs to be accomplished by the project: a product and work to generate the product. It provides a documented basis for the following: ◆ Developing a common understanding among the stakeholders about the project scope ◆ Making project decisions throughout the lifecycle of the project ◆ Measuring performance deviations from the scope The specific elements of the project scope statement are discussed in the following list. Project assumptions and constraints. Assumptions and constraints are initially included in the project charter. However, at this stage, you have more information about the project, and therefore you can revisit the initial assumptions and constraints, and you might be able to identify more assumptions and constraints. You should document the specific assumptions related to the project scope and also analyze their impact in case they turn out to be false. Due to the uncertainty built into them, the assumptions are potential sources of risk. The constraints related to the project scope must also be documented in the scope statement. Because the constraints limit the team’s options, the constraints’ impact on the project must be evaluated. The constraints can come from various sources, such as a predetermined deadline (also called a hard deadline) for the completion of the project or a milestone, limits on the funds available for the project, and contractual provisions. However, the following are common constraints to consider across all projects: Defining the Project Scope 111 ◆ Quality ◆ Resources that result in cost ◆ Scope ◆ Time (or schedule) I will discuss the details about these constraints in Chapter 5. Project deliverables. A deliverable is a unique and verifiable product, a capability to provide a service, or a result that must be produced to complete a project, a process, or a phase of the project. The deliverables can also include project management reports and documents. The scope statement provides the list of deliverables and their description. Project exclusions. This involves drawing boundaries around the project by specifying what is included and what is not, especially focusing on the gray areas where the stakeholders can make their own assumptions, different from each other. It generally identifies what is excluded from the project, which helps to manage stakeholder expectations. Product description. The scope statement must describe the product scope and the product acceptance criteria: ◆ Product scope description. Product scope is defined as features and functions that characterize a product, service, or result to be delivered by the project. The requirements documentation produced during the Collect Requirements process will help define product scope. ◆ Product acceptance criteria. This defines the process and criteria for accepting the completed products that the project will deliver. TIP You must be able to make a distinction between objectives, deliverables, and requirements. For example, in a project to launch a website, the website is a deliverable. That the website must print a warning message at the login time is a requirement, and that the website should increase the company revenue by three percent is an objective. The project scope statement serves the following purposes: ◆ It serves as a component to the baseline that will be used to evaluate whether the request for a change or additional work falls within or beyond the scope of the project. ◆ By providing a common understanding of the project scope, the scope statement helps bring the stakeholders onto the same page in their expectations. 112 Chapter 3 PROJECT SCOPE MANAGEMENT ◆ Because the scope statement describes the deliverables and the work required to create those deliverables, it is used to create a WBS, which helps in scheduling the project. ◆ It serves as a guide for the project team to do more detailed planning, if necessary, and to perform work during project execution. STUDY CHECKPOINT 3.2 In the following table, match each item in the first column with an appropriate item in the second column: A. The software product must run on both the Microsoft Windows and Apple Macintosh platforms. B. An online education website C. The drug must be developed within six months. D. The software module must not have more than 10 bugs. E. The project manager must have a PMP certification. 1. Project deliverable 2. Project constraint 3. Product requirement 4. Project management requirement 5. Product acceptance criteria In a nutshell, the project scope statement specifies the scope of the project in terms of the products, services, or results with specified features to be delivered by the project. From the perspective of actually performing the work, the scope statement is still a high-level document. To be able to schedule the project, identify and assign resources, and manage the project successfully, these deliverables need to be broken down into manageable tasks. This is largely accomplished by creating an entity called the work breakdown structure (WBS). Creating a Work Breakdown Structure (WBS) What is the secret behind accomplishing seemingly impossible tasks in any area? The answer is to break down the required work into smaller, manageable pieces. This is also a very important process in project management. To be able to actually execute the project, the project scope is broken down into manageable tasks by creating a work breakdown structure (WBS). In other words, a WBS is a deliverable-oriented hierarchy of the work that must be performed to accomplish the objectives of and create the deliverables for the project. Creating a Work Breakdown Structure (WBS) 113 CAUTION In context of the WBS, the term work or task actually refers to the result of an effort and not the effort itself. This planned work is contained in the lowest-level components of the WBS hierarchy, called work packages. The actual work is performed in the form of activities, which are scheduled. Figure 3.4 shows the input, tools and techniques, and output of creating the WBS. The project scope statement contains the list of deliverables and the product description. The requirements documentation describes the product and project requirements. Information in these two items provides the basis for creating the WBS. You should always consider organizational process assets while going through this and several other processes. In this case, the organizational policies and procedures related to creating the WBS and relevant project files and lessons learned from previous projects are some examples of organizational process assets that can be helpful. FIGURE 3.4 The Create WBS process: input, tools and techniques, and output. Furthermore, even though each project is unique, there are similarities among sets of projects in an organization. These similarities can be used to prepare templates that will be used as a starting point for the WBS, to avoid the duplication of work. With or without templates, you will need to go through breaking down the deliverables, a very important step in creating the WBS. Decomposition Decomposition is a technique for subdividing the project deliverables into smaller, manageable tasks called work packages. The WBS is a hierarchical structure with work packages at the lowest level of each branch. Based on their complexity, different deliverables can have different levels of decomposition, as shown in the examples presented in Figure 3.5. In a WBS such as the one presented in Figure 3.5, the lines are called branches, and the boxes are called nodes. This is a very simple example of a WBS to elaborate some concepts. Different organizations may have different ways of generating a WBS based on their needs. For example, a complex WBS may be generated in parts. As another example, you may include the efforts of the project management team into the WBS as well. 114 Chapter 3 PROJECT SCOPE MANAGEMENT FIGURE 3.5 An example of a WBS. The work packages are represented by the dark boxes at the end of each branch. Servlet and Bean refer to the programs that will need to be written. You decompose the project work by executing the following steps: 1. Identify the deliverables and the work involved by analyzing the project scope statement and requirements documentation. 2. Understand the relationships among the deliverables. 3. Structure and organize the first level (just below the root of the hierarchical tree) of the WBS hierarchy. Based on the project at hand, you can use one of the following approaches: ◆ Use the deliverables as the components in the first level. ◆ Use the phases of the project as the components in the first level. ◆ Use the subprojects as components in the first level. A subproject is a part of the project that is independent enough of the rest of the project that it can be performed by another project team. This approach is useful when you want to outsource (or procure) parts of the project. ◆ Use different approaches within each branch of WBS—for example, a subproject and deliverables in the first level. 4. Decompose the upper level into more detailed components for the lower level. 5. Keep decomposing to lower levels until necessary and sufficient decomposition has been achieved. 6. Assign identification codes to the WBS components. Creating a Work Breakdown Structure (WBS) 115 As the work is decomposed to lower levels of details, work components become more concrete and manageable. However, you should avoid excessive decomposition, because it will lead to a large number of work packages, and it will not be possible to manage all of them effectively. In other words, excessive decomposition leads to inefficient use of management and other resources. Necessary and sufficient decomposition is the key. An efficient level of decomposition may be determined by the organization based on its conditions. However, remember that the lowest level of decomposition is always work packages and not schedule activities. TIP During decomposition, the components are defined in terms of how the project work will actually be executed and controlled. You must verify the correctness of the decomposition at each level by requiring that the lower-level components are necessary and sufficient to the completion of the corresponding higher-level deliverables. One final point… While using the technique of decomposition, remember a useful concept or trick: rolling wave planning. It’s a fancy term that refers to handling a deliverable or subproject that cannot currently be decomposed fully because we don’t know the details about it yet—for example, it is to be executed long in the future. We leave the decomposition of such a deliverable at a level allowed by the available information and wait for further decomposition until more information becomes available. Yes, it is an example of progressive elaboration. The WBS document is the key item of the Create WBS process, but there are some other output items as well. Output of Creating the WBS The output of the Create WBS process consists of the items discussed in the following list. ◆ Work breakdown structure. As explained earlier, the WBS is a deliverable-oriented hierarchical structure that decomposes the deliverables into the work that will be executed by the project team to create the planned deliverables and to accomplish the planned project objectives. The project manager creates this document with the help of the project team. Following are some important characteristics of the WBS: ◆ Control account. Remember that each node represents a deliverable or a component of it at a certain level, and each deliverable will have a scope, schedule, and cost attached to it. Some suitable nodes in the WBS are selected as management control points. At each of these control points, scope, schedule, and cost are integrated for the purposes of monitoring and controlling the performance. For example, the integrated scope, schedule, and actual cost at these points can be compared to the earned value to measure the project performance. (You will learn about earned value in Chapter 5.) Such management points 116 Chapter 3 PROJECT SCOPE MANAGEMENT are called control accounts. Each control account may have one or more work packages under it. Obviously, each work package must belong to only one account; otherwise, some factors, such as cost, will be double (or multiple) counted. A WBS component that is below the control account that has a well-defined work content but does not yet have a detailed schedule is called a planning package. ◆ Code of account. Each component in the WBS hierarchy, including work packages, is assigned a unique identifier called a code of account identifier. These identifiers can then be used in estimating costs, scheduling, and assigning resources. ◆ Scope. The WBS embraces the full scope of the project. If a task is not included in the WBS, it will not be done as a part of the project. ◆ Step toward team building. Because the project manager creates the WBS with the help of the project team, it is also the beginning of the team-building process on the part of the project manager. ◆ Step toward scheduling. The WBS decomposes the project work into manageable pieces (work packages) that can be assigned to individuals. This helps define the responsibilities for the team members and is the starting point for building the schedule. ◆ Reference for communication. Throughout the project, the WBS works as a reference for communication regarding what is included in the project and what is not. ◆ WBS dictionary. This is a supporting document for the main WBS document to provide details about the components of the WBS. The details about a component might include elements such as a code of account identifier, description of work involved, quality requirements, acceptance criteria, a list of milestones schedule, cost estimates, required resources, contract information (if any), and the organization or group responsible for this component. ◆ Updates. During the Create WBS process, the project team might realize that something out of the existing scope must be included in order to accomplish something in the scope. This will give rise to a change request, which might also come from other stakeholders during or after the first creation of the WBS. After the change request has been approved, not only the WBS will be changed—the scope statement must also be updated accordingly. The impact of the approved change request on the project scope management plan must be evaluated, and the plan must be updated accordingly. ◆ Scope baseline. This is not a different item in itself. The scope statement, the WBS document, and the WBS dictionary combined constitute the scope baseline against which all the change requests will be evaluated. Creating a Work Breakdown Structure (WBS) 117 NOTE Do not confuse the WBS with other information breakdown structures, such as the organizational breakdown structure (OBS), which provides a hierarchy of the performing organization and can be used to identify organizational units for assigning the WBS work packages. Remember, the end goal of the WBS is to specify the project scope in terms of work packages; this is what distinguishes the WBS from other information breakdown structures. You might wonder who creates the WBS. Well, it is your responsibility, and you, the project manager, create it with the help of the team. Which team? The work packages do not exist before the WBS is complete; therefore, no assignments have been made yet. Catch 22? Yes, you are right—depending upon the project, the final formal project team might not even exist yet. However, practically speaking, there will already be some people working with you on the project by now. Some of them are the potential team members. In addition to them, you can use the help of relevant experts in the organization and some stakeholders. Also, by now you have very good idea of who will probably be working to generate the outcome of the project. It’s a very good idea to involve those individuals in creating the WBS. This will give them a sense of participation and ownership. After all, the WBS will be the reference for work throughout the project. CAUTION The CAPM exam expects you to know the ropes around the formal standard terminology. For example, if I say project plan, you should be able to figure out that I’m referring to the project management plan. Another example: If I say defining scope, you should be able to translate that to the Define Scope process, the same way you will translate the planning stage to the planning process group. STUDY CHECKPOINT 3.3 A. What is the difference between management control points and control accounts? B. What is the difference between control accounts and code of account? 118 Chapter 3 PROJECT SCOPE MANAGEMENT Before and After the WBS From the initiating process group until now, I have discussed quite a few documents created in various processes. Some of these documents become input into another process that creates some other document. It is important to understand the order in which these documents are created and which document is an input to creating which other document. This is shown in Figure 3.6. FIGURE 3.6 A number of documents are created during the initiation and scope planning process- es. An arrow shows the documents that are input to creating other documents, and the numbers indicate the order in which these documents are created. The WBS is at the heart of project management. It affects directly or indirectly almost all the processes that are performed after its creation. Figure 3.7 shows some of the processes that are directly based on the WBS as a component of scope baseline. The mantra before developing the WBS is: If it’s not in the scope, it will not be done. The mantra after developing the WBS should be: If it’s not in the WBS, it will not be done. In other words, the WBS is the representation of the project scope, which needs to be controlled. Controlling Scope FIGURE 3.7 119 Some processes based on the WBS. Controlling Scope Controlling the project scope includes influencing factors that create changes to the scope, as well as managing change requests and controlling their impact when the change actually occurs. While controlling the scope, you focus on the following tasks: ◆ Watch out for scope creep: Determine whether it has happened and correct the situation. Scope creep refers to scope changes applied without processing them through the change control process. ◆ Process the scope change requests through the integrated change control process for approval. ◆ Manage the implementation of scope changes after approval, as well as their impact across the project. 120 Chapter 3 PROJECT SCOPE MANAGEMENT TIP In real life, scope creeps occur for various reasons. For example, perhaps a development engineer thought something was a cool feature to implement, or the customer spoke directly with the engineer to make a request for a minor additional feature, or any other similar situation occurred. If a scope creep has taken your project off track, you need to take corrective actions to get the project back on track. You should also investigate how the scope creep happened and take steps to prevent it in the future—for example, by educating team members about the proper scope change process. As shown in Figure 3.8, the obvious input items to the scope control process are the elements that define the scope, such as the project scope statement, the scope baseline, the WBS, the WBS dictionary, and a scope management plan that describes how to manage the scope. The performance reports might help to detect a scope change, and some change requests in other areas can result in scope change as well. FIGURE 3.8 The Control Scope process: input, tools and techniques, and output. The main output of the scope control process is the update to scope-related input elements, such as the project scope statement, the WBS, the WBS dictionary, and the scope baseline. The components of the project management plan affected by these changes might also need to be updated. Change requests and recommendations for corrective actions are other obvious output items from the scope control process. Verifying the Scope of Project Deliverables 121 As part of controlling the scope, you need to use the project performance measurements to determine any variance from the original scope baseline. Therefore, the variance analysis discussed in Chapter 5 is the tool used in the Control Scope process. However, as discussed also in Chapter 5, scope is closely related to cost and schedule, and therefore when you are looking at scope variance, you should also look at schedule variance and cost variance. For example, schedule variance can have an effect on the scope if you want to finish the project on time and there are no additional resources available. The other process in monitoring and controlling the project scope is called Verify Scope, which we discuss next. STUDY CHECKPOINT 3.4 Q. What do you do with the work performance information in the Control Scope process? Verifying the Scope of Project Deliverables Verifying scope is the process of formally accepting the completed project deliverables by the customer. Before you hand over the project deliverables to the appropriate party mentioned in the project management plan, such as the customer or the sponsor, you need to verify with the customer that these deliverables actually meet the planned scope. So verifying the scope of the project deliverables includes reviewing deliverables with the customer to ensure that all of them are completed as planned and therefore as expected. Note that before verifying the scope of the deliverables with the customer, they are validated by the quality control process. CAUTION You should perform the scope verification process even if the project is terminated— that is, ended before completion. In that case you would verify and document the level and extent of the project and product scope that was completed. The process used to verify the scope is called Verify Scope and is illustrated in Figure 3.9. In order to verify the scope of deliverables, you need to pull out the project management plan and look at the sections related to the planned scope: project scope statement, WBS, and WBS 122 Chapter 3 PROJECT SCOPE MANAGEMENT dictionary. The project scope statement includes the list of deliverables, the product scope description, and the product acceptance criteria. More scope-related details can be found in the WBS that defines the decomposition of each deliverable into work packages. Further details, such as a description of each WBS component, the related statement of work, and technical requirements, can be found in the WBS dictionary. FIGURE 3.9 The Verify Scope process: input, tools and techniques, and output. STUDY CHECKPOINT 3.5 Q. Before you begin the Verify Scope process, you look at the project scope statement, WBS, and WBS dictionary. What are these three elements collectively called? The product requirements should be considered part of the scope and can be found in two documents: the stakeholder requirements document and the requirements traceability matrix that you prepared in the process of collecting requirements during the planning stage of the project. Finally, before you go through the process of scope verification, you should get all the deliverables validated through the quality control process. You can use the inspection or auditing on the deliverables if necessary, even during the Verify Scope process. In this context, some examples of inspection are product audits, product reviews, and walkthroughs. The actual scope verification activity has different names in different organizations, such as audits, inspection, product review, and walkthrough. Nevertheless, the output of this activity is documentation of two kinds: ◆ Documentation of which deliverables have been accepted—that is, verified. ◆ Documentation of those deliverables that have not passed verification and therefore are not accepted. Also, documentation of the reasons why they failed the verification. The scope verification process may also give rise to change requests, such as requests for defect repairs. Verifying the Scope of Project Deliverables 123 CAUTION Do not confuse scope verification with quality control. Quality control is primarily focused on checking the correctness of the deliverables and other quality requirements, whereas scope verification is primarily concerned with the overall acceptance of the project deliverables by the customer. Quality control is usually performed before scope verification, but they can be performed simultaneously as well, depending on the situation. STUDY CHECKPOINT 3.6 Q. The Verify Scope process belongs to which process group? The project deliverables that have been accepted through the scope verification process still need to go through final handover to the appropriate party, such as the customer or the sponsor. The technical term here is transition. The three most important takeaways from this chapter are as follows: ◆ You need to collect requirements by using the Collect Requirements process before you can define the project scope. Requirements documentation generated by the Collect Requirements process and the project charter generated during the project initiation are used to define the scope, which is documented in the project scope statement. ◆ The requirements documentation and the project scope statement are input items to create the work breakdown structure (WBS), which is a breakdown of project deliverables into manageable pieces called work packages. The WBS is supported by another document called the WBS dictionary, which offers details for the WBS components. ◆ To avoid scope creep and to ensure that the scope is implemented, you need to control the scope. The scope of the project outcome needs to be verified before the product goes to project closure. 124 Chapter 3 PROJECT SCOPE MANAGEMENT Summary Project scope management includes processes that are used to ensure that the project includes all the required and only the required work. It contains processes from the planning process group and from the monitoring and controlling process group. Collecting requirements is part of scope planning, which creates requirements documentation and a requirements management plan. The project charter and requirements documentation are used to define the scope, which creates the project scope statement. The project scope statement is a document that defines the scope of a project, including the product scope, by stating what needs to be accomplished by the project. It includes project deliverables, a product description, product acceptance criteria, assumptions and constraints, and project exclusions. The project scope statement and requirements documentation are input items to creating the work breakdown structure (WBS), which is a breakdown of project deliverables into manageable pieces called work packages, which in turn are used to develop the project schedule. The WBS is supported by another document called the WBS dictionary, which offers details for the WBS components. The scope statement, the WBS document, and the WBS dictionary combined constitute the scope baseline against which all change requests are evaluated. Once determined, scope needs to be controlled throughout the project execution. Also, the scope of the finished product needs to be verified with the customer or the sponsor before the product can be accepted. The WBS is the heart of project management, as it is used in managing many aspects of the project, including developing the schedule. Developing the schedule is a major part of time management, discussed in the next chapter. Exam’s Eye View Comprehend ◆ The stakeholder register generated by the Identify Stakeholders process is an input item to collecting requirements. ◆ Requirements documentation generated by the Collect Requirements process is an input to defining the project scope. ◆ The project charter and the requirements documentation are input items to the Define Scope process that is used to develop the project scope statement. ◆ The project scope statement and requirements documentation are input items to creating the WBS. ◆ The scope statement, the WBS document, and the WBS dictionary combined constitute the scope baseline against which all change requests are evaluated. Review Questions Look Out ◆ Do not confuse project scope with product scope. The product scope consists of the features and functions that characterize a product, service, or result to be delivered by the project, whereas the project scope is composed of the work that must be performed (and only that work) to deliver products, services, or results with specified features. ◆ There is no formal standard process to develop the project scope management plan; it’s created as a part of the effort to develop the project management plan. Memorize ◆ The project scope statement includes these elements: project assumptions and constraints, project deliverables, project exclusions, product scope description, and product acceptance criteria. ◆ Quality, resources, scope, predefined budgets, and imposed dates or deadlines are some common constraints you should consider across all projects. ◆ The scope baseline consists of the WBS, WBS dictionary, and project scope statement. ◆ Control points are the points in the WBS at which scope, schedule, and cost are integrated for the purpose of monitoring and controlling the performance. ◆ Each component in the WBS hierarchy, including work packages, is assigned a unique identifier called a code of account identifier. These identifiers can then be used in estimating costs, scheduling, and assigning resources. Review Questions 1. Which of the following is a false statement about the WBS? A. Each item in the WBS (not just the work packages) is assigned a unique identifier called a code of account identifier. B. You should keep decomposing WBS components to lower levels until necessary and sufficient decomposition has been achieved. C. Each work component appears in the WBS once and only once. D. The work packages should appear from left to right in the order in which the work will be performed. 2. Which of the following is done first? A. Creating the scope statement B. Creating the WBS C. Creating the requirements documentation D. Creating the project charter 125 126 Chapter 3 PROJECT SCOPE MANAGEMENT 3. The WBS is the output of which of the following processes? A. The Create WBS process B. The Define Scope process C. The Develop WBS process D. The Project Initiating process 4. The project scope statement is the output of which of the following processes? A. The Create WBS process B. The Define Scope process C. The Create Project Scope process D. The Project Initiating process 5. Which of the following is a false statement about the project scope management plan? A. It describes how to verify the scope. B. It describes how to control the scope. C. It serves as the baseline for the project scope. D. It describes how to create the WBS. 6. What are the components in the lowest level of the WBS hierarchy collectively called? A. Work packages B. Milestones C. Phases D. Features 7. Which of the following is not a constraint common to projects? A. Resources B. Imposed date C. Schedule milestone D. Skill set 8. Which of the following constitutes the project scope baseline? A. The WBS document and the scope statement B. The scope statement C. The WBS document D. The WBS, the WBS dictionary, and the scope statement Review Questions 9. Who creates the WBS? A. The project manager alone B. The upper management in the performing organization C. The customer D. The project manager with help from the project team 10. Which of the following is not included in the project scope statement? A. Project assumptions and constraints B. The WBS C. Product description D. Project deliverables 11. You are in the process of developing the scope management plan for your project. You will develop this plan: A. By performing the Scope Planning process B. By performing the Define Scope process C. As a part of the effort to develop the project management plan D. During the initiation stage of the project 12. You are in the planning stage of a project. Walking down the hallway, your supervisor mumbles, “Don’t forget job shadowing.” Job shadowing is a technique used in: A. Defining the project scope B. Collecting product requirements C. Creating the WBS D. Developing the stakeholder management strategy 13. You are planning the scope for your project. You have just created the requirements documentation after meeting with the stakeholders and studying the project charter. This requirements documentation can be used in developing: A. The stakeholder register and project scope statement B. The project charter and the WBS C. The stakeholder register and the project charter D. The project scope statement and the WBS 14. Which of the following is the correct order of running processes? A. Develop Project Charter, Collect Requirements, and Create WBS B. Collect Requirements, Develop Project Charter, and Define WBS C. Identify Stakeholders, Define Scope, and Collect Requirements D. Collect Requirements, Create WBS, and Define Scope 127 128 Chapter 3 PROJECT SCOPE MANAGEMENT 15. You have selected a node in the hierarchy of the WBS that you will use to compare schedule, cost, and scope with the earned value in order to measure the project performance. This node or component in the WBS is called: A. Code of accounts B. Control account C. Management account D. Performance node 16. You are the project manager for a software product, and your project is in the execution stage. You have learned that Maya, a developer, has started adding some new features to the deliverable she is working on. What is the best action for you to take? A. Tell Maya to delete the code corresponding to these features because this is scope creep, and scope creep is not allowed. B. Learn from Maya what those features are and how much time they will take and then make necessary updates to the WBS, the WBS dictionary, and the schedule. Also tell Maya that in the future, she should get approval from you before adding any new features. C. Determine where the request for the new features came from and process the change request through the integrated change request process. D. Contact Maya’s functional manager and ask the manager to replace Maya with another developer.