Showing posts with label structure. Show all posts
Showing posts with label structure. Show all posts

Saturday, October 18, 2008

What Does a Staffing Management Plan Include?

Jumping into your project without a staffing management plan is like jumping from a plane without a parachute. It might be the fastest way to your destination, but it clearly is not the safest or smartest decision.

The people you select to work on your project will either contribute to its success or its demise. To ensure the success of your project, you will want to identify your staffing requirements and come up with a staffing management plan.

A staffing management plan is an output of the organizational planning process. This kind of plan includes your basic staffing requirements and provides details about how people will be brought on board and released from the project.
  • staffing requirements
    Staffing requirements describe the team members you need to carry out the tasks your project requires. Objective and subjective criteria are used to match the team members to various positions that need to be filled.

    Objective criteria outline the technical competencies needed from a potential team member to successfully fulfill a project task. Subjective criteria deal with the needed personality traits to successfully fulfill a project task.
  • information about how people are brought on to the project
    Planning for your team members before they even come on board will help you to take better advantage of their expertise. Bringing people onto a project can be chaotic. New team members have many questions about their project tasks, roles, and responsibilities. You can help make this transition as smooth as possible by anticipating team members' questions.

    Job descriptions, training, project information, and reward programs, and a closing meeting are just some of the items to include in this part of your plan.
  • Job descriptions - When team members know the parameters of their position, they can focus on exactly what they are there to accomplish. Job descriptions eliminate confusion and provide direction.
  • Training - You want your team members to work as efficiently as possible. For this to happen, your team members require proper training. Training takes time up front, but saves you time in the long run.
  • Project information - Project information allows team members to see where their tasks fit into the big picture. The more fully informed team members are, the more focused their tasks will be.
  • Reward programs - Reward programs work as productivity incentives for your team members. This creates good morale, as team members feel they are recognized for a job well done.
  • Closing meeting - A closing meeting, reviews both the positive and negative elements of a finished project. It allows you and your team members to make better plans for the next project, as well as capitalize on the strengths demonstrated in the finished project.
  • Information about how people are released from the project
    Creating a plan to move people off projects is also beneficial. This type of planning provides direction, focus, and smooth transitions.

    Your staffing management plan should include a plan for re-assigning your team members as soon as the project is completed. Your team members should know when and where their next assignment begins.

    Properly releasing staff reduces costs by reducing or eliminating the tendency to make work to fill the time between this assignment and another. It also improves morale by reducing or eliminating uncertainty about future employment opportunities.
Completing a staffing management plan before jumping into your project will save you time and trouble later in the project. The plan you develop will help you to see how to put to the best use the skills, expertise, and talents of each and every team member. And this will allow you to execute the project sure and steady with fewer surprises.

Sunday, October 12, 2008

Structuring Organizations for Better Project Management

If you change the molecular structure of an organism, you change the way that organism functions. Every element of change brings about a subsequent change of function. Like an organism, your organization can and should be structured to enable you to better respond to project requirements.

Changing the structure of an organization is a relatively new phenomenon. Historically, an organization was structured along a pyramid model. This traditional form of organizational structure, called a "functional" structure, leaves the authority and decision-making in the hands of a select few. However, as the pyramid widens and the number of people increases, the effectiveness of those in authority decreases.

Most businesses now tend to focus on individual projects. If your company focuses on projects but uses a functional structure, your projects will be forced to wait in line for decisions that need to be made.
  • Functional structures reduce project efficiencies because:
  • decisions take too much time to go through the hierarchy
  • decisions are made by people not familiar with the project
those involved in the project become frustrated by those assuming all of the responsibility.
Fortunately, organizational structures have changed to meet the new challenges of business. Two different structures that have evolved are the matrix and projectized structures.
  • Matrix structures - Matrix structures are divided into two categories: weak and strong. The weak matrix structure provides relatively little authority for the project manager, while the strong matrix provides almost complete authority for the project manager.

    A weak matrix structure allows a project to exist apart from the main organization. It retains its own structure but still relies on the organization for some of the decision making.

    A strong matrix has its own structure apart from the main organization. The decision-making ability is quite strong within this structure, but it is still answerable to the larger organization.
  • Projectized structures - The projectized structure is similar to the strong matrix structure. While the strong matrix allows very strong decision-making abilities for the project manager, the projectized structure allows for complete decision making on the part of those involved in the project. For both of these structures, the organization plays an auxiliary role to the project. This change in project authority and responsibility allows for projects to run more smoothly. This in turn, brings a faster turnaround time.
How do you decide which structure is right for your project? Complexity, duration, and outside influence on your project are the three factors which determine the type of structure your project should have.

You need a strong matrix or projectized structure if your project:
  • is extremely complex
  • is long in duration
  • involves many different organizations.
The effectiveness of these structures is dependent on senior management. Matrix and projectized structures can only succeed if the larger organization lets go of control. Authority and independence are needed for these new structures to have validity. The benefits of these structures must be clear to the larger organization for them to relinquish power over individual projects.

Changing from functional structures to new structures calls for a change in both the main organization and the project team. Senior management must learn to give up control, just as the project team needs to learn to take it on. All of this change requires new competencies within the project team. Each team must be able to handle all of the functions usually accomplished by the larger company.

A project team must learn to equip itself before it gains independence. To function, the team must ensure that it is able to:
  • communicate
  • sell ideas
  • negotiate
  • problem solve
  • resolve conflicts across functional boundaries.
Requiring these competencies of a project team is a huge departure from the past. More is expected from individual members of a team, and more responsibility is placed upon them. This creates dynamic and skilled people. It also creates some new challenges for the project team.
Human beings are incredibly adept at adjusting to new situations and new demands. This adjustment does, however, take time. The same is true of new organizational structures and the new processes they create. The new challenges faced by project teams require an adjustment period and a clear understanding of how the roles have changed.

The four areas that provide the most challenge within the project team are ownership, commitment, authority, and process orientation. Some of these challenges for the project team are due to the limitations of the larger organization, while others rest within the project team itself.

Responsibility for a project calls for ownership of that project. When companies move toward a new structure, they must make the transition of assigning a process owner. They need a manager with responsibility over the process from beginning to end.

The challenge of commitment is found within the project team itself. This is particularly an issue if the project involves contract workers. The project manager must ensure that employees realize their unique role in the success of a project.

Formal statements from the project champion or customer are necessary. These state who has the authority and responsibility for the project and should be distributed to stakeholders, resource managers, and especially the contracted team members.

New structures require new processes. Turning from functional to process-oriented structures requires new work habits, skill sets, meeting formats, reporting structures, problem resolution methods, and other tools to make a project truly effective.

The changing face of business has required dramatic changes in how organizations structure themselves. These changes have brought about a greater sense of responsibility within project teams and the acquisition of competencies formerly only found within the larger organization. Acquiring new competency requirements also presents new challenges for organizations. Meeting these challenges, however, enables a company to be more efficient, to save time, and to gain expertise.

Monday, October 6, 2008

Identifying Project Constraints

Everyone has constraints on decision-making and action. During project organizational planning, there are many constraints to consider. Some of the most common constraints on decision-making are the organizational structure, collective bargaining agreements, the preferences of the project management team, and expected staff assignments.

Organizational structure
Organizational structure can be a constraint. The level of authority given to a project manager is largely dependent on the organizational structure, which may be functional, matrix, or fully projectized.
  • Functional structure - In a functional structure, personnel are grouped hierarchically by speciality.
  • Matrix structure - In a matrix structure, project managers share responsibility with functional managers.
  • Fully projectized structure - In a fully projectized structure, project managers have total authority.
Collective bargaining agreements
Collective bargaining agreements are another potential constraint. Written agreements with unions or other employee groups ensure that you don't ask anything of your team that goes beyond what the union has agreed is appropriate. For example, a union may require that certain employees be hired, or it may set boundaries concerning work done by members of the union. Union contracts may also limit work hours and travel and time away from an employee's designated job.

The preferences of the project management team
Team preferences may also be a constraint. A team may be used to functioning independently, and individual team members may resist the changes brought about by interdepartmental interaction.

Expected staff assignments
Expected staff assignments are constraints placed on you and your team from the larger organization. When someone above you expects you to use certain people on your team, you then have the constraint of a pre-selected team. A pre-selected team limits a project manager in a variety of ways. Expected staff assignments can hinder a project when tasks are assigned based on criteria other than competency, the required competencies of the project team are changed, and the chemistry of the project team is altered.

It may seem logical that competency should be the overriding factor in team selection. Unfortunately, organizations themselves are under the constraint of staff availability. There may be redundant employees who have not yet been reassigned to a new full-time position. Projects end at different times. If one ends just as yours is beginning, your project is a convenient new placement for these employees.

Overcoming project constraints resulting from organizational structure, collective bargaining agreements, team preferences, and expected staff assignments is possible when you learn to view constraints as a challenge. When you understand the constraints placed on you, you can plan your strategy to take advantage of the human and material resources at your disposal.

Saturday, October 4, 2008

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.

Friday, May 2, 2008

Cost Estimating and the Work Breakdown Structure

Do you often find it easier to solve a large problem by breaking it down into smaller parts? This is what the work breakdown structure (WBS) does for a project manager. The WBS itemizes the many tasks that make up a project.

The work breakdown structure contains the entire project scope—all the work you need to complete in order to deliver the product. Throughout the cost estimating process, you should refer back to the WBS to ensure that you have included each activity. The WBS enables you to:
  • organize your cost estimates
  • identify each project activity that generates cost
  • illustrate the project scope in a summarized, graphical representation.
A work breakdown structure is a type of tree diagram that enables you to see the project scope all on one page. It depicts a hierarchical listing of the work, showing how the work elements are broken down (or decomposed) into tasks, work packages, and detailed activities. The WBS is organized as follows:
  • The top line of the WBS contains the name of your project.
  • The first level of the WBS contains the major elements of the project. Most projects within a given organization will have similar project life cycles.
  • The lower levels of the WBS show the continued decomposition of the phases. The third level usually contains tasks. Lower levels would be comprised of work packages and ultimately, individual activities.
The work breakdown structure is developed as an output of defining the project scope. When creating a work breakdown structure for a project, use the scope statement to identify each of the project's major phases or elements.
Each phase will have its key deliverables, which are further decomposed into tasks and then into work packages or activities. Keep in mind that different elements may have different levels of decomposition.

For each project you manage, you'll have to decide to what degree you will decompose your work breakdown structure. If you want to develop detailed, accurate cost estimates, you will need to fully decompose the work.

As a guideline, ask yourself: "Can adequate cost and duration estimates be derived at this level?" If the answer is no, then you must continue to break tasks into work packages, and these into specific activities. The steps below summarize the process of decomposition.
  1. Identify the major elements of the project.
  2. Decompose elements into tasks, work packages, and detailed activities.
  3. Ensure that the lowest level items are tangible and can be measured for completion.
  4. Verify the correctness of the decomposition by comparing it to similar projects or having a qualified person review it.
  5. Assign a unique identifier to each item that corresponds to your firm's code of accounts.
Step 3, in which you verify that each bottom-level work package or activity is measurable, is the most important step to cost estimating. Ask yourself: "Can each item be appropriately scheduled, budgeted, and assigned to a specific department, team, or person who will be responsible to complete it?" You'll be able to produce fairly accurate and detailed cost estimates if each activity is measurable—if it can be assigned a duration and a list of required resources, including human resources, materials, and equipment.
The work breakdown structure makes it easy to find the total cost estimates. Once the work of your project is sufficiently broken down into measurable, verifiable activities, assign a cost to each item. The process of totaling bottom-level activities, assigning a total to the task, totaling all tasks belonging to a deliverable, and so on, is called "rolling up" the estimates.

In summary, project managers and their teams will refer frequently to the work breakdown structure during the life of a project. However, at no other stage is the WBS more important than when cost estimates are being prepared.

Thursday, April 3, 2008

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.

Monday, January 21, 2008

Project Outputs: Activity Duration Estimates

As a project manager, you can help ensure the success of your project by recognizing and understanding the various outputs of activity duration estimating. One of those outputs are the activity duration estimates themselves.

Activity duration estimates are quantitative assessments of the likely number of work periods (usually days) required to complete an activity. Project managers use activity duration estimates as a basis for scheduling time and resources for a project.

Activity duration estimates are derived from the Work Breakdown Structure (WBS). Use the WBS to determine which activities are involved in completing the project. Then, using the tools and techniques of activity duration estimating, prepare estimates for activity duration.

The estimates should include optimistic, most likely, and pessimistic estimates, listed in that order. For example, an activity that could be completed in as few as 10 days (an optimistic estimate), will most likely take 12 days to complete (the most likely estimate), but could take as long as 16 days (a pessimistic estimate).

Only the optimistic and pessimistic estimates are used by project managers to create a range of possible results. These results become your activity duration estimates, or valid durations. Valid durations are estimates arrived at using the tools and techniques of activity duration estimating.

You also should calculate the probability of the estimates being correct. Since you're working with estimates and not actual outcomes, you won't be able to use formulas for calculating probability. Instead, you should use other techniques, such as expert judgment or analogous estimating.

For example, using expert judgment, a project manager estimated that there is a 15 percent probability of an activity exceeding three weeks and an 85 percent probability of it taking less than three weeks.

Activity duration estimates form the backbone of the project schedule. Properly prepared estimates will lead to a better schedule—and a better schedule will help lead to a successful project.

Thursday, December 6, 2007

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.

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.