Sunday, August 26, 2007

Updating the Project Scope Statement

Heraclitus, the ancient Greek philosopher, once said, "Nothing endures but change." Changes to the elements that make up a project's environment will inevitably occur. Oftentimes, these changes are related to the project scope.

When changes take place that either increase or decrease the project scope, you will have to decide whether or not to update the project scope statement.

How do you know if you should update the project's scope statement to account for changes in a project's environment? You will need to analyze most changes to a project environment in order to determine if they warrant an amendment to the project's scope statement.

An update to the project's scope statement is essential if the change will result in an addition, deletion, or modification to the end product or service specified in the project objective. There are five common sources of change in a project environment.

1. Project specification change
Project specification changes are the most common source of change in a project environment. These types of changes reflect additional capabilities or features that were not included in the original scope specifications, but are considered crucial enough by the client to be included. Because they are at the client's request, project specification changes always require an update to the scope statement.

2. Design change
Design changes occur when a member of the project team identifies a better way to produce or provide the end product or service. Unlike specification changes, design changes do not result in a new feature or capability. They simply offer a way to enhance the product or service.

A design change is implemented only if the entire project team agrees that it will improve the end product or service. If an agreement is reached among the project team members, the design change is submitted for client review. Only upon client approval is the design change updated in the project scope statement.

3. Technological change
Technological changes are another source of change in a project's environment. These changes occur when new types of technology in equipment, material, communication, or expertise become available.

Technological changes are always reflected by advances in technology. These changes have to be updated in the scope statement if the new technology will be implemented in the project. They also require the client's approval.

4. Business cycle change
Business cycle changes occur when circumstances within the business industry change. Announcements by competitors and extreme changes in exchange rates are two sources of business change. These changes need to be updated in the scope statement only if the change has a direct impact on the project's delivery dates.

5. Personnel change
Personnel changes occur when key people involved in the project leave or are added to the project team. As a project progresses, the lead designer may leave, the project manager may be moved to another project, or a key expert may be added to the project.

When these changes occur, the project schedule may be affected. These changes need to be updated in the scope statement only if the person is a direct member of the project team whose presence or absence will have an impact on one of the project's deliverable dates.

Project environments can endure change. Knowing how to identify and analyze the sources of change will help you to update your project scope statement accurately and appropriately.

Tuesday, August 21, 2007

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.

Friday, August 17, 2007

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.