An IT Investment Risk Framework is a set of constraints that an organisation imposes on its development organisation to ensure that IT Investments are delivered in a way that manages the risk involved. It should create failure containers so that any failure does not propagate across the organisation like the failure at Knight Capital which caused the organisation to fail.
The boundaries imposed by the framework should be negotiable rather than fixed, otherwise the framework may fail catastrophically. (Hat tip to Dave Snowden’s Cynefin Framework.)
The Risk Framework should NOT specify how the IT Investment is made, simply the way that IT Investment risk is managed. The Risk Framework specifies a number of Commitments placed on the development organisation when they accept funding for an investment.
By comparison SAFE and LESS are frameworks that seek to optimise the delivery of value to the organisation. They provide a number of enabling constraints in the form of principles. The SAFE and LESS frameworks can both be deployed within a IT Investment Risk Management Framework providing they satisfy the its constraints. In effect, they are an Option that the development company may adopt.
In summary an IT Investment Risk Management Framework is a commitment placed on a development organisation whereas the SAFE and LESS frameworks are options available to the aid development.
The IT Risk Manager 
June 12th, 2016 at 1:59 pm
Hi Chris, thanks for sharing your perspective that I know is based on your experiences. I’m somewhat following what you’re talking about, but a more in depth example would help me grasp it even more. Do you have an example that you could share?
July 2nd, 2016 at 12:59 pm
[…] agile is about implementing a process or method. Instead I will argue that organisations need a framework […]
July 3rd, 2016 at 7:46 am
[…] My thanks to Martin Burns, Erik Gibson and David Morris for great challenges and questions about the Framework: […]
July 7th, 2016 at 11:43 am
Hi Chris,
Great post.
As regards the following statement, I was wondering exactly what you meant by negotiable? “The boundaries imposed by the framework should be negotiable rather than fixed, otherwise the framework may fail catastrophically.”
Do you mean that boundaries should be occasionally permeable or else impermeable but elastic? I strongly advocate the latter. I think a boundary that is occasionally permeable is really a filter rather than a boundary. If you use the former where you need the latter then things are likely to go badly wrong (e.g. zombie organisations in a free market economy which are deemed “too big to fail”).
I would also argue that the need for elasticity is not to prevent the framework from failing catastrophically but to prevent the managed asset from failing catastrophically: the two factors which determine the impact of a failure will be the size of the failed entity and the velocity of the failure process. Elastic boundaries dampen the failure process, reducing vecolity, enabling control and thereby reducing impact.
July 9th, 2016 at 12:07 pm
Hi Julian
Thank you for brilliant questions, builds and corrections. Yes. I am referring to catastrophic failure of the managed assets and as a result, loss of confidence in the system which may lead to people ignoring it altogether.
The obvious negotiation is that the managed asset currently has a lead time longer than the boundary. The managed asset can negotiate to be operating within the framework (even though it fails one of the boundary tests) if it can agree a future date when it will be within the boundary and can demonstrate progress towards that goal. in effect acknowledging and agreeing to a centred set of values, even though it does not meet the bounded set of value.
We can all imagine scenarios where there are important special cases that do not operate within the boundary. For example, a hardware or software component that cannot operate within the boundary for structural reasons. In those cases, the framework needs to be flexible enough to be extended, or it should contain a mechanism to manage exceptions. If the framework does not allow negotiation on the boundaries, assets will be managed outside of it and control is lost which in effect is a failure of the framework.
Even though we cannot imagine them, there are scenarios that we cannot imagine where we need to negotiate the boundary. The framework need to be flexible enough to manage them.
In other words, the framework needs to be as Agile as the assets being managed.
Thank you again.
Chris
November 27th, 2016 at 2:35 pm
[…] including the executives. In order to manage those risks, the organisation needs a framework to help them ensure they understand the risks, and appropriate processes and instrumentation to […]
December 3rd, 2016 at 7:18 am
[…] IT Risk Management Framework […]
December 19th, 2016 at 7:08 pm
[…] Rather than force a team to adopt Agile processes, a more enlightened leadership approach is to place constraints on the teams and let them decide how to meet them. This is what Al-Noor Ramji did at DrKW when he insisted every project should deliver value every three months. The leaders can then provide support for those who want to learn new approach (such as Agile) and tooling that might help them achieve that goal. An even more enlightened leadership might offer the choice of traditional oppressive governance and a light weight IT risk management framework. […]
December 22nd, 2016 at 5:34 pm
[…] the Fox concept… The fox knows many things, but the hedgehog knows one important thing. The IT Risk Management Framework is a fox thing, it is a super clever subtly complex framework for clever foxes to provide real […]