Loading...

Project risk management with Agile

Research shows that traditional project management is failing. Learn the secrets to reducing risk and delivering successful software development projects with Agile.

Nathan Donaldson

By Nathan Donaldson

The CEO of Boost, Nathan is an award-winning leader in business transformation, with more than a decade’s experience using Agile to help organisations make a bigger impact.

In this guide you’ll learn why Agile software development is less risky than traditional Waterfall approaches and get an Agile project risk management model for identifying and addressing risks.

This model breaks down common project risks and shows how you can use four key Agile risk management techniques to maximise your opportunities for success.

It gives you a decision-making tool for choosing your project management methodology and practical guidance on project risk management.

Reduce risk from day one

kickoff-kit-ipad-placeit How to run a successful project kick-off

The Agile Project Kick-off Kit gives you the tools, templates and tips you need to get your project off to a successful start.

"Brilliantly done - very impressive."

— Jimmy Ling, Agile Delivery Lead, NAB

Get the kit
content-chapter-1 mobile-chapter-1
01 Chapter 1

Approaches to project risk management

Trying to predict the future is like trying to drive down a country road at night with no lights while looking out the back window. — Peter Drucker

Traditional project management mitigates risk by plotting out the entire project in advance, trying to guess what might happen in the future.

Agile does it by observing what’s happening now. Agile focuses on delivering small batches of the highest priority work in short iterations so you can give your customers valuable working software. You base future work on how customers actually use the software, inspecting and improving your product and processes with every iteration.

By basing your risk management on knowns rather than unknowns, you do only the planning and mitigation that’s required.

Agile: pragmatic tools for project risk management

KPMG New Zealand’s Project Management Survey 2017 found that traditional project management approaches aren’t working. Around two thirds of New Zealand projects fail and only 21% deliver on benefits.

Announcing the report, Gina Barlow, Director in the Advisory team at KPMG New Zealand, said organisations need to be more agile in the way projects are managed.

“The survey shows that current project management methods are struggling to provide efficient project delivery, so there is a need for project management to take a big step closer to business strategy and agile project management,” she said.

It’s a global trend. The 2018 Standish Group Chaos Report found that only 33% of software projects were successful. It reported that Agile projects enjoy a 60% greater chance of success than non-Agile projects.

With Agile now best practice for software development, it is essential to understand how we can use Agile approaches and tools to manage and mitigate risk.

When we talk to organisations about the benefits of Agile software development, all too often we get the response that the current priority — Big Project X — is too important to fail and that Agile is too risky. This is despite the fact that their current methodology is not delivering what they need. The problem is often that they know traditional project management but don’t know Agile. Seeing how Agile techniques let you manage and mitigate risk will help you understand how an Agile approach reduces risk, rather than increasing it.

Once organisations see how they can reduce risk by working in an Agile way it becomes the obvious choice for Big Project X, as this case study shows:

Why a risk-averse CEO chose Agile for a mission-critical project.

In this guide we will summarise:

  • the four different kinds of risk faced by software development projects
  • the Agile project risk management model
  • how we can use the project risk management model to reduce risk.
content-chapter-2 mobile-chapter-2
02 Chapter 2

The four risks common to most software projects

There are many risks in software development projects, some of them generic and others specific to a particular project and situation. We will look at four of the most common and obvious risks that apply to almost all software projects.

  1. We will fail to deliver the quality that our market needs.
  2. We will not deliver within the resources available.
  3. We will fail to deliver within the timeframe needed.
  4. We will not deliver a product the market needs or wants. This is often the most underestimated risk.

1. Poor quality

Time and time again we hear about large project failures in the media. Take the New Zealand Ministry of Education's payroll system Novopay. Delivered $12 million over budget (a more than 100% cost overrun) and at a universally agreed level of poor quality, Novopay's problems and lack of success have remained in the media for years. The government had to spent $45 million fixing the system and supporting schools. In 2018 it was reported that $26 million would be spent to extend the life of the system.

Poor quality is a root cause of many failed projects. It destroys team productivity as more and more time is eaten up with finding and fixing defects. The teams that work on these systems often have one defining trait — they are terrified of touching the code base. They know that it is fragile but have no idea of where or how badly.

2. Too expensive

The second risk is that the project will consume all available resource and still not be in a complete state.

The KPMG research found that only 29% of New Zealand projects come in on budget.

Examples abound. For example, at the time of writing it has just been announced that the plug has been pulled on the National Oracle System for New Zealand’s health boards. The project had spent $90 million without achieving its objectives and was shut down when it asked for a further $23 million to complete the work.

3. Delayed delivery

The third risk is that the project may not be delivered in time. Many projects are extremely time-sensitive, and missing deadlines means lost revenue, lost market share and sometimes penalties.

Poor quality is a common cause of missed delivery deadlines. This problem is exacerbated by late integration, meaning that issues of quality are not discovered until very late in the project.

4. Perfectly executed failure

The fourth risk is that businesses may hit their deadlines, make their budgets and even deliver the necessary quality only to find that they have delivered a product nobody wants. Eric Ries describes it as "achieving failure".

"We spend a lot of time planning. We even make contingency plans for what to do if the main plan goes wrong. But what if the plan goes right, and we still fail?"

To reduce the likelihood of these risks impacting our projects, we need to stop and ask ourselves what we need to do differently. How do we adapt our management approach to ensure we deliver the right value to our organisation and our customers?

Maximise value and minimise risk

Floating iPad no BG

As Product Owner, it's your job to maximise the value your project delivers. Get a practical guide to using Scrum to deliver more.

"A great resource ... extremely thorough!"

 Jess Limbrick, Product Owner, Life Education

Get your guide
content-chapter-3 mobile-chapter-3
03 Chapter 3

A model for Agile project risk management

You can sum up the risks as challenges to these four success factors:
quality@2x Quality cost@2x Cost time@2x Time value@2x Value
Agile software development has a number of ways to reduce these four risks. The most powerful of these approaches are:
effective@2x Effective prioritisation transparency@2x Increasing transparency content-batch-size Reducing batch size hand icon@2x Limiting work in progress

Together this gives you an Agile project risk management model. This model shows how different Agile approaches mitigate different risks, with each approach primarily affecting one of the areas identified, as well as influencing the other areas.

The Agile software development risk management model shows the main project risk areas (quality, time, value, cost) and mitigations (prioritisation, transparency, reducing batch size, limiting work in progress). Prioritisation mainly targets risks around value and cost, transparency mainly quality and value, work in progress mainly quality and time, and batch size mainly targets cost, time and quality.

content-chapter-4 mobile-chapter-4
04 Chapter 4

Techniques for Agile project risk management

There are various tools for managing the common risks. Taken together, these tools greatly increase our chances of successfully delivering projects for our organisations.

The tools enable us to prioritise the continual, incremental delivery of working software. By prioritising the delivery of working software we are able to constantly inspect the quality, functionality and desirability of the software.

Like tasting food while you are cooking, we taste at every stage of the project and adjust the ingredients and seasoning as needed to ensure a flavourful and well-balanced dish.

When you adopt the Agile mindset — when you embed the Agile values and principles in the way you work — the use of these tools becomes second nature.


Effective prioritisation

Pie chart showing Agile prioritisation in the Agile risk management model. Prioritisation is a key approach for managing and mitigating the risks to value and cost.
Rigorously prioritising work reduces the risk of delivering software of low value while ensuring that costs are controlled by only working on what is important to our organisation and customers.

When working with Agile methodologies such as Scrum and Kanban we focus on prioritisation. Focusing on the highest value work is a key Agile project risk management technique. It avoids time and energy being diverted into low value work, This lets us deliver value to our customers much earlier than in traditional Waterfall projects.

An example of prioritisation in action is the mobile app Reel Choice that Boost produced for NZ On Screen. When writing the user stories we made sure that all stories contained some value to the end user. We then completed all stories to a releasable state and got feedback from customers as we worked.

Our backlog for the application looked like this:

  • display one video full screen
  • show multiple videos and let the user choose which to view
  • when the screen is in portrait view, show additional information about the video
  • enable certain videos to be "featured" and displayed larger in the multiple video listing.

We worked through the stories in priority order and at every stage we had a potentially shippable product that offered value to the end user and the client. At any stage the client could have stopped the project and had a working, valuable product.

This is in stark contrast to alternative project management methods where the plan determined at the beginning of the project must be followed to completion to see any value delivered.

Using Agile delivery project work is strongly prioritised as the assumption is that all functionality will and must be delivered in small batches. Compare this with other types of iterative development processes. In these, work may be delivered iteratively but without the focus on prioritisation — based on value to the customer — that is central to Agile.

In Agile projects, re-prioritisation happens continuously in the backlog of work as more information is discovered about the project. In contrast, with staged project delivery methods (and more traditional iterative delivery methods), priorities are set once at the start of the project, if at all, and are often based on imagined future needs and dependencies.

Increasing Transparency

Pie diagram showing how Agile transparency reduces project risk mainly in two areas, quality and value.
Increasing transparency reduces the risk of producing work of poor quality and helps to ensure that the project is delivering value.

Transparency is at the heart of Agile project risk management. If we do not have a full and accurate view of the status of the project, the business priorities, the resource needed to deliver and the quality of the output, we cannot manage risk in the project.

This is a key problem in many software projects. That’s because it's not until the final stages of a project — the release — when we really get to examine the quality of the product. We rely on wishful thinking to carry us forward.

Consider the graph below. We can see that risk remains high in a Waterfall project right until the majority of the functionality is delivered. At the end we are able to get a real view of the risk, which may be high or low depending on how well our requirements matched market need and whether our work has been of consistently high quality.

Simplified line graph comparing the risk profile of Agile and Waterfall projects. With Agile risk falls early, with Waterfall it remains until late in the project.

Contrast this with the Agile project shown on the graph. Here we see that initially risk was high — identical to the Waterfall project. Using Agile the risk drops quickly and significantly as we start to deliver working, tested and deployable software. We can determine the quality of our work and take our software to a test market to determine the value our features provide to our users.

During an Agile project we can shift the focus at any stage. Should we discover that our users need feature X instead of feature Y we can re-plan and re-prioritise without any penalty to our overall timeline.

Agile works to make projects more transparent in a number of different ways. An example is the iteration timebox in a Scrum project. It makes transparent the work the team is doing and the amount of work that can be completed by the resource applied. It also enables us to inspect working software. Other examples of increased transparency include:

  • regular "retrospectives" — meetings every iteration where the team can raise blocks, impediments and inspect the way they are working together and with the organisation
  • Kanban boards, Scrum boards and other "information radiators" — they make visible the work of the team and the progress being made, and are a rich source of information about the team's processes for the team and the organisation.

Reducing batch size

Pie chart showing that when you reduce batch size in Agile software development you target risks to cost, time and quality.
Reducing batch size reduces the risk of cost and time overruns while also increasing quality

Core to reducing the variability in our projects is reducing the size of the batches we work in.

Agile projects constantly work to reduce batch size in every part of the project. Whether in the daily work of the team or in the delivery of the product or project, reducing batch size remains paramount.

Software development projects have traditionally seen the project as one large batch that must be delivered in a big bang. Even iterative approaches see the iterative deliverables as part of a larger deliverable batch.

Reducing batch size is important for managing cost on projects for three reasons:

  1. It enables us to be more productive.
  2. It reduces the variability in the work.
  3. It enables us to inspect the output of our work at greater frequency.

Reducing the size of the batches we work in reduces the potential amount of rework needed to remediate errors. We can catch problems with our output, processes and tools at an early stage, limiting the extent and impact of an error.

Tools for managing batch size in Agile include:

  • splitting stories (or other units of work such as use cases) into the smallest increment of value
  • working on vertical slices of a system
  • continuous integration
  • increasing the frequency of deployment.

Limiting Work In Progress

Pie diagram showing that limiting work in progress reduces project risks around quality and time.
Decreasing WIP reduces the risk of missing deadlines and also increases the quality.

Limiting work in progress (WIP) is an effective Agile project risk management technique for ensuring your ability to deliver quality work on time.

Neglecting to limit the work in progress for our teams and organisations quickly leads to thrashing, as we constantly switch from one task to another.

We can see in the graph below (based on Gerald M. Weinberg's Quality Software Management: Systems Thinking) that as we have more tasks in progress at any one time productivity starts to fall to zero as we spend more time context switching.

Bar graph showing that the loss of working time due to context switching increases as the number of simultaneous projects increases.

With many of the Agile methodologies there is a focus on managing and reducing work in progress. Scrum does this using timeboxes. The amount of work in progress is limited by the size of the timebox (2 weeks for the majority of teams). The team takes on no more work than can be completed in that time. High-performing teams actively work together to reduce their work in progress by ensuring that each story (or increment of work) is fully completed, tested and ready to deploy before moving on to the next story.

In addition to timeboxes there are a number of other tools for limiting work in progress, including:

  • explicit WIP limits in Kanban stages
  • continuous integration
  • test and behaviour driven development
  • protecting the team from outside requests.

Reduce risk from day one

kickoff-kit-ipad-placeit How to run a successful project kick-off

The Agile Project Kick-off Kit gives you the tools, templates and tips you need to get your project off to a successful start.

"Brilliantly done - very impressive."

— Jimmy Ling, Agile Delivery Lead, NAB

Get the kit
content-chapter-5 mobile-chapter-5
05 Chapter 5

The tyranny of wishful thinking: the greatest risk of all

Reflecting on the traditional project management methodologies used in software development, it is easy for us to conclude that what appears concrete and real is merely wishful thinking. The scope, resource needed and cost are often portrayed as concrete and known, having been deduced through experience or wisdom.

However, we impose on the team what we wish to happen in terms of scope, time, quality and cost without actually giving them the tools or mandate to actively manage any of these variables. The team is being subjected to wishful thinking and is too often punished if they do not achieve these goals.

In contrast, Agile inspects the output of the team and adjusts expectations, resources and approaches based on evidence. The team is given the mandate to maintain quality and make decisions about how this is achieved. The business communicates its needs and the team determines how best to achieve this outcome with the resources available.

Rather than relying on wishful thinking, Agile provides pragmatic and tested ways to improve the success of our projects. Agile organisations across the world are applying these techniques to deliver better software more quickly.

The approaches mentioned in this guide are a few of these concepts and the application of these will vary across different teams, projects and organisations.

We hope that this has helped you to identify opportunities to reduce and manage risk within your teams and organisation.

content-chapter-6 mobile-chapter-6
06 Chapter 6

Putting Agile risk management into practice

The Agile risk management model describes the relationship between Agile approaches and the risks common to software development projects.

For organisations, it demonstrates how Agile actively mitigates risk in ways that traditional methodologies do not. It gives you a decision-making tool for choosing your project management methodology.

For teams, it clarifies how different but interrelated Agile approaches and tools address the risks you face on projects everyday. It gives you a tool for planning how you’ll manage and mitigate risk.

In the blog posts below you’ll get practical guidance on how to reduce risk through effective prioritisation, increasing transparency, limiting work in progress and reducing batch size. You’ll also get evaluation questionnaires to assess how well you currently use these techniques and case studies showing you how these approaches work in practice.

Your guides to the key Agile tools for reducing risk

Agile prioritisation and software development risk

Get practical prioritisation tools for reducing project risk, and complete a checklist to evaluate your current prioritisation work.

Limiting work in progress to manage project risk

Limiting work in progress helps you deliver quality work on time. Learn how you can evaluate and improve your ability to limit work in progress.

How to reduce batch size in Agile software development

Get five tools for reducing batch size, and find out how effective you are at keeping your batches small.

How Agile transparency reduces project risk

Assess the transparency of your projects and learn how to maintain transparency and minimise risk using the Agile toolkit.

Case studies on project risk management

Agile prioritisation reduces risk — Intuition HQ

Learn how effective prioritisation got an app released early, providing the feedback needed to build a better product.

Creating risk transparency — Smells, Meteors & Upgrades board

How a team managing a large legacy project used a big visible information radiator to manage risks.

Maximise value and minimise risk

Floating iPad no BG

As Product Owner, it's your job to maximise the value your project delivers. Get a practical guide to using Scrum to deliver more.

"A great resource ... extremely thorough!"

 Jess Limbrick, Product Owner, Life Education

Get your guide