Agile Risk Identification – From the Trenches

How many times have you felt a project could have done with better at risk identification or felt if only you would have got a particular individual or team involved.The effectiveness of all other risk management strategies like response planing, are directly related with the how effective risk identification has been.As with other risk management process, risk identification is an iterative exercise. However there is more focus on risk identification during the initial phases compared to the other phases.

So what makes the risk identification process most effective? Yes, there are the tools and techniques like brainstorming, diagramming techniques and Delphi methods. But what really makes the difference is getting the right people,teams and groups engaged and how soon you interact with them. Without sounding repetitive or restating the obvious , the earlier you are able to identify these individuals and groups and engage them effectively, the better you are at hedging of the threats and capitalizing on the opportunities.(PMBOK refresher – Risk referred here involves negative risks i.e threats as well as positive risks i.e opportunities. ). As Derek Huether (whom you probably, by now know as the zombie guy) points out in his post ‘Call Agile Whatever you want‘ , we have been using this methodology to carry out our risk identification exercise i.e placing people and interactions over the tools and processes, without actually terming it ‘Agile’.

To identify the right set of people who will be engaged is challenging. Some of the groups and teams that should be invited to participate in risk identification could include.

• Project Team - As obvious as it may seem, it is not uncommon to come across cases where the entire project team has not participated in risk identification. Each member of the project team can help uncover potential risks which might not seem obvious in the beginning. Since they are directly related and responsible for their specific delivery areas, they have the ability to identify risk which others would have been oblivious to. However this does not limit their risk identification to theirs specific areas only and it should not be taken as a constraint. In an ideal scenario you would like to have risk identification brainstorming sessions with the entire project team. Yes, there might be challenges with distributed and dispersed teams, but that’s where the tools and technology come to the rescue.
• Parallel Project Teams- Within the organization, at any given point of time there might be more than one active project.Even if these are not part of the same program or portfolio, they might still have interdependencies among them. These interdependencies are a source of risk and as such it makes sense to engage the project / program managers from these active parallel projects and initiatives to participate in risk identification.
• PMO / EPMO – The Project / Program Management Office or the Enterprise Project Management Office (if there is one) has an enormous vault of knowledge base and experience on past projects and the associated risks. A designated representative from the PMO/EPMO can bring in the experiences with respect to the risks that similar projects have faced in the past. They can also provide insights on the probability of realizing those risks as well as how effective past response plans have been.
• Project Sponsors – Project sponsors and stakeholders can bring in their perspective on any potential budget or funding related risks that might impact the project.
• The End Users – You would also want to include the end users of the product or the service that the project delivers, assuming this is different from the project team. They can bring in their experience to provide insights on the risks related to functionality and scalability of the application or product from an operations perspective.
• Production Support Teams – Lean organizations today have separate project and support teams (i.e. production teams that support the application and product after it has been deployed). Projects teams are often formed  for a the duration of the project only and might not have the complete picture of the production environment. The Production support team is best place to identify risks related performance or incompatibilities that may arise in a production environment. Project transition from development to production is one areas where risks might crop up. The production support teams can help identify them as well.
• Cross Functional Departments – An anatomy of enterprise risk shows that the risk source is enterprise-wide.The functional departments and teams can be involved in risk identification. They can perceive risks that the project team and stakeholders might not. The marketing team might uncover risks resulting from the changing market dynamics. Similarly the legal team can highlight any probable risks in the statutory compliance area.
• Subject Matter Experts – Subject matter experts including functional and technical specialists can be brought on board to participate in risk identification. These specialists and architects may be part of the project team itself, but agile teams may not always have that luxury. The decision to engage these groups will depend on the complexity of your project. However I would prefer to have these experts engaged at least once during the initiation phase.

Up until now the people and the interactions discussed were within organizational limits. What about the knowledge base and expertise outside the enterprise? How do you get their inputs without compromising on confidentiality? And do you really need to? Well, it can get a bit tricky here. In case do do decide to tap this knowledge and experience, you must do so with caution. Couple of examples on whom and how to engage can include

• Professional Groups – Professional groups and application user groups have been leveraged for their best practices, but they might also be used to complement risk identification. While you can dig in the archives and forums to look related projects and the challenges they have faced, you can also choose to involve these groups more actively i.e via questionnaires and surveys without getting into the specifics or divulging sensitive information. Based on the group, it might also be a good option to run these surveys in an anonymous manner.
• Social Media – Recently there has been a lot of activity on the topic of how to use social media can be used effectively in Project Management. But can you use it specifically for risk identification? Well you might actually have. How about the groups on networks likes LinkedIn? You can post scenarios and request suggestions. With a little tweaking you can setup polls, which can feed into your risk analysis latter on. A word of advice here, be patient.

While you might never be able to completely identify all the risks that impact your project or initiative. What does make a difference is how early you have been able to identify the risk and how wide the scope of your risk identification has been.

Have any agile (or whatever you call it ) risk identification you want to share ?

Tweet