Convivio Cookbook
  • Introduction
  • Our Business
    • The Convivio brand
    • What do we do?
    • Our work for clients
    • Our Purpose
    • Our Pulse
      • Big Rocks
      • Problems
    • Company Policies
      • Environmental Policy
      • Anti-Bribery Policy
      • Fair Tax Policy
        • Dividends policy
        • 2020 Results and Tax
        • 2019 Results and Tax
        • 2018 Results and Tax
        • 2017 Results and Tax
  • Our Team
    • Help! I'm new. How do I get started?
    • Starting at Convivio
    • Staff Benefits
    • Being a buddy
    • Having a buddy
    • Free-Range Working
    • Convivio Fridays
    • Notes: give & receive feedback
    • Security Screening
    • Submit Expenses
    • Purchases
    • Your home working environment
    • People Analytics
    • Recruitment
      • Help Card: Writing a Person Profile
      • Help Card: Writing a Job Description and Advert
      • Help Card: Publishing a Job Advert
      • Help Card: Reviewing CVs
      • Help Card: Preparing and Conducting Structured Interviews
      • Help Card: Preparing and Conducting Remote Working Interviews
    • Team Policies
      • Security Policy
        • Acceptable Use Policy
        • Business Continuity Management
        • Data Usage Policy
        • Document Access Policy
        • Mobile Equipment Policy
        • Two-Factor Authentication (2FA)
        • VPN Guide
      • Equal Opportunities
      • Grievance Procedure
      • Disciplinary Procedure
    • Taking time off work
      • Holiday
      • Sickness
    • Peer reviews
    • Mental Health
      • Mental Health Training
      • Mental Health First Aid
      • Returning to work
      • Resources
    • Continuing Professional Development
      • CPD Annual Planning
      • CPD Sprints & Scrums
      • CPD Annual Review
      • CPD Annual Retrospective
  • Our Clients
    • Principles For Building New Client Relationships
    • Researching
    • Connecting
    • Nurturing
    • Assessing
    • Learning and Thinking
    • Pre-qualification questionnaires
    • Proposing
    • Agreeing
    • Beginning
    • Inspiration
  • Our Marketing
    • Content Publishing
      • Git Repository Conventions
      • Help Card: Writing a Case Study
    • Brand Guidelines
      • Content Guidelines
      • Branded Documents and Reports
  • Our Tools
    • Infrastructure
      • External Firewalls
  • Internal Projects
    • How we improve our business
  • Client Projects
    • Delivery Launch
    • Delivery Team
      • Convivio People
      • The Coach
      • User Researcher
      • Other Team Members
    • Digital Strategy
    • Discovery
      • Discovery Briefing
      • Discovery Planning
      • Discovery Modules
      • Discovery Findings
      • Discovery Principles
      • Prepare for prototyping
    • Prototyping
      • Inputs to Prototyping
      • Prototyping Objectives
      • Prototyping Inception
      • Prototyping Sprints
      • Prototyping Outputs
    • Build
      • Inputs to Build
      • Build Kickoff
      • User Stories
      • Backlog Management
      • Backlog Scouting
      • Sprint Planning
      • Sprinting
        • Daily Standup
        • Story Lifecycle
        • Design in Sprints
        • User Testing in Sprints
        • Quality Control in Sprints
      • Sprint Review
      • Sprint Retrospective
    • Service Management
    • Digital Service Standards
      • Delivery Methodologies
        • Scrum
        • Kanban
        • Lean
          • Technical Standards
        • Code Quality
        • Testing
        • Automation
          • Security Standards
          • Quality Standards
          • Risk Standards
    • Delivery Governance
      • Steering Group
      • Risk Management
        • Risk Attitude
        • Assessing Risks
    • Delivery Help Cards
      • Help Card - Sprint Planning
      • Help Card - Sprint Review
      • Help Card - Sprint Retrospective
      • Help Card - Product Owner Feedback
      • Help Card - Common Issues
      • Help Card - Slack
      • Help Card - Github
      • Help Card - Trello
  • Our Recipes
    • Convivio Classic Cocktails
      • Ingredients
      • Tips and Techniques
      • Martini
      • Negroni
      • Manhattan
      • Old Fashioned
    • Potage Dubarry (or, creamy cauliflower soup) with spiced green pepper
    • Roasted Sweet Potato in a Herb and Nut Salad, with Maple Chilli Dressing
    • Aubergine Curry
    • Vegetarian Paella
    • Easy Ice Cream
Powered by GitBook
On this page
  • Discovery and acceptance of risk
  • Recording risks
  • Risk appetite and assessment of risks
  • Day-to-day management of risks
  • Risk summary
  1. Client Projects
  2. Delivery Governance

Risk Management

Risks need to be managed throughout the life of any project or delivery. Here I’m summarising the key steps in risk management and I’ll provide some links to useful tools and approaches towards the end of the page.

Discovery and acceptance of risk

Risks are an inevitable part of our work. Avoiding risks only compounds the problem. Assume that there are risks, root them out, be transparent about them and deal with them head on.

As soon as you set any plan in motion, you introduce risks. Risks such as not completing work by a particular deadline, risks that you lose key staff, risks that the end product will not be good enough or not fit for purpose, risks that you don’t know about yet.

In order to manage your risks properly you need to identify them, assign them an owner, assess the risks and the possible mitigation, decide whether to avoid, share, deal with or transfer the risk, and understand the value behind the risk and the likelihood that it will occur.

Recording risks

The discovery phase is a great place to begin looking for risks. Minds are generally quite fresh at this stage and there will be some obvious risks as well as those that you’ll uncover when digging into the problems that the discovery phase covers.

Recording the risks in a simple register takes very little effort but it’s a tool that will be used to review and manage the risks while they’re still active.

When recording risks be sure to capture the following information:

  • Description. A reasonable summary of the risk faced and the impact it will have should it occur.

  • Value. We need to know the value hidden behind the risk so we can assess whether it’s worth investing effort to manage this.

  • Mitigation. If there is one or more ways to manage this risk then record them here. Whether you can manage the risk, avoid it, transfer it or avoid it altogether, put your ideas down here.

  • Owner. The sooner a risk is owned by someone in the team, the sooner it’ll get the love it needs.

  • Probability. Whether you use numbers or a high-low scale, provide an indication of how likely this risk is to occur.

  • Impact. What will be the impact to the delivery if the risk occurs? Use the same scale as probability so you have the option to map the two together.

  • Status. We need to know if a risk is active or closed.

Risk appetite and assessment of risks

Now that you’ve got a record of the risks you’re aware of it’s time to assess them. All risks are different and we need to understand the facts and prioritise our efforts based on what we know, or roughly know. The facts to consider for each risk are:

  • Value. Sometimes it’s difficult to put an actual number on the value of something but use a scale or some kind of sizing indicators here if necessary. If the effort involved in managing a risk is far greater than the value gained then you need to consider whether the investment is justified.

  • Probability. What are the chances of this occurring?

  • Impact. If this risk occurs, what will be the impact on the delivery?

Another factor to take into account is your risk appetite. What level of risk are you comfortable with? Some of us are bigger gamblers than others. Taking a chance on a big risk can pay massive dividends but it can also spell disaster.

Day-to-day management of risks

Now that you’ve identified your risks, you’ve decided which to manage and who is responsible for them, you need to have the processes in place to manage these.

Our organisation is set up for constant improvement and there are certain cycles into which we can work the management of our risks.

When delivering a discovery or when we’re iterating through a delivery, there are natural points in the cycle when risks can and should be reviewed.

A sprint starts with planning. During the sprint planning session talk about any risks you find with the team and the customer. It’s important that we’re open and that we pool our knowledge. In doing this we give ourselves the best chance of successfully managing a risk. Capture the details of the risk and any mitigation in the register and cross check with the user story or epic if possible.

Daily standups provide another natural point in our work cycle to highlight risks. A risk here could be that a story requires more effort than originally estimated, that you’re not receiving the input required from the customer to finish a story, that the module you initially identified doesn’t seem to meet the requirements or that you’re having technical problems. All of these are examples of things that will impact the delivery and therefore pose a risk. Highlighting these early gives us the best chance to manage them successfully or reduce their impact.

Sprint reviews allow us to put risks into the context of a larger programme of work. If a sprint has under-delivered for whatever reason we need to talk through the impact this has. What is the initial impact? Are there dates we need to consider? Do we need to reprioritise work in the next sprint? Do we need to add more people or different skills into the team? What is the longer term effect? Can we make up the loss over the course of the next couple of sprints? What originally might seem like an uncomfortable conversation with a customer will actually help to develop a transparent relationship.

Taking each of these opportunities in any two week sprint means that risks have the opportunity to be raised every day while being reviewed 1-2 times each sprint. However, a Scrummaster should be making the point to review risks more regular, at least once a week with the Product Owner. If you want the delivery to be a success then keep on top of the things that can quickly derail the delivery.

Risk summary

It’s often difficult to measure a risk or the value behind the risk but it’s worth using different methods to reasonably size risks. It could be that you use a scale or you could size risks against each other in the same way you would with user stories.

What’s vital in the management of risks is identifying them, talking openly about them, having someone “own” the risk and reviewing them regularly.

If you’re prepared for a risk to occur then you’ve already reduced its impact which hopefully has saved the delivery.

For more on risk management see

PreviousSteering GroupNextRisk Attitude

Last updated 7 years ago

Developing a Positive Attitude to Risk
Assessing Risks