Asking four key questions

Determining how much detail you need isn’t a trivial task. You want to describe your work in sufficient detail to support accurate planning and meaningful tracking. But the benefits of this detail must justify the additional time you spend developing and maintaining your plans and reporting your progress.

Asking the following four questions about each WBS component can help you decide whether you’ve defined it in enough detail:

• Do you require two or more intermediate deliverables to produce this deliverable?
• Can you estimate the resources you need to perform the work to produce this deliverable? (Resources include personnel, equipment, raw materials, money, facilities, and information.)
• Can you accurately estimate how long producing this deliverable will take?
• If you have to assign the work to produce this deliverable to someone else, are you confident that person will understand exactly what to do?

If you answer yes to the first question or no to any one of the other three, break down the deliverable into the components necessary to produce it.

Your answers to these questions depend on how familiar you are with the work, how critical the activity is to the success of your project, what happens if something goes wrong, whom you may assign to perform the activity, how well you know that person, and so on. In other words, the correct level of detail for your WBS depends on your judgment.

If you’re a little uneasy about answering these four questions, try this even simpler test: Subdivide your WBS component into additional deliverables if you think either of the following situations applies:

• The component will take much longer than two calendar weeks to complete.
• The component will require much more than 80 person-hours to complete.

Remember that these estimates are just guidelines. For example, if you estimate that it will take two weeks and two days to prepare a report, you’ve probably provided sufficient detail. But if you think it will take two to three months to finalize requirements for your new product, you need to break the deliverable finalized requirements into more detail because

• Experience has shown that there can be so many different interpretations of what is supposed to occur during these two to three months that you can’t be sure your time and resource estimates are correct, and you can’t confidently assign the task to someone to perform.
• You don’t want to wait two or three months to confirm that work is on schedule by verifying that a desired product has been produced on time.

Making assumptions to clarify planned work

Sometimes you want to break down a particular WBS component further, but certain unknowns stop you from doing so. How do you resolve this dilemma? You make assumptions regarding the unknowns. If, during the course of your project, you find that any of your assumptions are wrong, you can change your plan to reflect the correct information.

Regarding the Training Program Creation and Presentation project example presented previously in this section — suppose you decide that the Completed interviews deliverable from Step 3 needs more detail so you can estimate its required time and resources. However, you don’t know how to break it down further because you don’t know how many people you’ll interview or how many separate sets of interviews you’ll conduct. If you assume you’ll interview five groups of seven people each, you can then develop specific plans for arranging and conducting each of these sessions. In most situations, it’s best to consider a guess in the middle of the possible range. To determine how sensitive your results are to the different values, you may want to analyze for several different assumptions.

Be sure to write down your assumption so you remember to change your plan if you conduct more or less than five interview sessions. See the discussion in Chapter 3 of this minibook for more information about detailing assumptions.

Focusing on results when naming deliverables

Whenever possible, name a deliverable based on the result you need to achieve rather than the activity you need to perform to achieve that result. For example, you might title a deliverable that signifies completion of a needs assessment survey you have to conduct in one of two ways:

• Survey completed
• Needs assessment finished

Both options state that something has been finished. However, although the deliverable Survey completed indicates that a survey was performed, it doesn’t explain what type of information the survey was supposed to obtain or whether it successfully obtained that information. On the other hand, Needs assessment finished confirms that the information from the completed survey successfully fulfilled the purpose for which it was intended.

Using action verbs to title activities

Use action verbs in the titles of activities that make up a work package to clarify the nature of the work the activities entail. Action verbs can improve your time and resource estimates, your work assignments to team members, and your tracking and reporting because they provide a clear picture of the work included in the activities and, thereby, the work packages of which they are a part.

Consider the assignment to prepare a report after a team meeting. Suppose you choose Draft report to be one of its work packages. If you don’t break down Draft report further, you haven’t indicated clearly whether it includes any or all of the following actions:

• Collecting information for the draft
• Determining length and format expectations and restrictions
• Writing the draft
• Reviewing the draft yourself before officially circulating it to others

But if you simply break down the work package into two activities that are titled “Design the draft report” and “Write the draft report,” your scope of work is instantly clearer. A few well-chosen words at this level go a long way.

Developing a WBS for large and small projects

You need to develop a WBS for very large projects, very small projects, and everything in between. Building a skyscraper, designing a new airplane, researching and developing a new drug, and revamping your organization’s information systems all need a WBS. So, too, do writing a report, scheduling and conducting a meeting, coordinating your organization’s annual blood drive, and moving into your new office. The size of the WBS may vary immensely depending on the project, but the hierarchical scheme used to develop each one is the same.

Occasionally, your detailed WBS may seem to make your project more complex than it really is. Seeing 100 tasks (not to mention 10,000) on paper can be a little unnerving! However, the WBS doesn’t create a project’s complexity; it just displays that complexity. In fact, by clearly portraying all aspects of your project work, the WBS simplifies your project.

Check out the sidebar “Conducting a survey using a WBS” for an illustration of how a work breakdown structure helps you develop a more accurate estimate of the time you need to complete your work.

Understanding a project’s deliverable/activity hierarchy

Figure 4-2 shows a portion of the deliverable/activity hierarchy for the project of surveying people to determine the characteristics a new product your organization may develop should have (refer to the nearby sidebar “Conducting a survey using a WBS” for details on this example). As illustrated in the figure, a project’s deliverable/activity hierarchy is comprised of three types of components:

• Deliverables: Intermediate or final products created during the performance of the project (see Chapter 3 of this minibook)
• Work packages: Deliverables at the lowest point in each branch of the hierarchy that can be further subdivided into activities
• Activities: Work that’s performed to produce a deliverable

The WBS is the portion of the hierarchy that contains the deliverables (from the topmost level down to and including all work packages) that will be produced during the project. The activities that make up the work packages are recorded in a comprehensive activity list. While not considered to be part of the WBS, each activity is a component of a work package, so you need to identify it as such. (For convenience, you should include activities in the WBS dictionary under the work package to which they relate; see the later section “Documenting Your Planned Project Work” for details on the WBS dictionary.)

Representing conditionally repeating work

Suppose your project contains a deliverable (such as an approved report) that requires an unknown number of repetitive cycles (such as reviewing and revising the latest version of the draft report) to produce, each of which generates at least one intermediate deliverable. In reality, you write the report and submit it for review and approval. If the reviewers approve the report, you obtain your deliverable of an approved report and proceed to the next phase of your project (such as a distributed report). But if the reviewers don’t approve the report, you have to revise it to incorporate their comments and then resubmit it for a second review and approval. If they approve the second draft, you obtain your deliverable of an approved report and proceed to the next phase of your project. But if they still don’t approve your report, you have to repeat the process (or try to catch them in a better mood).

Revising the draft is conditional work; it will be completed only if a certain condition (in this case, not receiving the reviewers’ approval) comes to pass. Unfortunately, a WBS doesn’t include conditional work; you plan to perform every piece of work you detail in your WBS. However, you can indirectly represent conditional work in the following two ways:

• You can define a single deliverable as an Approved report and assign it a duration. In effect, you’re saying that you can create as many Reviewed but not approved versions of the report as necessary (each of which is an intermediate deliverable) to obtain the final reviewed and approved version within the established time period.
• You can assume that you’ll need a certain number of revisions and include the intermediate deliverable created after each one (a different Reviewed but not approved version of the report) in your WBS. This approach allows more meaningful tracking.

Whichever approach you choose, be sure to document it in your project plan.

Assuming that your project needs three reviews and two revisions doesn’t guarantee that your draft will be good to go after only the third review. If your draft is approved after the first review, congratulations! You can move on to the next piece of work immediately — that is, you don’t perform two revisions just because the plan assumed you would have to!

However, if you still haven’t received approval after the third review, you continue to revise it and submit it for further review until you do get the seal of approval you need. Of course, then you have to reexamine your plan to determine the effect of the additional reviews and revisions on the schedule and budget of future project activities.

A plan isn’t a guarantee of the future; it’s your statement of what you will work to achieve. If you’re unable to accomplish any part of your plan, you must revise it accordingly (and promptly).

Handling work with no obvious break points

Sometimes you can’t see how to break a piece of work into two-week intervals. Other times that amount of detail just doesn’t seem necessary. Even in these situations, however, you want to divide the work into smaller chunks to remind yourself to periodically verify that your current schedule and resource estimates are still valid.

In these instances, arbitrarily define intermediate milestones to occur every two weeks that are defined as “progress confirmed as being on schedule” or “expenditures confirmed as being on budget.” Check out the sidebar “Keeping a close eye on your project” for an illustration of why it’s important to have frequent milestones to support project tracking and how to deal with WBS components that have no obvious break points.

Planning a long-term project

A long-term project presents a different challenge. Often the work you perform a year or more in the future depends on the results of the work you do between now and then. Even if you can accurately predict the work you’ll perform later, the further into the future you plan, the more likely it is that something will change and require you to modify your plans.

When developing a WBS for a long-term project, use a rolling-wave approach, in which you continually refine your plans throughout the life of your project as you discover more about the project and its environment. This approach acknowledges that uncertainties may limit your plan’s initial detail and accuracy, and it encourages you to reflect more accurate information in your plans as soon as you discover it. Apply the rolling-wave approach to your long-term project by taking the following steps:

• Break down the first three months’ work into components that take two weeks or less to complete.
• Plan the remainder of the project in less detail, perhaps describing the work in packages you estimate to take between one and two months to complete.
• Revise your initial plan at the end of the first three months to detail your work for the next three months in components that take two weeks or less to complete.
• Modify any future work as necessary, based on the results of your first three months’ work.
• Continue revising your plan in this way throughout the project.

No matter how carefully you plan, something unanticipated can always occur. The sooner you find out about such an occurrence, the more time you have to minimize any negative effect on your project.

Issuing a contract for services you will receive

Generally speaking, you use a WBS that you include in a contract for services to be provided to you by another person or organization differently from the way you use one to guide project work that you or your organization performs itself. When you perform the project yourself, the WBS provides the basis for developing detailed project schedules, estimating personnel and other resource requirements, detailing the project roles and responsibilities of project team members, and assessing all aspects of the ongoing work. However, when you manage a contract with an external organization that’s performing the project for you, you use the WBS to

• Support responsive progress assessment to help ensure that the overall project is on track to finish on time and within budget.
• Provide the contractor with a framework for tracking and reporting periodic assessments of project schedule achievement and resource expenditures.
• Confirm that product, schedule, and resource performance is sufficient to justify the making of scheduled progress payments.

In addition, you don’t want the WBS to unduly restrict the contractor’s ability to use his experience, skills, and professional judgment to achieve the results detailed in the contract. Typically, developing the WBS to two or three levels of detail is sufficient to meet the preceding needs without creating unnecessary restrictions.

The top-down approach

Use the following top-down approach for projects that you or others are familiar with:

1. Specify all Level 2 components for the entire project.
2. Determine all necessary Level 3 components for each Level 2 component.
3. Specify the Level 4 components for each Level 3 component as necessary.

4. Continue in this way until you’ve completely detailed all project intermediate and final deliverables.

   The lowest-level components in each WBS chain are your project’s work packages.

The brainstorming approach

Use the following brainstorming approach for projects involving untested methods or for projects you and your team members aren’t familiar with:

1. Identify all the intermediate and final deliverables that you think your project will produce.

   Don’t worry about overlap or level of detail.

   Don’t discuss wording or other details of the work items.

   Don’t make any judgments about the appropriateness of the work.

2. Group these items into a few major categories with common characteristics and eliminate any deliverables that aren’t required.

   These groups are your Level 2 categories.

3. Divide the deliverables under each Level 2 category into groups with common characteristics.

   These groups are your Level 3 categories.

4. Use the top-down method to identify any additional deliverables that you overlooked in the categories you created.

5. Continue in this manner until you’ve completely described all project deliverables and work components.

   The lowest-level components in each WBS chain are your project’s work packages.

The organization-chart format

Figure 4-7 shows a WBS in the organization-chart format (also referred to as a hierarchy diagram or a graphical view). This format effectively portrays an overview of your project and the hierarchical relationships of different WBS components at the highest levels. However, because this format generally requires a lot of space, it’s less effective for displaying large WBSs.

The indented-outline format

The indented-outline format in Figure 4-8 is another way to display your WBS. This format allows you to read and understand a complex WBS with many components. However, you can easily get lost in the details of a large project with this format and forget how the pieces all fit together.

Both the organization-chart format and the indented-outline format can be helpful for displaying the WBS for a small project. For a large project, however, consider using a combination of the organization-chart and the indented-outline formats to explain your WBS. You can display the Level 1 and Level 2 components in the organization-chart format and portray the detailed breakout for each Level 2 component in the indented-outline format.

The bubble-chart format

The bubble-chart format in Figure 4-9 is particularly effective for displaying the results of the brainstorming approach to develop your WBS for both small and large projects (see the earlier section “The brainstorming approach”). You interpret the bubble-chart format as follows:

• The bubble in the center represents your entire project (in this case, Report).
• Lines from the center bubble lead to Level 2 breakouts (in this case, Draft Report, Reviews of Draft, and Final Report).
• Lines from each Level 2 component lead to Level 3 components related to the Level 2 component. (In this case, the Level 2 component Final Report consists of the two Level 3 components Typed Final Report and Printed Final Report.)

The freeform nature of the bubble-chart format allows you to easily record thoughts generated during a brainstorming session. You can also easily rearrange components as you proceed with your analysis.

The bubble-chart format isn’t effective for displaying your WBS to audiences who aren’t familiar with your project. Use this format to develop your WBS with your team, but transpose it into an organization-chart or indented-outline format when you present it to people outside your team.

Drawing on previous experience

By drawing on previous experience, you can prepare your WBS in less time than it takes to develop a new WBS and be more confident that you’ve included all essential pieces of work.

Suppose you prepare your department’s quarterly budget. After doing a number of these budgets, you know most of the work you have to perform. Each time you finish another budget, you revise your WBS template to include new information you gleaned from the recently completed project.

The next time you start to plan a quarterly budget, begin with the WBS template you’ve developed from your past projects. Then add and subtract elements as appropriate for this particular budget preparation.

Improving your WBS templates

The more accurate and complete your WBS templates are, the more time they can save on future projects. This section offers several suggestions for continually improving the quality of your WBS templates.

When using templates, keep in mind the following guidelines:

• Develop templates for frequently performed tasks as well as for entire projects. Templates for the annual organization blood drive or the submission of a newly developed drug to the Food and Drug Administration are valuable. So are templates for individual tasks that are part of these projects, such as awarding a competitive contract or having a document printed. You can always incorporate templates for individual pieces of work into a larger WBS for an entire project.
• Develop and modify your WBS template from previous projects that worked, not from initial plans that looked good. Often you develop a detailed WBS at the start of your project, but you may forget to add intermediate or final deliverables that you overlooked in your initial planning. If you update your template from a WBS that you prepared at the start of your project, it won’t reflect what you discovered during the performance of the project.
• Use templates as starting points, not ending points. Clarify to your team members and others involved in the project that the template is only the start for your WBS, not the final version. Every project differs in some ways from similar ones performed in the past. If you don’t critically examine the template, you may miss work that wasn’t done in previous projects but that needs to be done in this one.
• Continually update your templates to reflect your experiences from different projects. The post-project evaluation is a great opportunity to review and critique your original WBS. At the end of your project, take a moment to revise your WBS template to reflect what you found.