This post is all about Continuous Service, a name we made up to fit with the theme of the Continuous Everything disciplines made popular by DevOps. We use Continuous Service to mean the impact on IT Service Management of the concepts of human liberation, free flowing systems, and incremental agility – what Teal Unicorn call Human Systems Adaptability, or Open.
This article was originally Unit 44 of our Open IT Project. For those of you who came in late, this is our project to bring Teal Unicorn’s successful Open concepts to the Information Technology context. This is our symbol for Open:
At Teal Unicorn, we have used our version of Open Work and Open Management to make work better for many organisations, large and small: better results, better lives, better society. The numbers are spectacular. We wrote 5-star books. We got on TV. Clients make videos about us. People laugh and cry. We all have a good time. We’ve made lifelong friends. This stuff works.
The purpose of this project is to bring those ideas to make a difference within IT organisations. IT is the epicentre of much of Open: it has been the thought leader in better ways of working for decades now, leading the way with XP, Scrum, Agile, DevOps, Resilience Engineering, Remote Working, and more. Teal Unicorn has done so well with Open in business. Now we want to bring our formulation of the same ideas back to IT – it is the least we can do.
We call it Open IT: learn more about Open IT, and about Rob the author, here.
We send a fairly regular email that shares a new unit of Open IT knowledge, also posted in short form as a LinkedIn post. We encourage discussion and contribution via the LinkedIn post, to evolve the syllabus even as we work through it, with an aim of an open body of knowledge that all can benefit from.)
We presented it at the Pink Elephant Pink24 conference in Las Vegas in March, and we will turn it into another book, and a course for the Open Management Academy.
ITSM has always had aspirations to describing all the practices of IT, from strategy and design to governance and improvement, but we focus here – as most of the IT sector does – on ITSM’s role in response to situations: that is, the provision of services that are continuously available and adaptable.
In Unit 27, we already looked at Teal Unicorn’s model of Standard+Case for situational response, and in several units we have looked at the more sophisticated Cynefin model. We use their language here. The adaptive capability of S+C is important here to allow our standardised responses to continually adapt to changing circumstances: as novel situations appear, we solve them, and learn from that to create new standardised responses.
In Unit 25, we introduced Charles Betz’s IT4IT™ framework, now owned by the The Open Group.
In this unit we are focused on two of those value streams, Request to Fulfill (R2F) and Detect to Correct (D2C), but we also look at Strategy to Portfolio (S2P) and Require to Deploy (R2D) in the contexts of SLAs and customer relationships. We will consider how to make them more empowered, more free-flowing, and more adaptive.
We will draw on the general Open principles we have already covered, such as
- Be nice (Unit 3)
- Liberate work (Unit 7)
- Embrace failure (Unit 12)
- Make systems antifragile (Unit 13)
- Make work fluid (Unit 18)
…and Open IT principles such as
- Break down Build/Run divisions (Unit 20)
- …in particular, shift left (Unit 20)
- Let the people doing the work organise the work (Unit 21)
- IT is a living system, “Live IT” (Unit 22)
- Be a toolmaker (Unit 38)
- Get out of the way (Unit 39)
- Work naked (Unit 41)
I asked Om, our custom ChatGPT trained on Teal Unicorn’s writings (our “TealGPT”),
Invent and describe a practice called Continuous Service, a name we made up to fit with the theme of the Continuous Everything disciplines of DevOps, such as Continuous Integration, and Continuous Delivery. Continuous Service is about what IT Service Management looks like after applying our principles of Open IT and of Open Management. It will include Adaptive Service levels, and Real-time responsive adaptable request and correct.
Then I asked our ChatGPT Assistant version of Om the same question. It was much slower (because it is free) but eventually I got a similar, but more conceptual and general, response. They were overlapping and complementary. Here is an edited amalgam of both replies – I didn’t add or remove anything (except some waffle about implementing Continuous Service, which we will look at later, and a couple of words that were just consultant hyperbole like “seamlessly”), I just shuffled it around and merged duplication. I have to say it’s spookily good:
The practice of Continuous Service, as inspired by the ethos of Open IT and Open Management and resonating with the Continuous Everything disciplines of DevOps, is the transformation of IT Service Management (ITSM) into a fluid, highly adaptive discipline that reflects the continuous improvement and evolution ethos. It marries the robustness of established ITSM frameworks with the the agility, responsiveness, and collaborative principles of DevOps, extending them to the entire spectrum of service management to ensure that IT services are not only aligned with but also dynamically adapt to the changing needs of the business and its customers, fostering an environment that not only supports but thrives on change and responsiveness.
Here’s an in-depth look at what Continuous Service entails:
Principles of Continuous Service
Customer-Centricity: At the heart of Continuous Service is a deep focus on the customer experience. Services are designed and adapted to meet the evolving needs and expectations of customers, ensuring that the IT services provided are always relevant and valuable.
User Experience (UX) at the Forefront: This is about embracing a human-centric approach where IT services are tailored to fit human needs, prioritizing the UX in service design to ensure ease of use, satisfaction, and reduced friction; and integrating service design thinking principles to understand user journeys and pain points, leading to more empathetic and effective service experiences.
Collaborative and Open Culture: Continuous Service fosters a culture of openness, where information flows freely across teams and departments. This approach is crucial for breaking down silos and encouraging a collaborative effort towards service improvement and innovation.
Open Communication: Embrace Open Management principles, communication channels that are open, transparent, and bidirectional. Customers, users, and service providers collaborate closely to create a shared understanding of expectations, experiences, and improvements.
Adaptiveness Over Prescriptiveness: Unlike traditional ITSM models that rely on predefined service levels and rigid processes, Continuous Service advocates for adaptive service levels. This means service levels and agreements are not fixed but are continually adjusted based on real-time performance data, feedback, and changing business requirements.
Streamlined Workflows: Implementing Continuous Service requires efficient, automated workflows that facilitate a rapid response from issue identification to resolution. This includes using CI/CD pipelines to deploy updates and corrections to service environments.
Real-time Responsiveness: Emphasizing the need for IT services to be as real-time as possible, Continuous Service incorporates technologies and practices that allow for instant detection, diagnosis, and correction of service issues. This real-time responsiveness ensures minimal disruption to the user experience and business operations.
Organizational Resilience: Building resilience within services through practices such as chaos engineering and robust disaster recovery planning ensures services can bounce back from disruptions swiftly and even improve from the experience.
Continuous Improvement: Borrowing from the lean principle of Kaizen, Continuous Service is committed to ongoing improvement. By leveraging feedback loops, analytics, and performance metrics, services are continuously refined and optimized.
Practices of Continuous Service
Self-Service and Empowerment: Provide users with robust self-service options powered by user-friendly interfaces and intelligent backend processes to handle routine requests and troubleshooting, thereby offloading the service team for more complex tasks.
Adaptive Service Levels: Service levels are designed to be flexible and adaptive, using smart contracts or agreements that can be automatically adjusted based on performance metrics, customer satisfaction scores, and business impact analysis. SLAs are viewed as living documents, evolving in response to user needs, technological advancements, and business goals. Service levels dynamically adjust to accommodate changing priorities, ensuring that IT services remain in lockstep with organizational requirements.
Real-time Service Monitoring and Analytics: This enables IT teams to anticipate issues before they affect customers and to make data-driven decisions. Implementing advanced monitoring tools and analytics platforms to track service performance in real-time. Applying predictive analytics and monitoring tools to anticipate service issues, enabling proactive maintenance and support, thus minimizing downtime and disruption.
Real-Time Responsiveness: Promptly addressing service requests and incidents, Continuous Service leverages automation and AI to detect, diagnose, and resolve issues in real-time. This approach allows IT to shift from a ‘firefighting’ stance to one of proactive service nurturing. [Self- healing]
Collaborative Platforms: Utilize platforms that encourage cross-team collaboration and knowledge sharing. Integrating service desks with development and operations tools helps orchestrate a unified response to service demands and innovate on service delivery.
Automated Service Operations: Utilize automation to handle routine tasks and responses, freeing up human resources to focus on more complex and strategic issues. Automation also plays a key role in ensuring real-time responsiveness to service requests and incidents.
Feedback Loops and Continuous Feedback: This fosters a culture of continuous learning and refinement. Establish mechanisms for continuous feedback from users and stakeholders to inform service improvement, incorporating user feedback mechanisms directly into services and using this information for iterative service enhancements. This includes regular surveys, user forums, and real-time feedback tools embedded within services.
Cross-functional Service Teams: Create integrated teams that include members from development, operations, and support to ensure a holistic approach to service management. These teams work together on service design, delivery, and improvement, embodying the DevOps principle of breaking down silos.
Adaptive Governance and Metrics: Redefine governance to allow for faster, delegated decision-making; and shift metrics from output-based to outcome-based. This aligns with monitoring and measuring service effectiveness in real-time, leading to more informed and flexible approaches to managing services.
Special mechanisms
There are some special mechanisms that Teal Unicorn recommends you consider as part of creating Continuous Service:
Adaptive request catalogue
Your taxonomy of types of requests for service that users can make will not be static – this is a common mistake. The landscape of user needs is constantly changing, unpredictably – it’s a VUCA world.
Therefore it is essential that the request catalogue includes one or more categories’ of request that are of the form “Not in catalogue” or “Special request” so that users don’t “fall off the bottom of the page”.
This changes Service Desk behaviour from “Sorry, you can’t have that” to “Sure, we will look into it and let you know if it is possible”.
The category would then trigger a Case to investigate what the user needs, why you don’t currently provide it, and whether you can in fact fulfill the request. If you can, then fulfill the request; and then review the response to see whether you need to add a new Standard request category to the catalogue.
Realistic SLAs
It seems to be a common issue with Service Level Agreements (SLAs) – especially when outsourced into a contractual relationship – that the provider struggles to meet them and the customer is unhappy with performance. Trust breaks down, and attitudes become evasive and punitive respectively. We believe the primary cause is unrealistic SLAs – they’re unachievable. And the primary cause of that is the fallacy of a simple predictable system, including the prediction of service level performance. Read my book Response Taiji for the explanations. In brief, only Standard known familiar situations have a predictable response, whereas much of reality doesn’t. See Unit 27 on Standard+Case.
From the book:
Service levels should be measured according to customer-centric, outside-in metrics. We can use metrics such as “mean time to resolve” for Standard response and “mean time to change state” for Cases – see “Measurement”. But these metrics are internal “machinery” measurements. They are good for helping improve internally but they don’t measure the service: they don’t measure how happy customers are with the result, what the costs were, or how much value it delivered.
Outside-in, black-box measurements of service delivery – like satisfaction, cost, and value – will work well as service level targets in a Service Level Agreement (SLA), independent of whether we are applying a Standard or Case approach internally for each response.
The very fact that “difficult” tickets are being dealt with by expert case-workers, and are producing some visible action and outputs, should improve external satisfaction measures regardless of the “solve” rate. Users like to see good response – they will be more sympathetic if we haven’t yet achieved a good resolution.
…
The conventional Service Level Targets for responsiveness are based on time to resolve, by priority. Mean time to resolve a number of responses (e.g. per month) is a useful measure for trending and improvement but it is hardly a fair measure of how well a case-worker team is performing. They have limited control over how long they take to find a resolution. Case-workers who take on the toughest cases will seem to perform the worst.
Measuring the number of responses that exceed a time threshold (the “long tail” of the distribution curve) is even less fair. And holding people accountable for the time to resolve any one response is less fair still. The service provider cannot be held to a target resolution time when the sequence of states for each case is unpredictable. Nobody can control how long cases take to resolve: only reality decides that.
The negotiation of Service Level Agreements and their subsequent documentation must make clear that resolution-time targets only apply to Standard situations, and that other measures for responsiveness besides time will be used for Cases.
Customers might initially baulk at this. Explain that this is only reflecting reality, unlike including the non-Standard situations in resolution time data, which is unrealistic and distorts the picture. By measuring only Standard responses, the targets can be more tightly predicted and measured. We can commit to mean time to resolve standard responses (and we can commit to shorter times than in conventional all-inclusive SLTs where we have to build in slack, with more accuracy and confidence). For cases, we can only commit to levels of resources (especially people) applied. These metrics can be set and measured for differing levels of priority as we do now.
This might seem like a hard sell to customers, especially in outsourced contractual service provision. We must demonstrate to them that the conventional model is delusional, that it does not reflect reality. It drives the wrong behaviours. By moving to a model that better reflects reality, we can offer tighter prediction of standard response resolution (“100% within 3 hours”), while reporting cases more clearly. We offer them access to our case review process to reassure them that the Case categorisation is only used appropriately.
Layered relationships
The concept of a Product Owner as defined in Scrum is a hotly debated concept. The ideal is a single person who has the knowledge and authority to prioritise the backlog of work for the product, and who is available to the build team(s) multiple times a week. Many would argue this is a mythical animal (except in startups or organisations with a similar culture). Anyone who is that highly available is too junior to act, and anyone with the decision rights is too busy, and probably too removed from the work to know the answers. In either case, they have to go ask, and they end up acting as an intermediary bottleneck. Especially if they need control and omniscience, so that they prevent any contact between users and builders except through them.
Make sure that your relationship between service provider and customer is on multiple levels, with many channels of communication in different contexts.
In 2015, I released the Hono Engagement Model for Supplier-Customer relationships. Within a wider discussion of the touch points betwwen supplier and customer, one aspect is the roles that engage. They can be thought of at three different levels, with free communications within each level, but less so across levels. In this diagram, for Project Manager read Product Manager or Agile Product Owner. I will update Hono some day.
Antifragile review
When you have your postmortems and other forms of review of service failure or response failure, the focus is on how do you come back better and stronger, not who is responsible, which cause you choose to nominate as “root”, nor how to prevent this specific thing from happening again. You might find those out during our enquiry, but they aren’t the goals.
Remember this quote from Unit 5
If you have the capacity for response to the unexpected, then you don’t have to plan for it. The important thing to do then is to continuously increase the capacity to respond to whatever occurs in the future.
– Russell Ackoff
Don’t focus on prevention – that particular conjunction of circumstances may never happen again. Focus on improving resilience to the future unknown and unexpected events.