A Project View of Risk: Will Your Project Deliver?

[article]
Summary:
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.

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

User Comments

4 comments
Kevin Robertson's picture

Nice job Randy; this is succinct and usable. Risk management made simple!

May 17, 2007 - 1:59pm
Kevin Robertson's picture

Nice job Randy; this is succinct and usable. Risk management made simple!

May 17, 2007 - 1:59pm
Kevin Robertson's picture

Nice job Randy; this is succinct and usable. Risk management made simple!

May 17, 2007 - 1:59pm
Kevin Robertson's picture

Nice job Randy; this is succinct and usable. Risk management made simple!

May 17, 2007 - 1:59pm

About the author

Randall W. Rice, CTFL's picture Randall W. Rice, CTFL

Randall Rice is a practitioner, trainer, and consultant in the field of software testing and software quality assurance. He is co-author of Surviving the Top Ten Challenges of Software Testing and the forthcoming book Testing Dirty Systems. Randy is a regular speaker at STAREAST, STARWEST, and EuroStar conferences. You can reach him at rrice@riceconsulting.com or by visiting www.riceconsulting.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Aug 25
Aug 26
Sep 22
Oct 12