Common Causes of Project Risk

Marina is a project manager for Outback Retailers. Her current project involves the development of a new type of high-speed racing bike. She has learned that there are several identified risks that have the potential to negatively impact her project objectives.

As a result, Marina is trying to develop risk responses that will eliminate or reduce the impact of these identified risks. Do you think it is possible for Marina to address two or more of her project risks with the same response?

Yes! By addressing more than one project risk with the same response, Marina will be able to deal with risk threats and risk opportunities more quickly, which will maximize the likelihood of a successful project completion.

Every project will encounter numerous risks. Many of these risks will be driven by a common risk cause. A common risk cause is an event or situation that produces more than one project risk.

As a project manager, you can identify common risk causes during the risk identification and risk analysis processes. It is important to take advantage of these opportunities whenever and wherever possible.

It is important to remember that every project is unique. Therefore, you cannot expect to identify the same common risk causes in every project that you manage. However, there are some causes that may occur more frequently than others. These common risk causes include:

• unavailability of resources
• inadequate quality standards
• lack of communication
• inadequate tools or technology

One common risk cause that may threaten the successful completion of your project is unavailability of resources. These resources may be people or materials. During the life cycle of your project, many risks may arise if you do not have sufficient personnel or supplies available to complete the project as planned. Such things as excessive cost and schedule overruns are only two of the risks that you may encounter if your project is threatened by a lack of available workers or materials.

Another common risk cause is inadequate quality standards. Identifying this common risk cause early in the course of a project is especially valuable because this risk cause has the potential to create several project risks that can adversely affect the promised consumer deliverable.

As a project manager, it is important to remember that if quality standards are not properly set or are not specific enough, your project will either fall below the expected standard or aim for a standard not required by the client.

Marina, from Outback Retailers, is beginning the risk response planning process for her current project. After studying the results from her project's other risk management processes, she finds that some of the quality procedures that concern the new product are not clearly detailed. In addition, phase three may be short by two people due to a recent staff reduction. Marina hopes that the identification of these two common risk causes up front will help make her risk response planning process more efficient.

A lack of communication is another example of a common risk cause. In daily life, whether at home or at the office, people often suffer the unpleasant consequences of not giving or receiving adequate or accurate information. This is especially true in project management. If clear and open lines of communication are not firmly established, a project may be put in serious jeopardy. Such things as change requests and project plan modifications may not be properly carried out if there is a break in communication.

Inadequate tools or technology is a common risk cause that can severely impact the outcome of a project. It is difficult to develop a product efficiently or according to its established standards if you do not have the adequate tools or technology to complete the product as specified in the project plan.

It is also possible that a project may suffer a complete failure if critical tools are not readily at hand when needed. This common risk cause may also result in project deliverables not meeting widely accepted industry standards.

As a project manager, it is important to remember that some of your project risks may be driven by a common risk cause. As a result, the identification of these common risk causes is a valuable input to risk response planning because it may allow you to address more than one project risk with a single response. This will help eliminate the creation of redundant risk responses and make your risk response planning process more efficient.

Resources to Help You Avoid Past Mistakes

Somebody once said, "Every time history repeats itself the price goes up." If companies are aware of past experiences, they can save themselves from the expense of repeating mistakes.

One way to avoid past mistakes is to pay attention to historical information when developing your risk plans. Two sources of historical information are especially helpful in meeting this objective: past project files and published information.

Past project files
There are three types of project files that you can use to examine historical data: previous project documentation; the lessons-learned report; and the risk response plan.

You can find previous project documentation in the form of outputs from other planning processes. However, you should limit your search to documentation generated from similar projects.

Another good resource for identifying risks and avoiding past mistakes is the lessons-learned report. This document includes lessons learned from past projects, a description of the problems encountered along with the solutions to these problems.

The risk response plan file contains information on the processes put in place to monitor, review, and update the project risk. An examination of these risks will show that some risks are greater at specific stages of the project.

Published information
Other valuable sources of historical information are available in the form of published information. Published information which may give insights into past mistakes includes:

• Commercial databases - Commercial databases are sources that you can access to obtain professionally compiled information. A common example of historical information that commercial databases can provide you with is statistics.
• Academic studies - Academic studies may focus on risk factors of projects similar to the one you are managing. A great deal of time and research often goes into academic studies. You can benefit greatly from exploring this information source when developing your risk plan.
• Benchmarking report - Benchmarking involves an examination of your competitors' business practices or products. A benchmark report could give you insight into how other companies carried out similar projects and handled risks.

When researching the possible risks for a project, you can use historical information, gathered internally or externally, to avoid past mistakes.

Past projects completed within your company can provide a gold mine of lessons learned. But you can also look outside the company at how other companies and organizations have dealt with similar projects and their associated risks.

Historical information can provide you with important insights into the risks for the projects you are currently managing. If you have researched pertinent historical information, you will be able to deal with project risks more effectively.

Three Inputs to Cost Estimating

Resource requirements, resource rates, and the chart of accounts are three important inputs to project cost estimating. Details about these three closely linked inputs to cost estimating are provided below.

1. Resource requirements
A project's resource requirements come in the form of a list of items needed to complete a project. The list is produced during the resource planning phase.

Resource requirements refer to the types and quantities of resources needed to complete each activity listed in a work breakdown structure (WBS). Resource types, and the quantities needed to complete an activity, help determine project costs.

Project managers obtain the necessary human resources through staff acquisition and obtain materials through procurement. Typically, a project's resource requirements fall into five categories.

• Labor. Labor includes all of the human resources needed for a project, such as receptionists, computer programmers, engineers, and managers.
• Materials. Materials include the inputs you need for production or for delivery of a service. You will usually purchase materials from an external supplier, or from another division of your firm if it owns the raw resources you need for production.
• Equipment. Equipment includes machinery, hardware, software, and methods of transportation you need in order to complete the work. When estimating costs, consider how long equipment will be useful before it must be replaced.
• Overhead costs. Overhead costs can include costs associated with the facilities in which your project is carried out and interest payments on loans or leases.
• Contingency costs. Contingency costs are allowances made for risk and uncertainty. A project budget should contain a buffer to allow for unexpected costs, such as those that can result from natural disasters, computer viruses, accidents, strikes, or unexpected increases in the cost of supplies.

2. Resource rates
Another input to cost estimating is resource rates. Resource rates refers to the per-unit cost for each resource required to complete a project. If exact rates are not known, the rates themselves may have to be estimated.
Cost estimating is virtually impossible without the unit rates for each resource required. Examples of resource rates are staff costs per hour, printing costs per copy, lease costs per day, interest costs per year, utilities costs per month, and component costs per part. You will benefit from having accurate cost estimates based on accurate resource rates early in the project.

3. The chart of accounts
When calculating your cost estimates, you should allocate resources to the project based as closely as possible on your organization's chart of accounts. This is a table that contains the coding or numbering system that is used by the accounting department to monitor expenses. Categories of expenses can include staffing costs, office supplies, equipment, rent, and insurance costs.

Divide your project costs into categories that match the categories in your company's general ledger. This will save you time during your cost management efforts later in the project, especially if you use project management software that is integrated with your company's accounting system.

Perhaps part of your performance reporting efforts and postmortem analysis for your project will involve comparing the cost performance of different projects. This will be much easier if all projects use the same coding system.

You will need your company's accounting codes, as well as your project's WBS, resource requirements, and resource rates, to calculate cost estimates. Remember, determine resource requirements and resource rates before you begin estimating project costs to ensure the accuracy of your estimates. Integrate cost estimates with your company's chart of accounts to simplify cost control.

Sources of Expert Judgment in Resource Planning

Who did you look to for advice when you were younger? Was it a parent? A relative? A teacher? Chances are you sought out someone who you felt had been through your situation before. Having lived through the situation made that person an expert on the subject.

In project management, you may find you need help in the form of expert judgment. There are various sources of expert judgment for the resource planning needs of your project. Where you go depends on what kind of information you need.

The primary sources of expert judgment in resource planning are:

• other units within the performing organization
  The first place to look for help with your resource planning needs is within other units of your company. Different departments have specialized knowledge, and they can provide you with their resource pool descriptions, work breakdown structures, and scope statements. And remember, when you use company resources, your company saves money by using skills it already pays for.
  

• consultants
  Consultants are another avenue you can look to for help with your resource planning. Consultants focus their knowledge in one specific field. When that field plays a role in your resource planning, you should seek out the person who knows the information inside and out.
  

• professional and technical associations
  Expert judgment can also be found in professional and technical associations. These associations may offer their members up-to-date industry training or provide information on the latest developments in your field. This could be useful for updating organizational policies and as a source of historical information.
  

• industry groups
  Industry groups are another source of expert judgment for resource planning. Industry groups are involved in setting industry standards and lobbying governments, and can refer you to important sources of information relating to your project.
  
  Industry group lobbying may necessitate changes to your company's organizational policies. It may also require you to upgrade staff or equipment. These actions would affect your resource pool description.
  
  Industry groups can also put you in touch with companies you are interested in doing business with, or that have similar interests. If you need specific materials or equipment, your industry group may be able to tell you who to contact. This would impact your resource pool description. It may also influence your scope statement. As you contact more people in relation to your project, you have a better idea of the possibilities.
  

Knowing where to go for expert judgment and advice means that as soon as you need information for resource planning you know where to get it. This saves time for you and your project team.

The Importance of Resource Planning and Acquisition Policies

Organizational policies are the policies of the performing organization regarding staffing and the rental or purchase of supplies and equipment. These policies must be considered during resource planning to ensure that your project will run as smoothly as possible.

Organizational policies are the result of tried and true business practices. Company policies can encompass a wide range of issues from employee benefits to resource acquisition.

Staffing issues are covered by your company's human resource policies. A collective bargaining agreement is a factor that might affect your company's policies. These agreements place restrictions upon employers concerning hours of work, wages, and job security. They can determine overtime, vacation pay, and safety standards. Consider the example of Kurt, a project manager for an appliance manufacturer.

Another example of staffing policies are company hiring policies. These policies may include equal opportunity programs, internal hiring practices, and educational requirements.

Not abiding by these policies can lead to employee dissatisfaction, high employee turnover, and even lawsuits. To avoid these potentially debilitating problems, you will want to commit your organization's staffing policies to memory.

The other policy areas of interest to resource planners are organization's equipment and materials policies. These policies specify how you are to acquire resources from suppliers.

For example, your company may have policies:

• requiring that all suppliers be approved by the Quality Assurance department
• listing preferred suppliers from which you must choose
• regarding each step of the acquisition process.

Other policies may exist to help you decide whether to rent or purchase the necessary materials and equipment. If a project requires equipment or materials for a short period of time, a company may determine it is cheaper to rent rather than purchase the equipment or materials.
Each step of acquiring resources may have an accompanying policy. Make sure you know what your company has determined regarding these resource decisions before you begin. Failure to abide by resource acquisition policies can destroy hard-won relationships with favored long-term suppliers and may result in significant increases in supply costs which could result in project budget overages.

Organizational policies act as a guide to ensure a quality project. They help your project run more smoothly because everyone knows what is expected in terms of resource planning and acquisition. In addition, these policies serve to protect against the negative effects of not abiding by policy, which can include employee lawsuits, damaged relationships with long-term suppliers, and increased project costs.

Planning Resources Using a Resource Pool Description

Before you begin working on a project, you need know if you have the resources to support it. This is where a resource pool description comes in. A resource pool description is a report that gives details about the people, materials, and equipment necessary to complete the project work.

People
To keep track of the human component of your project, you should compile a list of potential human resources. This list should include:

• the person's name
• whether she is an internal or external resource
• her resource type
• her skills
• the company or division she works for
• her supervisor
• her pay rate
• the anticipated project start and end dates
• her availability
• any vacation she may be eligible or already scheduled to take
• additional comments

Your human resource requirements may change as the project progresses and so may not have all the spreadsheet information at project inception, but you should strive to fill in as much information as possible before you begin assigning resources.

Equipment and materials
The information you need for your equipment and materials spreadsheet varies only slightly from your human resource spreadsheet. You would need to know:

• the resource name
• whether the resource is internal or external
• the supplier (source of the resource)
• the rate or cost per unit
• the resource location
• the resource availability
• a contact name
• the resource type
• specifications
• comments

Your resource pool description is not static. The different phases of a project may require different resources. That's why your list of possible resources may change as your project progresses.
You may need a large number of people working on your project to start with. As the project progresses, you may need fewer people, but with highly specialized skills. Or the opposite could happen. This means that you will constantly have to adjust your resource pool description.

Similarly, your project could require completely different equipment or materials, depending on which phase of the project you are working on. Your resource pool description should reflect this.

In addition to keeping track of what resources are "available," you should also keep track of the resources once you use them. This information is needed for accounting purposes and can also be used to estimate future resource requirements for future projects.

Your project plan outlines the type of work your project requires. Your resource pool description allows you to match the right resource to a specific task. As such, a resource pool description is an invaluable tool for the project you are planning now and for those you will plan in the future.

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.

Detailing Supporting Data and Resource Requirements

Have you ever had so much to do that you needed a little extra help? Or have you ever overlooked something that was very important?

Supporting detail and resource requirement updates are two essential outputs from project schedule development that can help you effectively manage your time.

Supporting detail includes all identified assumptions and constraints. Included as part of a project schedule's supporting detail are:

• times when resources are required
• best- and worst-case scenarios
• schedule reserves
• schedule risk assessments

The amount of additional detail depends on the project. If you were to look at the supporting detail for a large construction project, you might see items such as a resource histogram (a graph that shows the amount of project resources), cash flow projections, and an order and delivery schedule.
Whereas, if you looked at the supporting detail for a small electronics project, you might only see a resource histogram.

Have you ever heard the saying "There are no guarantees in life"? Well, the same is true for the life of a project. For this reason, updating the project's resource requirements is a very important component of the project schedule development process.

Throughout the course of your project, events may arise that require the project's resources to be adjusted or activity lists to be updated. Adjustments of this nature will likely have a significant effect on preliminary estimates of resource requirements. Therefore, in order to maintain a degree of accuracy, the resource requirements will need to be monitored and updated to reflect the changing demands of the project.

Vinyl-Win is developing its project schedule for the production of a packaging machine. The project team has been notified by senior management that its client would like two machines instead of one, produced in the same time frame. This change requires the project team to update the resource requirements for the project.

The original schedule includes the resources to develop one machine. The amount of resources is not enough to produce two machines in the same time frame, so the resource allocation will have to be changed. Then the schedule needs to be updated to include the resources needed to produce two machines.

Since change is constant, it is virtually impossible to complete a project without having to make adjustments to the plan. However, understanding the importance of detailing all the project's supporting information will eliminate the need to make changes to your project. This will also reduce the need to update your requirements.

Coding Project Data for Extracting and Sorting

As a project progresses, project managers need to sort tasks based on their attributes. The easiest way to do this is to take advantage of the coding structure capabilities of whatever project management software you are using.

Project activities should be assigned a coding structure that will allow them to be sorted or extracted based on attributes such as, responsibility, geographic area or building, and project phase.

Sorting using the responsibility attribute will provide information about who is responsible for an activity. This may be an individual, a group, or a team.

The geographic area or building attribute tells you where an activity will take place. The geographic area may be a specific location such as the Dickson Building, or a general area such as a client's site.

The project phase attribute refers to a particular stage of development. Sorting by project phase will provide information about which activities will occur during specific phases of the project.

Jennifer is the project manager for BMR Railway's passenger car renovation project. She needs to find out several important details about project activities, and she needs them in a hurry. With a properly configured coding structure Jennifer will be able to quickly sort and retrieve this information.

Using the responsibility attribute, she is able to find out that four activities are being overseen by the project's lead designer.

Using the geographic area or building attribute, Jennifer discovers that 9 out of 10 project activities will occur at the rail yard on Wilber Avenue East.

Using the project phase attribute, Jennifer learns that the seat-recovering activities will be taking place during the second phase of the project.

As a project manager, you will be called on to sort and extract project-related data. By using a properly configured coding structure, you will find you can quickly and easily isolate the information you need.

Deciding if a Project Needs Resource Leveling

Another tool used for schedule development is resource leveling heuristics. The mathematical analysis process often results in the creation of a project schedule that requires more resources than are available at a given time. This is where resource leveling heuristics come into effect.

Resource leveling heuristics is a prioritization process that allocates scarce resources to critical path activities first. In other words, it is a technique that resolves resource conflicts by delaying tasks within their slack allowances.

Projects seldom have an abundance of resources. In many situations, a project will require a critical resource that must be available at certain project points. To ensure availability, the critical resource will need to be scheduled in reverse from the project ending date, this is known as reverse resource allocation scheduling.

To use the reverse resource allocation scheduling method, you must be able to complete the activity with the limited number of resources that are available. For example, the resource requirements for a renovations project indicates that three electrical engineers are needed. However, the project manager discovers that the work, which was scheduled to be done by three people, must now be done by two. The result is that the activity may take three weeks with two engineers instead of two weeks with three engineers as originally planned.

Another method of resource leveling is the resource-based method. This involves looking at the workload for each resource in a given work period and assigning a more realistic workload.

Resource leveling is the activity in which project teams encounter problems when developing their project schedules. If a company has multiple projects running simultaneously that require the same resources, problems can arise. Problems may occur when not enough attention is paid to resource allocations and their conflicts.

When conducting resource leveling heuristics, there are a number of details that must be taken into consideration. Asking the following questions will help you to determine where leveling is required or possible.

Does the activity have slack time?
If activities have little or no slack time, they are usually critical path activities. They are provided with the necessary resource requirements, when possible. If for example, activity A has zero float, activity B has a three-day float and activity C has a two-day float. Activity A is allocated resources first.

Is this activity high priority?
If resources are limited, higher-priority activities are allocated resources before lower-priority activities. Activities that are higher priority are normally on the critical path. For example, if activity D is a critical path activity and activity B a non-critical activity, activity D is allocated resources before activity B.

Can this activity be split?
If resources for an activity are only available at particular times, splitting the activity may be required. For example, the resources for activity E are only available on Mondays, Wednesdays and Fridays. Therefore, the manager must split the activity into three non-consecutive days.

Is this a flagged activity?
If an activity is flagged, it means that a component of that activity has a significant detail attached. Flagged activities have a higher priority than others. For example, a computer design project may require a special part that is only available at a certain time. The activity requiring this part would be flagged.

Can the activity requirements be altered without affecting the overall project?
If an activity can be altered to reflect the availability of resources, then that activity is finished when the resources are available. For example, an activity requires two engineers 100 percent of the time: one is only available 75 percent of the time. The activity will be finished when the other resource is available.

DataWare Software Development (DSD) is currently working on a project to develop education software. The project manager has been informed of both a reverse resource allocation scheduling conflict and a resource-based conflict. He has already determined that each of these activities has slack time and neither is on the critical path.
The resource requirements call for two graphic artists. Unfortunately, only one is available. The project manager will have to perform resource leveling by lengthening the schedule so that the work to be done by two people can be done by one.

The schedule calls for the audio to be recorded for three different projects at the same time. When the project manager applies resource leveling heuristics, these three projects will take three days for audio instead of the one day originally scheduled.

Resource leveling requires a degree of common sense. If an adjustment does not seem realistic, don't make it as it may do more harm than good.

Documents Used to Plan Project Resources

When planning your projects, have you ever wondered whether you have enough resources for the project or whether the resources assigned to the project are able to perform the tasks in the allotted time?

The resource requirements and resource pool descriptions are valuable inputs to schedule development. Together, they will help you determine the resources needed to successfully complete your project.

Resource requirements detail the human and material resource required to complete a given project. In assigning resources to a project, you will want to consider that the duration of most activities will be significantly influenced by the resources assigned to them. For example, three people are required to work on Task 2, from week 6 to week 13. If two are working part-time and the other full-time, the full-time employee will finish twice as fast as the part-time employees.

Project managers use a process called resource planning to determine what physical resources, and what quantities of each, are needed to complete a project's activities. Physical resources include people, equipment, and materials.

When developing a project schedule, you need to know what resources are potentially available. A resource pool description is a list of the resources that will be available, times that they are available, and in what quantities. The amount of detail may vary depending on the project.

Resource requirements and resource pool descriptions go hand in hand for project schedule development. The resource requirements determine what type of resources are needed. Whereas, the resource pool description determines what type of resources are available.

Project Activity Duration Reserve Time

You've probably heard of the Army Reserves. The Reserves are made up of citizens who are trained as soldiers and who can be called upon in situations that demand extra resources.

Similarly, reserve time is added to project activity durations to provide the extra time that may be needed based on identified risks. Risks can affect the project schedule and cause delays. Reserve time helps offset such delays.

Reserve time should be documented along with other data and assumptions relating to the project. Reserve time, like other assumptions, is contingent on project results and subject to change as the project progresses. Two methods you can use to determine reserve time are discussed below.

1. As a percentage of activity duration
Reserve time is normally calculated as a percentage of the estimated activity duration. Using this method, reserve time can be calculated by simply adding an extra percentage to each activity duration estimate.

Reserve time can be reduced or eliminated as specific project information becomes available. Its use is at the discretion of the project team and is normally guided by expert judgment or historical information.

Consider this example. You are managing a road construction project and you have estimated that it will take you 50 days to build an overpass. After consulting with one of your lead engineers, an expert on highway construction, you decide to add an additional 20 percent to the duration estimate as reserve time.

To calculate the reserve time as a percentage of the estimated activity duration, you simply multiply your duration of 50 days by 20 percent. The reserve time for this activity is 10 days.

2. As a fixed number of work periods
Another approach to creating reserve time involves simply tacking on an additional fixed number of work periods to the current estimates for each activity. Work periods are often measured in days, but may vary by project.

Let's say you're managing a similar road construction project and you have estimated once again that it will take you 50 days to build an overpass. This time, though, after reviewing historical information on similar projects, you decide to calculate the reserve time by adding five additional work periods, or days, to your estimate.

If you take into account your reserve time of five work periods, your adjusted activity duration estimate for building the overpass would be 55 days.

Whether you decide to determine reserve time as a percentage of the estimated activity duration or as a fixed number of work periods, make sure you consult with a team member who is familiar with the given activity. This will help ensure that the reserve time you decide upon is as accurate as possible.

When performing activity duration estimates for your project, remember to allow for reserve time to accommodate circumstances that could interrupt or delay the progress of your project activities.

Resource Requirements and Project Activities

How many people does it take to install a computer network, write a user's manual, or analyze a customer's needs? What equipment is needed to deliver a training session? These questions may not be pertinent to every project, but it's important for you to know what physical resources it will take to complete any activity related to your project.

Physical resources can include any or all of the resources listed below, depending on the nature of the project.

• People. This is the most important resource of all. It is also the most diverse resource the manager has to deal with. People come with a wide variety of skills. The manager's job is to match the possible skill sets with the project tasks.

• Facilities. Facilities are where the project activities will be performed. The project manager has to take into account what kind and how many of these facilities are required. Availability of facilities can have a big impact on the project schedule and has to be taken into account.

• Equipment. Specialized equipment may be needed for some projects. This equipment may have to be bought, rented, borrowed, or built. The project manager has to make sure that the equipment will be available according to plan.

• Materials. If a project produces anything tangible, the raw materials to produce the product need to be managed. Materials have to be managed to ensure they are available when needed.

Project managers should develop a list of all the resources needed to complete a project. This list is known as "resource requirements." Resource requirements are descriptions of the types of resources required and quantities needed for each element of the work breakdown structure and are important inputs to activity duration estimating.
Resource capabilities are another input you should consider when estimating activity duration. Resource capabilities can have a direct effect on an activity's duration. For example, a person with more experience and skills will complete a job faster than someone who is unskilled.

The capacity of the materials used for a project also will affect an activity's duration. For example, a machine that runs at only 50 percent capacity will take twice as long to complete the activity as a machine that runs at full capacity.

Resource capabilities not only affect the duration of an activity, but they can also affect the resource requirements. For example, if workers are unskilled, more of them will be needed to complete a project on time. If workers have more experience, fewer people will be needed.

As a project manager, you should look at all aspects of a project's resources when estimating activity duration. Remember, resource capabilities can have a far-reaching effect on the duration of a project activity.

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.

Key Attributes of an IT Project

Lawrence J. Peter once said, "If you don't know where you're going, you will probably end up somewhere else." This is particularly true of an IT project. To ensure the success of your IT project, you need to map out and follow an effective process.

Where do you start? Perhaps the best place to begin is to look at the concept of an IT project. The Project Management Body of Knowledge (PMBOK) is a good source for information on project management in general. PMBOK describes a project as "a temporary endeavor undertaken to create a unique product, service, or result."

Every IT project has five key attributes that play particular roles in project development and completion. Details about these key project attributes are provided below.

1. Purpose
There must be a purpose to justify the need for a project. Many ideas for projects can be discovered through company surveys or questionnaires aimed at determining needs.

For example, in an e-learning corporation, a survey identified a need in the course development department for a program to log and maintain course status records. This will be the purpose of the corporation's next IT project.

2. Length
As noted above, PMBOK describes a project as "a temporary endeavor." In other words, an IT project has set beginning and end dates.

The length of the project will depend on its complexity. For example, a short-term project might be developing a report on a company's needs. A long-term project might be the creation of a database for collecting and generating statistics.

3. Resources
Resources for an IT project can include skilled employees from inside or outside of the company, hardware, software, and other assets as deemed necessary.

4. Sponsors
There may be many interested parties who have a stake in a project, but there is usually only one main sponsor. This main sponsor provides the needed direction and financing for the project.

Non-financial sponsors may be acquired if the project incorporates many departments within a company. For example, if the product of a project will be used by the accounting and human resources departments, it may be necessary to ask experts from each department to provide input to ensure departmental needs are considered.

5. Uncertainty
Every project will face uncertainty. Anything can go wrong. Although efforts should be made to ensure that the IT project plan is concise, factors such as time and cost can change due to unforeseen circumstances.

Key attributes are an important aspect of every project. Keeping these attributes in mind throughout the project can help you and your team meet established goals.