Applicants to Innovate UK grants are always expected to present an analysis of the issues potentially threatening their project – and the latest iteration of the Smart grant application is no different in that aspect. Often, our clients are not really sure what to include in the risk section; the aim of this post is to give some guidelines.
What are risks?
Risks are all the things that may hinder or downright kill your project. They don’t have to be huge: a lack of communication could for example lead to a delay in the completion of a deliverable. Annoying, but not devastating.
A natural tendency would be to consider that the main risks are technological risks; this is only partially true. Many other types of risk can have a negative impact on your project, for example:
- regulatory: the law imposes you to protect your customers’ personal data, and you comply; now, a new, stricter law is passed, and you need to take time to modify your framework to make it compatible. This could damage your project’s timescale and estimated delivery.
- managerial: your CTO and your COO are an item; they fall out and won’t talk to each other for two weeks – how can you ensure this doesn’t impact the project?
- organisational: a collaborator suggests adding a previously unplanned task; it makes sense and you accept – and find yourself missing an important deadline because you didn’t have any resource allocated for that extra task.
NB: It is good practice to include all types of risks in your analysis.
How do you assess risks?
Given their variety, risks cannot be assessed solely at the start of a project, by the project leader alone; team meetings are thus necessary for the initial assessment and to keep track as the project goes along.
Identifying the risks isn’t enough in itself: you need to also be able to assess their possible impact. To do so, you need to identify:
- Their probability: a team falling behind, a collaborator being absent for a couple of days is pretty likely, a data breach much less so,
- Their severity: some problems will cost you half a day’s work, others will make you break the law.
The conjunction of the severity and the probability give you an idea of the possible impact of the risk:
NB: “3” is in this case higher than “4” because a small problem but highly repetitive problem is more disruptive to a project than a rarer but more severe problem; similarly, a very-rarely-seen problem could kill a project in one occurrence (e.g. data piracy).
NB: You should always include all the risks you can think of, even if they seem minor – were it only to signal the assessors that your thinking has been thorough.
How do you address them?
Each risk needs to be assigned an owner, i.e. a person in charge of monitoring the risk, alerting the stakeholders in case of appearance and following its resolution. The owner must of course be chosen logically – for example, the CTO will own the technical risks, the CEO the managerial ones etc.
Each identified risk should be paired with a credible mitigation strategy, formulated collectively by the stakeholders: this will enable to reduce the risk and/or the project team to act rapidly and efficiently in case a problem arises.
How do you represent them?
Risks should be reported in a risk register, which should be updated at least quarterly during a project. The register should include, at a minimum, a description of the risk, its impact assessment and a remediation. Ideally, it could look like this:
In a nutshell, risk assessment is worth taking time to do: though not impossibly complex, there are a number of hoops needing jumping through, and a well-thought-out risk management plan can be a great asset for the success of a project. If in any doubt, don’t hesitate to send us your question at firstname.lastname@example.org.