Monday, 26 May 2014

Change and Realse Management

I was recently challenged by an organisation to answer a simple question: what is the purpose of change and release management is in ITIL or any other IT best practice framework?

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?

An example:

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.  


Friday, 23 May 2014

Why Process Mapping for improvements realisation and organisation maturity are linked

We do a lot of work with clients in the areas of Business Process Improvement and Systems Implementation.  When supporting clients in these spaces, we find that mapping current and preferred process states will reveal enormous and broad value.  Overlaying these maps with our practitioner lens reveals all kinds of opportunities to:

  • Understand the user experience
  • Reduce complexity and process time
  • Define and assign accountabilities
  • Understand and optimise interfaces and handoffs
  • Define capability and skill requirements
  • Inform change plans and change ‘hot spots’

We are yet to see a process improve itself, however with the right people and the right focus there are masses of value there to be realised, and generally a set of quick wins that can provide a momentum for change.

Of significant value is the extent to which process mapping informs change and communication planning.  What underpins any successful process is clarity, accountability and performance expectation – sound familiar?

Many organizations look to Lean Six Sigma (LSS) in order to meet bottom-line expectations or even just to survive in a competitive business climate. After being enticed by the potential of a LSS program to dramatically improve business performance, leaders often dive head-first into a deployment.

Unfortunately, they may not understand that as an organization they are far from mature enough to utilize LSS in a meaningful way. When the LSS program does not come to fruition as expected (whether expectations were realistic or not), it puts a bad taste in everyone’s mouths for quality improvement practices.

For a more positive experience with process improvement, a company must first assess its maturity level in regard to quality management.

Stating the Obvious

On average, approximately 94 percent of all quality management implementations fail. That statistic can be argued, but suffice it to say that the number of implementation failures is extraordinarily high. The greatest factor in failure is a lack of organizational maturity in quality management systems and trying to implement far above a company’s current state.

Should an organization seek to reduce variation in a process when it has not established standard work for that process yet? The answer is obviously “No!”

But one of the questions that most leaders fail to ask is: Should I be seeking to implement LSS projects when none of my team members understands how to properly manage a project? The answer is a slightly less obvious “No!”

These questions and answers may seem obvious to anyone within the LSS universe, but they are not obvious to an uninitiated organizational leader.

A Quality Management Maturity Model

To get the biggest bang for its buck and have an effective implementation, a company needs to be clear on where it is starting from on the quality management maturity scale, and thus where effort should be expended. Leaders can identify their organization’s maturity level using the model shown in the figure below.

Quality Management Maturity Model

This figure shows a clear progression in quality management processes, with one process building on the previous process once competency is reached at any given level. Notice that Six Sigma is at the far right; tacklingvariation should not be contemplated until the vast majority of waste is eliminated from the system. In most organizations, there is not just low-hanging fruit, there is fruit lying on the ground that will rot if it is not picked up and used.

Focused waste-reduction projects should not take place until employees are properly trained to manage projects under the constraints of time, cost and quality – which become the areas for targeted Lean projects to reduce time, eliminate costs and improve quality.

From a business perspective, what would an executive in a business that is thinking about starting a quality program see? There will be a cadre of those in the organization that hold sway because they represent the organizational knowledge bank for getting the work done – the way it has always been done. And the way it has always been done is haphazard, and purposely so, as it provides power to the cadre. Chaos is ever-present so that the cadre is able to regularly pull the organization together to meet a deadline or back from a financial brink. The work areas will be cluttered and only the cadre will be able to find what is needed.


As shown in the figure, 5Ss (sort, straighten, shine, standardize, sustain)should be the first process implemented so that everything involved in any given process can be put in place and itemized. The cadre will fight this as a waste of time and intrusion into their work areas. A slowing in production may take place until the cadre realizes that the quality program is there to stay. On the flip side, there will be employees who want to see change as they have been victims of the cadre and will push to accomplish the work in spite of any hampering efforts from the cadre.

Standard Work

The next phase is to hold multiple kaizen/kaikaku (“change-good”/ “change-great”) blitzes, at least one in each section of each department in the organization. These blitzes should be held prior to training the majority of personnel in Lean so that teams can fully explore the nature of the problems their divisions face in their current processes. All employees should participate in the identification of what that work is and how to best accomplish it; the group as a whole can determine a final task list of what will be the standard work going forward for each process. With those task lists combined, a standard value stream will be mapped for all to follow.

The cadre will push back hard at this point as they will be afraid of losing control; however, they will be unable to stop the momentum of the process improvement deployment. They may shut down completely and self-identify as roadblocks. Other cadre members will identify as new leaders committed to the process, and standard work will be set in place as long as the executive team show unequivocal support for it.

Project Management

If the organization gets past the standard work stage, it is ready to be managed with a focus to time, cost and quality factors as processes are developed and discrete projects are identified. The organization can begin to be managed with a focus to time, cost and quality factors as processes are developed and discrete projects are identified. At this stage, personnel can be trained in project management combined with Lean. This is also where the design of the future state of the organization can begin.

Mature Lean

With the future state clarified, it can start to be set in place through systems mapping, planning and waste reduction. These changes will drive the bottom-line impact of the quality process and ensure sustainability as the organization becomes mature in its use of Lean.

Six Sigma

Now the organization can tackle variation through the use of Six Sigma in the tracking and analysis of outputs of tasks and processes to ensure that what the customer wants, the customer is getting. As capabilities grow, new ideas identified from ongoing kaizen/kaikaku blitz events can begin to take shape in an environment where Design for Six Sigma is built in from the start. This can drive innovation, new revenue generating services and strategic engagements, aid in rapid deployment, and will not cause disruption of existing systems and processes.


There are two battles to face in working through the quality management maturity model.

  1. All executive leadership must be on board with the process improvement deployment.
  2. The cadre members that become roadblocks to progress must be removed or co-opted.

How can the rest of the quality management maturity model be achieved? There are only three words to focus on after that: training, training and more training!

Thursday, 1 May 2014

Phases of gap analysis

A gap analysis is a tool that ITIL recommends organizations use to compare their current state to some future desired state. The idea of a gap analysis is to help an organization understand the path and commitments in terms of resources and time that it must make to achieve a particular goal.

The Continual Service Improvement doesn’t provide too many specifics about a gap analysis or how one should be conducted. When I’ve been involved in gap analyses, I tend to think of the activities as occurring in several phases. Following are the phases of a gap analysis and some of the activities that occur during those phases.

Phase I: Planning 
The initial phase of a gap analysis involves planning the various gap analysis activities. This includes finalizing the scope of the gap analysis, agreeing to gap analysis questionnaire content, and determining the format of the gap analysis. During this phase, relevant stakeholders are identified, the formal communication plan is established, and the deliverables are specified. At the end of this phase, the gap analysis is formally kicked off in the organization.

Phase II: Discover and Review Background Information 
During this phase, those conducting the gap analysis review various sources of information. These sources of information include existing policies and process descriptions, service documentation, process flowcharts, roles and responsibilities, process outputs, communication plans, CSI activities and plans, service level agreements and associated reports, and other information as applicable. The purpose of this phase is to establish the organization’s formal intent for service management activities.

Phase III: Stakeholder Interviews 
The stakeholder interview phase involves interviewing existing service owners, service managers, process owners, process managers, and any other relevant stakeholders in the organization. The interviews are conducted based on the questionnaires established during Phase I and should investigate based on the information discovered during Phase II.

Phase IV: Draft Gap Analysis 
Based on the results of prior phases, an intermediate assessment is drafted and reviewed with key stakeholders. Significant portions of the gap analysis are reviewed and adjusted with key stakeholders, and the gap analysis is validated with organizational sponsors.

Phase V: Complete Final Deliverables 
The last phase of a gap analysis involves making any final documentations to the gap analysis report; providing short, medium, and long-term recommendations; and conducting a formal gap analysis review meeting. During this phase, the gap analysis project is formally closed and the organization presumably start working on some of the items identified during the gap analysis.

A gap analysis is one of the most valuable tools described by ITIL. When conducting a gap analysis, following a logical, phased approach results in usable deliverables that help the organization achieve its vision.

© Copyright 2012 Gateway to Process Improvement LtdWebsite design by Toolkit Websites