Tipu: continual service improvement as a real approach to ITSM

At the recent itSMF Australian National Conference (a.k.a. LEADit, a top conference) I delivered a keynote on Tipu, my "agile ITSM" approach to continual service improvement, which garnered some positive feedback. The same day I was interviewed by the itSMF's journalist, and we spoke about CSI as an approach from the start; processes are the wrong granularity; how we must align to the business need; ETF and pragmatism; and most of all the need for change at a human pace. Here is that interview (7 minutes):

and a presentation on the same topic:


Well spoken as always

Well done Rob, I like your style.

Who doesn't need and start with improvement?

Hi Rob

Welcome aboard. For a while now I've been trying to explain, evidently badly, that implementing anything is a sign you might be thinking about service management the wrong way, and that every IT organization should operate a continuous improvement (note I have dropped the word service here) program (CIP).

Why - well it helps place the focus back on the customer and avoid the issues and common pitfalls associated with a foot race to re-engineer back office processes to look like one book's storyline, or anothers. And - who can say they don't need some means of continuously improving how they do things? So, for a few years now I have been helping rescue ITSM/ITIL projects by morphing them into a CIP approach.

As for granularity - can I also persuade you to focus on each individual service request and the customer expectation, outcome and experience it embodies, rather than smaller bits of processes. After all - service is all about the customer and interaction and in today's service society much of what starts off a service encounter and influences the entire cycle - is the customer....

As I hope I've said before Rob - good luck with Tipu, just don't get tempted into a Tipu-Lite! Believe! So once more with vigor - 2012 should be the year of continuous improvement programs focused on how IT responds to individual service requests (so much easier) and hopefully the repositioning of ITSM projects as something best left undone...

fulfillment of requests as a unit of work

I agree with all but one bit: There is so much more to IT Management than the fulfillment of requests. That is one subset of service delivery. What has fulfillment of requests to do with portfolio, funding, continiuty, security, release, CRM, ....? I suspect you are going to answer that a request spans all of those because it relies on them, especially if you include the processing of RFCs. In which case we are back to enormous units of work again. I agree that processing of requests provides a good perspective for identifying efficiency and effectiveness problems and hence for prioritising work - if and only if the business requirement is to improve request fulfillment. But it's not a useful granularity for units of work.

The humble service request is (almost) everything


In my world (USMBOK) the humble service request is the cause of all service provider work - all. ITIL's request fulfillment is at best - limited and naive. Remember - the USMBOK has the service transaction engine concept, ITIL does not. So we are talking different things when comparing or discussing ITIL's 'request fulfillment' and the USMBOK's service request management 'systems'.

99.999% of service requests are handled just fine by systems without human intervention (withdraw cash from ATM).
Continuous improvement in the service business realm (listen to me carefully now you ITers...) is all about being able to map, inspect and improve all, or a defined subset of the service encounters wrapping a service request. The business even uses the term 'service request' more and more nowadays. For you ITILers out there - epiphany alert - an incident is a type of service request.

Regarding your question about portfolio and the gang, nope. Suggesting a request span all of them is what I would call 'inside-out' thinking. Customer interaction with a product. service, or provider organization drives internal work effort. Portfolios and all the ITSM gubbings are the background, back office infrastructure that MAY be required. Rather like all the stuff that hums behind the counter and back at HQ to run an airline.

You think and act outside-in, from the customer need, desired successful outcome, service encounter and the request they likely unknowingly trigger. What activity is the customer performing and why - what outcome and what experience are they expecting. Put money in a soda machine - what do you expect to happen?

Service management is about designing the interactions so customers and their requests for service are responded to appropriately, and focusing improvements there first - because the customer feels these. Improving back office aspects without knowing how these affect the customer experience is both a waste of time and likely viewed as lacking value - by the customer....

IT is not hollow

Nope. IT is not hollow. Outside-in does not mean the inside is non-existent. Again: considering requests does indeed set context, but improving all parts of a request and its supporting infrastructure is way too big a unit of work. You must deconstruct the internals and consider improvement of every piece, according to the goals.

Syndicate content