Desired states are the states of “goodness” to achieve and sustainably maintain, the continuous “end in mind” for things worth managing; not an output or deliverable or outcome, although these could contribute to (or detract from) a desired state.
There are two main approaches to managing things worth managing: focusing on desired states (“ends”), or “means”; e.g., seeking to “minimize the business disruption of change, and know what changed” is a desired state or “end”; you might focus on this, or on “means”—e.g., engineering processes, etc.; OSM describes means (best practices), but focuses on ends
Many things can be barriers or enablers to achieving and maintaining desired states, e.g., a process or tool can be a means to achieving and maintaining desired states, or it can be a blocker, or some combination thereof, depending on how it was designed, tools used, organizational culture, cadence, etc.
In OSM, desired states are written from the perspective of the service provider
At its inception, with Jan Carlzon’s “Moments of Truth”, service management was lightweight, agile, and focused on outcomes, or ends, and interactions among people (“moments of truth”).
And while traditional ITSM guidance seeks be outcome based, by focusing on, “What to do and why”, and giving an EXAMPLE of how, quite often in practice people have applied this guidance with a focus on a heavy-handed how, layering heavyweight, end to end processes on top of the work they do, without a call to action for individuals, teams, and the organization to know, and drive towards, service management outcomes.
OSM returns to the roots of service management, and puts its focus squarely on outcomes, on maintain desired states for things worth managing. So for example, “changes” are a “thing worth managing”, with an outcome of, “we minimize the business disruption of change, and can track what changed”; a process could enable—or disable—this desired state.
OSM focuses squarely on these outcomes, with a call to action for individuals and teams in organizations to know the things worth managing, and their desired states, and to work within their patch to drive to achieve and maintain desired states for things worth managing.
The idea is to make knowing and driving towards desired states, by working to remove and reduce barriers and add and amplify enablers to achieving and maintaining those desired states, “how we do things around here”.
Let’s talk about the different states something worth managing can be in.
There are typically four states tracked in modern monitoring systems:
Green means good, it’s in the desired state.
Yellow means potentially or actually degraded in some way, for example, disk space is filling up or circuit utilization is high, which may be affecting performance.
Red means bad, dead, down, or critical.
Grey means “unknown”—the thing worth managing is in an unknown state.
Think of it this way, if you join or start a service provider organization, and are responsible for managing it, you’ll want to know a couple of things.
First, what is “it”? What are the things worth managing that you are responsible for?
Once you know what “it” is, your next concern will be anything that’s red, or critical—how do we get that back online, to green?
Next, you’ll want to address anything that’s degraded or potentially degraded—the yellow stuff.
And lastly, anything that’s in an unknow state, you’ll want to get to a known state, and then work towards making whatever is red or yellow, green.