There is a degree of risk in everything we do, from getting up in the morning to deploying a multi-million dollar project that has high visibility and criticality. Software project management is basically an exercise in risk management. And how you identify and handle risk on a project has a direct impact on the success of the project.

One problem is that people often recognize risks intuitively but really don't have a good framework in which to identify and manage them. Another problem is that risks come in unknown quantities, and there is always the possibility that we'll get burned by unexpected situations that aren't on the assessment or watch list.

Risk Perspectives
I've learned to keep three perspectives of risk firmly in view. If I focus on any one of these at the exclusion of the others, I'm setting myself up for problems. Even worse, if I ignore any or all of these perspectives, then I'm really in trouble!

• The project perspective-This gives me a proactive way to determine if the project is likely to succeed or fail based on past lessons learned or project success factors. It can include things such as levels of leadership, customer involvement, scope of impact, etc.
• The technical perspective-This lets me see where risks may exist in a system or project. Technical risks allow me to prioritize testing to focus on the critical features of a project. For example, I will want to focus on the nuclear reactor shutdown sequence more than the functions for reporting daily tasks completed
• The business or mission perspective-This allows me to determine the criticality of a function or service to the people I serve vicariously through the system. For example, will a feature have private information that must be kept secure? How many people will a function impact? Does the feature give our business a competitive advantage? 

A Project View of Risk-From a Different Angle
To discuss all of the aspects of these risk perspectives could take longer than we have in this article. So, I want to deal with a perspective of risk that is often minimized-the project perspective.

When people do perform a project risk assessment, they typically do it once during the project. This is unfortunate, because risks change constantly throughout a project. These types of risk assessments typically look at how the project is conducted, which is important. However, I want to explore an angle that I have found to be very helpful in keeping a project on track from a quality perspective and that can directly intersect with testing.

Critical Success Factors
On any given project, there will be certain success criteria. For example, on most projects correctness is high on the list. You also may find other factors such as usability, security, reliability, performance, maintainability, and portability. These often are called "non-functional" attributes since they relate more to what the system or application should "be" rather than what it should "do."

These envisioned success criteria often are called critical success factors (CSFs). Although they could number over ten for some projects, the workable number to assess is in the six to eight range. Keep in mind that each CSF has a distinct focus and associated needs (people, tools, processes, etc.) to make it a reality.

So, make your list, and then prioritize it carefully (a mini risk assessment).

A Team Approach Is Good
I like to form a small team of four to six people who conduct this type of risk assessment. First, they discuss the definitions of risks to avoid rating too many risks as "high." Then you get the chance to have people involved from the various project roles, such as developers, testers, and project managers. Finally, the team helps to carry the workload-although this is not a heavy process.

Tip: Try to keep the same assessment team intact for the entire project, since the assessment will need to be performed-or at least updated-throughout the project. Continuity is a good thing!

Ask the Right Questions

The key to performing this assessment is found in the questions asked for each CSF. Your goal is to discover whether or not the right things are being done to achieve each success factor. Conversely, you are also trying to discover if the wrong things are being avoided.

Instead of thinking of these questions on the spot, I prefer using a predeveloped questionnaire. Besides the reusability and consistency of the questionnaire, another advantage of this approach is that it allows me to conduct either an interview or a survey, depending on which is the most appropriate for the time at hand.

As an example, let's take the most common CSF, correctness. Your goal is to assess the ability of the project to deliver a correct system or application. Therefore, the questions you ask people should directly pertain to this factor. Examples include:

• Are user requirements defined in writing for all features?
• Are reviews or requirements performed consistently?
• Is unit testing performed consistently? 

You will notice that these are all yes-or-no questions. That's because I like to keep the assessment simple. You may find that a one-to-six scale works better for you, especially if the answers aren't so well defined in your situation.

You'll also notice that some of these questions aren't answerable early in the project. That's why you will need to revise your questions, depending on when in the project you ask them.

Quantifying the Responses
Although you could get some value from just asking the questions, I like to make this assessment a dashboard item. To do this, you need to quantify the questionnaire results.

First, assign a weighting factor to each question. I use a range from one to five, where one is the least important question and five is most important.

Then, when the questionnaire has been completed, you take the score for each question and multiply it by the weighting factor. A "no" response on a question gets a score of zero.

Finally, sum the multiplied scores and divide by the total possible score to get a percentage score for the critical success factor. For example:

Eight divided by twelve yields a score of 67 percent.

Now, continue this process for all the CSFs you wish to assess. If you use a survey approach where several people are completing the questionnaire for the same CSF, you can average the final percentage score.

Getting Visual

To present the assessment results in an easy-to-understand fashion, I use Kiviat charts. Some people call this chart a radar chart.

Each CSF is shown on a separate spoke, with the percentage scores shown on concentric circles, as shown in figure 1.
 

Figure 1: A Sample Kiviat Chart

The beauty of the Kiviat chart is that it immediately reveals two things: 1) the degree of coverage and 2) strengths and weaknesses. In this example the coverage isn't all that great, and we see two major weak points: security and compatibility.

Another benefit of Kiviat charts is that you can place them in a dashboard or presentation and explain them quickly.

All of this information is great, but unless action is taken, little value will be seen.

Conclusion
As the project progresses, you should see the chart become more filled and the gaps eliminated. Remember that risk assessments are snapshots at any given point in the project. Since the risks change, you will need to perform multiple assessments throughout the project.

Also, keep in mind that any risk assessment can contain errors, biases, and misassumptions, so use your intuition and contingencies to balance this possibility.

This view of risk assessment is one that can keep your project on track, yet it seldom is performed on projects. If it is performed, it is presented at the end of the project. This is the one perspective that senior management and stakeholders need to see. Ideally, this type of risk assessment should be owned by the project manager, who is in the best position to take action.

I hope this adds a helpful, risk-based tool to your collection. For me, it has been very valuable
.