I was recently challenged by Mike Orzen (co-founder of Lean in IT practises and my mentor) to answer a simple question: what do you think the purpose of change and release management is in ITIL or any other IT best practice framework?
I started by asking what aren’t they?
Change is not about doing the change, and release is not about managing the approval of a request to change. Change helps me make a decision; it answers the question WHY with a “yes” or “no”. But “yes” or “no” to what?
How many times has a request been approved, but what was delivered did not match what was approved? If IT has no value until it releases something that is usable to a customer, we better be sure that “yes” and “approved” are used for getting an organisation to be competitive, compliant, reliable, secure and cost-efficient as quickly as possible. Lean helps by creating a value stream from idea to solution, in a similar fashion to the ITIL lifecycle of service strategy to service operation. In both cases, the solution to the customer needs to be delivered as timely as possible.
You can’t manually approve every request as this would block the flow in the IT value stream. So the creation of standard change types assist in identifying low-impact, repetitive, and easy to fix types of requests. LeanIT likes standard work, as once you know if the request or change will not place the organisation at risk of losing a customer or wasting money, you can then automate the decision process to flow the request to the design phase, if required. If it will impose a risk or loss, then the request can be routed to a more formal approval process that can also be leaned over time.
Change should control every aspect of a release (the doing process of an approved change), so we have to look at all of the places change gets involved to help design a fast, flowing stream across IT, and ultimately one that works from the customer (pull) instead of IT pushing releases to the customer.
So where does or should change get involved?
The above could form the basis of a release process. I am sure more questions are needed, but if we allow the various teams to continuously improve the above, we can release valued services into the organisation. The teams might use lean methods such as kanban boards to control work, kaizen to improve work and agile or DevOPS to get services developed and agreed. Another aspect of lean that the table demonstrates is waste removal. If the change gateposts help to reduce defects, re-work, wait time between tests via automation or script reuse, for instance, then the flow of the value stream is enhanced end to end. Removing or automating/facilitating the gates in a formal process will also help increase flow resulting in a better time to market, quality enhancement, productivity improvement and cost reduction.
Configuration management – the needed process for ITSM & lean success
To be effective (first) and efficient (second), we need data. Where are requests, business cases, regulatory and architectural requirements for design, code, tests, or service acceptance criteria kept for example? We turn data into information to gain knowledge to deliver value. Configuration management is the data to knowledge management process. The information in a configuration management database (CMDB) can be used to enhance the way a process, team or tool performs. For instance, if we create a cycle of CCRCCR: (change to configuration to release to change to configuration to release…) to be as fast as possible; then the agility of creating solutions in a timely manner becomes our standard culture or way of working.
How do we start?
I suggest by mapping the value stream, as much as possible, from end to end. At first you may only be able to do the parts internal to IT but keep adding until you have the entire value stream from requester to customer mapped. Lean value stream mapping helps improve how an IT organisation, business enterprise and partners create and improve ways of work. Get as many representatives as possible involved in a mapping exercise and use post-it notes to visualise the current way of working. Try to get the people that do the work involved as this generates buy-in for future change improvements. Your post-it notes could include time of steps, teams involved, tools used, etc. Don’t trust what you create in a conference room. Go out and see (lean calls this “gemba”) to validate your understanding.
Now return to the conference room armed with your knowledge and improve the flow of the stream (steps). Add a few measures to control the flow of the stream and most importantly BEGIN. Don’t wait for the tool changes or other procrastination reasons: start using the new way. Check how changes are approved, the steps performed to create a release, the results of any improvement (agreed and tracked) and use the CMDB to maintain the information such as your review of other ITSM processes. You can continue to create a unified view of your IT practices, processes, tools, capabilities, etc. The lean trick is to make checks or improvement a daily part of work, not something owned by the program team, but by the people doing the activities all along the stream. Let them own and celebrate the success.
Set some stretch goals for how long it should take to agree a requestor, how fast to perform a release etc. Look at quality, productivity, stock reduction (number of tests or environments needed) as examples. PLEASE note that cost is a benefit and if you see that as a target it may be viewed as a job-cutting exercise when it should be viewed as a job enhancement opportunity.
Please let me know what you think and try blending Lean into your ITSM world. Have fun doing it!