How can you work with your team to identify risks?

Identifying risks to their work helps development teams.  Recently I spoke to a team who had talked through the ways in which their work could fail, and built on this to identify risks to their work.

The team adapted Failure Modes Effects Analysis (FMEA) to suit their needs. FMEA is a technique that is used in manufacturing to identify the modes of failure for a piece of work and calculate a number that represents the risk of each failure mode. A team using FMEA will, for each failure mode, assign a value for each of the following :

  • Severity (how severe is the failure)
  • Occurrence ( how likely the failure is to occur)
  • Detection (how likely it is that the failure will be detected)

And from these values calculate a value to represent the risk for each failure mode. This enables the team to identify the failure mode with the highest risk.

The team I heard about used a simplified version of FMEA. They found that identifying failure modes for their work would be useful, and that discussing severity, occurrence and detection for each failure mode helped them identify the risks to their project. They created a simplified spreadsheet, based on the one in the article below,  with columns for: failure type, potential causes, potential impact and current process controls. However, assigning values and calculating risk for each failure mode felt to be more than was required for their project.

The team identified failure modes, entered them in the failure type column,  and then completed the columns for each of the failure modes. The team were able to ensure that there were process controls in place for each failure mode, and identified an additional control to put in place. The team plans to revisit the process if they identify more failure modes for their work.

This simplified FMEA process gave the team confidence as it enabled the team to ensure that they had methods of reducing the risk of each failure mode of their work. The confidence the team gained enabled the team to move more quickly. 

Further reading:

Published by Mike Harris

Mike has been working in testing for 20 years and is currently the lone tester for Geckoboard. He has been a Test Lead and has also worked as a part of waterfall, lean and agile teams. He is also Programme Secretary of BCS SIGiST. Mike has a B.Sc.(HONS) from Middlesex University and is an Associate of the University of Hertfordshire. He has set up and led a Testing Community of Practice and been part of a successful agile transition. He is Co-Programme Chair of the British Computer Society’s Specialist Interest Group in Software Testing. He also contributed to the e-book Testing Stories and has had articles published by the Ministry of Testing. Follow Mike on Twitter: @TestAndAnalysis

Leave a comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website with
Get started
%d bloggers like this: