Who, Why, How and What
the four dimensions of strategy
A service encodes a strategy for creating value for the business. We’re using the term strategy in the sense of the definition “A careful plan or method…”
In Demystifying Strategy, Michael Watkins defines strategy as how people throughout the organization should make decisions and allocate resources in order accomplish key objectives.
The questions who, why, how and what form the four dimensions of strategy. Analysis of these four questions will subsume the four components of a service, discussed above, and put them in the context of the function and purpose of the service.
Who, Why, How and What
It is common in process engineering to use the term “why” to talk about the desired outcomes, but here we use the word “what” — that is to say: what are we trying to get done. In the language of services, why refers to the motivation and incentives of the participates in the service — why they participate.
1.) The Story of Who
To tell the story of “who” in Service Discovery, we need to move beyond the user, and get to who is making the promise.
Software stories are typically told from the perspective of the user, which if fine, as far as it goes. Sometimes “Customer” is used to mean the same thing as “User”, but note the distinction here. It is possible for the user and customer to be the same for a given service, but we still take the trouble to tell the stories that correspond to both perspectives
Customer: Those who pays for the service and benefits from the outcomes.
User: Those who have the privilege to make use of service to build mobile apps.
Agent: Those who facilitate and control the use of the service.
Provider: Things or entities with surpluses, or why there will be a surplus of affordances
Value Stream Mapping tells the story of Customer and User but is blind to Agent and Provider. That's because a VSM has different, more limited objectives than a Service Specifications. VSM is the yellow brick road, where Service Specifications include the backstories of Dorothy and the Tin man.
2.) The Story of Why
When we talk about the story of why, we’re not talking about KPIs, we’re talking about why users are willing engage in the process.
Business Process Modeling uses the term “why” for the outcomes and objectives, as in “why we are doing this”. In the language of services, outcomes and objectives are “what” outcomes are sought. “Why” refers to the motivation of the various parties identified above.
Artifact: Things with shortcomings which is why there is demand for performances.
Capability: Things with skills, or why there will be supply for performances.
Resource: Things with surpluses, or why there will be supply for affordances.
Event: Things with shortfalls explaining why there will be demand for affordances.
The use of “why” to indicate the motivation of Users, Customers, Agents and Providers is an essential part of our syntax needed to construct promoises, which form the basis of contracts, which are at the core of what Service Specifications are all about.
3.) The Story of How
The Story of How cross-references the various stories of Why and Who. Now we’re starting to get to texture.
Value Steam Mapping can be a bit of a muddle when it comes to the question of “how”. Some steps clearly are about how things should happen, others represent states. This kind of ambiguity is eliminated by making Agent and Provider full partners in the process model.
Task: How the artifact needs to be acted on, comprising actual instances of demand:
Activity: How the capability performs the task: actual instances of supply
Availability: How the resource is made available for access: actual instances of supply.
Access: How the event needs to have access to the resource: actual instances of demand
A casual observer tends to conflate the task with the activity. A task is afforded but is only potential until activity converts it to an outcome, a transformation from an existing state to some preferred state.
1.) The Story of What
The Story of What is about outcomes, builds on the foundation of KPI, providing the language to look at outcomes from multiple perspectives.
Services model the process by which a present reality is transformed into a preferred state.
Enhancement: What the outcome of a performance is: product of activity or task:
Enrichment: What the outcome of an affordance is: product of availability and access.
Provision: What users and agents go through (experience) to set up availability and access
Commission: What users and agents go through (experience) to set up activity and task
Telling the story of “what” from four distinct perspectives gives Service Specifications the kind of rigor not found in casual process models.
We now have a 16 word vocabulary to express the who, why, how and what of each of the components found in every service. We’ll explain and extend this vocabulary in the next section, The Language of Services.
Luca Bravo — "Pair of boats on water in Lago di Braies"
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.