Friday, March 27, 2009

The Benefits of a Risk Database

William Pollard, a businessman and author, once said, "Information is a source of learning. But unless it's organized, processed, and available to the right people in a format for decision making, it is a burden, not a benefit."

A risk database is a repository that can organize, process, and format the information that is collected and used in the risk management processes. The use of a risk database throughout a project's life cycle will make documented information easily accessible for important decision-making purposes.

Project risk information that you may need to store in a database could include agreements, current priorities, specifications, project plan changes, instructions, results, and other information depending on the nature of the project.

You must enter information into the database on a regular basis so that this information is up to date.

You can use a risk database not only for storing and retrieving data, but also for analysis. A database can sort information into categories and generate reports based on what you need to know.

The database can perform complicated calculations in seconds, which provides information that may help decision makers avoid mistakes. You can analyze project information for risks and alert team members about any emerging risks.

Over time, your company will gain experience in keeping track of project risks in a risk database. This documentation can be compiled for a single project or across similar projects, and be used as lessons learned for future projects. Prior to planning new projects, team members can search through the lessons learned to avoid making similar mistakes.

You can use a risk database to help you avoid mistakes and plan effectively for future projects. A risk database can organize and format information so that it is a learning source to help you make important project decisions.

Monday, March 23, 2009

Updating Risk Identification Checklists and Response Plans

Have you ever tried to follow a plan only to find that the plan wasn't up-to-date and contained inaccuracies? For a plan to be effective, it must be kept current. New information, changes, and corrections have to be made in a timely manner to prevent inappropriate actions being taken on inaccurate or outdated information.

When monitoring and controlling risks, documentation is especially important because project managers and teams use risk documentation to:
  • track risks
  • to identify new risks
  • to plan additional risk responses
  • to record any actions taken to control risks
If the information being acted on is not current, a new risk is introduced—the risk of acting on inaccurate or outdated information. To avoid this confusion, you must strive to keep all documents up to date.

Two of the most important documents to keep current are the risk identification checklist and risk response plan.

Risk identification checklists
Risk identification checklists describe the criteria used to identify new risks. Project team members should use the experience gained during their projects to update the checklists. This will make the checklists more effective for use in the risk management of future projects.

Risk response plans
The risk response plan is a document that describes in detail what actions should be taken in response to specific risks. Since the risk response plan acts as a guide to risk monitoring and control, the project team should update it regularly to keep everyone equally informed.

There are many elements that you can include in updates to risk response plans. Usually updates are the product of an action or event that changes the risk situation of the project. In some cases, the fact that an action was not taken leads to the need for an update. Some of the common elements included in updates to a risk response plan are:
  • Implementing risk controls - The implementation of risk controls may reduce the impact or probability of identified risks. Documenting the implemented risk controls will provide the project team with the information it needs to change its future expectations for particular risks.

  • Changing risk rankings - Risk rankings change throughout the project's life cycle. You should document these changes so you and your team can properly control higher ranking risks.

  • Closing risks - Risks that do not occur and that are no longer considered a threat should be documented and closed in the risk response plan.
Updating documentation can help avoid confusion and keep everyone on the project equally informed. The information added to the documentation will help you prepare for similar risks that may occur in future projects.

Wednesday, March 18, 2009

Processing Project Change Requests

Imagine that your project has just encountered a risk. You have implemented a workaround to control the risk, but the cost of the workaround will affect the project budget. What should you do to ensure that this change is incorporated into the project plan?

When the members of the project team determine that changes must be made to compensate for controlling risks, they issue a project change request. Project change requests are used to recommend changes in project scope, budget, schedule, or quality. There are various types of change requests including oral or written, direct or indirect, externally or internally initiated, and legally mandated or optional.

Regardless of the type of project change being requested, either the person requesting the change or a project team member will have to fill out a project change request form. The form should include the project name, client name, who requested the change, a description of the requested change, the reason for the change, the impact of the change, and whether it is accepted or rejected.

Project change requests are processed using integrated change control. Integrated change control is concerned with maintaining the project scope and the project's integrated performance baseline. Its ultimate goal is to accept or reject project change requests.

Integrated change control is achieved in a series of five steps.
  • Step 1: Submit the change request.
    The process is initiated by the submission of a project change request. The person requesting the change, or a project team member, should fill out the project change request form.

  • Step 2: Record the request in the project change request log.
    Once the project manager receives the change request, he records it in the project change request log. This log keeps track of change request submissions and the status of those requests.

  • Step 3: Assess the impact of the proposed change.
    One or more of the project team members must assess the impact that the proposed change will have on the project as a whole. Project changes may affect many project areas, such as the scope, budget, schedule, quality, and objectives.

  • Step 4: Make recommendations whether to accept, reject, or modify the request.
    The people who were in charge of the assessment will make recommendations about whether to accept, reject, or modify the change request. They will base these recommendations on the validity of the request and its impact on the project.

  • Step 5: Decide whether to accept or reject the request.
    The project authority will use the recommendations to decide whether to accept or reject the project change request. Rejected requests will be closed and filed. Accepted requests will be incorporated into the project plan.
Project change requests are processed through the integrated change control process. This process leads your company to make informed decisions on whether or not change requests should be incorporated into the project plan.

Monday, March 16, 2009

Managing Risk with Contingency Plans and Workarounds

Eleanor Roosevelt once said, "What you don't do can be a destructive force." This is especially true in terms of risks. Leaving risks to run their course without taking action can be very destructive to your project.

When a risk occurs, you must take corrective action to harness the risk and lead it down the least destructive path. In project risk monitoring and control, two of the most helpful forms of corrective action are contingency plans and workarounds.

Contingency plans
Contingency plans are management plans that identify alternative strategies project teams can use to ensure project success if specified risk events occur. They are developed before the risk occurs and are used if the original risk response is not effective. Contingency plans go beyond the original risk response to address "what if" scenarios that may further complicate risk control efforts. Risks that pose a significant threat to the project should have a contingency plan.

Contingency plans should contain information such as the plan's objective, criteria for implementation, roles and responsibilities, and the details for implementation.

Untouchable Tires is producing winter tires to stock its retail outlets. During this project, the company has encountered a major risk. The employees have gone on a strike that has lasted longer than the company had originally anticipated. The original response was to negotiate with the employees to get them back on the job as soon as possible.

To ensure that production deadlines are met and that retail orders can be filled, the company reassigned the work that would be done at this factory to other factories nearby. It will make production more expensive, but it will help meet the deadlines.

Workarounds
Another type of corrective action is a workaround. Workarounds are unplanned responses to emerging risks that weren't accepted or identified. Workarounds give you a way to "work around" the problem and as a result, reduce the effects that the risk has on the project. Workarounds should not be applied without documentation. Since using workarounds may have a positive or negative effect on the project, you need to incorporate them into the project plan and risk response plan.

Corrective action is any action taken to bring expected future project performance in line with the project plan. Implementing corrective actions such as contingency plans and workarounds will help your company keep its project performance in line with the project plan.

Thursday, March 12, 2009

Two Indicators of Additional Risk Planning

When you build a house, many factors can cause construction to veer off track. Similarly, in project management, there are many risks that can affect the progress of a project. The risk monitoring and control process watches for signs that a project is going off track so project managers can do additional planning to regain control of the risk.

Two signs that may indicate the need for additional risk response planning are: the occurrence of an unanticipated risk and a risk having a greater effect on a project than expected.
  • the occurrence of an unanticipated risk
    When an unanticipated risk occurs, you must do additional risk response planning. Since unanticipated risks are not covered in the initial risk response plan, the project team will now have to decide on a strategy to deal with the risk. The most common risk response strategies include avoidance, transference, mitigation, or acceptance.

    • Avoidance - is a strategy that requires changing the project plan to eliminate the risk. This is done to protect the project from the potential effects of the risk. A team might reschedule an activity to avoid the risk of having resources spread too thin.
    • Transference - is a strategy that does not eliminate the risk but moves the ownership of the risk to a third party. This third party is then responsible for the management of the risk. A team might transfer a financial risk by paying a premium to insure against the risk.
    • Mitigation - is a strategy that attempts to reduce the risk to a manageable level. Early actions will reduce the probability of the risk occurring. A team might add more time to its schedule to reduce the effects of a risk.
    • Acceptance - is a strategy that indicates that the project team has decided not to take any actions in regards to this risk. For example, a team might decide to accept the effects that an employee strike will have on the project if it occurs.
  • a risk having a greater effect on a project than expected
    The second sign that additional risk response planning is necessary is a risk that has a greater effect on a project than expected. In this case, the planned response was implemented but was not effective in controlling the risk. If there is no contingency plan in place, the project team must then reevaluate the risk response and decide what changes need to be made to gain control of the risk or to better control the risk in the future.
Skilled project managers look for risks that have a greater effect on the project than expected. They also look for unanticipated risks. Learning to recognize these signs that additional risk response planning is necessary will help you gain control of project risks and increase your chances of achieving your project objectives.

Friday, March 6, 2009

Using TPM Analysis to Identify Technical Risks

Marcus, a project manager at Playerz Gaming, Limited, is working on the development of a new search and destroy mission-oriented game. The game is projected to hit store shelves within the next nine months. There is still much work to be done before the project enters the final testing stages.

Recently, Marcus discovered that a technical component of the game is not yet functional. This upset Marcus because it could mean a project delay of up to six months. How could this risk have been monitored and controlled sooner?

Technical performance measurement (TPM) is an analysis and control technique that can help identify technical risks so that action can be taken sooner rather than later. TPM compares technical accomplishments during the project to the expected accomplishments in the project plan. TPMs provide an early warning of deviations from the project plan. For example, a deviation could be a technical parameter that does not demonstrate functionality as planned. Uncontrolled deviations can affect project success.

TPMs include a variety of performance measures depending on the project's content. Performance measurements that are common to all projects include cost and schedule variances and performance indices.

There are three basic steps involved in TPM analysis.
  • Step 1: Choose technical performance parameters.
    The first step is to choose your technical performance parameters (TPP). You should choose TPPs to measure based on the risk areas of your project. More parameters should be chosen from project areas that are considered high risk than from other areas. This will ensure that these areas are being measured effectively.

    Choosing TPPs is not always an easy task. You must be careful to choose parameters that your project team can measure, but also monitor over a period. For example, the survivability of a product under adverse conditions may be a product requirement. Survivability itself is not particularly measurable, but there may be other TPPs—like product speed, weight, and power—that your team could measure to indicate the survivability of the product.

  • Step 2: Record actual performance.
    The second step of TPM is to record actual performance. The actual performance of the TPPs will be measured at specific intervals over the life of the project and will be recorded in the form of a graph. TPPs are generally measured in units such as speed, weight, size, power, or number of units completed. The risk management plan will state when you should measure the parameters and how to record the measurements.

  • Step 3: Compare actual versus expected performance.
    The third step for TPM is to compare actual versus expected performance. In order to monitor and control the technical risks, you must compare the results from the actual performance measurements to the expected results and graph the results for each TPP separately.

    To monitor the progress of TPPs, you should perform this comparison of actual versus expected performance periodically. This will allow you to take steps to control any TPPs that are deviating significantly from the expected performance.
How can you tell when a TPP is a risk? You must look at where the achieve-to-date line falls on the graph. Lines that are outside of the tolerance band are already considered risks. Lines that are inside of the tolerance band, but are moving away from the planned value line toward the outside of the tolerance band, are potential risks. Lines that are steadily within the tolerance band or are moving toward the planned value line are not considered risks.

Knowing how to interpret TPM results can help you monitor and control technical risks. This will allow you to be proactive and implement controls sooner rather than later.

Monday, March 2, 2009

Using EV Analysis to Monitor and Control Risk

Did you know that you can use earned value analysis to monitor and control risks? Earned value analysis is traditionally used to monitor overall project performance against a baseline plan and to identify any deviations from the plan. In keeping track of these deviations, you will also help your company to monitor and control project risks, which increases your chances of a successful project.

Earned value analysis calculates whether the work for a given period is accomplished as planned. This type of analysis uses three key values: earned value, actual cost, and planned value.
  • earned value (EV) - EV is the budgeted value of work actually completed in a given period of time. It answers the question: "How much work is done and what was the original budget to complete that work?"

  • actual cost (AC) - AC is the total of costs incurred in accomplishing work on an activity during a given period of time. It answers the question: "How much has it cost to complete the work that has been done so far?"

  • planned value (PV) - PV is the portion of the approved cost estimate budgeted for an activity during a given time. It answers the questions: "What should the work planned for this period cost?" and "How much work should be done by now?"
The formula for calculating earned value is:

EV = PV x % Work Complete

EV is the PV of your project multiplied by the percent of work complete. The PV is in the project budget and you can determine the PC by dividing the amount of work completed by the total amount of work that is expected to be completed during this time period.
With a good basic understanding of these key values, you can move on to performing the calculations used in earned value analysis. A careful interpretation of the results will help you determine if additional risk identification and analysis is required.

To determine whether your project requires additional risk identification and analysis, you must calculate four performance measurements.
  1. cost variance (CV)
  2. schedule variance (SV)
  3. cost performance index (CPI)
  4. schedule performance index (SPI).
CV is the difference between the budgeted value of work actually completed and the total of costs incurred to complete that work in a given period of time. The formula is:

CV = [(EV - AC) / EV] x 100

SV is the difference between the budgeted value of work actually completed and the amount the company planned to spend to complete the work during a given period of time. The formula is:

SV = [(EV - PV) / PV] x 100

The last two performance measurements are ratio expressions of CV and SV. CV and SV tell you the percent that your project varies from the baseline, while the CPI and SPI tell you how efficiently the work has been performed.

CPI is the cost efficiency ratio of earned value to actual costs. The formula is:

CPI = EV / AC

SPI is the schedule efficiency ratio of earned value accomplished against planned value. The formula is:

SPI = EV / PV

Once you have calculated the results for CV, SV, CPI, and SPI, they must be interpreted. This is the information the company needs to decide whether additional risk identification and analysis is necessary.

When analyzing the CV and SV for a project, you must look at how close to zero the results are. A result that is equal to zero indicates that the project or activity is performing as estimated. A result that is greater than zero indicates the project or activity is ahead of the estimates. A result of less than zero indicates that the project or activity is behind the estimates. When the result varies significantly above or below zero, additional risk identification and analysis may be necessary.

When analyzing CPI and SPI for a project, you must look at how close to one the result is. A result that is equal to one indicates that the project or activity is performing as estimated. A result that is greater than one indicates that the project is performing ahead of the estimates. A result of less than one indicates that the project is performing behind the estimates. When the result varies above or below one and exceeds the company's predetermined acceptable range, additional risk identification and analysis is necessary.

Earned value analysis can help you determine when additional risk identification and analysis is necessary. Being able to perform the calculations and interpret the results will help you handle and control project risks properly.