Project completed on schedule
Project completed 10 days late
Project completed 20 days late
The project manager, then, is faced with a decision about whether the project team should conduct a full systems test as planned or shorten the time originally allocated to testing. The cost of a full test will be $10,000; but the project manager believes that there is a 95 percent chance the project will meet the quality standards set forth by the client. In this case, no additional rework will be required and no additional costs will be incurred. Since there is only a 5 percent chance the system will not meet the standards, the project manager believes that it would only require a small amount of rework to meet the quality standards. In this case, it will cost about $2,000 in resources to bring the system within standards.
On the other hand, the shortened test will cost less than the full test and bring the project back on track. But, if the project team limits the testing of the system, it will very likely lower the probability of the system meeting the quality standards. Moreover, a failure will require more rework and cost more to fix than if these problems were addressed during a full testing of the system. As you can see from Figure 8.5, a limited testing of the system will cost only $8,000, but the chances of the system failing to meet the quality standards increase. Moreover, the time and cost to complete the rework will be higher.
Even though the project manager still has a difficult decision to make, it now becomes a more informed decision. If the project team continues with the testing activities as planned, there is a very good chance that the system will not require a great deal of rework. On the other hand, reducing the time to test the system is more of a gamble. Although there is a 30 percent chance the limited testing will save both time and money, there is a high probability that the system will not pass or meet the quality standards. As a result, the required rework will make the project even later and more over its budget. If you were the project manager, what decision would you make?
Risk Impact Table We can create a risk impact table to analyze and prioritize various IT project risks. Let's use another example. Suppose a project manager has identified seven risks that could impact a particular project.
The left-hand column of Table 8.4 lists the possible risks that were identified using the IT project risk framework introduced in the last section. For simplicity, we will focus only on risks in terms of threats, but opportunities could be analyzed and assessed using the same technique.
The second column lists the subjective probabilities for each of the risks. In this case, the probabilities do not sum to 100 percent because the risks are not mutually exclusive. In other words, none, some, or all of the risk events could occur. A probability of zero indicates that a probability has absolutely no chance of occurring, while a probability of 100 percent indicates an absolute certainty that the event will occur. The next column provides the potential impact associated with the risk event occurring. This also is a subjective estimate based on a score from 0 to 10, with zero being no impact and ten having a very high or significant impact on the project.
Table 8.4 IT Project Risk Impact Analysis
Key project team member leaves project
Client unable to define scope and requirements
Client experiences financial problems Response time not acceptable to users/client
Technology does not integrate with existing application
Functional manager deflects resources away from project
Client unable to obtain licensing agreements
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.