Last night I attended the software engineering forum on risk management and taxonomy that was hosted by Stewart Johnsonon behalf of Engineers Australia. This forum is a small group of software engineers that gather monthly to discuss various issues to do with the proces of building software. The typical format is that the host gives a short introduction to the topic after which the forum is open for discussion. As most attendees ahave been around the industry for sometime these discussions are a based on a large number of personal experiences.
The topic of risk management as presented by Stewart can be divided into identification, analysis, monitoring and resolution. Stewart’s presentation focussed on identifying the mapping that happens between the investigation/analysis phases to the corresponding monitoring/resolution phases. Of course as with any action in a software project there are always going to be reprocussions and I suspect that they need to consider a mapping back from any monitoring/resolution activities back to the identification/analysis phase. This would not only give the project team the feedback channel that is necessary for risk management it would also give them a process through which to iterate it in a similar way to the actual software dev process.
There was a bit of discussion as to which orgs this process should apply to and the general concensus was that we were talking about CMMI 3+ orgs. Imho this is wrong and that risk management should apply equally to all org sizes. Whilst a small org might not have the same number of projects from which they can extract data their projects are likely to be less diversified making their data more relevant to future projects. Further, if the process of risk management is so complex/time consuming that a small org can’t do it because of resourcing issues then it is questionable as to whether it is cost effective for an org of any size to carry it out – in all cases the process should be refactored to encompass the whole team, thus reducing the burden on any one person. This also gives the whole team ownership of the problem that raises its significance within the team.
I’d like to end this post with some open questions:
- How do you manage your risk?
- Do you look at the risk of a project at the beginning, plan tasks to resolve/mitigate and then tick off risk mgnt, or do you revisit risk at each project meeting?
- Is the current risk of the project an on going measurable item?
- How do you identify the risks of your project – do you have a set of standard risk areas or do you just brainstorm for areas of the project that might go wrong?
- How do you plan the monitoring/resolution tasks – do you have a mapping from risks to strategies?