When you review the definition of the role of an Architect you often see references to “managing” or “owning” technical risk. Technical risk might include

  • Does the solution perform in the prescribed way under typical load?
  • Is the solution secure?
  • Can the solution be integrated with all the necessary external systems?

So what does managing or owning this risk look like.

Most projects manage a risk log. This is a log of all the identified risks, the likelihood of their occurrence, the likely impact if the risk is realised, and mitigations to minimise the risk occurring or its impact if it does. Sometimes people focus efforts on the risk discovery. This is the process of identifying the risks and mitigations. Much effort is spent on this process and the results neatly compiled into a spreadsheet. This becomes a project document and is tightly controlled. Adding or removing risks suddenly becomes a chore and the document instantly becomes a historical record of the project risks when it was compiled. It no longer represents the current status. The project team have missed the point about managing the risk.

The project or solution landscape is constantly changing. If you are undertaking mitigating actions, you should be reducing the likelihood and impact of the risks. You may even be eliminating them. Your actions may have side effects, causing new risks to emerge. External factors could introduce new risks and turn risks into issues. Risks are not static.

One of the best pieces of advice I have received is to use a technical risk log as basis for constructing a daily task list. This means reducing risks, mitigating them and discovering more risks becomes part of your daily routine, driving your daily activity. This helps a risk log come alive rather than being a static list. You are constantly asking what is being done about technical risks rather than simply looking at them in a document.

This might not sound like it is appropriate for agile projects but it can be. Even if Architecture is a role rather than a person there is value in addressing risks regularly. This may involve reviewing the risk log with the PO and helping them understand what the risks are and what their impact might mean to the project and the solution. This can be fed into the prioritisation process so stories that address technical risk can be delivered at the appropriate times. The risk log itself is lightweight with each risk given a score or a weighting. As risks are mitigated these weightings are reviewed regularly. The total of these weightings are recorded at regular intervals (perhaps at sprint reviews) and the changes to the total weighting slowly burndown over time. This should be made visible along other with metrics on the project radiator, demonstrating to all stakeholders and other interested parties that the project is reducing its risk profile over time.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s