*Version 2.0, November 1, 2003. Edited by Ronald G. Ross.
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.
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.
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.
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.
Source: ITSM REVIEW
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:
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
A few month ago, the Lead consultant of a large multi-national consulting company asked me to join them in a planned business review session with a large manufacturing company overseas.
I read the brief and quickly concluded it is a great idea. The big problem: I didn't see how managers could modify their leadership style to meet the coaching and training needs of each new hire. Instead, This lead consultant suggested hiring people who already fit their business approach to management.
I later researched this concept of Managerial Fit and described the process in The Essential Guide for Hiring.
The candidate assessment starts by first categorizing managers into six basic styles based on how hands-on or hands-off they are. During the interview, candidates are categorized into six companion styles based on how much support and direction they want and/or need. The two styles are then compared to determine their Managerial Fit.
Some managers overdo it. Others don't do it at all. As you read the following descriptions, position yourself and/or your manager on the grid from very controlling on the left to largely uninvolved on the right. Most managers have one dominant style but are flexible enough to deal with situations that require adjacent styles. For example, coaches can normally become trainers or delegators as necessary.
1. Controller: This is the directive micromanager style that oozes "my way or the highway."
2. Supervisor: These people need to tightly control a repeatable process using metrics and constant follow-up.
3. Trainer: These managers excel when working closely with people to teach them new skills. The best have the ability to back off and let people learn on their own.
4. Coach: These managers tend to work best with people who have most of the skills needed to do the job, but they are more than willing to coach them through new or problem areas. On an ongoing basis, they provide regular guidance, support, and feedback.
5. Delegator: These managers provide broad direction and regular feedback. They typically agree on the results needed but leave the detailed process up to the person.
6. Hands-Off: These managers tend to provide very little direction and limited feedback. They won’t intervene unless things go awry.
When interviewing people for management positions, I ask candidates who they like to hire and why. This allows me to assign them into one or more of these categories.
Some people need more direction than others and some want more than others. When I ask candidates to describe their major accomplishments and where they’ve excelled, I find the role the manager played. Patterns quickly emerge, depending on how much support, direction, and training the person needs.
1. Dependent: These people need constant direction, follow-up, support, and handholding.
2. Structured: These people perform best when required to do repeatable tasks on a continual basis.
3. Trainable: These people have the ability to learn and apply new skills but need extra support and coaching before they're left on their own.
4. Coachable: These people have the basic skills but are more than willing to take direction in areas where improvement is needed.
5. Manageable: These people prefer to be given lots of leeway in how the work needs to be done but are very amenable to support during the planning phase and in reviewing results.
6. Independent: These people prefer to be given broad direction and full responsibility for achieving the agreed upon result.
Managerial Fit problems occur when the manager's style does not complement the subordinate's needs or wants in terms of training, direction, and support. Problems occur on the extremes, or where the manager or subordinate isn’t flexible. For example, a very controlling manager hiring someone who requires more independence is a recipe for frustration and underperformance. Expect similar problems with a strong delegator-style manager who hires someone who needs extra coaching and direction.
Otherwise good people tend to underperform for three big reasons: the work itself isn't appealing or motivating, or they don’t get along with their manager.
Good managers underperform when using a skills-based job description to define the work, which leads to hiring people who aren't motivated to do the work since it wasn't clarified properly, or demotivating these same people by over- or under-managing them. Managers control the complete solution. Defining the work upfront using a performance-based job description will solve the first problem. Conducting a performance-based interview will solve the second. And even if the person isn't a perfect manager, understanding Managerial Fit will minimize the third.