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.
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