IIRMFW : Governance and Manage Risk (Part1)

The IT Investment Risk Management Framework for Agile development would be very different to that for Traditional approach. By its very nature, Traditional operates in the Obvious and Complicated domains of the Cynefin framework. Traditional assumes the correct answer which means it is not well suited to manage risks in the Complex and Chaos domains. The entire approach to risk management between Agile and Traditional is different. Traditional funds a list of features (Scope) to be delivered whereas Agile iterates towards a business value goal.

A traditional approach mandates a list of deliverables that need to be created to satisfy the SDLC. Agile mandates a list of risks that need to be managed in the context of the investment. This difference in approach means that two projects doing different things could both be satisfying the Agile Risk Management framework. Even stranger, there may be two projects following the exact same process but one of them satisfies the risk management framework BUT THE OTHER DOES NOT! For this reason, the policing service within the governance framework is critical and very different to traditional SDLC policing.

Traditional SDLCs are typically practice and deliverable based. There is a simple yes/no checkbox approach to policing the IT investment. e.g. Do you have a functional specification? And a project plan? And a test plan? Do you have 100% automated test coverage?

Agile Risk Management Frameworks are much more principle based. The policing service needs to be able to identify where there is risks because the approach is not quite right. e.g. On one team, the scrum master does all of the updates to Jira. On another team, everyone on the project updates Jira. Both projects are transparent but one might have a key man dependency. The policing service might ask to see a Skills Matrix or ask other team members if they know how to use Jira. Simply put, its not black and white.

The key role of the policing service is to challenge claims of “transparency”. To ensure that the perceived transparency is genuine. Having shed some transparency on risks, the policing service can suggest resources for the team to learn to improve. As they have a responsibility to the organisation, the policing service are responsible for the making the risk visible and recording it so that it does not become forgotten. Most teams do not intend to obscure information, often the problem is a lack of understanding and experience.

The diagnostic skills required of the policing service that allow them to identify risks that should be managed are similar to those of an Agile Coach. Even though the skills overlap, the Agile Coaches should never be used to implement the Policing Service. They can coach the policing service and help them acquire analysis skills. They should not act as the policing service, otherwise it will destroy trust between the team and the coach.

It is the responsibility of the policing service to ensure transparency on all risks. As such they should not report to a delivery organisation where there might be a conflict of interest between their responsibility to their management and the organisation. e.g. Consider private security guards versus independent police force.

It is the responsibility of the policing service to identify where the IT Investment Risk Management Framework is flawed. Either too constrained which limits the ability of the organisation to deliver, or not not constrained enough so that the organisation is exposed to risks that are not managed.