Beginning to think about risk management in Agile projects

Three books on Agile risk management
Of course, there is always a risk that I don’t find the time to read all of these

I’ve been thinking a lot about risk in Agile projects recently. It is something that I’ve known for a while we need to manage better. Here’s some of what I’ve discovered so far.

A few months ago I attended a three-day training course on portfolio, programme and project offices (P3O). It was fascinating and introduced me to, among other things, the P3M3 — because what we really need at St Andrews is more abbreviations! — which is the portfolio, programme and project management maturity model.

I was immediately interested in the — abbreviation warning! — PjM3, the project management maturity model, and used it to evaluate how we manage projects. Within this model, project management is broken down into seven elements:

  1. Management control
  2. Benefits management
  3. Financial management
  4. Organisational improvement
  5. Risk management
  6. Organisational governance
  7. Resource management

Each element is marked out of five, and a team’s overall performance is judged on the lowest score. So, for example, if a team scores 3/5 for the first six elements but scores only 1/5 for resource management then the overall score is 1/5. A team is only as strong as the weakest link, and all that.

As I predicted, we scored lowest (1/5) for both benefits and risk management; everything else was 2/5 except organisational governance (3/5) because of the work done to create the DCPB (digital communications portfolio board).

Risk management is one aspect of project management that we really need to improve. In Brilliant Project Management, Stephen Barker and Rob Cole define risk as “an event that may occur and if it does will threaten the successful delivery of the project” (p.32). In other words, it is something bad that predictably may happen. In risk management you try to anticipate what these bad things may be and work out both how you might try to prevent them from happening in the first place, and also what you would do if it did happen.

Types of risk

When beginning to think about how we might better manage risk within Agile projects, I’ve found the booklet Agile Risk Management and DSDM by Alan Moran very useful.

In that pocketbook Moran categorises six sources of risk:

  1. Requirements
  2. Technical
  3. Schedule
  4. Project (approach)
  5. Supplier
  6. People

From a starting point of low maturity in risk management, I find these categories to be a little broad, so I have been supplementing this list with one found in the book Brilliant checklists for project managers by Richard Newton (Pearson, 2011) which includes among others stakeholder management, communications, impact of other projects or programmes.

Principles of Agile risk management

What I have found really helpful, though, are the three principles of Agile risk management that Moran offers. These are

  • Flow
  • Balance
  • Transparency

Flow is about ensuring that events (incidents and problems) do not inhibit or delay project progress. To help create a sense of flow, appropriate contingency plans should be made and updated throughout the project, and blockages are removed immediately after identification, escalating to the next level of management if appropriate.

Balance is about ensuring that there is an appropriate distribution of risks and benefits throughout the project plan. You don’t want to run sprints that are top-heavy with risks that could potentially jeopordise the project.

Transparency is about ensuring that all risks associated with the project are made visible and are accessible to everyone on the team. This could be through running risk management workshops with stakeholders, keeping a risk log that everyone on the team has access to, or copying appropriate risks directly into Trello cards so that the risks are very clear even at task level.

Moran goes a step further and maps each of these principles of Agile risk management to the eight DSDM principles which gives a broad view of how these might be used throughout the project management process.

Risk-driven planning?

Last night, as I was pondering all of this, it occurred to me that as developers often use test-driven development (TDD) to guide their development perhaps we could use risk-driven project planning (RDPP perhaps, if we need yet another acronym) to make risk management more prominent in our planning and help us get up to speed with our management of project risks.

Just this morning a copy of Moran’s book Agile Risk Management (Springer, 2014) was delivered (safely) to my desk. I guess I have my homework set for the next few weeks.

There is certainly a lot here to consider as we begin to improve our management of risks in Agile projects. I’ll report back later with our findings.

Leave a Reply

Your email address will not be published. Required fields are marked *