DB

Welcome to week 5! You’ve probably noticed that, as we move through the course, we’re encountering more and more of the “typical project management” processes with which you’re already familiar. This may be because, while we spent the first 3 weeks focused on identifying the “what” of our project (the business case, business requirements, and solution requirements), since last week we have begun to focus more on the “how” (how we will ensure our requirements will be met.) And, as we discussed in course week 2, project management often first focuses on “how” to deliver a project successfully so as we discuss traditional project management deliver a project successfully, so as we discuss traditional project management deliverables like last week’s scope statement, we find ourselves on more familiar ground.

This week continues that progression. This week, we’ll be analyzing a planning tool that should already be familiar to you: the work breakdown structure (WBS.) To ensure we don’t forget about our business and solution requirements while ensure we don t forget about our business and solution requirements while developing this WBS, however, we’ll also discuss what may be new tool to you: a traceability matrix.

1

Our learning objectives this week are a combination of old and new. Since you’ve already been introduced to the concept of a work breakdown structure in your previous courseware, we’ll briefly review some of the important features, concepts, and terms associated with creating a WBS. We’ll spend more time discussing different options for creating a WBS (the concept is easy to understand; the implementation can be more challenging!) And finally, we’ll look at how to use a Traceability Matrix to ensure everything in our WBS does in fact link back to at least one solution and business requirement one solution and business requirement.

2

Before getting into this lecture further, it’s suggested you take a first pass at the required reading for this week, as listed above. Although this looks like a lot of reading, know that the Practice Standard for Work Breakdown Structures is a fairly short document to read. You’ll find chapters 2-5 to be the most descriptive, and appendices D, E and F show you different WBS examples.

3

Before we review the details about work breakdown structures, it’s critical to remember that a WBS is not built from scratch. Many times, project teams are given a high-level project description and immediately get to work planning tasks, durations, and resources – without the benefit of familiarizing themselves with the larger goals and history of the project first. Since a project team is often not present during the project initiation phase (and sometimes not even heavily involved in requirements collection), it’s not a given that the project team already knows why a project is being undertaken project is being undertaken.

Ideally, a WBS draws directly from all the scope-related documentation that preceded it, including the business case (or project charter, which reflects the approved business case.) A well-built WBS considers both business and solution requirements as specific tasks are planned. If a WBS does not draw from pre- defined requirements then the chance a project team will create a well-structured defined requirements, then the chance a project team will create a well-structured WBS that doesn’t meet larger needs is fairly high. (This is how many projects are delivered on time, and within schedule, but don’t satisfy the original reasons for which the project was undertaken and therefore are still considered failures.)

Since your written assignment this week is to create a WBS for your individual case study project the lesson from this slide is to review the requirements both

4

study project, the lesson from this slide is to review the requirements – both business and solution requirements – you created in previous homework assignments and use those requirements to help you determine the tasks (and structure) your WBS needs.

In the project planning process, WBS creation marks a significant shift in thinking. Previous deliverables, such as the business case, requirements documentation, and the scope statement focus on clearly stating the “problem to be solved” and identifying high-level solution features. None of these deliverables are task oriented (nor should they be.)

Project teams, however, are assigned to tasks: actions, steps to be taken, processes to complete. Teams don’t complete requirements; they complete tasks that lead to satisfied requirements. This means, for each requirement, we need to determine the tasks that must be undertaken in order to satisfy that requirement. We literally need to divide the work needed to satisfy requirements among project resources, and we need to do this in a way that is clearly understand by everyone who will work on the project so that no tasks are duplicated and none are left out.

In other words, we need to translate requirements (both business and solution requirements) into a more detailed, working, team-oriented action plan where similar activities are grouped together for easier project scheduling, budgeting, and control. This more detailed picture of the project is what’s known as a work breakdown structure, or WBS.

5

Here’s a review of the formal definition of a WBS from the PMBOK® Guide, and of course you’ve seen different examples of a WBS in your previous coursework so the idea of a “hierarchy” (organizing tasks from less detail at high levels to more detail at lower levels) should be familiar to you.

The most important characteristic of a WBS, however, is the boundary it maintains around a project’s scope: all project work that helps fulfill requirements – and only work that helps fulfill requirements - should be captured in a WBS. In other words, if a task isn’t contained within a project’s WBS, it’s not considered part of the overall project scope and shouldn’t have resources, time, or money assigned to it.

6

The idea of a WBS is an easy one to understand: it’s a map of all project tasks, divided into logical i k b b d h d h S l k j lik categories so work can be better managed. When drawn as a graph, a WBS looks just like an

organization chart, with the same relationship structure: the overall project is represented at the top of the chart, and then all the work associated with completing that project is next broken into large, general categories.

Next, each general work category is further broken down into smaller amounts of work. The idea d f ll f k l h f dto is continue identifying increasing smaller amounts of work until the specific duration, resources

needed, and cost associated with a task can be reliably estimated. The lowest level of a WBS – that smallest piece of work that has a defined duration and cost – is referred to as a “work package”.

When describing the relationship between tasks, the analogy between a WBS graph and a family tree is apt: any task that has smaller tasks underneath it is referred to as a “parent” task. Conversely, any task that has a larger task above it is referred to as a “child.” Each time we create smaller tasks underneath larger ones, we add a “level” to the WBS. The highest level of a WBS, the overall project, is referred to as “level 1.” The general categories created directly underneath the overall project are referred to as “level 2”, and so on.

Conceptually, understanding the basic idea of the WBS is not challenging. What’s often difficult

7

about creating a WBS is deciding what categories to use to initially break down all the work required for a project: what categories to create for “level 2.” Some WBS’ break down project work according to major outputs (deliverables); others break down project work according to chronological sequence (phases.) What categories we use for dividing the overall project is referred to as the WBS’ framework. Let’s look at some examples on the next few slides.

This slide shows an example of a WBS organized by project deliverable, meaning that the second level of the WBS reflects categories of outputs. For example, if the primary output of our project is a house (WBS level 1, in the example above), the major deliverables associated with building that house can be organized according to the room of the house being constructed (in this case, the house has a kitchen, bathrooms, landscaping, a garage, and bedrooms – these categories form “level 2” of this example WBS.)

There are also, of course, tasks that must be completed within each room, and some of those deliverables are also noted here. As we discussed on the previous slide, each room of the house (“kitchen”, “bathrooms”) is considered a “parent” task, with the tasks associated with that specific room are “children” (example: “kitchen” is the parent task; “cabinets” is a child task.)

This example WBS has a total of 3 levels, including the overall project task entitled “house.” “House” is level 1; “shrubs” (within the landscaping task) is level 3. (Other tasks associated with “landscaping”, such as “grass” and “inspection” are not lower levels; they are the same level as “shrubs.” If we were comparing this WBS to a family tree, think of “grass”, “shrubs” and “inspection” as siblings.) We’ll examine how to determine how many levels a WBS should contain but for now know that

8

how to determine how many levels a WBS should contain, but for now, know that there is no prescribed number of levels for a WBS – each WBS is built differently according to project type and complexity.

While many WBS’ are organized by deliverable, as we saw on the previous slide, sometimes using the phases in which a project will be completed is a more logical way of breaking down work. The example above shows the same project reflected on the previous slide (constructing a house), but instead of organizing project work by deliverables (the rooms of the house), this WBS is organized by phases: plan, construction, and inspection.

Note that, once the work has been divided into phases in WBS level 2, the next WBS level reflects major deliverables (the kitchen and the bathroom. “Landscaping”, “garage”, and “bedrooms” also belong to this example WBS but have been omitted here for brevity.) This is a common pattern: if we organize our WBS by deliverable (level 2 reflect major deliverables), the next level (level 3) will often reflect phases – notice that “inspection” was a level 3 task on the previous slide. If, however, we organize our WBS by phase the next level will often reflect deliverables organize our WBS by phase, the next level will often reflect deliverables.

In other words, the content of a WBS is nearly always the same regardless of how we organize it. Using the example above, the tasks associated with building a house will be the same set of tasks whether organized by phase, by deliverable – or by some other framework. What does it matter, then, how we choose to organize a WBS? Remember the purpose of creating a WBS: to organize all project work in such a way

9

Remember the purpose of creating a WBS: to organize all project work in such a way that it is clearly understood and manageable by the people who will work on the project. A WBS framework needs to be created in the way that reflects the clearest way the people working on a project can understand it.

Following the discussion from the previous slide, a WBS framework is as much a reflection of the people who will work on a project as the tasks required to complete the project. What constitutes a “logical” framework depends on what the people working and monitoring a project believe is “logical.”

Will the work on a project be divided between different departments or skill sets (engineering, design, project management, electrical, plumbing?) Then it might make the most sense to divide project work according to those departments.

Is the project work driven by major milestones or events (initial plan, first prototype, final product?) To make overall planning and monitoring of project status easier, we might want to create a WBS that is organized by these major milestones.

In organizations where the basic project management processes are well-recognized, we might even want to divide project work into the 5 project management process groups (initiating, planning, executing, monitoring and controlling, and closing.)

Choosing a WBS framework depends on many environmental (and organizational cultural) f t th i i l t f k t S l th WBS t ll j t

10

factors – there is no single correct framework to use. So long as the WBS captures all project work to be completed, and is able to be clearly understood and monitored by those working on the project, then the WBS is “correct.”

Another important administrative item to remember in creating a WBS is to assign each WBS component a unique numeric identifier. Each WBS component is numbered so that the component can be referred to easily. Although this seems unnecessary in a small WBS, most WBS’ quickly become too large to refer to each component by name without becoming confusing. Also, the name of a task might appear more than once in a WBS: using the “house” example we saw on previous slides, the task “inspection” occurred in each room of the house. Without uniquely numbering each WBS component, it would be difficult to know which “inspection” task we were referring to.

WBS components are not numbered randomly; the numbers reflect each component’s relationship to others within the WBS. The highest level of a WBS, the overall project, is often assigned the number “1.” Some WBS’ do not assign numbers to the overall project level (level 1) but instead begin assigning numbers at WBS level 2; in this class we’ll assign a WBS number to the overall project level for discussion purposes.

Each time we add a level to the WBS, we add a decimal point to the number of the previous level. For example, if the overall project is assigned the number 1, level 2 tasks would begin with the number 1.x. The first level 2 component would be numbered 1.1, the second level 2 component would be numbered 1.2, and so on, until all level 2 components were numbered.

Using the same logic, level 3 tasks would reflect the same WBS number as the task above it (the

11

“parent” task), and add a decimal point. Child tasks within task 1.2, for example, would be numbered 1.2.x (1.2.1, 1.2.2, 1.2.3, etc.)

You can also see a graphic of this numbering concept in the WBS Practice Standard text on page 11. The collective set of WBS numbers is sometimes referred to as the WBS “code of accounts.”

Now that we’ve reviewed the basic WBS concept and options for different frameworks, let’s p p , examine the individual levels a WBS contains. The graphic above shows a 4-level WBS, with level 2 reflecting major deliverables. Those deliverables are then divided into increasingly smaller amounts of work. The act of breaking up deliverables (or phases) into increasingly smaller parts is known as “decomposition.”

At the top of the WBS, we start with the highest level of all: the project’s name. This is nothing p , g p j g more than a brief description of what we call the project.

As previously mentioned, the second level of a WBS reflects general work categories and is often the most difficult to define. Level 2 reflects either major deliverables, project phases, organizational departments, or another “most logical” framework.

The third level of a WBS divides the category we identified in the second WBS level into the individual deliverables required.

We continue breaking our project pieces into increasingly smaller parts, and stop when we have a description of work small enough to determine a budget and schedule for. This smallest

12

component is the “work package”, and may contain one or more tasks. This may be at the third, fourth, eleventh, or another level of the WBS – no two WBS are exactly the same.

Determining the “correct” number of WBS levels is a challenging part of building a WBS, because the number of WBS levels appropriate for your project is influenced by several things. As you might imagine, the more complex your project, the more tightly you’ll want to manage it, and more levels and breakouts will be required. On the other hand, if the project is relatively simple, or if you’re working with a project team you’ve worked with before and who knows each other well, such detail may constitute micromanagement.

As a general guideline, more WBS levels are appropriate for projects with tight budgets and schedules; new clients (or new senior management); new project teams; or projects that are exceptionally risky for other reasons. As projects become more familiar and less complex, fewer levels are required.

It’s acceptable to modify WBS levels as you go (so long as you’re not changing the project’s p y y g g y g g p j scope in the process.) Keep in mind it is always easier to collapse the number of WBS levels if a project is running smoothly and combining tasks for management purposes makes sense. It’s very challenging, however, to add levels to a WBS (to create additional sub-tasks to manage) – so if you’re unsure, it’s often best to err on the side of caution and create a WBS component for each part of the project that seems to require specific oversight.

13

When developing a WBS, we generally have two choices for physically creating it: a hierarchical view and a line-item view. This slide depicts a hierarchical view WBS, which has both advantages and disadvantages.

The primary advantage of a hierarchical view is it’s easy for someone to read and immediately understand the relationships between categories, deliverables, and work packages. Not much explanation is needed. If space is available, a hierarchical WBS chart is a great item to display in a project team’s war room, or as a wall chart in the project manager’s workspace.

This view has its drawbacks, however. First, it is harder to physically update – anyone wanting to update the chart must know how to use the “organization chart” features in MS Office or other desktop software applications. Second, anyone p pp y viewing the chart electronically must have software that allows them to do so. This may not be a significant restriction if the project team is largely office-based, but teams that contain large “field” components may find viewing the WBS more difficult.

14

Another common WBS view is known as a “line item” view. If you’ve worked in most project management software applications (such as MS Project), the display on the slide above probably looks familiar to you.

This is an easy format to print, copy, and export into multiple software applications. It’s also easier to update than a hierarchical view can be.

On the other hand, it’s much harder for the average reader to see and understand the relationships between project deliverables and different project phases. A line item view particularly shows the value of using a WBS code of accounts, since the WBS component numbers easily show relationships between tasks.

15

Now that we’ve reviewed the basic WBS concepts (and a few considerations in building one), let’s formally review the “create WBS” process as shown above formally review the create WBS process, as shown above.

As mentioned at the beginning of this lecture, when beginning to create our WBS there are a number of documents to help us, as described above: the scope statement , requirements documentation, and even the business case or approved business case, otherwise known as the project charter. (Why aren’t the business case and project charter reflected here? Because the assumption is that the business requirements identified in the business case and project charter have been carried into the scope statement.)

Note also that – if we’re fortunate – our organization may already have a standard WBS framework it uses (by deliverable, by phase, by organizational department, etc.) It may even have an archive of WBS’ created for previous, similar projects, which can help determine how future WBS’ should be created. These examples and organizational best practices are the “organizational process assets” identified here.

Decomposition is the principal activity used to turn the scope statement into a WBS. As we’ve discussed, creating the appropriate level of detail in a WBS isn’t easy (too little detail and future , g pp p y ( planning is difficult; too much detail and effective management is difficult), and may require adjustment as the project progresses. Adjusting the WBS mid-project is perfectly acceptable. Because the WBS, like the scope statement, is intended to capture and manage a project’s scope (which can change continuously), the WBS is a living document.

Changing the level of detail in a WBS is one thing. Changing the content of a WBS – that is, adding or deleting work packages or deliverables – is another. If you find yourself changing the WBS to match the project, realized you’ve just changed the project’s scope (and likely the schedule and budget), and

16

the project, realized you ve just changed the project s scope (and likely the schedule and budget), and the scope of your project is “creeping” outside its original boundaries.

Change all your scope documents deliberately, BEFORE the change is implemented instead of afterward. If you have changes that should be added, ensure those changes have been approved by the client, are understood by the project team, and are within the project’s schedule and budget. We’ll examine specifically how to control changes to project scope as our final topic in the course, next week.

The primary output of the WBS creation process isn’t just the WBS it’s the total The primary output of the WBS creation process isn t just the WBS, it s the total expression of all planned project scope to date, otherwise known as the scope baseline. The scope baseline forms a reference point for subsequent project planning deliverables, particularly the project’s schedule and budget. The scope baseline also provides a starting point for the beginning of the project execution phase. It can then be used for comparison purposes as the project progresses, to see how much the scope has changed over time.

Finally, it’s very common for the WBS decomposition process to highlight a number of items that were overlooked in the scope statement and requirements definition process. As a result, we may decide to change our policies, pre-defined scope management process, and the project scope itself based on additional information brought out by the WBS’ creation. These changes would require updates to the other project documents, perhaps including the solution requirements themselves, the project cost baseline, or the project g q p j p j schedule.

17

Once an initial WBS is created, it’s important to ensure all WBS components do in fact directly contribute to satisfying one or more solution requirements (which, in turn, satisfy larger business requirements.) Since most projects do not have unlimited resources, we want to ensure that resources are spent only on tasks that can be linked to at least one solution requirement, and that no tasks are unnecessary redundant.

A traceability matrix is a table that links each individual requirement collected in the requirements collection process to one or more WBS components. Requirements form the rows of the table; features associated with that requirement (such as the stakeholder source of the requirement, the associated WBS component, or even how the requirement will be tested or inspected for completion) form the columns. Know that the columns used in a traceability matrix can vary from project to project as appropriate, and the example provided here is a fairly high-level matrix (but prior traceability matrices may provide strong or poor examples of what best fits an organization or a particular project type ) what best fits an organization or a particular project type.)

Similar to the “code of accounts” numbering used within a WBS, it’s often a good idea to assign each requirement a unique identifier (such as a number or letter) and describe the nature of the requirement as well – it’s even possible to combine numbering systems between business requirements, solutions requirements, and WBS components to really show links between each area Numbering requirements within a traceability matrix can then also provide a quick

18

area. Numbering requirements within a traceability matrix can then also provide a quick summary of what requirements should be contained in the project and the status of those requirements. Finally, because traceability matrices are created using a table format, they can also be sorted and filtered to show only certain project phases, requirements groups, or task areas.

You may have noticed that the traceability matrix is NOT an output of the WBS creation process. In fact, it’s considered an output of the “collect requirements” process we discussed in course weeks 2 and 3. Why didn’t we discuss it then?

It’s true the best time to begin creating a traceability matrix is while solution requirements are being documented, to ensure that each solution requirement can be traced to a business requirement. Many times, however, traceability matrices focus only on requirements, which still leaves a project open to the possibility that specific tasks – like those identified during WBS creation – won’t also link to solution and business requirements. It’s therefore a good idea to continue populating a traceability matrix as the WBS is built, to create a complete link between business requirements, solution requirements, specific tasks, and – since the WBS is the basis for project scheduling and planning – the project schedule and budget budget.

19

This concludes the lecture for lesson 5. The WBS is a simple concept to understand, but a tricky one to implement, as you’ll undoubtedly remember as you create a WBS for your written assignment this week. Note that your WBS must be created using MS Project. You’ll need to develop a traceability matrix as part of your assignment as well (the traceability matrix can also be created using MS Project or you may use another format of your choosing.) You may use the high-level traceability matrix example contained in this week’s lecture materials (on previous slides), or you may create your own create your own.

As a note, expect that creating the traceability matrix will require some real thought: while there are several examples available online, many are structured for software development projects (finding exactly the traceability matrix that suits your project is unlikely. You’ll probably need to develop your matrix from multiple sources…and a bit of trial and error So give yourself some time for this one!)a bit of trial and error. So give yourself some time for this one!)

You’ll then move on to your discussion board assignment, where we’ll debate the merits of different WBS’ frameworks and how to make creating one a bit easier.

Just one week to go!

20

g