Risk Management in Small Teams
I was taught risk management the classic way. You know, risk log, voting for probability and impact, finding out which risks are the most painful, deciding on mitigation plan, discussing results etc.
A cool thing in this old-school process is that it activates different members of the team. Even those, who wouldn’t be asked otherwise. Even those, who would tell you that the project is doomed unless you decide to do something about that performance issue found last month.
At the same time in small teams this kind of process looks like complete overkill. In small teams which deal with small chunks of work knowledge about risks (about everything actually) is often commonly shared. The problem isn’t about bringing individual opinions to the table. The problem is to make risk management as simple as possible yet still effective.
An easy and powerful approach here is to forget that there is something like risk management at all. At least to the point where you don’t consider having dedicated formal process to do risk management. Instead you incorporate risk management to everyday tasks: stand-ups, retrospectives, demos, planning meetings etc. You discuss potential risks every time you discuss a task or story. You discuss potential risks whenever you feel about it.
You won’t even need a risk log. If you talk about risks at every occasion you quickly learn how to catch those which may become painful (filtering by type) and those which are likely to hit you (filtering by frequency of mentioning).
When you keep talking about risks all the time people learn to deal with them naturally as they work on their tasks. Potential performance problem Luke mentioned yesterday? I’ll run some stress tests as I just have a while and maybe Mike would take a look at database as he’s already tweaking it to build that new feature. The trick is we don’t call it a risk. It is just a performance issue. Possible performance issue actually. Luke just thought it might become a problem but in a couple of days the problem will be gone, this way or another. And you don’t need to use the word risk, have a risk log, perform risk assessment, build and implement mitigation plans etc.
The only thing you need to have this kind risk management in place is a bit of trust and open atmosphere. Oh, co-location and no-meeting culture may help as well but in small teams both are usually in place already.
Read this and other articles of Pawel Brodzinski on his Software Project Management blog.
I was taught risk management the classic way. You know, risk log, voting for probability and impact, finding out which risks are the most painful, deciding on mitigation plan, discussing results etc.
A cool thing in this old-school process is that it activates different members of the team. Even those, who wouldn’t be asked otherwise. Even those, who would tell you that the project is doomed unless you decide to do something about that performance issue found last month.
I was taught risk management the classic way. You know, risk log, voting for probability and impact, finding out which risks are the most painful, deciding on mitigation plan, discussing results etc.
A cool thing in this old-school process is that it activates different members of the team. Even those, who wouldn’t be asked otherwise. Even those, who would tell you that the project is doomed unless you decide to do something about that performance issue found last month.
I was taught risk management the classic way. You know, risk log, voting for probability and impact, finding out which risks are the most painful, deciding on mitigation plan, discussing results etc.
A cool thing in this old-school process is that it activates different members of the team. Even those, who wouldn’t be asked otherwise. Even those, who would tell you that the project is doomed unless you decide to do something about that performance issue found last month.
At the same time in small teams this kind of process looks like complete overkill. In small teams
At the same time in small teams this kind of process looks like complete overkill. In small teams
At the same time in small teams this kind of process looks like complete overkill. In small teams
which deal with small chunks of work knowledge about risks (about everything actually) is often commonly shared. The problem isn’t about bringing individual opinions to the table. The problem is to make risk management as simple as possible yet still effective.
An easy and powerful approach here is to forget that there is something like risk management at all. At least to the point where you don’t consider having dedicated formal process to do risk management. Instead you incorporate risk management to everyday tasks: stand-ups, retrospectives, demos, planning meetings etc. You discuss potential risks every time you discuss a task or story. You discuss potential risks whenever you feel about it.
You won’t even need a risk log. If you talk about risks at every occasion you quickly learn how to catch those which may become painful (filtering by type) and those which are likely to hit you (filtering by frequency of mentioning).
When you keep talking about risks all the time people learn to deal with them naturally as they work on their tasks. Potential performance problem Luke mentioned yesterday? I’ll run some stress tests as I just have a while and maybe Mike would take a look at database as he’s already tweaking it to build that new feature. The trick is we don’t call it a risk. It is just a performance issue. Possible performance issue actually. Luke just thought it might become a problem but in a couple of days the problem will be gone, this way or another. And you don’t need to use the word risk, have a risk log, perform risk assessment, build and implement mitigation plans etc.
The only thing you need to have this kind risk management in place is a bit of trust and open atmosphere. Oh, co-location and no-meeting culture may help as well but in small teams both are usually in place already.
Read this and other articles of Pawel Brodzinski on his Software Project Management blog.
which deal with small chunks of work knowledge about risks (about everything actually) is often commonly shared. The problem isn’t about bringing individual opinions to the table. The problem is to make risk management as simple as possible yet still effective.
An easy and powerful approach here is to forget that there is something like risk management at all. At least to the point where you don’t consider having dedicated formal process to do risk management. Instead you incorporate risk management to everyday tasks: stand-ups, retrospectives, demos, planning meetings etc. You discuss potential risks every time you discuss a task or story. You discuss potential risks whenever you feel about it.
You won’t even need a risk log. If you talk about risks at every occasion you quickly learn how to catch those which may become painful (filtering by type) and those which are likely to hit you (filtering by frequency of mentioning).
When you keep talking about risks all the time people learn to deal with them naturally as they work on their tasks. Potential performance problem Luke mentioned yesterday? I’ll run some stress tests as I just have a while and maybe Mike would take a look at database as he’s already tweaking it to build that new feature. The trick is we don’t call it a risk. It is just a performance issue. Possible performance issue actually. Luke just thought it might become a problem but in a couple of days the problem will be gone, this way or another. And you don’t need to use the word risk, have a risk log, perform risk assessment, build and implement mitigation plans etc.
The only thing you need to have this kind risk management in place is a bit of trust and open atmosphere. Oh, co-location and no-meeting culture may help as well but in small teams both are usually in place already.
Read this and other articles of Pawel Brodzinski on his Software Project Management blog.
which deal with small chunks of work knowledge about risks (about everything actually) is often commonly shared. The problem isn’t about bringing individual opinions to the table. The problem is to make risk management as simple as possible yet still effective.
An easy and powerful approach here is to forget that there is something like risk management at all. At least to the point where you don’t consider having dedicated formal process to do risk management. Instead you incorporate risk management to everyday tasks: stand-ups, retrospectives, demos, planning meetings etc. You discuss potential risks every time you discuss a task or story. You discuss potential risks whenever you feel about it.
You won’t even need a risk log. If you talk about risks at every occasion you quickly learn how to catch those which may become painful (filtering by type) and those which are likely to hit you (filtering by frequency of mentioning).
When you keep talking about risks all the time people learn to deal with them naturally as they work on their tasks. Potential performance problem Luke mentioned yesterday? I’ll run some stress tests as I just have a while and maybe Mike would take a look at database as he’s already tweaking it to build that new feature. The trick is we don’t call it a risk. It is just a performance issue. Possible performance issue actually. Luke just thought it might become a problem but in a couple of days the problem will be gone, this way or another. And you don’t need to use the word risk, have a risk log, perform risk assessment, build and implement mitigation plans etc.
The only thing you need to have this kind risk management in place is a bit of trust and open atmosphere. Oh, co-location and no-meeting culture may help as well but in small teams both are usually in place already.
Read this and other articles of Pawel Brodzinski on his Software Project Management blog.
About Pawel Brodzinski
Pawel Brodzinski is an experienced leader and team builder who managed different software teams along his career from tiny groups working on in-house solutions up to big divisions working on multiple complex projects for big corporations. Pawel is a fan of choosing right approach to right problem and doesn't believe in a silver bullet. He is well-recognized blogger writing about software project management at http://blog.brodzinski.com. Pawel is passionate about leading great teams, fixing broken projects and creating high-quality software.
View all posts by Pawel Brodzinski →
Enlighteded thought…,
Team inclusiveness is most essential to identify/mitigate/manage the potential risks of the project.
Thanks Pawel for your excelleant view.
It is a nice thought.. But I would call it more a wishful thinking.
Having a vast Project Management background, I agree with the part that for small teams the classic Risk management is time consuming and not cost effective. Still, in my experience there has to be some kind of Risk management method, at least a Risk log. If the name Risk is not good, call it Open issues list, but have a list.
Otherwise you may lose some of the risks. Small teams work very closely and discuss risks all the time anyway, still people being human, get distracted. One has a sick child at home, the other have a car in the garage and have to discuss repairs on the phone every couple of hours, the third is on a business trip. So you identify the risks in time only if you ask the right questions, which means that somebody in the team need to be constantly aware. Since he is human too, managing Risks log as a task, helps you to have it in mind always.
And sometime a small problem develops into a big one and this development might be missed if the problem when small wasn’t monitored because of forgetfulness.
We could discuss the semantics but if something is an issue we have bug tracker/task list to put the issue there. This is an easy part.
The hard part is when there isn’t real problem yet, but you feel it may appear. Task list don’t work well anymore here and that’s why we often have separate risk log. The problem I see with risk logs in different teams is the risk log has probably the lowest possible content quality. Actually barely anyone cares what is in the risk log. And the effort to keep it that way is pretty significant. And the effort along with low quality outcome result in negative people attitude to risk management as a whole.
Informal approach described above isn’t wishful thinking. I see it working every day. It isn’t easy. You can’t implement it in any team. But small teams are specific. Level of trust is typically much higher than in big teams. You can easily co-locate them. It is much easier to build good atmosphere etc.
It isn’t a sure shot method, but it works. Actually that’s exactly how we’re doing it in my current team and it is one of two teams I worked with, which had pretty good risk management process. (The other one had very formal way of doing it and a dedicated tool developed to support it.)