Someone recently said to me that the need to manage the customer’s experience of a service once it’s been delivered often seems to get forgotten. And I was reminded of this illustration I put in a presentation some years ago.
Service management is usually an afterthought
Yes – that’s vintage 1990s PowerPoint clipart.
You wouldn’t sell or hire out a car without a steering wheel and dashboard instruments. As a customer you wouldn’t expect to hear “But it does 0 – 60 in 7 seconds with a top speed of 115. And it complies with government emissions standards (no … not just under lab conditions). The documented requirements didn’t say anything about the end-user being able to control the direction or receive reports on the actual speed.”
So why is this so common with software and with technology services?
And why is this still an issue after 20 or 30 years?
The simple answer
I’d like to keep this post brief and practical, and give you the simple answer to this problem. But there doesn’t seem to be one. (At least it means continued work for us ITSM specialists! Though it seems all the evangelism and awareness-raising has not yet delivered any fundamental change in the ICT industry.) Something about it is fundamentally difficult.
Let’s consider a few things.
Best practice?
It’s not because of a lack of examples and best practice – ITIL has provided that for decades. It’s true that organisations or projects sometimes find parts of ITIL confusing and difficult to apply in real situations—sometimes, difficult to know which bits not to apply. But we need to understand why that is.
Everything is custom-built
Cars are commodities, and manufacturers compete on service. With software and communications services (beyond raw processing power, storage and bandwidth) things aren’t nearly so commoditised. Businesses want them differentiated to give their own processes and services a competitive edge.
Most cars aren’t designed from scratch to the customer’s requirements. Insofar as this happens, it’s a selection from a menu of options and packages. With complex software and communications systems, the requirements and ideal design are rarely clear in the early stages, and even when they get reasonably clear they can be complicated to build, with tradeoffs between competing requirements (not least cost). Functional requirements that can designed and built directly are easier to focus on earlier – and the non-functional requirements can be frustratingly vague in the early stages. “The system must be easy to use.” What does that mean when you’re still working on the data model?
“Support” is assumed to be simple
“Supporting the solution” is too often regarded as something simple; something the service desk automatically do (without any training or preparation!); somebody else’s job, even as far as outsourcing; or something well-defined and already solved (just add 750g of ITIL and stir well)?
It is of course none of these.
The complicated answer
I think the most common reason—or set of reasons—is that the beginning of development projects is too soon (you need some conceptual design before you can begin to specify the non-functional characteristics and support needs); but later on, the teams involved tend to be those specialised in design, development and test, not support; and when service management does get considered—much later—it’s very often assumed (or hoped) that “implementing a tool” is enough, or “throwing it over the wall” to a service desk or support company.
There is too rarely any integrated analysis and management of support requirements (and I mean integrated – this cannot be done independently of, or after, the solution development).
So what we need is requirements managements for service support, built iteratively through the solution development cycles or sprints—nothing more than principles before the high-level design is done (and you can’t implement principles), with
- successively more detail as the design and development is elaborated,
- feedback into the coding and systems configuration (and partner / supplier negotiation), to specify functional requirements for things like diagnostic logging, performance instrumentation, and appropriate support access to user data and system status,
- management tool configuration including asset and alarm information,
- and support training, testing and acceptance in parallel to user training, testing and acceptance.
More posts on this subject may be called for…
Deconstructing ITSM 
Leave a comment