LESSON 3

5. PROJECT SCOPE KNOWLEDGE AREA

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. Managing the project scope is primarily concerned with defining and controlling what is and is not included in the project.

We tackle scope first because you cannot figure out how long your project will take or how much money you will spend until you will first know what the project must deliver. To "scope out" your project, you will first need to identify the entire project's deliverables. You will also need to know all the work required to complete them in sufficient detail. Many projects are doomed to fail because there is insufficient or incomplete work done around scope management. Teams find out too late that they have missed some critical requirement or functionality and end up scrambling to get it done. This increases risk, cost, and schedule.KEY CONCEPTS FOR PROJECT SCOPE MANAGEMENT:There is project scope and product scope. Make sure you understand the difference. Project scope is all the work that is done to plan, manage, and control the project.Product scope focuses on the work required to create the project's deliverables. Please make sure you read the questions carefully. There is only two letters different between these two words, and you do not want to answer incorrectly.Project and product scope are measured differently.Project scope is measured against the project management plan. Product scope is measured against the requirements.The scope mantra is: Do all the work but only the work required to accomplish the project's objective(s).

Trends and emerging practices for Project Scope Management include but are not limited to:Determine problems and identify business needs;Identify and recommend viable solutions for meeting those needs;Elicit, document, and manage stakeholder requirements in order to meet business and project objectives; Facilitate the successful implementation of the product, service, or end result of the program or project.

TAILORING CONSIDERATIONSKnowledge and requirements management; Validation and control; Development approach; Stability of requirements; Governance.

CONSIDERATIONS FOR AGILE/ADAPTIVE ENVIRONMENTSIn projects with evolving requirements, high risk, or significant uncertainty, the scope is often not understood at the beginning of the project or it evolves during the project. Agile methods deliberately spend less time trying to define and agree on scope in the early stage of the project and spend more time establishing the process for its ongoing discovery and refinement. Many environments with emerging requirements find that there is often a gap between the real business requirements and the business requirements that were originally stated. Therefore, agile methods purposefully build and review prototypes and release versions in order to refine the requirements. As a result, scope is defined and redefined throughout the project. In agile approaches, the requirements constitute the backlog. 5.1. Plan Scope Management Plan Scope Management is the process of creating a scope management plan that documents how the project and product scope will be defined, validated, and controlled. The key benefit of this process is that it provides

guidance and direction on how scope will be managed throughout the project. This process is performed once or at predefined points in the project.This process is all about creating the scope management plan and the requirements management plan. These are two subsidiary plans for the overall project management plan that you will assemble and never touch again. Kidding! Because these are planning processes, chances are you will be editing these plans over and over, as you move through planning. The point is that these two plans shape your approach to how you will define and control both the project’s scope and the project’s requirements.Inputs into this process are: Project charter, Project management plan: (Quality management plan, Project life cycle description, Development approach); Enterprise environmental factors, and Organizational process assets.To begin this process, you will need the information already gathered and included in the project charter. You will use the charter because it is the launching point of the project and already maps out the high-level requirements and vision for the project. The project charter sets the direction for the project, while the scope management plan and the requirements management plan define how the project will achieve those objectives.Quality management plan. The way the project and product scope will be managed can be influenced by how the organization’s quality policy, methodologies, and standards are implemented on the project.Project life cycle description. The project life cycle determines the series of phases that a project passes through from its inception to the end of the project.Development approach. The development approach defines whether waterfall, iterative, adaptive, agile, or a hybrid development approach will be used. Tools and techniques for this process are: Expert judgment; Data analysis: (Alternatives analysis); MeetingsThe project management team can use expert judgment to help them analyze all inputs to create the best project scope management plan. The primary tool and technique for creating the scope management plan is planning—and this means meetings. A data analysis technique that can be used for this process includes but is not limited to alternatives analysis. Various ways of collecting requirements, elaborating the project and product scope, creating the product, validating the scope, and controlling the scope are evaluated.OUTPUTS from this process are: Scope management plan; Requirements management plan

Project scope management plan will be used to define, validate, manage, and control the project scope. There are four more juicy facts you need to know about this this plan:• The project scope management plan defines how the official project scope statement will be defined based on the project charter.• The plan defines how the WBS will be created, controlled, and approved. • The plan documents the process for scope validation. To clarify, scope validation is the inspection of the project deliverables by the project customer. The goal of scope validation is to validate that the deliverables are in alignment with the project goals and then are formally accepted.• The plan documents and defines how changes to the project scope will be managed and controlled. This is linked to our past lesson on integrated change control. As a refresher, integrated change control acknowledges that a change in one knowledge area can affect any of the other knowledge areas.The project scope management plan is a subsidiary of the project management plan. This plan sets the tone for the remainder of the project. As you may have already guessed, the larger the project - the more important this plan. As a general rule, larger projects require more detail. The scope management plan can rely heavily on organizational process assets and enterprise environmental factors. From organizational process assets, you can call on the policies and procedures that you must follow as a project manager in your organization. From the enterprise environmental factors, you will allow the organization’s culture, organizational structure, project team administration rules, and the overall marketplace conditions to influence your planning and development.

Requirements Management PlanThe second plan that comes out of this process is the requirements management plan. While similar in nature to the project scope management plan, this plan explains how the project will collect, analyze, record, and track the requirements throughout the project. Like the scope management plan, this plan doesn’t list the actual requirements, but sets the rules for how the project manager, team, and stakeholders will interact with the project’s requirements. This plan is also a subsidiary plan for the overall project management plan. This plan can be based on a template, just like the scope management plan can be, but you can tailor it to your project as needed. The following elements can be included in this plan:• The process for planning, tracking, and recording all of the project requirements• Configuration management activities for the product (changing the product, specs for the product scope, and who can approve any changes to the product)• The process for analyzing and prioritizing requirements• Metrics for measuring the acceptability of the requirements• How the requirements will be tracked through the project (usually through a requirements tracing matrix).Example of the question:Henry is the project manager for his organization, and management has asked him to create a project management plan to define the scope statement. Which project management plan guides the creation of the detailed project scope statement?A. The charterB. The project management planC. The project scope planD. The project scope management planAnswer is D: The project scope management plan defines the creation of the detailed project scope statement. A, the charter, does include the preliminary project scope statement, but not the detailed one defined by the project scope management plan. B, the project management plan, is a parent of the project scope management plan. C is not a valid plan, so this answer is incorrect.

5.2. Collect requirements.We need to define requirements. Requirements are mandatory for the project, and there is a hierarchy of requirements. At the highest level, business requirements specify what but not how. They are related to the business objectives. For example, the project must comply with approved company policies. It will be up to the project team to determine how the project will comply. The next logical level is the project requirements and product requirements. In the diagram shown here, these are just some examples. It is not intended to be all-inclusive. Every project may identify other requirements as appropriate for their industry and company. As you identify and collect requirements, you'll need to document them in your requirements documentation. Collecting requirements is part of planning your scope. It's a precursor to defining your scope clearly, as it communicates what you plan to do. Think of the Collect Requirements process as activities that lead to a clear picture of the Define Scope process.Example of the question:

Answer: C

Inputs into this process are: Project charter; Project management plan: (Scope management plan, Requirements management plan, Stakeholder engagement plan); Project documents: (Assumption log, Lessons learned register, Stakeholder register); Business documents: (Business case); Agreements; Enterprise environmental factors; Organizational process assets

Project charter: Identifies the business needs of the project, Project management plan: Specifically, the scope management plan, the requirements management plan,

and the stakeholder engagement plan, Project documents: Assumptions log, lessons learned register, and stakeholder register, Business documents: References the business case for the project, Agreements: Contracts or service-level agreements that you’re utilizing in the project Enterprise environmental factors: Ensures that you follow the rules and governance framework for your

organization, Organizational process assets: Standards, guidelines, checklists, forms, or other assets you can rely upon

to capture requirements.Tools and techniques for this process are: Expert judgment; Data gathering: (Brainstorming, Interviews, Focus groups, Questionnaires and surveys, Benchmarking); Data analysis: (Document analysis); Decision making: (Voting, Multicriteria decision analysis); Data representation: (Affinity diagrams, Mind mapping); Interpersonal and team skills: (Nominal group technique, Observation/conversation, Facilitation); Context diagram; PrototypesExample of the question:

Answer:

Working with Project StakeholdersYou will have to work with the project stakeholders in order to identify the requirements your project needs. This is where the stakeholder register comes in handy, because you’ll need to contact the stakeholders to schedule times to elicit their project requirements. One favorable approach is to categorize the types of users and stakeholders to streamline your requirements collection process. By grouping similar stakeholders together, you can save time and effort and keep the project moving along. –Focus groups - bring together prequalified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service, or result. A trained moderator guides the group through an interactive discussion designed to be more conversational than a one-on-one interview.Interviews. An interview is a formal or informal approach to elicit information from stakeholders by talking to them directly. It is typically performed by asking prepared and spontaneous questions and recording the responses. Interviews are often conducted on an individual basis between an interviewer and an interviewee, but may involve multiple interviewers and/or multiple interviewees. Interviewing experienced project participants, sponsors, other executives, and subject matter experts can aid in identifying and defining the features and functions of the desired product deliverables. Interviews are also useful for obtaining confidential information.Benchmarking - involves comparing actual or planned products, processes, and practices to those of comparable organizations to identify best practices, generate ideas for improvement, and provide a basis for measuring performance. The organizations compared during benchmarking can be internal or external.Decision-making techniques that can be used in the Collect Requirements process include but are not limited to: Voting is a collective decision-making technique and an assessment process having multiple alternatives

with an expected outcome in the form of future actions. These techniques can be used to generate, classify, and prioritize product requirements. Examples of voting techniques include: Unanimity. A decision that is reached whereby everyone agrees on a single course of action. Majority. A decision that is reached with support obtained from more than 50% of the members of the

group. Having a group size with an uneven number of participants can ensure that a decision will be reached, rather than resulting in a tie.

Plurality. A decision that is reached whereby the largest block in a group decides, even if a majority is not achieved. This method is generally used when the number of options nominated is more than two.

Autocratic decision-making. In this method, one individual takes responsibility for making the decision for the group.

Multicriteria decision analysis. A technique that uses a decision matrix to provide a systematic analytical approach for establishing criteria, such as risk levels, uncertainty, and valuation, to evaluate and rank many ideas.

Data representation techniques that can be used for this process include but are not limited to: Affinity diagrams - allow large numbers of ideas to be classified into groups for review and analysis. Mind mapping - consolidates ideas created through individual brainstorming sessions into a single map to

reflect commonality and differences in understanding and to generate new ideas.The interpersonal and team skills that can be used in this process include but are not limited to:Nominal group technique - technique enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization. The nominal group technique is a structured form of brainstorming consisting of four steps: 1. a question or problem is posed to the group. Each person silently generates and writes down their ideas. 2. The moderator writes down the ideas on a flip chart until all ideas are recorded. 3. Each recorded idea is discussed until all group members have a clear understanding. 4. Individuals vote privately to prioritize the ideas, usually using a scale of 1 – 5, with 1 being the lowest and 5 being the highest. Voting may take place in many rounds to reduce and focus in on ideas. After each round, the votes are tallied and the highest scoring ideas are selected.Observation and conversation - provide a direct way of viewing individuals in their environment and how they perform their jobs or tasks and carry out processes. It is particularly helpful for detailed processes when the people who use the product have difficulty or are reluctant to articulate their requirements. Observation is also known as “job shadowing.” It is usually done externally by an observer viewing a business expert performing a job. It can also be done by a “participant observer” who actually performs a process or procedure to experience how it is done to uncover hidden requirements.Facilitation - is used with focused sessions that bring key stakeholders together to define product requirements. Workshops can be used to quickly define cross-functional requirements and reconcile stakeholder differences. Because of their interactive group nature, well-facilitated sessions can build trust, foster relationships, and improve communication among the participants, which can lead to increased stakeholder consensus. In addition, issues can be discovered earlier and resolved more quickly than in individual sessions.Facilitation skills are used in the following situations, but are not limited to:

Joint application design/development (JAD). JAD sessions are used in the software development industry. These facilitated sessions focus on bringing business subject matter experts and the development team together to gather requirements and improve the software development process.

Quality function deployment (QFD). In the manufacturing industry, QFD is another facilitation technique that helps determine critical characteristics for new product development. QFD starts by collecting customer needs, also known as voice of the customer (VOC). These needs are then objectively sorted and prioritized, and goals are set for achieving them.

User stories - which are short, textual descriptions of required functionality, are often developed during a requirements workshop. User stories describe the stakeholder role, who benefits from the feature (role), what the stakeholder needs to accomplish (goal), and the benefit to the stakeholder (motivation).

The context diagram is an example of a scope model. Context diagrams visually depict the product scope by showing a business system (process, equipment, computer system, etc.), and how people and other systems (actors) interact with it. Context diagrams show inputs to the business system, the actor(s) providing the input, the outputs from the business system, and the actor(s) receiving the output.

Prototyping is a method of obtaining early feedback on requirements by providing a model of the expected product before actually building it.

Outputs of this process are: Requirements documentation; Requirements traceability matrix.Once you have gathered all of the project requirements, you will need to do something with them. The first place to start is the requirements documentation—a listing of all of the project requirements and the supporting detail for the identified requirements. Requirements need to be measurable and consistent and then they can be presented to the key stakeholders for their confirmation of what you’ve captured and what the stakeholders were expecting to receive from you. Here are some examples of requirement types: Business requirements - These describe the higher-level needs of the organization as a whole, such as the

business issues or opportunities, and reasons why a project has been undertaken; Stakeholder requirements - These describe needs of a stakeholder or stakeholder group. Project requirements - These describe the actions, processes, or other conditions the project needs to meet.

Examples include milestone dates, contractual obligations, constraints, etc. Solution requirements - These describe features, functions, and characteristics of the product, service, or

result that will meet the business and stakeholder requirements. Solution requirements are further grouped into functional and nonfunctional requirements: Functional requirements describe how the solution functions, including actions, processes, data, and interactions the product will have. When you describe what the product does, it is likely a functional requirement. Nonfunctional requirements describe the attributes of the product that are needed in order for it to be effective. For example, an IT solution may have uptime, redundancy, security, level of service, supportability, and other conditions that describe a nonfunctional requirement. Both functional and nonfunctional requirements are captured and documented as part of the project requirements.

Quality requirements -These capture any condition or criteria needed to validate the successful completion of a project deliverable or fulfillment of other project requirements. Examples include tests, certifications, validations, etc.

Transition and readiness requirements -These describe temporary capabilities, such as data conversion and training requirements, needed to transition from the current as-is state to the desired future state.

Example of the question:

Answer:

Because requirements can comprise a long, long list, it is better to record them in a table called a Requirements Traceability Matrix. This table documents and numbers each requirement and its status in the project, and shows how each requirement is linked to a specific deliverable that the project will create or has created. You’ll also, usually, provide a little narrative about the requirement in the matrix as a point of reference, current status of the requirement, owner, and status date. For more detail, you’ll reference the actual requirements documentation. The traceability matrix helps the project manager and the project customer see the product of the project and compare it against the requirements to confirm that all of the requirements have been met and are in existence in the final deliverable for the customer.

Example of the question:

Answer:

5.3. Define Scope Define Scope is the process of developing a detailed description of the project and product. The key benefit of this process is that it describes the product, service, or result boundaries and acceptance criteria.Project scope and product scope are different entities. The project scope deals with the required work to create the project deliverables. The scope of the project is specific to the work required to complete the project objectives. The project scope focuses on what must be done to create the deliverable. Product scope, on the other hand, refers to the attributes and characteristics of the deliverables the project is creating. There would be specific requirements regarding the features and characteristics of each project: the materials to be used, the dimensions of the space, the function of each building, and all other related details. The product scope is what the customer of the project envisions.

Example of the question:

Answer:

The project scope and the product scope are bound to each other. The product scope constitutes the characteristics and features of the product that the project creates. The end result of the project is measured against the requirements for that product. The project scope is the work required to deliver the product. Throughout the project execution, the work is measured against the project plan to validate that the project is on track to fulfill the product scope. The product scope is measured against requirements, while the project scope is measured against the project plan.

Inputs for this process are: Project Management Plan: (Scope management plan); Project charter; Requirements documentation; Enterprise environmental factors; Organizational process assets The project charter provides the high-level project description, product characteristics, and approval requirements.A project management plan component includes but is not limited to the scope management plan, which documents how the project scope will be defined, validated, and controlled.The assumption log identifies assumptions and constraints about the product, project, environment, stakeholders, and other factors that can influence the project and product scope.Requirements documentation identifies requirements that will be incorporated into the scope.The risk register contains response strategies that may affect the project scope, such as reducing or changing project and product scope to avoid or mitigate a risk.EEF, OPAs

Tools and techniques for this process are: Expert judgment; Data analysis: (Alternatives analysis); Decision making: (Multicriteria decision analysis); Interpersonal and team skills: (Facilitation); Product analysis Facilitation is used in workshops and working sessions with key stakeholders who have a variety of

expectations or fields of expertise. The goal is to reach a cross-functional and common understanding of the project deliverables and project and product boundaries.

Product analysis can be used to define products and services. It includes asking questions about a product or service and forming answers to describe the use, characteristics, and other relevant aspects of what is going to be delivered.Each application area has one or more generally accepted methods for translating high-level product or service descriptions into meaningful deliverables. Requirements are captured at a high level and decomposed to the level of detail needed to design the final product. Examples of product analysis techniques include but are not limited to:For Tangible Deliverables:Product breakdown - literally subdivide a product into components or modules for further analysis. Value analysis (VA) - is used on existing products when they are being evaluated to improve (cost) efficiency or add new functionalitiesValue engineering (VE). - is used on new products during product development when they are being evaluated regarding costs and functionalities. VE/VA is not a design review process to find errors and omissions. Rather, it begins on the premise that initial product designs work and meet customer needs. However, it assumes that opportunities exist but are hidden by organizational boundaries incorrect assumptions, technological changes, and outdated methods. Organizations that strive to produce deliverables on time, with no errors, and at minimum cost rarely have the resources to seek out these opportunities.For Intangible Deliverables:Requirements analysis - can be used by itself or in conjunction with systems analysis. The goal of requirements analysis is to review and analyze each (business/project/product) requirement and figure out how it can be met and measured. Systems analysis - can be used to figure out each step in a given process and determine what needs to occur. It helps identify and solve problems within a system.Systems engineering - can be used with either products or services. It is an interdisciplinary approach to design, implement, and integrate the deliverable into a new or existing system. The emphasis of the process is stakeholder satisfaction with the functional and operational performance of the project's deliverable

Outputs from this process are: Project scope statement; Project documents updates: (Requirements documentation, Requirements traceability matrix, Stakeholder register);

Your project scope statement establishes the project boundaries, specifies all deliverables, and describes the project scope in sufficient detail. This is a required document for every project. Literally, every future decision you make will be based on what is and what is not contained here. All future planned actions will be compared to your scope statement to confirm alignment.

The project scope statement is made up of four sections:1. A detailed description of the product scope,2. Outcomes or deliverables,3. Conditions that must be met before a deliverable is considered acceptable (acceptance criteria), and4. Project exclusions, which are an explicit statement of what is not part of this project.Many people confuse the purpose and content of these three required project management elements: the project charter, the scope statement, and the project management plan. Simply put, the project charter initiates the project. The scope statement specifies what will be created (deliverables), and the project management plan spells out how you will do it (the strategy or approach).Exam Tip: Although the project charter and the project scope statement are sometimes perceived as containing a certain degree of redundancy, they are different in the level of detail contained in each. The project charter contains high-level information, while the project scope statement contains a detailed description of the scope components. These components are progressively elaborated throughout the project.

Project Scope Statement can be as detailed or as broad as you like. There is one thing to keep in mind: If all future decisions are based on what is in this document, then you will want it to be as unambiguous as possible. Ambiguity can lead to different interpretations, and that could increase risk in the form of scope changes. The best way to define a project's scope is to decompose (or break down) the major deliverables into small, more manageable work efforts the team can work on. This process is one of the distinctive attributes of project management.

Scope Creep. Without control, projects experience scope creep. Scope creep is unauthorized and uncontrolled changes to the project or product scope. Here are some examples: One of your team decides to "tweak" one of the components to make it prettier even though the customer did not ask for it and does not want to pay for it. The team includes a test that was not planned because "we always do it." If the test was not part of the schedule or budget, this could be a problem. One of the customer's team members has a chat with one of your team members, and they take it upon themselves to add a new feature without going through the formal approval process.

The key words are unauthorized and uncontrolled. Changes to scope are not uncommon, but they must be controlled and approved. Only approved changes can be implemented. Unapproved changes are denied and closed. The project manager must stay alert to scope creep's presence. Scope creep can result in extreme schedule and cost overruns and, consequently, project managers not making good on what they originally promised. Scope creep is nasty business because it can undermine all your hard work. Yet, interestingly, nearly all projects suffer from changes due to scope creep to some degree. Do not get me wrong. Changes can be a good thing, especially when you are able to exceed expectations. However, you must clearly identify, evaluate, agree on, schedule, and control changes. The trouble with scope creep is that it is not subject to any of these things.

Top Reasons Why Scope Creep Occurs:

Lack of formal scope management plan or process. Ambiguous or poorly defined scope. Insufficient level of detail (scope and requirements). Lack of stakeholder engagement in the scope definition process. Inconsistency when identifying, tracking, or controlling requirements.

Example of the question:

Answer:

Gold Plating. Gold plating means intentionally adding extra features or functions to the products, which were not included in the scope statement. Usually, gold plating is performed by either the project team or the project manager with no additional cost to the client. You must to avoid it.Example of the question:David, one of your project team members, has been making changes to his work, which, as a result, changes the project scope. David’s changes are also known as what?A. Gold platingB. Scope control defectC. Scope creepD. Improvised scope compositionAnswer:Right answer is C. Undocumented changes are examples of scope creep. A, gold plating, is when the project team adds changes to consume the project budget. B and D, scope control defect and improvised scope composition, are not valid change management terms.

Example of the question:

Answer:

5.4. Creating the Work Breakdown StructureCreate WBS is the process of subdividing project deliverables and project work into smaller, more manageable components. The key benefit of this process is that it provides a framework of what has to be delivered . This process is performed once or at predefined points in the project.

In project management, there are a few artifacts that are required. The work breakdown structure (WBS) is one of them.Inputs in to this process are: Project management plan: (Scope management plan); Project documents: (Project scope statement, Requirements documentation); Enterprise environmental factors; Organizational process assets.The scope management plan documents how the WBS will be created from the project scope statement;The project scope statement describes the work that will be performed and the work that is excluded;Detailed requirements describe how individual requirements meet the business need for the project.

Tools and techniques for this process are: Expert judgment, Decomposition

Decomposition is a technique used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts. The work package is the work defined at the lowest level of the WBS for which cost and duration can be estimated and managed. The level of decomposition is often guided by the degree of control needed to effectively manage the project. The level of detail for work packages will vary with the size and complexity of the project.Decomposition of the total project work into work packages generally involves the following activities: Identify the project deliverables and related work. Form the WBS structure. Decompose the upper tier deliverables into lower tier deliverables. Create and assign WBS identification codes to the WBS packages. (This is called the code of accounts

and is a numbering system that identifies each element within the WBS.) Confirm that the decomposition is appropriate for the type of project.

Example of the question:

Answer:

The WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. The WBS organizes and defines the total scope of the project and represents the work specified in the current approved project scope statement. The

planned work is contained within the lowest level of WBS components, which are called work packages. A work package can be used to group the activities where work is scheduled and estimated, monitored, and controlled. In the context of the WBS, work refers to work products or deliverables that are the result of activity and not to the activity itself.How Many Levels Do You Need in Your WBS? In other words, how far do you need to decompose each deliverable? The classic answer to this question is, it depends. One thing is for sure: Not every deliverable has to be broken down to the same number of levels. You need to go as far as you need to go. There are some tricks to help you determine the number of levels:The 8/80 rule - The 8/80 rule states that no work package should be less than 8 hours (one day) or more than 80 hours (two weeks). This guideline helps with sizing and functions well for small- to medium-size projects. Adjust the numbers upward for larger projects.Use an estimating range - For example, if you had an estimating range of plus or minus 25%, then you break down as many levels as you need in order for you to confidently provide estimates that meet the specified range. In some cases, you may only have to decompose one more level. In other cases, you may need to decompose three more levels.Single ownership - Sometimes it can meet the above two guidelines, but you still have unclear or diffuse ownership. That is a recipe for disaster. You need to hold one owner accountable, so decompose until there is a single owner for each work package.A WBS is the result of your decomposition efforts. A subdivision begins with major deliverables, proceeds to smaller deliverables, and finally ends with work packages. Work packages should be small enough to allow for adequate control and visibility, but they should not become an administrative burden.

Example of the question:

Answer:

Outputs from this process: Scope baseline; Project documents updates: (Assumption log, Requirements documentation).The scope baseline is the approved version of a scope statement, WBS, and its associated WBS dictionary, which can be changed only through formal change control procedures and is used as a basis for comparison. It is a component of the project management plan. Components of the scope baseline include:

Project scope statement. The project scope statement includes the description of the project scope, major deliverables, assumptions, and constraints.

WBS. The WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. Each descending level of the WBS represents an increasingly detailed definition of the project work.

Work package. The lowest level of the WBS is a work package with a unique identifier. These identifiers provide a structure for hierarchical summation of costs, schedule, and resource information and form a code of accounts. Each work package is part of a control account. A control account is a management control point where scope, budget, and schedule are integrated and compared to the earned value for performance measurement. A control account has two or more work packages, though each work package is associated with a single control account.

Planning package. A control account may include one or more planning packages. A planning package is a work breakdown structure component below the control account and above the work package with known work content but without detailed schedule activities.

WBS dictionary. The WBS dictionary is a document that provides detailed deliverable, activity, and scheduling information about each component in the WBS. The WBS dictionary is a document that supports the WBS. Most of the information included in the WBS dictionary is created by other processes and added to this document at a later stage. Information in the WBS dictionary may include but is not limited to:

• Code of account identifier and charge number• Work package description• Statement of work• Work package owner or responsible role• Schedule milestones• Contract information• Quality requirements• Technical references• Associated activities and work packages• Schedule• Resources• Cost

Every project must have a WBS. Why? Because it is the foundation for many other parts of your project. Here are some key examples:

Schedule: You must first identify the work (WBS) before you can sequence it. Budget: You must first identify the work before you can estimate costs. Quality: Each deliverable must have a quality metric we can test and confirm it was built

correctly. Resources: You can't identify required resources, team size, or skill sets until you first identify

the work.

Risk: Risk associated with the work. Work is associated with each deliverable. Controls: The first level of project controls is your WBS.

EXAM TIP. The WBS is primarily about things, not activities. The work package is just a label for the smallest deliverable within the WBS. The PMI has lightened their stance on allowing appropriate activities, such as testing, into the WBS. A work package can be scheduled, can have its cost estimated, and can be controlled. Usually, the WBS is a visual mapping of the subdivision of the project deliverables, though this approach isn’t always the best technique to use. The WBS can also be created by using the project phases, by subcontractors that will complete parts of the project work, or even by the type of labor the WBS will require.

EXAM TIP. Myth: The WBS is an input to the scheduling process. IT IS NOT!!!!!! It is not true. For one thing, the WBS is a Scope Management concept, not a Schedule Management concept. The WBS focus is on identification and organization of project deliverables. Schedules are all about sequencing project activities. In project management, the project scope statement is first composed, and then the scope is broken down, or decomposed, into the individual items that the project will create. Some items in the WBS may not be available for decomposition because they are far off in the future. In these instances, the project management team will break down those items as more information regarding the deliverables becomes available. This is an example of rolling wave planning. Some projects may elect to create their WBS based on the phases within the project, rather than on the total deliverables of the project. Either approach is fine.

WBS BenefitsA well-designed WBS offers many benefits:It describes the complete effort of your project.It enables you to authorize work.It facilitates budgeting.It leads to development of the project schedule.It helps you report on progress.It controls tasks.A WBS also serves as an excellent communication channel. It provides a common basis for planning and

control for all project participants. How does the WBS do that?A WBS identifies and organizes all the work. Using the 100% guideline means you are less likely to

overlook any work. It sets expectations with stakeholders and clarifies their understanding of each deliverable. That means better stakeholder management and improved communications, and prevents changes later.It establishes the first level of project controls. If you think about it, each work package is a very small

project with its own deliverable, schedule, budget, and resources. By establishing controls here, you have more control at the global project level.It makes it easier for the team to get their arms around something so big it seems impossible. They can now

see all the parts, and especially their own parts within the big picture. This increases buy-in and provides the initial understanding of how the team needs to work together. Each work package has a deliverable. Each deliverable has quality metrics and acceptance criteria defined. The analogy here is that if each jigsaw puzzle piece is correctly built, then the whole puzzle, once assembled, will also be correct. You must establish incremental quality at the work package level.

Exam TIP. Finally, you will see the scope baseline often in your PMP endeavor. You need to REMEMBER: The scope baseline is an output from The Create WBC process!The scope baseline is the combination of the project scope, the work breakdown structure, and the WBS dictionary.

5.5. Validate ScopeValidate Scope is the process of formally accepting completed project deliverables. The key benefit of this process is that it brings objectivity to the acceptance process and increases the probability of final product, service, or result acceptance by validating each deliverable. This process is performed periodically throughout the project as needed. Inputs for this process are: Project management plan: (Scope management plan, Requirements management plan, Scope baseline); Project documents (Lessons learned register, Quality reports, Requirements documentation, Requirements traceability matrix); Verified deliverables; Work performance data.

• The Scope management plan, because it defines the scope validation and approval process. You will also reference the Requirements management plan. This documentation of what the stakeholders expect from the project defines all of the technical requirements that must be present for the work to be accepted by the stakeholders. The Scope baseline is also part of the project management plan you will reference.• Project documents. From the project documents, you will reference the lessons learned register, quality reports, requirements documentation, and the requirements traceability matrix.• Verified deliverables. The deliverables that your project team has completed have passed your project’s quality control process.• Work performance data. This information defines how well the deliverables are in compliance and records those requirements that are not in compliance with the project scope. These four things will help you and the project stakeholders inspect the project work to confirm that what you have created is what was promised to the customer.

Example of the question:

Answer:

Exam Tip. Verified deliverables are an output of the Control Quality process and serve as an input to the Validate Scope process. These verified deliverables are reviewed with the customer or sponsor to ensure that they are completed correctly and that they match the requirements, so that they can receive formal acceptance from the customer. Scope validation is the process of the project customer accepting the project deliverables. It either happens at the end of each project phase or as major deliverables is created. Scope validation ensures that the deliverables the project creates are in alignment with the project scope. It is concerned with the acceptance of the work.

A related activity, quality control (QC), is concerned with the correctness of the work. Scope validation and QC can happen in tandem because the quality of the work contributes to scope validation. Poor quality will typically result in scope validation failure.

I found a very good example of the “meaning” Validation: Imagine a project to create a full-color, slick catalog for an electronics manufacturer. The project manager has completed the initiation processes, moved through planning, and is now executing the project work. The only trouble is that the project manager and the experts on the project team aren’t sharing the work progress with the customer.The work they are completing is not in alignment with the product description or the customer requirements. The project team has created a trendy 1950s-style catalog with funky green and orange colors, lots of beehive hairdo models, horn-rimmed glasses, and tongue-in cheek jokes about “the future” of electronics. The manufacturer, however, wants to demonstrate a professional, accessible, current look for its publications. What do you think will happen if the project manager presents the catalog with his spin rather than following the request of the customer?

Tools and techniques for this process are: Inspection; Decision making: (Voting);

Example of the question:

Answer:

Project InspectionInspection includes activities such as measuring, examining, and validating to determine whether work and deliverables meet requirements and product acceptance criteria. Inspections are sometimes called reviews, product reviews, and walkthroughs. In some application areas, these different terms have unique and specific meanings.You could just rush into scope validation, but that would be a waste of time and not a very organized approach to confirming that the project deliverables are accurate. It’s better to collect all inputs (I’ve mentioned then early) to help you prepare for the project inspection. To complete scope validation, the deliverables must be inspected or voted upon for completeness. Inspection may require measuring, examining, and testing the product to prove that it meets the customer’s requirements. Inspection usually requires the project manager and the customer to inspect the project deliverables for verification, which, in turn, results in acceptance.

Outputs from this process are: Accepted deliverables; Work performance information; Change requests; Project document updates: (Lessons learned register, Requirements documentation, Requirements traceability matrix).

Deliverables that meet the acceptance criteria are formally signed off and approved by the customer or sponsor. Formal documentation received from the customer or sponsor acknowledging formal stakeholder acceptance of the project’s deliverables is forwarded to the Close Project or Phase process.

Work performance information includes information about project progress, such as which deliverables have been accepted and which have not been accepted and the reasons why. This information must be documented.

If a project scope has been completed, the project is complete. Resist the urge to do additional work once the project scope has been fulfilled. Also, be cautious of instances where the scope is fulfilled and the product description is exact, but the customer is not happy with the product. Technically, for the exam, the project is complete even if the customer is not happy.5.6. Control Scope process.Control Scope is the process of monitoring the status of the project and product scope and managing changes to the scope baseline. The key benefit of this process is that the scope baseline is maintained throughout the project. This process is performed throughout the project.

Scope control is about protecting the project scope and the product scope from change and, when changes do happen, managing those changes. Ideally, all requested changes follow the scope change control system, which means that change requests must be documented. Those changes that sneak into the project scope are lumped into that project poison category of scope creep. Scope creep is bad, bad news. Of course, if you’re working in adaptive environment, there is still change control to the product scope and project scope, but change is managed through refinements of the product backlog. Change in a predictive environment is anticipated, but change follows the integrated change control process.

Inputs in to this process are: Project management plan: (Scope management plan, Requirements management plan, Change management plan, Configuration management plan, Scope baseline, Performance measurement baseline); Project documents: (Lessons learned register, Requirements documentation, Requirements traceability matrix), Work performance data, Organizational process assets.

Example of the question:

Answer:

Tools and techniques for this process are: Data analysis: (Variance analysis, Trend analysis)

Variance analysis is used to compare the baseline to the actual results and determine if the variance is within the threshold amount or if corrective or preventive action is appropriate.

Trend analysis examines project performance over time to determine if performance is improving or deteriorating.

Important aspects of project scope control include determining the cause and degree of variance relative to the scope baseline and deciding whether corrective or preventive action is required.

Preventing scope changes is better than dealing with a change after the fact. You have all the information you need in your project documentation. Use them!

Corrective actions—steps taken to move the project back into alignment with the project scope—do require formal change requests, because the project manager is not changing the scope, but rather the work that is outside of the project scope. Corrective actions are a part of scope control because you’re nudging, and

sometimes shoving, work back into alignment with the project scope. The trouble with scope creep and corrective actions is that the project team is doing or fixing work that should never have entered the scope in the first place—and that means wasted time and dollars. That’s one sure way for a project to be late and over budget.

The project manager must control the project team and the project stakeholders from doing anything—absolutely anything—that are outside of the project scope. This also means that the project management team should capture the customer’s vision in planning before much of the project work begins. For example, it’s much easier to make changes on a blueprint before construction begins than to make changes to an already-built structure. Gathering all requirements and creating an accurate project scope statement can ward off changes during execution.The Performance Measurement Baseline is an integrated Scope- Schedule-Cost Plan used to compare planned vs. actual results in terms of the overall project, rather than only for the individual Scope, Schedule and Cost Baselines.

Scope control addresses three things:1. Proactively preventing changes from occurring in the first place - Preventing scope changes is better than dealing with a change after the fact. You have all the information you need in your project documentation. There's the project management plan, scope management plan, and scope baseline to name a few. Use them!2. Recognizing an unauthorized change has occurred - Dealing with a change before it occurs falls into this category. Customers can initiate a change request for some additional feature or function. You must first analyze the impact the change would create in terms of schedule and cost and then get customer approval. In many cases, customers decide against changes once they learn about the additional cost and change to delivery date. The first essential ingredient for scope control is your scope baseline. If you don't have that, then you don't have a basis of comparison. This is important for two reasons: first, preventing an undesirable change from happening, and second, recognizing a change once it has occurred.3. Managing the implementation of approved changes. - The Control Scope process is also used to implement approved change requests. Approved changes will require updates to impacted project baselines. For example, the scope baseline will need to be re-baselined. It is also possible the schedule and budget baselines were impacted and must be adjusted accordingly. This is where the Integrated Change Control process intersects with the Control Scope process. Now you need to make sure the change is implemented successfully and has the desired effect.Example of the question:

Answer:

Exam TIPS. Read questions carefully. Only approved changes can be implemented. The Control Scope process is used to prevent changes, identify unauthorized changes and the resulting corrective actions, and implement approved changes.

Outputs from this process are: Work performance information; Change requests, Project management plan updates: (Scope management plan, Scope baseline, Schedule baseline, Cost baseline, Performance measurement baseline); Project documents updates: (Lessons learned register,Requirements documentation, Requirements traceability matrix).

EXAM TIP. Undocumented change requests should not be considered at all. Change requests must be documented according to the project scope management plan. When there is a difference between what was planned and what was created, variance analysis is needed to determine what corrective actions should be implemented.Change requests must always follow the change control system, or they are considered out of scope. As the project manager and the project team discover and report changes that are out of scope, the project management team must deal with the changes to remove them through corrective actions or incorporate them through the change control process. Those changes that are incorporated into the project must still be documented and then reflected in the preceding project components. No changes without documents!

Example of the question:

Answer:

Example of the question:

Answer: