Certification Objective 2.04: Identifying Key Project Risks


Any event that can have an adverse affect on a project is a risk. It might seem odd to start off a project by thinking about all the things that can go wrong. After all, the whole purpose of following a proper design and development methodology is to ensure that nothing goes wrong. However, things can and will go wrong on any project. If you follow a proper design process, you will have predicted in advance everything that could negatively impact the project, and you will have worked toward minimizing the probability or impact of these events. The goal of this step of the envisioning phase is to identify the most likely or serious risks to the project. Once those risks have been identified, you can figure out how to avoid them during the planning phase of the project.

The results of this initial risk assessment should be saved in a “risk assessment document.” This document is the third of the three deliverables that are produced during the envisioning phase. The other two documents deal with project structure and vision/scope, and were discussed earlier in this chapter.

When you think about it, there are many things that can have an adverse affect on a project. For example:

  • A key team member could leave the company or suddenly be transferred to another project (a people risk).

  • The development phase may take longer than planned because of the number of new skills the developers will have to learn (a people risk).

  • The product might have several bugs due to an overly aggressive schedule (a process risk).

  • Government regulations for this product could change between now and the delivery date (an environmental risk).

All of these examples are considered risks to the project. Of course, not all of these risks are considered equal, as we will see later in this section.

The MSF risk management discipline lists over 20 potential sources of risk, broken into four major categories. This list should stimulate a project team’s planning when thinking about risk. Consider each category carefully and identify any risks (whether they are likely or not) that could affect the project. Table 2-2 lists what Microsoft suggests are the potential sources of risk in a project.

Table 2-2: Categories and Potential Sources of Risk

Risk Category

Risk Source

People

Customers
End users
Sponsors
Stakeholders
Personnel
Organization
Skills
Politics
Morale

Process

Mission and goals
Decision making
Project characteristics
Budget, cost, and schedule
Requirements
Design
Building
Testing

Technology

Security
Development and test environments
Tools
Deployment
Support
Operational environment
Availability

Environmental

Legal
Regulatory
Competition
Economic
Technology
Business

It is often a good project team exercise to try to list as many potential risks to the project as you can. This can be during a brainstorming session where the project team sits in a room and all risks are listed on a whiteboard. All potential risks should be considered. At this stage, be very careful when dismissing risks that have not yet been assessed.

The next step is to assign probability and impact values to each of the risks that have been identified. The probability of each risk occurring is listed either as a percentage or as a numerical value from one to ten. An impact value also needs to be assigned, and it represents how serious the potential effect on the project will be if the risk occurs. Impact is listed either as a value from one to ten or simply as “low,” “medium,” or “high.”

Exam Watch

A project risk is anything that can negatively impact the project.

At this point in the process, we have identified the project risks and assessed the probability and impact of each risk on the project. Table 2-3 provides an example of such an assessment.

Table 2-3: Project Risks Example

Risk

Probability (1–10)

Impact (1–10)

Lead developer suddenly leaving the team

3

7

Long development phase due to learning curve on new skills

7

5

Overly aggressive schedule

7

7

Change in government regulations

3

3

Of course, most projects have many more potential risks. Large and complex projects potentially can have dozens of risks; and any time one project is dependent on another for information or resources, there is the potential for even more risks.

You may feel as though you are going overboard with the number of risks you are considering, but that’s okay because you have to evaluate the potential for catastrophic events to occur, such as a server hardware failure or a key vendor going bankrupt. From experience, I would suggest that some risks could be grouped together if they are closely related. For instance, you do not have to consider the failure of the web server and the database server separately—they can both go under the general risk of “server failure.” Some sense of reasonableness should exist in the list of risks, however. Some risks, such as the destruction of the planet Earth, are too catastrophic to consider. If that happens, we will have bigger problems to worry about than missing the delivery schedule for our infinitesimally unimportant little project.

Of course, there is a way to distinguish between unlikely but severe risks and those that are more likely but will cause only mild impact. There are many ways to do this, but I usually add a third column to my table that multiplies the probability and impact values together to come up with a measurement of total risk. Table 2-4 shows how the preceding example (see Table 2-3) looks with the inclusion of the total risk calculation. I have resorted the table, placing the risks in order of severity from top to bottom.

Table 2-4: Project Risks Example Including Total Risk Calculation

Risk

Probability (1–10)

Impact (1–10)

Total Risk (P I)

Overly aggressive schedule

7

7

49

Long development phase due to learning curve on new skills

7

5

35

Lead developer suddenly leaving the team

3

7

21

Change in government regulations

3

3

9

As you can see, an overly aggressive project schedule is the most serious risk this project faces. There is also a serious risk that the development phase will take longer than normal due to a steep learning curve for some developers. These risks are related, but the project schedule could still be considered aggressive even with experienced developers working on the project, so solving one risk does not solve the other. This type of risk assessment gives the project team leaders a useful “heads up” to potential problems down the road.

Exam Watch

The three documents that get created during the envisioning phase in the MSF process model are the vision/scope document, the risk assessment document, and the project structure document.

Case Study: Identifying Key Project Risks for the RPM System

In Chapter 3, you will learn about gathering and analyzing business and user requirements. As you will learn in that chapter, the business requirements document is a definitive list of what operating tasks the user expects the system to perform. Having an intimate understanding of this document is crucial for the success of the project; however, there are other important factors in order for a project to be able to succeed.

Oftentimes, mitigating the possible events that could cause serious harm to the project—the project risks—are not explicitly listed as a business requirement, although protecting the project from those risks is one of the important tasks of the project team. For the RPM system, Jack can identify three project risks.

First, the project team has not been identified, which could delay the start of the planning phase of the project. Jack’s boss assures him that this will be taken care of, but it is still a risk. Jack assigns a probability of 2 out of 10 to this risk, but the impact would be a 7, so the total risk is be 2 7, or 14.

Second, the new promotion types have not been identified, which could necessitate changes to application design in a later release. Since the new promotion types are not needed until a later version of the application (the first version will handle only coupons), it won’t have a big impact now. Jack assigns this a probability of 5, but an impact of only 1, so the total risk (5 1) is only a 5.

Scenario & Solution

What is the high-level outline of a solution called?

Solution concept

What type of feasibility examines the skills of the project team?

Availability of resources

What milestone of the envisioning phase applies time and budget realities to the project vision?

Scope

Third, since the application is being developed in .NET, Jack worries that the developers might need to be sent to a training course before project development can begin. In part, this relates to the first risk in that the development team hasn’t been identified. He thinks this should be listed separately, however, because even if the project team members are identified tomorrow, they still might need to be trained. Jack assigns this a probability of 6 and an impact of 3, for a total risk (6 3) of 18.

Those are the only risks Jack is able to come up with for this project. Of course, as the project progresses, other risks may be identified and need to be addressed. All of the risks seem manageable to him, and he’s confident the project will be a success.

In the next chapter, we will complete the envisioning phase of the project and begin the planning phase. We will see how analyzing the business, user, and operational requirements is key to proper application design.




MCSD Analyzing Requirements and Defining. NET Solutions Architectures Study Guide (Exam 70-300)
MCSD Analyzing Requirements and Defining .NET Solutions Architectures Study Guide (Exam 70-300 (Certification Press)
ISBN: 0072125861
EAN: 2147483647
Year: 2003
Pages: 94

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net