Well, I started this three part post back in September, then got caught up in other things, and never quite got around to finishing it. I thought for a while of taking the Douglas Adams approach to trilogies: “Check out these two blog posts, giving a whole new meaning to the term ‘Three Part Series.’” However, finding myself to be a posterchild for the Language Action Perspective, I felt that it was finally time to get back to wrapping it up.
So a bit of summary to get us to the right place:
1) Part 1 (Innovation Stories from Toyota) – we visited a fundamental feature of innovation – that successful organizations are ones that communicate their values to the folks identifying improvement opportunities, and that encourage ideas for projects to be developed from a wide variety of inputs.
2) Part 2 (The PMBOK) – where we took that concept of developing feedback mechanisms and applied it to the project as a system, discussing how the PMBOK processes can be interpreted as creating a self-organizing, learning system.
And finally, Part 3, where we apply the same focus on ITIL processes, and look at how this ends up presenting the organization as a fractal:
First of all, I don’t plan to introduce ITIL here. There’re a lot of resources for that, and the best place to start would either be the Wikipedia page or the ITIL v3 Pocket Guide. A lot of folks have different definitions of ITIL, based on their own focus, and I must admit that I am no different. Some people have described it to me as a configuration database and the processes required to keep it up to date. I prefer to see ITIL as an innovation system.
In ITIL, we have a prescription for a Change Management system. Think of this as a processing mechanism for the myriad of change requests that pour into an IT operation on a daily, if not hourly basis. The Change Management mechanism reviews changes, assesses potential risk, cost, and schedule issues, performs a cost/benefit analysis, and then manages the change building process until (or through depending on whom you talk to) the Release Management process.
So where do these changes come from? That’s the beauty of ITIL in my opinion. The guidance tells us what processes to put in place to identify potential changes. We get a rich list of processes such as:
- Processes that monitor variance between the current state and the desired state:
- System Monitoring
- Capacity Management
- Demand Management
- Incident & Problem Management
- Availability Management
- Processes that define our desired future state:
- Service Level Management
…and the list of processes goes on. Each individual process coming with all of the baggage of dedicated user groups, vendor ecosystems, critical blogs, and online forums…
In my view of the world, each one of these processes is primarily tasked with a single activity: identify discrepancies between the current state environment and the desired future state environment. Then identify what it will take to get us to the desired future state and feed it into the Change Management process. Each of these processes is a sensing mechanism for change proposals, or as they’re called in ITIL parlance, RFCs.
So in a sense, we have identified yet another innovation system. Where else in the organization can we observe this combination of:
- A Goal/Values Identification Mechanism
- A Problem Sensing Mechanism
- A Problem Prioritization Mechanism &…
- An Execution Mechanism…?
What about Strategy Development, Portfolio Management, Project Management, Operational Change Management, and even taking that further, Departmental and Application Level Change Management….an endless cascade of repetitive forms and functions?
It’s a fractal structure, repeated ad infinitum from the top of the organization to the bottom.
