Service Specifications
codify the creation of value
Services are a means to codify the creation of value for the business. Typically a service is a component of a larger system, modeled as a series of steps, a boundary delimited fragment, where each step is a key waypoint on the road toward some definite objective.
Being a mental model, there is no single definite solution. The “right” model of a service is one that produces value for the business under the current circumstances of time and place.
There’s no set and forget in a dynamic problem domain anyway, so we don’t need to land on the ideal from the start. Instead of striving for the ideal solution, we shoot for resilience.
Codifying the Creation of Value
The model is not just a guide for implementation, but also a source of insight into the process for ongoing management. Managers don’t need to have the expertise of people on the line, but knowing when to leave things be, and when to intervene, that is key to management, if by management we mean improvement.
An important attribute of a process is that it generates systemic feedback. Opacity is an obstacle to management, and feedback is the antidote. The secret to effective service design has to do setting this up to produce the right information to allow people who do not have their hands on the work to be able to see where the sparks and friction are being generated.
The “Feedback” we talking about here is not the anecdotal reelections of team members offered up in the occasional retrospective, but signaling from the system. Retrospectives can be valuable, but they are no substitute for automated service controls. Before we get into where to our hang signal wires, we first need to develop the concept of the service specification.
Services and Specifications
The purpose of a service is to create a preferred state out of some aspiration of the present state.
Think of the service implied by a letter box; a bill payment or perhaps a thank you note aspires to be somewhere else within a given time. The mental model is an abstraction of what needs to happen: drop off, pick up, sorting, carrying and delivering.
The service provides structure and guidance on how things should happen, but a well designed service survives those instances where departure from the model is required in order to meet the function and purpose of the service.
How work flows when everything is as it was expected to be is hardly worth time it takes to talk about it. Getting value out of a service in the face of unanticipated circumstances is where the magic is.
Common and Special Cause Activities
The purpose of a service specification is to allow a team with relevant competencies to understand what is intended, and to reliably generate desired outcomes. It also serves as a field guide to identify what is common activity for the service, and to call out those activities which are generated from special causes.
The specification also serves as the medium for managers to convey changes to process or procedure within the service made in response to special cause activity, to prevent the recurrence, by accommodating and subsuming the variance into process, or by excluding it by policy.
Service Frame History as Evidence of Improvement
A service exists to create value, while a service specification exists to relate essential information about the process by which value is created. Things change: sources of work, quality criteria, delays, potentially degrading the value of a once-and-proper service. When the service adapts, and the service specification is updated accordingly, then the service’s frame of reference shifts accordingly.
Thus, the service specification is a record of the model of the service at a point in time. When model records are consistently framed, then they become artifacts to support retrospective. A series of frames from a service over time begin to tell the story of adaptation. The service frame history is evidence of improvement.
In order for there to be an outside view, there needs to be some delimiter; some line marking the perimeter.
Siarhei Plashchynski — "Post Box"
Ant Rozetsky — "Steel Mill"
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.