I have been learning a little a bit about systems thinking. I have spent a bit of time watching, lisstening to and and reading John Seddon’s work. His observations of the UK public sector resonate with what I saw when I worked there.
A lot of what Seddon talks about is the industrialization of the service sector and government services. He explains why he thinks that the arbitrary utilization of management tools and targets is actually counterproductive. He advocates systems thinking and suggests ways of achieving a regime of continuous improvement using the Vangard Method. ( I am not going to comment on how the Vangard Method could be construed as a tool.)
One important thing Seddon talks about is the principle of “Failure Demand“. This is additional demand upon a system that would not have been there if the system had done what it was supposed to do. In IT operations this sits neatly with the Visible Ops idea that you should break your work in to what creates value for the business and what does not. Merging the two together you have two levels of waste in Incident Management to work on reducing. I am going to classify them as definately failure demand and probably failure demand:
Definitely Failure Demand
The following fit Seddon’s definition of failure demand:
- Incidents logged due to an incident. When a customer or client needs to log another incident because the original one that she logged did not resolve the issue.
- Incidents logged due to a recently completed change. If a change causes a breakage that results in a customer or client logging and incident.
- Incidents logged to expedite an Incident. While a good service desk rep should not let this happen, it does and is failure demand.
- Incidents logged to expedite a change. Seems to happen a bit – the squeaky wheel and all that.
Unfortunately, figuring out if any of these things happen and how much involves trawling through the demand side of your ITSM system. This is definitely a good thing to do anyway. Any systems thinker will tell you that there is lots of really good information to be gleaned about your system by examining the demand side.
Probably Failure Demand
Here I am stretching Seddon’s definition to include some of the wisdom of Visible Ops and the principles of Devops.
Visible Ops suggests that you seperate your daily work in to tasks that add value to the business (ie. the mission of your company, or that of your customers) and those that do not add value. They advocate finding ways to reduce time spent on non value add tasks, especially the predictable stuff. Is it fair to say that incident management is ficing broken stuff. Therefore, it is actually switching negative value to nominal value. It definitely does not add value to the customer’s business. Does that mean it is failure demand?
In Devops – the hot, new cultural force that is trying to propel IT operations from good enough to excellent – talks about not viewing application devolpment, and deployment / support as separate processes. Instead they suggest we view development and operations as a single system where one part affects the others. If that is the case then are incidents logged against that application failure demand against that it? Instead of declaring the app as “in production” and making incidents operational issues, by treating these incidents as failure demand upon the development process perhaps developers will be more compelled to take a more proactive role in incident management. Perhaps failure demand could also be another metric the project managers track.
A lot of the ideas I have just said are still half cooked. Any comments, thoughts or extra ingredients to add are welcome.




