In Software Project Management, Risk is Everything

Posted by Keith McMillan

September 15, 2008 | Leave a Comment

We got into an interesting conversation at work the other day regarding the role of risk in an agile project. Perhaps I have an extremely broad definition of risk, but I believe that risk is a primary, and perhaps the most important, thing to consider when running such a project.

Risk can take on a number of facets.  PMI defines both negative and positive risks, which I think is a bit wierd myself, but I think most things I do during a project can be related back to addressing a risk. Let’s take a look at some activities, and how they relate to risks.


This is perhaps an obviously risk-related activity, but I thought I’d pitch a softball for the first one.  Testing is designed to address the risk of building software that produces incorrect results, or otherwise doesn’t work.  Performance testing addressess the risk that we make software that takes too long to work.  Testing helps us reduce this risk.

Software Architecture and Design

Software architecture and design are the activities of thinking about the problem you’re trying to solve, and creating structures that can be used to represent the problem, and it’s solution in software.  If we don’t do software architecture, some high-level thinking about how we can structure a solution to meet the main demands of the software, then we run the very real risk of producing software that is expensive to build, because of extensive refactoring, or that is expensive to fix, extend, and otherwise maintain.

Prioritizing Requirements

Prioritizing our requirements addresses the risk that we build functionality that isn’t as beneficial as other functions we could have built instead.  It also addresses the risk that we may be viewed as producing less value, and our project may be cancelled as a result for showing poor results.

Continuous Integration

Continuous Integration is the practice of regularly reconciling your code with the rest of the team.  Good CI environments automatically build the software product when code is checked in, run regression tests, and notify the team if something breaks.  CI addresses the risk that we build on unstable foundations because we didn’t detect an inconsistency as soon as we could.  It also addresses another risk: if it’s been an appreciable amount of time since we checked in a change, and we are notified that something we did was broken, we need to remember what we did, and then figure out how to fix it.  If we’re notified right away, then it’s much easier to remember what you just did to the source code.


Documentation is the project’s way of communicating information to people who are separated from the team in either time or space (or both). We may document high-level design in order to communicate it to those who come after us, or requirements to provide a good basis for an outsourced development effort.

Mistaking Form for Function

The subject of documentation raises a good point. Agile projects favor face-to-face collaboration over documentation because it’s a more effective form of communication.  Sometimes, however, we need documents.  We get into trouble when we forget why we’re writing documents (to reduce a particular risk), and think our goal is the document itself.  If we’re not reducing a risk by documenting, we shouldn’t be documenting.

This really applies to all risk reduction activities, and it’s really why the software industry sometimes seems like it’s such a mess.  If we forget the goal is to have working software that produces value for the business, then everything else is just a step along the way.  When we put work into creating a deliverable such as documentation, design or test plans, we should be sure that we’re really reducing a risk, and that the cost of reducing the risk is less than the cost of leaving it alone.

I’ve had people take issue with my belief that risk is such a key activity in software project management.  Because of my broad definition of risk, everything from creating software with less than maximum return on investment, to producing software that’s expensive to maintain, to building broken software, I can rephrase most project activities in terms of what I percieve of as risk.


RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.