Like the Standard Model in Physics, we've been hearing the mantra of People, Process, Technology (PPT) for a years. You must approach the problem in that order, PPT.
The basic mantra makes sense--nothing gets done without people. Yet too often it's used as a crutch to dismiss technology considerations from the ITSM project. But let's remember that Mantra, according to Wikipedia, "... are used in Eastern spiritual traditions to divert the mind from basic instinctual desires or material inclinations." In other words, away from buying things.
This is a mistake for the service catalog. Good for the soul, bad for IT projects. I'll tell you why in bit.
Trying to sequence PPT is a bit like looking for the Higgs boson particle of process improvement by building ITSM equivalent of the Large Hadron Collider (which would be cool, but we can't afford it).
At some point in your project there's a 1-2-3 order - people, process, technology -- like the big bang had an order of 1,2, and 3. But within a few nano-seconds, all the elements of the universe are there to be dealt with.
The vast majority of the time we already have people, process and technology going all at once; we don't have a clean slate.
So I tend to think of the PPT model more like this picture below.
The cogs are the three moving parts (PPT). At different moments we hook our engine (resources, energy, attention) to power different parts of the initiative.
No question that there are times where we' get a better payoff from investing in the people part, others in the process part and other times you have to have technology.
But technology should always be considered early. Because technology can be a transformative catalyst to process, or it can be an enabler to process. Technology can make the process more efficient, or it can actually make it exist. Like the jet for an airline or the telephone system for a call center. Service catalog software today is the latter kind; it can make the catalog exist.
Here's an example of enabling: Try to have an airline without jets. Try to have a call center without phones. Try to have event management without event software. Try to process credit cards without networks. Try to charge for a service without a bill. Try to have a restaurant without a menu.
Or a restaurant where the
customers make up the menu, the kitchen staff makes up the recipes, and
the fish-monger is the sole supplier (pun intended). We'd have anarchy
for lunch and chaos for dinner. And sole fish would be the corporate
standard for breakfast, lunch and dinner.
Technology changes how we do process; it can even eliminate certain processes altogether. So spending a lot of time on a process that could be eliminated. And technology also changes the skills and roles needed (therefore the people).
When we look at IT service management processes like Incident, Problem, Change we know we'll need technology eventually but this stuff is a commodity: well understood, been around for a couple of decades -- it's getting long in tooth, big gut and bald. Because we are so familiar with this type of technology, we implicitly account for the impact this technology will have in our process and leave the decision for after people and process. Which makes total sense.
This is not true for service catalog technology because it's a core enabler to the demand, catalog, portfolio, finance, request, access, service level, relationship and self-service functions.
These process are transformational to IT -- you implicitly or explicitly have decided to operate differently. So you need to understand how you'd operate day to day. The easiest way is to see a technology based simulation of your new operating model. Hence technology.
But unlike help desk software, service catalog technology is very new so it's hard to know how to evaluate it. Why? Because it's still so new.
Until recently there wasn't a framework or list of 120 things a service catalog product should do; (there are now a few: Our book, Gartner, Pink, and EMA). Most of practitioners don't know what the catalog process should be, what the roles are, what the governance models should look like or the impact of technology in our project.
So we (sensibly) fall back to PPT. But sensibly isn't working for most catalog projects. And you won't figure it out without considering technology in parallel.
This is why I say that documentation projects by themselves don't achieve their objectives.
Most of the time they are like documenting the ingredients and utensils in the restaurant kitchen hoping that somehow it will attract customers, tell us what to cook, and make us profitable. Or get us in compliance with the health code. But that kitchen is not going to clean itself without people and some cleaning tools.
The ultimate objective of a service catalog is to enable a a new operating model for IT. The documentation is a step in the project, but you need to know how that information is going to be used operationally to specify:
- what elements and attributes need to be documented,
- from whom (what people roles)
- for what purpose (what actions will taken)
If the catalog is just static, if there is no flow of information, if there's no process supported, then document might as well not exist. Service Catalog technology is enabling technology, not just "make my paper process efficient."
Here's an example of enabling: working with a customer, we are defining a number of metrics. A key issue they face is how will they collect the metrics, crunch them and build their key performance indicators? Some seem pretty hard to get. Answer: their service catalog technology already provides them; there's no tedious overhead. They were not aware they had those metrics. That's enabling.
Here's an example of disabling: a company is struggling with the level and granularity of their service definitions. Too high level and it's can't drive operations, too low level and it confuses the customer. There's also a a lot of repetition, but it's hard to keep in sync. So try to implement the three views of the service catalog becomes impossible. The result? Something that is neither fish, nor fowl. A sla check that IT can't cash.
As the founder of a software company, it's natural that I'd think technology is important. It'd be weird to dedicate my life to a job if I didn't think was important.
Yet I do agree that it's people, process and technology. It's just that I believe that sequence is seconds or days, not months nor years. And that it's circular, your technology will drive what kind of people you need, and the processes you'll use.
What do you think?
Comments