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.

Tuesday, August 7, 2007

Work Breakdown Structure Templates

Like a map that shows you the entire world at a glance, the Work Breakdown Structure (WBS) is a graphical representation of the entire work effort of a project. It is a deliverable-oriented grouping of project components that is used to:
  • organize and define the total scope of the project
  • confirm a common understanding of the project scope.
Often, you can use a previously developed WBS as a template, or pattern, for new projects because most projects will resemble one another. Patterning a project after a previous one will enable a project manager to save both time and money. The project manager needs to consider three factors when deciding whether a previous project's WBS can be a template for a new project.
  • Project life cycle. Organizations usually create a framework that all project managers follow when developing projects. This framework is known as a project life cycle. The project life cycle defines the beginning and the end of a project. Project life cycles are usually organization specific.
  • Project phase. A project life cycle is broken down into phases that make it easier for a project manager to manage a project. Each project phase contains related project activities, usually culminating in the completion of a major part of the product or service.
  • Project deliverable. Each project phase is broken down into deliverables, which helps the project manager to control the project. A project deliverable is any measurable, tangible, verifiable outcome, result, or item that must be produced to complete a project or part of a project.
Many companies use a framework for project development that begins when an idea for a project is accepted and ends when the product or service is delivered to consumers. This is considered the project's life cycle. The life cycle includes the following phases:
  • planning—understanding the proposed product or service
  • designing—creating a detailed plan
  • manufacturing—building the product or developing the service
  • testing—making sure that the project or service meets expectations.
If a past project and a new project share similar project life cycles and deliverables, the past project can serve as a WBS template for the new one. The more similarities that exist between the life cycles and deliverables of the old and new projects, the more appropriate the old WBS will be as a template for the new project.
To determine similarities in the two project life cycles, look at the project phases of the two projects. Are the phases the same or similar? Do the projects have the same number of phases? Are the phases in each project named differently but accomplish the same thing?

If the answer to any one of these questions is "no," you can't use the WBS from the past project as a template, and you don't need to do any further research. However, if the answer to all three questions is "yes," you can probably use the past project's WBS as a template for the new project.

If the project phases of two projects are similar enough that the WBS from the older project can be used as a template, the project manager should then look at each projects' deliverables to see if they are the same in number and similar in outcome. Although the deliverables may be project-specific, project managers can consider them similar as long as they are accomplishing similar tasks.

In summary, when comparing past projects to the current project to determine if you can use the WBS template from the previous project, you should look for similar life cycles, phases, phase outcomes, deliverables, and deliverable outcomes. If a previous and a new project have the same or similar project life cycles, phases, deliverables, and outcomes, save yourself time and money and reuse the WBS from the previous project.

Wednesday, August 1, 2007

Historical Information and Scope Definition

Norman Cousins—writer, editor, and renowned Federalist—once said, "History is a vast early warning system."

Information from past projects can serve as an early warning system for your current project by giving you considerable insight when you're defining project scope. This type of scope definition input is referred to as historical information. Information from past projects that will be helpful in defining the current project scope includes the following.

1. Previous project documentation
You can find previous project documentation in the form of outputs from other planning processes. When collecting historical information, you should limit your search to documentation generated from similar projects.

The emphasis should be on identifying areas in which other similar projects were particularly successful. This information is easily found in the project development data that is included within a project's scope specifications.

You also should look for information that may have caused problems, such as scope omissions. This information is commonly found in the lessons learned output created during project wrap-up.

2. Personal experience
You also can gather historical information from personal experience. For example, the first working experience with a client provides insight into that client's preferences. Since you already know the client's likes and dislikes, you can apply this knowledge to your next project and make scope definition changes in advance.

You also can draw on the personal experiences of your co-workers. For example, a person who has worked on a project similar to the one for which you are defining the scope may provide you with useful information.

The lessons learned from previous projects provide early warning signs for potential project scope problems. Using historical information as an input to scope definition will result in more successful projects and happier clients.