This is our manifesto, what we call the “seven ways”, written in the style of the Agile manifesto https://agilemanifesto.org/
We are uncovering better ways of applying service management by doing it and helping others do it. Through this work we have come to value:
- Enacting and enabling outcomes over engineering and enforcing end-to-end process activities
- Enlightening and empowering people over engineering and enforcing end-to-end process activities
- Lowering barriers and increasing enablers over engineering and enforcing end-to-end process activities
- Improving moments of truth over engineering and enforcing end-to-end process activities
- Relentlessly rooting out variation and dependencies over getting process out of the way
- Lowering transaction costs and making things ready-to-hand over working mostly directly on culture
- Individuals, teams and organizations reflecting and acting over mostly org-level effort
That is, while there is value in the items on the right, we value the items on the left more.
You can see that the first four statements value other approaches over engineering and enforcing end-to-end process activities. In a lot of organizations, despite the intent of traditional ITSM to be outcome-focused, the focus is mostly or exclusively on activities—the “why” or the “end-in-mind” or outcome gets lost in the shuffle. In the end, there is no “ask” of individuals and teams to do anything except comply with processes that have been engineered end-to-end at the organizational level. If you conception of processes is that they are what people do, directed towards and outcome, your approach changes. You focus on skills, knowledge, mindset change, behavior change, and so on, over process documentation activities.
With this approach to applying service management concepts, you value the traditional ITSM processes primarily for their outcomes, over the examples traditional guidance provides of possible process activities; your focus is on the “why” and getting everyone to chase after it; for example, the key outcomes for change management is for everyone to, “minimize the business disruption of change, and be able to track, “what changed?””; you focus on everyone getting that and getting on making it “how we do things around here”, over process documentation activities.
Value statement 4 focuses on Moments of Truth, which takes us back to the agile roots of service management (Jan Carlzon), prior to the “Reengineering The Corporation” end-to-end process-heavy era. While many implementation approaches focus on end-to-end processes, the “macro-level” stuff, what often gets overlooked is working on “moments of truth”—key interactions between people and systems—the “micro-level” stuff, like how we run a post implementation review. Focus your application and improvement efforts on key moments of truth.
Value statement 5 focuses on variations and dependencies. A lot of people look to “get process out of the way” to get faster time-to-value. While getting faster time-to-value is the ultimate goal, simply removing checks and balances and process gates isn’t the real answer. Think about it—why do we have to meet about a change, or a release, or anything? There is one simple answer: because there are dependencies and variation that, if not sorted out, will result in us taking actions that shoot ourselves and others in the proverbial foot. So the right approach—the things that vastly reduces the amount of overhead required for service management, the #1 contributor to making it lightweight, is to aggressively root out unnecessary complexity, variation, and dependencies. If you close the book on this course right now and do nothing else with this material, taking this advice back on the job should pay huge dividends. More on that—and all of this later. On with the manifesto.
With value statement 6, we come to what could be perceived as a bit of a heresy. Should we solve problems in organizations by address culture, first and foremost? Or should we focus on the medium, the context, affects and often “constructs” culture, as well as the opposite—culture affecting choice of tools, and work practices, etc. There’s a whole area of study around this called Sociotechnical systems. But won’t get into the details of that here. What we’re suggesting is that working relentlessly to lower transaction costs and making things more ready-to-hand (that is, reduce the time and effort and number of clicks it takes to do work) is a better approach the working directly on culture.
For example, for a company still shipping software on DVDs, the cost of pulling back a mistake is huge. But for a company that’s shifted to the cloud and doing blue-green deployment, they can try something out and yank it back at little or no cost. And if you have to dig around to get to stuff, e.g., info on the status of an incident is all over the place and you consolidate it on a status page, the info is more ready-to-hand and this removes a blocker. This is lowering transaction costs and making things more ready to hand—while it doesn’t replace working “directly” on culture, I have come to value it over working directly on culture only or mostly, as it sure goes a long way towards creating the right results and constructing the right culture in the end.
You may recall the maxim, “a fool with a tool is still a fool” from traditional ITSM. While that may be true in some cases, in many cases a tool provides breakthrough performance, where working directly on culture does not. Another example may help illustrate: if we work together in a kitchen, we could come up with all sorts of exhortations to get you to chop vegetables faster, but simply giving you a food processor is a better bet.
What we’re not suggesting here is to always start with the tool, without culture in mind, or to hoard tools (like someone with a kitchen full of tools who can’t find the ones they need because they’re behind a pile of tools they don’t need), but that working mostly directly on culture may not be the better approach; a central idea here is tools influence culture and v.v. (from Sociotechnical systems).
Value 7, individuals, teams and organizations reflecting and acting, highlights the battle royale between “the sandwich” and “the slice of bread”. Who wouldn’t prefer a whole sandwich over a mere slice of bread? Seriously, though, this is important—many attempts to apply service management concepts are top-down, organizational-level efforts only or mostly—there is no ask of individuals or teams to really think, learn, apply, and improve with service management. That’s why I advocate the “sandwich” approach.
Ever try to eat a sandwich without the bottom slice of bread? It kind of falls apart. Ever try to eat a sandwich with no filling in the middle? Not very tasty. Having an ask of individuals—to grasp the outcomes of service management and to drive towards them, within their circle of influence, for their patch—is like that bottom slice of bread for a service management implementation—without it, the whole thing falls apart, and with it, the whole sandwich stays together. Similarly, having an ask of teams to do the same is the tasty middle of the sandwich—without it, organizational-level only or mostly efforts fall flat, not very tasty.