Mapping the Customer Journey provides a basic template for understanding how a customer feels at each stage of a service engagement. While it may look like a sales cycle from the outside, the magic of a well-executed Customer Journey lies in the insight provided by this fundamental perspective shift. In this short video Patrick von Schlag begins walking us through the aspects of the Customer Journey.
Blog post – The ITIL 4 Journey – One Year In
Axelos was nice enough to ask me to write an ITIL 4 blog post a little while ago on the Managing Professional certificate. I was happy to do it; you can read a little more about what we came up with at https://www.axelos.com/news/blogs/december-2019/itil-4-mp-transition-a-transformed-framework
It’s been a couple of months since I worked with them on this post, and I’ve had a chance to reflect a bit on what we’ve learned in this first year of ITIL 4, and as part of this ongoing transition. A few lessons seem to keep coming up again and again, and I thought I’d share them with you.
There are countless new areas of guidance in ITIL 4 that will help you during your digital transformation journey. If you haven’t explored some of the new ITIL Specialist and ITIL Strategist programs, I encourage you to take a look. If you haven’t read the new ITIL books, they go far beyond traditional ITIL practice guidance to help you improve customer value and optimizing organizational resources. Take a look and reach out to us if we can help you on your journey.
One of the spectacles of the past 20 or so years has been the competing approaches and frameworks for improving governance, streamlining workflows, and delivering services. Practices like LEAN, Agile, ITIL, DevOps, and even governance frameworks like CObIT all competed for attention in promising adopting organizations more efficient and more effective teams, better results, and improved quality and consistency.
Well, the winner is in…it is…drumroll…all of the above!
Each of these approaches brings with it native practices and capabilities, yet most organizations are by now seeing that the most appropriate approach was never an “either-or”, but of course a “both-and.” LEAN brought us a focus on value streams, waste identification, and creating continual improvement cultures. Agile practice like Scrum introduced lightweight approaches to requirements (focused on user experience through user stories, a core idea in design thinking), prioritization through the use of backlogs, and acknowledging the reality that we just don’t know what we don’t know, and that being adaptive as learning occurs creates better solutions and higher customer delight. ITIL established the focus on service delivery and value creation, over mere execution of processes, and encompasses how cross-functional we must act to support the collaboration models we need to operate as end-to-end service teams. DevOps leveraged many of the above practices to drive a focus on the value stream of delivery and deployment of IT applications, and improves the velocity of solutions while improving the overall risk management of IT through rigorous testing and validation, environment controls through infrastructure as code, and improving flow with feedback. Even in the updated version of CObIT, the focus is on integrating new sets of best practices into an overall IT governance and management framework that acknowledges the profound changes in how IT operates.
Implications: There’s a lot to learn…and real upside for organizations that make the effort.
Most IT organizations are trying to adopt some number of these core practices, but often without an integrated vision of how they will work together to gain efficiencies and improve overall quality of service. In our consulting practices, we often see siloed thinking from development or operations organizations, with concomitant inefficiencies and poor results. Rationalizing these practices together is critical to get the value you seek from any of them.
The good news: there are many successful approaches to making this work. Over the next few weeks we will be sharing a number of success stories from organizations that have successfully adopted and adapted these practices to improve their organizations.
In the ITIL guidance, Capacity Management is broken down into three related sub-processes. In this blog we will look at the three subprocesses and how they help us have better visibility into customer needs.
The first of the subprocesses is Component Capacity Management. For this subprocess we could easily substitute the word Utilization, for the purpose of this subprocess is to maximize the effective utilization of the components we have. Whether we’re discussing disk space, bandwidth, processors, memory allocations, or any other use of our physical and virtual components, the goal is to extract the most value we can from the components that we have. All of the capacity management processes have a financial management link, so here clearly the goal is to be able to defer expenditures until needed, and to balance the cost of provisioning to the resource requirements.
The second of the subprocesses is Service Capacity Management. For this subprocess we could substitute the phrase “End-to-end Performance.” The purpose here is to ensure that services have the right level of end-to end throughput and response time to meet customer requirements. Again, the goal is “enough,” enough performance to meet the need without gold-plating or what in the Lean world we would call “overprocessing,” or over-delivery (and overspending) relative to the business need.
The third subprocess is Business Capacity Management. Here would could substitute the phrase “future planning,” and there is a straight line between business capacity management and budget planning. Here we look at both the existing component and service capacity needs AND the future ones; next week, next month, next year, what is happening based on the business plan and what are the implications for the capacity plan. In short, everything in capacity management is demand-driven. Business Processes drive business activity drive consumption of service. As business use increases (demand), provisioning must scale to support it (supply). This of course has implications for budgeting and spending patterns, with the rule of thumb that we wish to plan for what is needed, and defer expenditures until the need is realized. These could be for new services, or changes in the use patterns of existing services.
Techniques used in Capacity Management include application sizing, simulation or analytical modeling, and the use of a tactical capacity plan to maintain visibility across your services. Half the point of having a process defined like this is to establish this as a focus area, where the Capacity Manager can look across technical/functional disciplines to ensure that capacity provisioning is optimized over time.
How well does your organization do capacity management? Is the focus too technical, looking at the component level in detail but perhaps missing the end-to-end? Do you have the right interactions with your business customers to get a decent forecast of future needs and patterns of use so that your planning and budgeting is properly aligned? Do you have alignment with the members of your team looking at new technologies and their implications for capacity and service improvement?
Many people understandably think about ITIL as a process framework. When you describe good practices for 25+ processes and capabilities it seems a no brainer. Yet when you look at the books, their names, and their objectives, it becomes clear that processes are an important means (COBIT calls them one of seven enablers), but that the desired end is delivering services.The entire concept of service in ITIL is embedded in thinking end-to-end; how service teams facilitate outcomes for customers and manage costs and risks on their behalf.
When I teach ITIL courses, I emphasize the idea that services describe not in fact what we do in IT, but what the customer gets. How do our hardware, software, people, processes, etc. produce valuable results for customers and enable them to perform better, faster, or more cost-effectively? The entire construct of information technology is predicated on the CSI model, or how the technology enables the use and processing of information to automate and otherwise facilitate business processes.
If the goal is services (and therefore outcomes for customers), the how-to is the Service Lifecycle. WAAAAAAYYYY too many people consider ITSM consistent with the operational and support process around Incident, Problem, Change, and Configuration Management. In order to set the table for success in those operational processes, we have to be able to manage the service first. Here is a brief summary of how the Service Lifecycle notion really supports the cultural transformation from technology provision to service and outcome enablement.
Service Strategy – there are many things we’d like to do, but simply cannot. Why? Not enough money, time, people, etc. In short, we are always facing some type of constraints. Therefore, given all of the things we could do, what things will we commit to do, and who decides? Service Strategy outlines a transparent way to make strategic decisions in the face of uncertainty and limitations.
Service Design – how do we understand customer requirements for a service (utility and warrant you), and how do we in turn build/buy/integrate a service to meet the requirements. The Service Design processes enable us to essentially take a piece of paper (a Service Charter, and Approved Change Request, etc.) and transform it into a new or updated service.
Service Transition – my usual flip statement about Service Transition is how to take a new or changed service from development successfully into production without “blowing stuff up.” Sadly, the industry data continues to finger transition practices as a primary reason for production incidents. In the highly dynamic and Agile world we are working in today, change is normal and a fundamental source of competitive advantage in business. Our ability to streamline transition practices and build compelling and highly reliable models is critical to supporting highly iterative business needs.
Service Operation serves essentially as a party host. Deliver services to customers according to our agreed levels and support them as needed. In order to actually be able to operate services, we have to be able to visualize them (typically through a CMS), monitor them, and be able to coordinate support for them across a number of technical/functional teams. The service lifecycle emphasizes early engagement with operations teams during design, transition ( and even strategy) to ensure we don’t get over our skis when establishing service targets that will be incorporated into SLAs.
CSI emphasizes the need for accountable owners and the intentional and ongoing use of metrics and measures to drive ongoing, consistent improvement in the performance of processes and services. CSI supports process and service owners (and managers) in the proactive seeking of improvements in all practices across the lifecycle, and drives the execution of the 7 step improvement process to execute improvement projects and drive iterative improvement in practices.
While each service lifecycle stage clearly uses processes to carry out many of their activities, the bigger value proposition is how the service lifecycle itself visualizes how we manage constrained resources to optimize service value delivered for customers. In this blog we will explore many processes, but you will see me tend to tie these back to bigger picture questions that hopefully answer the “so what” question for you. If we follow these practices, so what? Stay tuned!
Don’t miss our upcoming free ITIL webinar on “Lessons Learned: Best Practices in Implementing ITIL Best Practices.” Deep Creek Founder and President Patrick von Schlag will review many of the most critical issues organizations face in implementing ITIL and how to overcome them.
Register for the Webinar
As many of you know, I’ve been intimately involved with ITIL practice for more than 10 years. I am launching this Lessons Learned, user-consortium-driven blog to document good practices based on the ITIL and other frameworks.
My hope is that this will be a great place to get facts and support for making ITIL work in your organization. Your moderator does not claim omniscience, and so I hope that each of you will share your own wisdom as well.
This is a great place to ask questions, share success stories and get the support and tools you need to make ITIL work in your organization.
The more I read, and the older I get, the more focused I become on results. At the end of the day, people care about outcomes, and are less picky about the path we take to achieve them.
Many of the success stories about ITIL are really success stories about the culture of CSI. You’ll see a common thread among them.
As I counsel my clients, resist the temptation for large-scale CMMI Level 1 – 3 moonshots and focus on establish real commitment to CSI.
Do you have established processes, including written policies, procedures, and process owners?
If not, what are the 2-3 most important things to get started?
Don’t try to implement all the processes at once. Focus on processes and services that will optimize the value and help you achieve quick wins…Incident, Change, and Request Fulfillment come to mind as great places to start.
BTW, RF is consistently underrated (maybe because it doesn’t make any vendors rich)…spending time making “routine service requests” really routine, for you and your users, is enormously beneficial.
Start small to win big!
I have been thinking about Carol’s and IT Skeptic’s comments about PM (and have read the thread he pointed me to, and an awful lot more) and I still think this comes down to a simpler notion. We have a yawning, enormous gap in most IT organizations between Design and Operations, in many cases cast in stone through outsourcing deals to different entities with no aligned targets or shared accountability. This creates the hot potato issue with which so many of us are familiar, and which really drives my interest in service transition, and particularly in placing Early Life Support (ELS) firmly in the hands of Release and Deployment Management. It is in fact the job of PM to manage the SUCCESSFUL transition of their project deliverables (which we’ll assume to be a new or changed service) into the live environment, and to support it until
1) The service is accepted by the customer AND
2) The service is meeting its designated service levels (this implies successful event mgmt, operational monitoring and reporting, and other operational readiness capabilities that really should be flushed out more as part of testing and validation activities).
Project Management (and Software Development Lifecycle Mgmt, but that’s another article) need to be able to coordinate service design and transition activities, and I would liken it to the approach ITIL takes with functions. PM necessarily coordinates across all the activities in service design and transition…based on the scope of their project. Process team leads perform activities across multiple projects in support of process goals and objectives (which should map to project goals around, for example, functional and non-functional (or warranty!) requirements).
The actual ITIL books don’t in fact describe exactly how to run projects (and rightfully leave this for the complementary guidance), but like a similar discussion currently on one of the LinkedIn threads about how ITIL leaves appropriate space for governance models (can anyone say CObIT), it really does so for PM as well, leaving flexibility needed to encompass large programs and small projects alike, while still providing a core set of building blocks needed to build a good service.
I’d like to hear from all of you…where do you see the big gaps, and what are your recommendations for addressing them? If you were writing ITIL 4.0, what would you add/remove/change to improve the efficacy of the guidance?
If you look at the descriptions of Critical Success Factors associated with ITSM adoptions, the first one on almost any list is Management Commitment.
Sounds good…until you try to figure out exactly what that means…
Management Commitment is more than just the willingness to train people, or buy software, or even have big Communications strategies about how important ITIL is…it’s the willingness to BE committed. The best way to actually measure this is willingness to sign up for roles like process and service owners. In order to ask for accountability from IT teams and to employ meaningful governance and oversight of Service Management, the senior managers (with enough authority to enforce commitments) must be willing to commit themselves as well. IT staff notice when senior teams make real commitments, and will align their efforts accordingly.
I recently watched a short promotional video from one of the major ITSM vendors (I’ll protect the guilty, but you can find it quickly if you look). It depicts a CIO describing the value of Business Service Management, and includes a roundtable with his senior IT staff. Ironically, the copy from the video is more typical than ever.
“I think we should tell the IT staff about the commitments I made on their behalf, so they know what I need them to do.”
Can’t get buy-in that way!
If you want IT organizations to commit to Service Management, IT leadership has to commit itself to processes like Service Level Management, which prevent “free lunch” behaviors and encourage the business to work cooperatively with its customers to evaluate evolving requirements against achievable targets. This involves listening to both clients and IT teams, and working to establish collaboration that focuses on the business value of the outcome, not only “do more with less.”
CIOs need to focus on business outcomes, and then work closely with their teams to support the optimal level of service to meet those needs, balancing cost/value. Taking specific service ownership of a key business service (perhaps, say, an online marketplace critical to sales growth) and taking specific accountability for service outcomes related to that service will raise the game a great deal, and drive the interest in metrics, continual service improvement, and ultimately business results. Once a CIO signs up for the most mission-critical one him- or herself, it’s a lot easier to get other senior managers to sign up for other services, and really establish cross-functional “service views” of the world.
Management Commitment is good talk, but, most of the time, talk is cheap. If you want to see results, demand real commitment, and real action. It will help you dramatically improve your results!