Lesson 9: Create WBS, Validate Scope, and Control Scope

WBS Guidelines

-Must be clearly distinguishable from other work packages -Must have scheduled start and completion dates -Should have it's own budget -Should not be too small but large enough so that the work package can be competitively bid -Relatively short time span You'll need to gather all the project documentation you have so far as a starting point: specifically, the scope statement because it states the project outcomes and names major deliverables. It also establishes the project boundaries, so you know what's in and out of scope. This is a good starting point for your WBS. A WBS should not be created by a single person. You'll need the insights and expertise from others to make sure all the work has been identified. The project manager can facilitate the session and encourage others to think about any additional or support deliverables that may be required to accomplish the project objectives. Drawing the WBS on a whiteboard or using sticky notes is very visual and can be easily changed as the team works through the process. When complete, the WBS is broken down to the work package level. The work package is the lowest-level deliverable on any vertical branch or leg of the WBS. There are 8 work packages in this diagram

Scope Control addresses three things:

1. Proactively preventing changes from occurring in the first place, 2. Recognizing an unauthorized change has occurred, and 3. Managing the implementation of approved changes.

Exam Insights

1. Read questions carefully. Only approved changes can be implemented. 2. The Control Scope process is used to prevent changes, identify unauthorized changes and the resulting corrective actions, and implement approved changes. 3. Controlling domain represents 25% of the exam questions, so you need to know it well. 4. Questions around scope change might be tricky. Remember, only approved changes can be implemented. 5. Watch out for key words like verify versus validate. Remember to verify correctness and validate acceptability. You can have completed deliverables before they undergo testing. Verified deliverables have successfully completed quality control, and accepted deliverables have completed Validate Scope. That will give you the frame of reference for the question.

WBS as a communication channel

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? 1. A WBS identifies and organizes all the work. Using the 100% guideline means you are less likely to overlook any work. 2. It sets expectations with stakeholders and clarifies their understanding of each deliverable. That means better stakeholder management and improved communications, and prevents changes later. 3. 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. 4. 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. 5. 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.

8/80 Rule

A good rule of thumb that ensures that no work package is less than 8 hours (1 day) or more than 80 hours (2 weeks) in the WBS. This guideline helps with sizing and functions well for small- to medium-size projects. Adjust the numbers upward for larger projects.

Work Breakdown Structure (WBS)

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 is required in Project Management. Every project must have a WBS. It is the foundation of many other parts of your project. Example: 1. Schedule: You must first identify the work (WBS) before you can sequence it. 2. Budget: You must first identify the work before you can estimate costs. 3. Quality: Each deliverable must have a quality metric we can test and confirm it was built correctly. 4. Resources: You can't identify required resources, team size, or skill sets until you first identify the work. 5. Risk: Risk associated with the work. Work is associated with each deliverable. 6. Controls: The first level of project controls is your WBS.

Verified and Accepted Deliverables

A verified deliverable is one that has passed quality-control testing An accepted deliverable has completed the Validate Scope process and has been accepted by the customer Pay careful attention to the distinction between Validate Scope and another project management process, Control Quality (Section 8.3). Validate Scope refers to final acceptance, while Control Quality is a precursor process because it's concerned with determining if project results meet requirements.

WBS Benefits

A well-designed WBS offers many benefits: 1. It describes the complete effort of your project. 2. It enables you to authorize work. 3. It facilitates budgeting. 4. It leads to development of the project schedule. 5. It helps you report on progress. 6. It controls tasks.

WBS - Definitions

A work breakdown structure organizes all project and product scope in a hierarchal (tree) deliverable-oriented format.

Documenting Lessons Learned

After you finish performing Validate Scope, take time to document lessons learned. These lessons concern scope change and are often negative. However, they can also be positive, too. Lessons learned help to improve future projects because of benefits derived from the experience of others . They range from sharing a valuable project technique to issuing a warning about something that was a complete failure. Lessons learned pertain to one of our most memorable and sometimes painful of teachers: experience. Some people don't want to take the time to share lessons learned. This is a shame since there are so many good things that can come from it. Sharing information provides 2 key benefits: 1. Ensures we repeat our successes. 2. Ensures we don't repeat our failures. Although the PMBOK Guide doesn't refer to it as an element of the closing processes, make sure to take the time to identify what went right, recognize your team members for their efforts, and celebrate!

Managing Scope Changes

Change is unavoidable. It comes in two forms: Changes that you don't want (bad) and changes that you do want (good). Despite your best efforts, change is unavoidable. It comes in two forms: changes that you don't want (bad), and changes that you do want (good). I don't know of any project that doesn't change, so you'll need an effective scope control process to minimize its negative impact and to maximize the positive. First, you need to know if a change has occurred. How can you do this? Monitor work progress frequently enough and compare it actual to the baseline to determine if there's a variance. Variance analysis is a primary tool for Control Scope. Variance analysis gives a project manager a framework to break down the overall performance of the project; determine if, where, and when shortfalls occur; and decide what to do about them. Performance measurements, also called metrics, should tell you what to expect and what you're getting. I find exception reporting is helpful, especially when a team member raises the alarm that there's trouble ahead. This is the self-control version of scope change control. Because team members are close to the action, who knows better than they when things are not happening according to schedule or are about to head in the wrong direction? So encourage your team members to raise the alarm when they recognize a problem. If the project is out of alignment with the scope baseline (there's a variance), then you'll need to determine if a corrective action is required and what that looks like. Scope variances almost always translate to time and cost variances. Not finishing the project on time or on budget does not bode well for project success.

WBS Decomposition

Decomposition is a process. It is the act of breaking down items into smaller pieces. To break down infers this is a top-down process, and that's a good place to start. And at some point, you may want to include some bottom-up processes to confirm all work is included. Start with the outcome in mind. What will you provide to your customer in terms of outcomes or deliverables? If there is more than one, you'll need to go to the next level up so that all are included. I'll give you an example. Let's say your company is relocating. They are consolidating all offices into a single corporate campus. This will be a new build. What is the highest level or outcome of the project? Is it the construction of the new buildings? Is it moving everyone to the new location? This is a trick question. In all likelihood, this is multiple projects within a program. So pick one. Let's go with the construction project. The highest level of the WBS would then be the building Now that we have the outcome, we break it down to the next horizontal level. This level is critical because it sets the tone for all other levels by determining the WBS orientation. (We'll discuss orientations in the next topic section.) The recommendation is to first confirm that 100% of the project and product scope is included in this first level. If we add AA, BB, CC, DD, and EE together, this is 100% of the project (next higher level). Then you'll start breaking down each one to subsequent levels vertically. Each time you break down to another level, 100% of the scope must be included vertically. If we add AAA and AAB (horizontal), this represents 100% of its parent AA (vertical). This is known as the 100% rule. It means you've cross-checked both vertically and horizontally to confirm that 100% of the scope has been included.

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.

Hierarchical Format of WBS

Hierarchy is defined as an "arrangement of things in successive rank or order." This is true with the WBS. Larger deliverables are arranged in successive ranks from largest to smallest. The most common presentation format of the WBS is a tree format. It can also be displayed in an outline format.

Gaining Acceptance

If done right, there should be no surprises at this point. The acceptance criteria were defined and agreed upon during planning. You should also know who will make the decision regarding deliverable acceptability and how the decision will be made. There are only two possible outcomes: Customer accepts with or without exceptions or Customer rejects At the end of each phase, product and project deliverables may be completed and accepted. Accepted deliverables are formally signed off. If unacceptable, then a change request for a defect repair is issued.

How far do you need to decompose each deliverable in the WBS?

It depends. Not every deliverable needs to be broken down to the same number of levels. You need to go as far as you need to go. A WBS is the result of your decomposition efforts. It is a subdivision that 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 shouldn't become an administrative burden.

All Scope of the WBS

It's easy to include all the work associated with the product of the project within the WBS. And yes, that represents the bulk of the work, but it isn't 100%. All scope means including project scope as well.

WBS Myths

Myth #1: The WBS is an input to the scheduling process. 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. Myth #2: The WBS includes activities. Not true. The WBS contains deliverables exclusively. Deliverables are the nouns of your project, and activities are the verbs. If you have activities in your WBS, you need to rethink it and group activities together into a work package deliverable.

Deliverable-Oriented WBS

Only deliverables are included in your WBS. So watch out for naming conventions and make sure they accurately reflect deliverables (nouns) and not activities (verbs).

Accepted Deliverables

Products, results, or capabilities produced by a project and validated by the project customer or sponsors as meeting their specified acceptance criteria. What needs to be done for the customer to accept? The acceptance criteria were determined earlier and documented in the project scope statement. As you identify each deliverable, you must also define all "conditions" or terms of acceptance that have been met. Typically, these are all features, functions, and capabilities that meet quality measures and satisfy customer needs. If you didn't do a good job defining acceptance criteria, then customer acceptance will be challenging. You'll want to include staff and representatives from user groups in planning Validate Scope. They often know best when a project generates acceptable deliverables and when it does not. Their participation is also a great source for enhancement suggestions. Have you ever built something for a customer that was exactly what they asked for but not what they wanted? This happens when there's a disconnect between building it right (Quality Control) and making it acceptable (Validate Scope). On the other hand, just because we didn't build it correctly doesn't necessarily mean it won't be acceptable. Customers accept what's not correct all the time. I'll admit, the defects are often small and are addressed after the fact, but the point is they did accept knowing there were defects. Think about building a new house and the items identified on the punch list to be fixed before closing as an example.

Control Scope Overview

Scope defines the boundaries of the project, and once the boundaries are set, we establish the scope baseline. The goal of the Control Scope process is to monitor project performance and progress against the baseline and keep it in alignment. Piece of cake, right? Not so fast. That's only when everything goes right, and how often does that happen? There are four common situations that occur in almost every project. Once you know and accept this to be true, you'll recognize the need for good scope control. 1. The scope definition was never fully formed in the earliest days of the project prior to planning and execution. The team had to circle back for clarification at some point regarding one or more deliverables or functions. There's just too much ambiguity. 2. The deliverables may have been known, but all the requirements were not fully known down to the level of detail required to build it. And to make the situation worse, there's a breakdown in communication to the team who is supposed to build it, and they don't understand what they are supposed to do. 3. The customer is less than pleased with one or more of the deliverables you built even though you built it exactly the way they told you to. Furthermore, they can't explain to you why they don't like it, and now they don't want to accept the deliverables. 4. You've got some excellent subject matter experts (SMEs) on your team who are perfectionists. Perfectionists like to do more than what is defined in the scope just because, in their opinion, "that's the way it should be done." This is a problem if it isn't what the customer asked for. For one thing, more work costs more money, and the budget will take a hit. The other possible problem is integration issues if what they work on no longer fits with some other deliverable because of the changes they made.

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's a single owner for each work package.

Implementing 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. If the request was to add a new feature, has the new feature been successfully added and integrated? Let me be clear. We never implement change requests that are not approved. Only approved changes can be implemented. So if you see a question on the exam hinting at whether or not a change can be implemented, confirm that it is approved. You'll need to monitor work performance to confirm the associated new work has been done. Variance analysis compares work performance to the current baseline to confirm corrective actions were effective. Trend analysis is also useful to determine if the situation is improving or not. Project documentation is dynamic and requires updating. Changes in scope must be reflected appropriately in all impacted documentation, such as the scope management plan, baselines, and even requirements documentation.

WBS Dictionary

The WBS dictionary is one of the four components that make up your scope baseline. Regardless of the WBS presentation format you use (graphical tree or tabular outline), there's just no room to add any details. That's where the WBS Dictionary comes in. It is the companion document for your work breakdown structure and provides all the details. It is also a required project management artifact because it is one of the four components that make up your scope baseline. Typical information included in the WBS Dictionary includes: 1. An identifier linking it to the work package or control account 2. A description of the work to create the deliverable 3. Schedule and cost estimates for the work 4. Schedule dependencies such as predecessors 5. Team or organization responsible for doing the work 6. Resource information, including team size and skill sets 7. Acceptance criteria for the deliverable 8. Any assumptions or known constraints

Organization of the WBS

The WBS organizes the work of the project in a logical way. This is accomplished in at least two ways: 1. Typically, a WBS is created top-down, so you start with the final goal in mind and then decompose to smaller, more manageable units of work called work packages. 2. The orientation of the WBS (to be discussed later) aligns the work with business or other processes, so it seamlessly flows once embedded in the schedule.

Validate Scope

The focus of the Validate Scope process is taking all actions that lead to customer acceptance of all completed deliverables. The term validate is used intentionally and is not the same as verify. You'll need to know this for the exam. We verify the deliverable is correct and validate that it is acceptable. That means we must first perform quality-control testing before we're ready to have the customer look at it.

Control Scope

The process of monitoring the status of the project and product scope and managing changes to the scope baseline.

WBS Orientations

What is the best WBS orientation? There is not a good answer for this. It depends on how you want to design the project and it depends on your schedule. It also depends on the culture of your organization and the processes that they usually do. Example: You are going to build two widgets. Each widget must be designed then built. Which WBS orientation is best, the one on the left or the one on the right? Answer: The one on the left is oriented by phase, and all the design work will be done before the build work when this WBS is integrated into the schedule. On the other hand, the WBS on the right is product-oriented. All the work for widget A is to be done before work begins on widget B when this WBS is integrated into the schedule. Assuming all the work was included on the WBS, then all the work would be included on the schedule. Orientation determines how easy it will be for you to manage the schedule. You can make more work for yourself if the orientation doesn't align with your company's processes. It's the proverbial square peg in a round hole scenario. It's just harder. You should now have a good grasp of work breakdown structures. Let's summarize the benefits.

What do you need to know about a WBS for the exam?

What you need to know about a WBS: 1. What a WBS is and how is it constructed. 2. Benefits of using the WBS. 3. A WBS is required of every project and is an element of the scope baseline. 4. A WBS is not an input to the scheduling process. 5. A WBS only contains deliverables. 6. You could see questions that probe how you use the WBS in different situations that may occur later in the project, such as addressing change requests or controlling scope creep.

Preventing Scope Changes

You know what's in the scope, and you know what's on the schedule. You communicate with your team constantly about current tasks and the ones next up on the schedule. By reviewing the documentation and requirements prior to work beginning, you'll eliminate many sources of potential scope changes. Set expectations and answer questions before they become issues or problems. 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.