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.

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.

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.

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.

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.