Risk. It might be a four letter word, but it certainly isn’t one that you should be avoiding in projects. It shouldn’t be brushed under the carpet. Risk is not an indication that a project has gone bad – when risk is being proactively identified and considered by the team as a whole, it allows the right actions to be taken by the right people to ensure the project’s progression. Dealing with risks, issues and problems on a project is not an exercise in appointing blame, it is an exercise in working together to secure the success of the project for everyone in the team – to that end transparency and honesty should be the watchwords of all team members.
Not all risk can be removed from a project, but steps can be taken to recognise it and to make decisions on how it should be handled or not handled. Maximising opportunities that arise and minimising the impact of threats should be kept in mind at all stages, be it in the defining, developing or delivery of a product.
Here are a few things to keep in mind when managing risk on your projects – remember, although the Project/Delivery manager may be the central co-ordinator responsible for communicating and managing risks and opportunities, the team as a whole should be considering the risks that arise as part of what they do, and be working together to report them and act upon them – to this end the list below is useful to everyone on a project.
A lot of this may seem like common sense, but in the midst of a project things can get easily missed – it’s good to return to the basics and refresh your mind on the simple yet effective steps that you can take…
Risk Management is a part of ANY project you work on
It’s just common sense that evaluating and managing risk should be a part of any project, but it’s easy to let it slip, be it through complacency, ignorance, over confidence or even lack of time. It doesn’t matter how simple a project may seem or how routine it may be, potential issues should always be given due and relative consideration. I can’t think of a single project that you should be confident enough in that you can assume there are no risks to be at least considered, if not necessarily monitored or mitigated.
Also as mentioned above, risk awareness should be considered a task for all team members. It shouldn’t be assumed that the project manager is the only one that has to care. As a team you’re reliant on each other to raise the risks that arise in your areas. Everyone is key in raising concerns from their areas, and for providing the essential information required in order to make informed decisions on them. Processes and routines, such as daily stand ups for example, can help make risk/blocker reporting habitual and part of the team’s day to day routine operation. Working as a team and bringing everyone together regardless of function can help to remind everyone that you’re all in the same boat, working together towards the same goal of success (and will help to promote transparency, which is essential to good communication).
Identify risks as early as you can
The earlier you can identify risks the better. In some cases there will be no way to see it much before it arises, but regardless you should use all sources available to you in order to identify issues where at all possible. Broadly speaking this will be either via documents or data that exist in one form or another, or directly from people that are in your project team, from those you’re collaborating with on the client side, or from other key stakeholders – it could in some cases also be via other people not directly involved in your project, but who can offer insight into what you are working on.
The point being is that you need to have an open mind towards sources of information in order to recognise the breadth of inputs and knowledge that you have at your disposal. Never be too arrogant to think you can recognise all of the issues and options that may arise by yourself – a Japanese proverb I keep in mind is “Together we are smarter than any one of us”. Working as a team increases the chances of recognising risks early as well as the available methods for addressing them.
Stand ups, meetings, workshops, sprint planning, reviews, project plans, business cases, user stories, resource estimates, retrospectives of previous projects/sprints, company wikis, and so on. Using all that is available to you will increase your chances of identifying risks and opportunities sooner, and give you more time to address those that will blind side you no matter how much planning you’ve done.
Make sure risks are communicated
To quote Jerry Maguire “Help me, help you”. When you’re managing a project, a lot of what you can do is dependant on what people tell you; on what people do to allow you to help them. There’s nothing worse than a team or a client that doesn’t communicate to you that essential piece of information that would have allowed you to lessen the effect of that one risk you didn’t, or couldn’t, see coming.
I think it’s really important to let team members, clients, stakeholders, etc. know that if they have anything to communicate about any issues or problems that have come to light, to do so as soon as they can. It can be strangely difficult sometimes to make people understand that there is nothing negative about raising risk – in fact it’s extremely positive. The moment a risk is a known entity is the moment something can be done about it. Communication is everything and you need to encourage and nurture it in every corner of the project.
Make reporting risks, blockers and concerns a key part of communications – make it understood that it is an important aspect of the project, and make it easy to do so through the rituals and the tools you use. Where possible adopt a “go see for yourself” attitude and do what you can to increase your understanding of what is being faced. Provide those in your team with another avenue of risk reporting by making yourself accessible and approachable. Help get the message across that risks are an important aspect of a project and that communicating them is massively important. If you are adopting an iterative approach and utilise daily stand ups/meetings/call them what you will, then these will provide a natural point for your team to be able to communicate risks that they have identified.
Additionally, consider how you will communicate risks from your side back to the client or sponsor – ensure what you communicate is succinct and understandable in order to ensure that the client can make as informed a decision as possible.
Ensure ownership of issues is clearly assigned and understood
As important as recognising a risk, is determining who has responsibility for actions that need to be taken for it. A risk that isn’t ‘owned’ has no impetus for action. Cover next steps in your stand ups and set completion criteria. Monitor progress via the tools your team uses.
This is important not just within the team, but when working with a client too. Sometimes the risk sits squarely with the client, meaning that the responsibility to address it, along with the impact in terms of cost, quality or scope, lays squarely with them. Maybe they need to assign resource on their side in order for you to complete design, or maybe APIs need to be in place in order for sprints to progress. Clarifying the ownership of risks and clearly commuicating the effects of them to the client or sponsor can really help to prompt action where it is needed. Those whose bottom line it effects will start to pay attention when it’s made absolutely clear the ownership sits with them.
Prioritise a project’s risks
Not all risks are made equal. Risks can be assessed in terms of the level of impact and the likelihood of occurrence. There are many similar diagrams on the internet that clearly layout this concept and you can easily search for them. For example:
Determining impact and likelihood will aid you in prioritising which risks need the most attention and when. Not all risks are equal. Also consider how far away the risk is in relation to how much effort will be required to attend to it. Any showstoppers with the potential to halt a project completely should demand a greater priority, especially if the likelihood of them happening is high. In any case measure consistently and prioritise appropriately.
Analyse risks you’ve discovered
Whenever possible look for the root cause of a risk and truly understand why it is occurring. The more you can understand the underlying reasons for a risk arising the better your response will be, and the better prepared for similar ones you will be in the future. Using an approach like 5 Whys (an iterative question-asking technique used to explore the cause-and-effect relationships underlying a particular problem) can be a simple but effective way of uncovering the real issues behind a risk and it’s resulting effect.
Use this in conjunction with the build, measure, learn principle advocated by the Lean Startup methodology and you’ll hopefully have an approach that will allow you to get to the root causes of risks and take those learnings forward to ease the avoidance or mitigation of similar ones in future projects.
Some risks are simply a part of the project by nature. In these cases or in cases where only so much can be done to reduce the impact of the risks that exist, you need to analyse what the cost will be to the project and what factors, if any, will effect the magnitude of the effect: changes in budget, quality, time and resource can all have measurable implications that need to be relayed back to the sponsor.
Plan and Implement your responses to risks
Once you’ve unearthed and analysed the risks, it’s time to plan the actions required to reduce their effect on the project. What can you do to either remove or minimise the risk or, failing that, accept it and communicate it to all concerned stakeholders in order to prepare them. Taking the previous steps to discover, understand and evaluate risks will hopefully allow you to formulate the best response possible in each case.
Can you re-organise a project in order to avoid a risk altogether or to at least minimise the impact it could have? Change a chosen framework or API that you’re using, change at what point particular work is done within a project etc.
Sometimes accepting the risk and the impact of it on the project can be a valid option, if no other path of mitigation is available and especially if the effect on the project is minimal or the amount of effort, time or cost needed to influence it is in fact more detrimental than the risk itself – in these cases communication of the risk is paramount in order to assure that this choice is a conscious one taken by those in the position to do so. Perhaps the effort, time and cost of getting a particular feature into the next build of your app is not worth the risk of impacting other features sitting in the same sprint. Is it more acceptable to acknowledge that a particular feature is unlikely to make the next build if it means no other items will be impacted and testing/QA can be completed in the usual manner? You may find in some cases it is.
Record risks and track their tasks
Whatever tools or processes you use, risks should be logged in order to capture ownership, progress and the decisions made by key stakeholders on them. In doing so you can chronicle, assess and communicate the progress made on them, as well as prevent any that were raised and discussed during meetings from being forgotten in the midst of everyday routine.
Logging risks is essential. Risks are a part of project life and are to be expected. Recording them allows you to retain the details of all essential tasks taken to handle them, and in the event of questions being raised further down the line, you have to hand a record of key points that you can track back through.
How you track risks compared to the tracking of their associated tasks depends on the tools you use for your projects, but in any case you want to track the status, importance/priority and likelihood of risks, and with regards to the tasks for those that you’ve agreed to take action on, you need to record the progress, the changing circumstances over time and the effect of the tasks on the risk itself.
Accept risks are a part of the landscape, deal with them, and continue to improve your approach over time
No matter the style or methodology of project management that you use, risks will always be a part of what you need to deal with; and you do need to deal with them. They are not to be ignored and they are not to be handled in isolation. Honesty and transparency within the team is hugely important. Do not underestimate the power of a team that is communicative, collaborative and energised to work together to face issues. Going hand in hand with that you must ensure that you track the risks that are there. Recording risks and tracking tasks will facilitate the steps your team take to analyse the problems identified and action the right responses.
Finally, remember to hold your retrospectives – measure, learn and continue to refine the processes you use as a team. Create a lessons learned list/wiki and share it with everyone. Don’t let hard earned lessons slip away or be forgotten. There is almost always something that you can do better or more efficiently, so never stop that cycle of continuous reflection and improvement.
rickynealeuk 