What Are the Inputs to Risk Management Planning?

In his famous book, "Poor Richard's Almanac," Benjamin Franklin wrote, "An ounce of prevention is worth a pound of cure." What might this mean in the context of risk management planning?

Prevention seems like a common sense idea, but achieving it does require some thought. Remember that projects are often long and complex and that they involve large amounts of money and other resources. Therefore, it's important to plan your risk management approach so that an "ounce" of risk prevention is in place.

You will use several different types of information and documents as inputs when planning for the management of your project's risks. The inputs used in risk management planning are the:

• project charter and work breakdown structure (WBS)
• organization's risk management policies
• defined roles and responsibilities
• template for the organization's risk management plan
• stakeholder risk tolerances.

The project charter and the WBS are key documents you use when planning risk management activities. Some of these activities are budgeting, scoring and interpretation, and tracking.
The project charter is a document that formally authorizes a project. It includes the business need that the project is undertaken to address.

The WBS is a deliverable-oriented grouping of project components that organizes and defines the total scope of the project.

When it comes to an organization's risk management policies, every organization is different. Some organizations have predefined approaches to risk analysis and response that need to be tailored to match individual projects that are carried out by the organization. It is your responsibility to know whether or not your organization has these predefined approaches. If it does, you need to make sure that you tailor and apply the predefined approaches to risk analysis and response to the project you are managing.

Another input to effective risk management planning is the defined roles and responsibilities. These include the predefined roles, responsibilities, and authority levels of the people that will influence project planning.

Templates for the organization's risk management plan are used as a format for creating the risk management plan. Many organizations have developed templates that are also known as pro-forma standards. Project team members adapt the template to their current project. Companies continuously improve the template based on its application and usefulness to the project.

The final input to risk management planning is stakeholder risk tolerances. Different organizations and different individuals have varying tolerances for risk. These tolerances may be expressed in policy statements or in actions.

The starting point of any risk management planning process must include inputs. Without them, the effect of your risk management planning would be like trying to take medicine from an empty bottle: no inputs, no positive benefits. Understanding the inputs used in planning risk management activities is basic to a sound project management approach at any level of expertise.

Identifying Your Project Staffing Needs

People make or break a project. That's why, as a project manager, it is important to carefully plan your project staffing needs. You need to choose people with the right competencies and personalities if you want your project team to work well together and to be capable of getting the job done.

Selecting the right people for your project begins with a staffing requirement plan. Staffing requirements are created using the project's Work Breakdown Structure (WBS) and Skills Inventory Matrix.

Work Breakdown Structure (WBS)
The first step in determining your staffing requirements is to choose people with the right competencies. The WBS details the competencies you need to complete your project. A WBS is the organization of a project into a group of deliverables that defines the project scope.

Project managers complete all phases of the WBS. These phases are:

• identifying the major work assignments for the project
• breaking down each work assignment into tasks
• matching competencies to tasks.

When it comes to matching competencies to tasks, you need to consider both objective and subjective criteria. Objective criteria may include: technical ability, level of proficiency, project management skills, and previous experience as a leader.
Subjective criteria may include: social skills, opinions of fellow project managers, and opinions of co-workers.

Skills Inventory Matrix
After using the WBS, objective and subjective criteria to select the members of your team, you need to assign tasks based on team member competencies. A Skills Inventory Matrix is ideal for this purpose.

A Skills Inventory Matrix allows you to see all the competencies within the project team. The matrix can be created using a simple table. In the first column on the left, list each team member. In the columns to the right, list the competencies required to complete the project. If an employee has a particular competency, place a checkmark in the table cell corresponding to their name and the competency.

A WBS and a Skills Inventory Matrix help you to determine your staffing needs. These inputs ensure that you know which competencies and people you need, as well as what the time frames are for your project.

To ensure the timely completion of your project, you need to match people to competencies and competencies to tasks. A project manager is more likely to have success when all of these staffing requirements are in place.

Four Inputs to Project Cost Budgeting

You will want to enter the cost budgeting phase of a project well-equipped. To do this, you will need to know what the inputs to cost budgeting are, and you should understand their importance to the budgeting process.

During cost budgeting, a number of project elements come together to form the project's cost baseline. The following four inputs are used in the cost budgeting process.

1. The project's work breakdown structure (WBS)
The project's work breakdown structure is important in cost budgeting because it organizes all project activities into work packages. Cost budgeting involves assigning a budget, or cost account, to each work package.

Can you imagine trying to assign budgets to project elements if the work was not organized in some way? Without reference to the WBS, vital costs may be overlooked. Any omissions would cause variances later on between planned and actual costs, and cost performance may be reported as "poor."

Part of creating the work breakdown structure is assigning accounting codes to project tasks and activities based on the organization's chart of accounts. Budgeting is simplified when the cost accounts are integrated in this way.

2. The cost estimates for the work
You have made predictions about the costs of the resources required to complete your project's activities. These cost estimates are another important input to cost budgeting.

The budget for each work package is based on the estimates you have prepared. For budgeting purposes, you should be using budget or control estimates with a range of 15 percent or better. The budgeting process may increase an estimate's range by adding an appropriate allowance or contingency to cover the risk of overruns.

3. The project schedule
The third input to cost budgeting is the project schedule. In fact, it is the application of the schedule to the project budget that produces your main tool for cost control: the project's cost baseline.

Once budgets have been assigned to work packages, use the schedule to distribute the predicted costs over time. The project schedule includes the expected start and finish dates for each activity to which costs will be allocated. This information is important to the cost budgeting process because allocated funds must be assigned to the time period in which the costs will be incurred.

As you develop the control budget for your project, you'll find that a bar-chart diagram can be useful. Use it to measure the total costs that fall within each week for planning or comparative purposes. You can easily measure the cumulative costs as the project progresses.

Time-phasing the budget in this way provides the project's cost baseline. Information about cumulative costs over time is also used to determine the project's "burn rate"—that is, the rate at which funds are expended.

4. The risk management plan
Finally, the risk management plan is an important input to cost budgeting. It outlines strategies for dealing with potential risks that could cause project cost overruns. It also can include cost contingencies that are based on the reliability of your cost estimates. You will build contingencies into the budget to compensate for potential cost overruns.

An accurate and appropriate budget is one of a project manager's greatest assets when it comes to cost management. Understanding the inputs to cost budgeting will help you to create such a budget.

Using Bottom-up Cost Estimating

If you were to begin your project cost estimates at the very lowest level of your work breakdown structure and then "roll them up" through the project to finally arrive at total estimated costs, you would be performing a bottom-up estimate. You will want to use this type of cost estimating when the following conditions exist.

1. You have enough detail about the project.
The accuracy of a bottom-up estimate is driven by the level of detail it contains. This technique relies heavily on a well-decomposed work breakdown structure (WBS). Low-level activities should include a list of required resources, resource rates, and activity duration estimates.

If you do not have specific information about your project at the outset, either choose another estimating technique or be prepared to revise your estimates as the project progresses and more information becomes available.

2. You have the time necessary to use this technique.
Your project team is starting a new project. There is a lot of detail in the WBS, so the bottom-up technique is an option. Now you have to make sure that you have budgeted sufficient time to produce the estimates.

Why does bottom-up estimating take more time to perform than other cost estimating techniques? It takes time to calculate costs for every activity and every resource, especially for large and complicated projects. Unique projects may require you to research prices and dig for rates.

3. You require a high degree of accuracy.
Bottom-up estimating is perhaps the most time- and labor-intensive way to estimate project costs. The "up side," however, is the high degree of accuracy you obtain using this technique. No other estimating technique enables you to better narrow down your range of possible results than this one.

Bottom-up estimates are generally considered to be accurate within five percent to 10 percent. They can be used as "control" estimates, meaning they are used during the cost control process to measure cost performance once actual costs are known.

4. You have little historical information upon which to base cost estimates.
There is a final type of project that would call for the bottom-up cost estimating technique: one for which there is little or no historical information. There are several reasons why you would not find historical information, including cost estimates, from other projects.

• Your project is unique. You may have a project that is unlike any that has gone before, and there are no similar projects upon which to base your cost estimates. Perhaps you are working in an emerging field or discipline for which no established history exists.
• You are using new technology. Have you implemented new technology into your processes? It may alter actual costs to the extent that previous cost estimates will not be accurate for the new project. New technology may either increase or decrease actual costs.
• You choose not to consult commercial databases of cost information. There are commercial databases of cost information available for many different industries. However, there are costs involved in purchasing a database plus the periodic upgrades. You may find it more worthwhile to develop your own database over time.

In summary, the bottom-up estimating technique is one that you will want to use to produce accurate cost estimates when there is little historical data about similar projects, a real need for accuracy, and adequate detail and time available.

The Analogous Estimating Technique

One of the most common methods of estimating project costs enables you to take advantage of the similarities between a current project and projects that have been performed in the past. This technique is called analogous estimating.

An analogy is a set of comparisons you draw between two things with similar characteristics. Analogous estimating is also known as "top-down" estimating because you apply the total costs from a previous project in order to estimate the total costs of a new one. Just keep breaking the budget down according to the new work breakdown structure (WBS).

The main benefit of using the analogous estimating technique is that it is less costly than other estimating techniques. The down side of using this technique is that it is also generally less accurate.

You may be wondering, "If analogous estimating is not considered to be accurate, why would I use this technique?" However, before you disregard analogous estimating altogether, you should be aware of the circumstances under which it is most reliable. It is particularly beneficial when the following conditions are present.

1. The new and previous projects are similar
There are two situations in which analogous estimating is used. One is when your project is similar to other, previous projects. The more similar the projects are, the more accurate the estimates will be. You also can base estimates on a similar project when you don't have detailed information about a new project. More details are provided below.

• Are they similar? To determine the degree of similarity between the past and current projects, examine the scope and purpose of the former project to ensure the projects are alike in fact, and not just in appearance.
• Not enough detail. Sometimes important costing information becomes available only after a project has begun. A similar project's budget will provide a general baseline to go by.

2. The individuals preparing the estimates have the necessary expertise
Knowledge about, and experience with, the subject matter determines whether the individuals preparing the estimates have the needed expertise. You may want to hire one or more external experts to help with cost estimating.

3. The estimating team has access to adequate information about the previous project
If your current project lends itself to the analogous estimating technique, you'll want to furnish your cost estimating team with everything they will need to produce accurate results. Listed below are some types of information they should have on hand when they are developing cost estimates using analogous estimating.

• Scope statements. The team will not know whether two projects are in fact similar unless it can compare descriptions of the project and product scopes.
• Work breakdown structure. The work breakdown structure from the previous project is also necessary to ensure that similar processes and steps will be followed in the current project. Differences in the two projects could affect the accuracy of cost estimates.
• Performance reports. Actual costs are the most important information from the old project. Your team will use them to determine which of the previous estimates were accurate. It should use the actual costs to revise any inaccurate estimates before copying them into the new project.

Remember the analogous estimating technique as a less costly way of estimating project costs when your team has the needed information and expertise to effectively compare the current project to previous, similar projects.

The Components of the Work Breakdown Structure

Did you ever have so much to do that it was difficult to know where to start? What strategies did you use to complete your work? Did you break things down into manageable components?

A work breakdown structure (WBS) breaks down a project into manageable components. It is a chart that outlines project phases and organizes and define the scope of the project.

A WBS breaks down your project so that it is easy to identify the resources you need to complete each phase and task. When combined, these resources form a project resource list.

A WBS has several components. A code of accounts is one component of the WBS. It is a numerical identifier that is assigned to each item in the WBS. This identifier indicates to which level of the WBS hierarchy the task belongs. This identifier is also a quick indicator of which WBS level you are currently working on. It also makes it possible for you to see how your task is linked to others at each level. Looking at these other levels may help you understand how your task fits into the big picture.

Work packages are another component of a WBS. Work packages are the lowest-level items and show the division of project labor into workable units. Each unit can then be given to an individual or group to accomplish.

How do you know what degree of detail you need for the work package level of a WBS? A general guide is to make each work package small enough so that you can use it as a separate work element for estimating purposes. All of the work packages should have a consistent level of detail and control. If the level of detail varies between work packages, your plan will be distorted and confusing. If your work package needs further detail, it can be sub-divided into a list of work activities or tasks.

The WBS contains a great deal of information within its simple chart form. There is another element of the WBS that helps explain all of this information. This element is called a WBS dictionary, and it explains the nature of the work done in each of the WBS items. A WBS dictionary is a document that includes information concerning each phase and sub-phase of the WBS.

Information concerning the phases and sub-phases of a project can include planning information such as, schedule dates, cost budgets, and staff assignments.

The WBS dictionary is most often used on large projects and is compiled by team members after the WBS hierarchy has been determined. Planning teams can then refer to it when they are developing their detailed plans. This ensures that they are organizing their work into the WBS hierarchy correctly.

MercuryRising is an IT company with many series of ongoing projects. Lisa is a project manager handling approximately five series of Internet courses for a total of 42 courses. She must ensure that these courses are completed on time and within budget. To do this, she uses a WBS dictionary. Lisa needs a WBS dictionary so she can quickly see who is assigned to which course, the final date each is due to the client, and how much each course is costing her in resources.

A sample of what she might find in her WBS dictionary is:

Course: Interview Skills
Writer: Jane Scott
Course deadline: June 16
Project Cost: $3,000

The Work Breakdown Structure—with its code of accounts, work packages, and dictionary—is an important tool for breaking down and tracking the progress of your project. Once you finish each work package, you can move up the WBS hierarchy until the project is completed. This helps you plan the resources you need and monitor their use throughout your project.

The Outputs of Project Activity Definition

Taking the time to clearly define project activities reduces the chance for costly project delays. The process of defining project activities results in new or revised project documents or documentable items. These are the outputs of the activity definition phase of the project.

In any given project, there are three main outputs of activity definition: the activity list; supporting detail and WBS updates.

• the activity list
  The first and most obvious output of activity definition is the activity list. The activity list results from using the WBS to decompose the project into a series of activities to be performed. To ensure completeness and adherence to project scope, the activity list should be developed and organized as an extension of the Work Breakdown Schedule (WBS).
  

• supporting detail
  The second output of activity definition is supporting detail. Once an activity is defined, the next step is to clarify how it should be performed. To do this, you need to take into account project assumptions and constraints.
  
  Consider the example of Telecom Corporation's VPN project. The development of a new corporate web site is going on at the same time as the VPN project. The assumption that the web site development project uses standard technologies compatible with the VPN project must be documented in the supporting detail.
  
  The constraints imposed by the existing client infrastructure affect project activities and must be included in the supporting detail.
  

• Work Breakdown Schedule (WBS) updates
  The third and final output of project activity definition are WBS updates. The WBS helps identify which activities to include in a project. If a missing deliverable is identified during the activity definition process, you must update the WBS to include that deliverable. You should also update the scope statement since it is a related document that includes a list of the project deliverables. Any changes in the deliverables must be reflected in the WBS and related documentation.
  

The outputs from activity definition include the activity list, supporting detail, and WBS updates. These outputs serve as important inputs to the next task required of a project management team—activity sequencing.

Project Decomposition and Templates

To complete any task, you need to know what tools are at your disposal. Project managers who are engaged in defining project activities use two main tools to accomplish this task: decomposition and templates.

Decomposition
Decomposition means breaking a project deliverable down into a list of achievable activities.

Telecom Corp. is a telecommunications company. One service that it provides to its clients is the virtual private network (VPN). VPN project deliverables include a firewall, routers, encryptors, Internet service, IP backbone, and secure remote access.

The last deliverable could be decomposed into the following three activities:

1. provide remote access
2. provide encryption key
3. authenticate users

After dividing a deliverable into potential activities, the team must evaluate each activity using the following six criteria.

1. Status is measurable.
2. Sign of completion is visible.
3. Start and end conditions are clearly defined.
4. Time and cost are easily estimated.
5. Duration has acceptable limits.
6. Work assignments are independent.

The first criterion to consider is whether the activity's status is measurable. For example, one deliverable in a Telecom Corp. VPN project is secure remote access. One activity defined for this deliverable is authenticating users, and it is measurable. When half the users have working login IDs and passwords, the activity is fifty percent complete.
Whether there is a visible sign that the activity is complete is the second criterion. This sign could be the delivery of a document or product, or it could be the manager's signature. In the Telecom Corp. example, the visible sign that users have been authenticated to the network is when all users can access the network with a functional user password.

The third criterion to use is whether an activity has clearly defined start and end conditions. Once the beginning event has occurred, work may begin on the activity and continue to a visible sign of completion. For Telecom Corp., the authentication activity should only begin when the network is in place. The authentication activity is clearly finished only when the users are able to use their login IDs and passwords to access the VPN.

Whether activity time and cost can be easily estimated is the fourth criterion to consider. This is accomplished by estimating the time and cost of a project's activities. In the Telecom Corp. example of authenticating users to the VPN, time can be estimated at a few days.

The fifth criterion to examine is whether an activity's duration is within acceptable limits. Although there is no set rule on this, projects should avoid activities with long durations. Delays in such activities can create serious scheduling problems. In evaluating Telecom Corp.'s authentication activity, duration can be estimated at a few days. Delays here would not create huge project delays or large-scale scheduling problems. The authentication activity then meets this fifth criterion.

The final criterion is an activity's level of independence from other project activities. Independence in an activity means that once work has begun on the activity, it may continue without interruption. For example, once Telecom Corp.'s authentication activity begins, it is not dependent upon any other project activities for completion.

Templates
The second tool a project manager and team uses to define project activities is a template. A partial or total activity list, or WBS from a previous project, can be used as a template for a current project. Using templates simplifies project activity definition and reduces project costs by improving team efficiency.

To define project activities, project managers use decomposition and templates. Decomposition means breaking project deliverables into achievable activities. A template is a partial or total WBS, or activity list defined in a previous project, which can be used in a current project.

The Inputs to Project Activity Definition

When a project reaches the activity definition phase, certain documents or documentable items have already been established. These "inputs to activity definition" include the Work Breakdown Schedule (WBS), scope statement, historical informaiton, constraints, assumptions, and expert judgment.

• Work Breakdown Schedule (WBS)
  One of the principle inputs to activity definition is the WBS. This document defines project tasks and deliverables.
  

• scope statement
  The scope statement refers directly to project justification, project objectives, project deliverables, and project product description.
  

• historical information
  Historical information is another important input to activity definition. Consider activities required on previous, similar projects in defining current project activities. After all, if something works, why not repeat it?
  

• constraints
  Constraints are also an input to project activity definition. A constraint is anything that can limit the project management team's options.
  

• assumptions
  Assumptions are the fourth input to activity definition. For planning purposes, assumptions are factors that are considered to be true. Over the course of the project, these factors may turn out to be true or false.
  
  Assumptions always carry a degree of risk. For example, if assumptions about materials or costs are false, a project may be delayed or exceed its budget.
  

• expert judgment
  The final input to activity definition is expert judgment. Expert judgment is advice from people with specialized knowledge or training that directly relates to your project. Some sources of expert judgment are:
  

experienced employees in the organization
outside consultants
professional associations
industry watch groups.

The inputs to activity definition are an important part of any project. These documents and documentable items help the project manager and team to determine project deliverables and the tools and techniques needed to achieve the deliverables.

Ensuring that Scope Changes Are Properly Implemented

Do you find it easier to manage a huge task by organizing it into smaller tasks? Project managers manage a huge task—the project—by organizing it into activities using a work breakdown structure (WBS).

The WBS is a framework that defines the scope of the entire project; work not in the WBS is outside the scope of the project. The approved WBS represents all of the work packages and activities that must be completed in order to finish a project.

To effectively control scope change throughout your project, you have to review the approved WBS. By reviewing the approved WBS, you ensure that the change will be properly implemented. At this review stage of the project, you should be looking at the activities and any resulting changes and impacts.

• the activities - The first thing to review is the activity level of the WBS to ensure that all activities resulting from the change have been included so that the corresponding deliverable can be met. A forgotten activity can result in a missed deliverable or non-acceptance by the client, so this is a very important step.

• any resulting changes and impacts - The project manager must also review the WBS to ensure that the resulting changes to the activities and their impacts on the schedule and budget have been considered. The project manager should ask himself if the change to the activities could cause the starting or ending date of the corresponding deliverables or final products to be delayed. He should also determine if the budget will be sufficient. If the answer to either of these questions is yes, the project manager can then use the tools and techniques of scope change control to assess the impact.

Project managers and the project team frequently refer to the WBS throughout the project. The WBS is the key to scope change control because it defines all the work in the project.

A 4-step Approach to Scope Verification

As a project manager, you will need to prepare for a critical inspection of the project work. The inspection of the work results usually occurs at a meeting with project team members and key stakeholders. When conducted properly, this critical inspection verifies that all deliverables and work results are completed according to the project plan.

The project manager is frequently asked to facilitate the inspection meeting. There are four steps for facilitating a scope verification inspection meeting.

1. First, you need to choose the appropriate reviewers who will attend the inspection meeting.
2. Next, revisit project goals so that all of the reviewers are aware of the direction of the project.
3. Then you should review the work results to compare the project's product to the expected deliverables as outlined in the WBS.
4. Finally, you need to decide on appropriate action as a result of the scope verification.
   

Even before the actual inspection meeting begins, the project manager needs to choose appropriate reviewers. In addition to the project manager and at least one project team member, you may want to ask the following people to attend the meeting:

• Subject Matter Expert (SME) - An SME acts as an adviser to the project team when the team needs external expertise. SMEs should attend the inspection meetings to provide the team with the necessary advice and to verify the results of the work.

• Project Sponsor - The project sponsor is the individual or group that provides the financial resources for the project. The project sponsor should attend the inspection when the project is a new or risky venture. It is not necessary to include the project sponsor for projects that are repetitive or recurring.

• Customers - The customer is any individual or organization that will use the project's product. It could be the client or outside consumers. Customers should attend the inspection meeting when their cooperation is essential for the project.

The next step in facilitating a scope verification inspection meeting is to revisit the project goals. The meeting facilitator needs to ensure that all reviewers are aware of the original purpose of the project and of the goal of the inspection meeting.
As the meeting facilitator, you need to explain to the inspection team members that they will compare the actual work results to the planned scope of the project to ensure that project results are acceptable.

Once all of the reviewers are aware of the purpose of the project and the inspection meeting, the inspection team should review the work results and do the following:

• Identify any omissions in the product that were in the original plan.

• Verify whether the omissions, if any, were approved through a scope change.

• Note any oversights in the work results.

• Ensure that all documentation is available.

• Note any exceptions or deviations from the project baseline.

• Note any discrepancies (variances) between the work results and the scope baseline.

• Note any violations of industry or client standards.

After reviewing the work results, the inspection team needs to decide on appropriate action. In a scope verification inspection, there are three actions that you may choose from, depending on the outcome of the meeting.

1. The inspection team can accept the work results if the planned scope and the work results match. There should be no unapproved deviations from the plan when you accept the work results.
   
   
2. The reviewers at the inspection meeting should request minor changes if it won't affect the project budget or schedule. Minor changes could include asking for slight product modifications or for more detailed documentation.
   
   
3. The inspection team should reject the work results if there are obvious and substantial deviations from the planned scope. If the changes required to fix the deviations cause cost overruns or put the project behind schedule, the reviewers should reject the work results.

Before presenting your project to the client for final acceptance, you can use the tools and techniques for scope verification to ensure that the work results are acceptable. Remember to perform a careful and thorough inspection.

Verifying the Work Breakdown Structure

The task of decomposing your project's major work elements can be difficult, detailed, and time-consuming. Once you've decomposed your project and created the Work Breakdown Structure (WBS), is there a way to verify that your work is complete?

To verify that your WBS is complete, you need to ensure that the lowest-level work packages can be appropriately scheduled, were appropriately budgeted, and can be appropriately measured. Keep in mind that the work packages, which also are referred to as tasks, are the constituent components of activities, which in turn are the constituent components of project deliverables.

1. You must ensure that work packages can be appropriately scheduled.
Duration estimates were crucial in creating the WBS, but to verify that the WBS is complete, you must be able to appropriately schedule each low-level work package. This means that each work package must have a clearly defined starting and ending event.

The starting event can be the result of completing another phase or activity, but the ending event should complete the work package. If the ending event leads to another activity, the new activity should be decomposed to create an even lower level within the WBS.

In general, you should schedule the lowest-level work packages for less than three calendar weeks, or 15 business days. This avoids long duration activities whose delay could create serious scheduling problems. If the work packages in your project are longer than three weeks or you can separate tasks within the activities with distinct durations, try to decompose them further.

2. You must ensure that work packages were appropriately budgeted.
The second criterion for verifying that a WBS is complete is whether or not the lowest-level work packages were appropriately budgeted. To determine this, project managers must look at the cost estimated for each low-level work package and compare it to what they would expect it to cost based on their previous project experience.

For the WBS to be properly decomposed, the amount estimated for each work package must fall within a specified range of the expected amount.

3. You must ensure that work packages can be appropriately measured.
Measurability is the third criterion for verifying that your WBS is complete. For any lower-level work package in the WBS, there must be a sign of completion. A sign of completion is any visible indication that a work package is finished. For example, a sign of completion could be:

• an approving manager's signature

• the delivery of a physical product or document

• an authorization to proceed to the next activity.

In addition to having a sign of completion, team members must be able to convey progress for a work package to be measurable. They must know how to report progress and to whom to report it.
For example, if team members can report a percent complete on an activity to a specific person, department, or team, the activity is measurable. Examples of measurable and nonmeasurable activities are provided below.

• Nonmeasurable. "Communicate progress to others" is a nonmeasurable activity. This task has no sign of completion, so it will simply stop at the end of the project. It is not possible to estimate the progress of the task, since it has no distinct parameters.

• Measurable. If the task "communicate progress to others" were broken down to "report weekly progress on phase one to executives," the task would be measurable. It would be possible to report what had been accomplished in the reporting period.

Work packages that are vague or too broadly defined may not be accurately scheduled or budgeted. Similarly, work packages that are unnecessary or insufficient may not be accurately measured. That's why it's important to remember that you don't have to wait until the decomposition process is complete to begin verification. You can save time and money by verifying that each work package is complete as you create the WBS.
The WBS is important for defining project scope because it defines all the work in the project. Since project teams frequently refer to the WBS throughout the project, finalizing the WBS and verifying its completeness is the key to project success.

The Process of Project Decomposition

In most instances, it is much easier to solve a problem once it has been broken down into smaller, more manageable parts. How do project managers do this? The answer lies in decomposition.

Decomposition involves subdividing the major project deliverables into smaller, more manageable components until the deliverables are defined in sufficient detail to support development of the project activities involved in planning, executing, controlling, and closing the project. These smaller constituent components then become the basis for creating a project's Work Breakdown Structure (WBS).

The process of project decomposition entails three major steps. These steps will enable you to divide all work, regardless of complexity, into manageable elements. Once you have completed these steps, you will have a workable WBS.

1. Identify the phases and deliverables of the project.
The names of the phases are usually such things as project management, design, development, testing, and integration. The project phases form the basic outline for how the project will unfold. They become the first level of the project's WBS.

A deliverable is any measurable, tangible, verifiable outcome, result, or item that must be produced to complete a phase. You should divide each project phase into its deliverables. These deliverables become the second level of the project's WBS.

2. Determine if deliverables require further decomposition.
A deliverable requires further decomposition if cost and duration estimates cannot be developed at this level of detail. How do you determine whether you can develop adequate estimates of cost and duration? Project managers must answer two questions to determine if they can develop adequate cost and duration estimates for each deliverable.

• First, can the project manager state the approximation of the cost of the resources needed to complete the deliverable?

• Second, can the project manager define the number of work periods required to complete the deliverable? A work period is usually expressed in workdays or workweeks, not including holidays or other nonworking periods.

If the project manager can answer "yes" to both questions, the decomposition process is complete for that deliverable. If the answer is "no" to either question, the project manager will have to proceed to the third step to further decompose the deliverable. Remember, this step is repeated for each deliverable.

3. Identify constituent components of deliverables.
The third step in the decomposition process is identifying the constituent components of the deliverables. The constituent components are referred to as activities. They become the third level of the WBS. As with deliverables, you should define the activities in terms of how the project work will be organized and accomplished.

• Activities should be results-based. You should describe activities in terms of tangible, verifiable results to facilitate performance measurement.

• Activities can be products or services. Activities can include services as well as products. For example, "weekly status reporting" is a service, while "writing software code" is a product.

Once you've identified the activities, you need to do more cost and duration estimating, just as you did for the deliverables. If the component is too broad to develop an accurate estimate, continue to break the constituent components down further.
Constituent components of activities are referred to as tasks or work packages. These components become the fourth level of the WBS. Once you can determine cost and duration estimates, you have finished the decomposing process for that task.

If you apply the three steps of the decomposition process, you can create a WBS that will make your project more manageable and increase the chance of its success.

Project Management Artifacts

Most projects, to be successful, must adequately document objectives and deliverables. These documents are a mechanism to align sponsors, clients, and project team's expectations.

1. Project Charter
2. Business Case / Feasibility Study
3. Scope Statement / Terms of Reference
4. Project Management Plan / Project Initiation Document
5. Work Breakdown Structure
6. Change Control Plan
7. Risk Management Plan
8. Communications Plan
9. Governance Model
10. Risk Register
11. Issue Log
12. Action Item List
13. Resource Management Plan
14. Project Schedule
15. Status Report
16. Responsibility Assignment Matrix
17. Database of Risks
18. Database of Lessons Learned
19. Stakeholder Analysis
    

These documents are normally hosted on a shared resource (i.e., Intranet web page) and are available for review by the project's stakeholders. Changes or updates to these documents are explicitly outlined in the project's configuration management (or change control plan).