Many organizations rolling out an ITIL program have approached it in a prescriptive manner trying to drop “best practices” into their IT shops. The added discipline is invariably an improvement over most home grown ad hoc practices, however, as the ITIL literature makes clear, this flexible framework and best practice guidance for the Service Management Lifecycle are just the starting point. The framework includes in addition to the principal four Lifecycle Phases namely Service Strategy, Service Design, Service Transition, Service Operation the over arching phase of Continuous Improvement.
Continuous Improvement is an essential component to getting the most out of ITIL. It is not enough to just drop in best practices, it takes careful analysis and tweaking to maximize the outcomes you seek. ITIL is viewed as successful for three reasons; vendor neutral, non-prescriptive, and best practices. Note that ITIL is not saying that we cannot learn from the experiences and thought leadership from the world’s best in class service providers, just don’t blindly follow these lessons prescriptively.
The question you need to ask yourself is how do I take some ITIL Service Process and apply Continuous Improvement to bring more value to my organization. Consider the Service Transition Process of Change Management. If we start with the premise that change management is to control the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services, we can see how Lean IT drives us to a significant greater degree of fulfillment of that purpose. Most organizations have a Change Manager who approves minor changes and manages a Change Advisory Board (CAB) for larger changes and likely an Emergency CAB to handle emergencies.
Lean IT is largely congruent with this perspective; the difference comes down to managing the workflow. Lean IT would advocate that IT should focus on making many small changes over fewer bigger changes (small batch size) and that the changes be made automatically and integrated continuously. So instead of major changes managed within a VCS branch with a subsequent and often challenging integration phase, changes are small and continually merged into trunk (using feature toggles if required) to ensure they are integrated. Moreover, Change Managers who have previously focused on inspection and review of changes attempting to predict how those changes will fly in production now can be focused on helping improve the automated validation tooling driving Lean IT Change Management. With this approach the Change Manager now brings value to the engineers work by helping them improve the flow of their work. Contrast that to the traditional CM who acts as a gatekeeper and invariably adds delays to the release of the change the organization has requested. In my next post I will explore this further by addressing the role of the Change Manager when using Infrastructure as Code.