Will it ever be possible to innovate in outsourcing deployments?

Will it ever be possible to innovate in outsourcing deployments?

Will it ever be possible to innovate in outsourcing deployments?

I only ask, because you would think, in fact, that outsourcing deployments would be the perfect way in which to deliver small but effective areas of innovation.

Yet the very nature of outsourcing, both for organisations and service providers, is proving to be its own worst enemy.

The ITSM piece tends to be part of a much larger bid, often consolidating data centres, teams, resources and now typically with the sensitive matter of off-shoring work too.

Can it work?

Of course.

If an organisation is completely happy for all their services to be run in a shared instance with many other customers and a standard delivery model for your processes and resources, they are laughing.

There is no bespoke configuration to do, minimal to no requirements for knowledge transfer –merely hand over the details required, maybe have some training and perhaps some process focus and away they go, literally!

No debates about 99.999% up time of the service desk, or arguments about how to connect active directory servers to the hosted systems to abide with security requirements.

It just all works, and everyone is a winner.

And the flip side?

Complex projects involving multiple countries, heightened security implications in certain sectors, and dare I say it, almost a reluctance to “let go”.

There is nothing more sensitive (and in a small way a little soul destroying) knowing that you are working in an implementation where some, but not all of the people you need to interact with to do that transformation work will be losing their jobs.

Why the struggle?

Very simply, I think it comes to difference of expectations.

Often implementation teams are not involved in the bid process or if they are, it is often at the very end when it may well be far too late to point out potential issues.

Expectations are set by the sales and solution teams before the whole thing is thrown over the fence to be implemented by multiple groups, as part of a large project team.

Then the silo-mentality kicks in and suddenly you go from all-in-together to “Your bit of the solution needs to do this, why doesn’t it?”

Trying to innovate

How can you try and stop the inevitable from happening?

Because ITSM touches a lot of IT User groups, it is worth the ITSM Solution Architect having a broad view of everything that has been promised in the Service Management piece, but also make sure you cast an eye over Service/Help Desk and Asset Management schedules.

They may have their own teams, their own process writers and so on, but determining what YOUR tool (as it will often be called!) can actually do to achieve THEIR goals is vital.

For example:

ITSM Tool Expectation

Shared Platform Reality

Thou shalt enable retained staff and outsourced support staff to have access to, create, update, delete asset records in accordance to processes Well…. We’re writing the processes, so I agree with that but the way the platform is set up, you can’t have people updating assets if they are not working for us!
The service desk is all seeing, all knowing and shall have control of every ticket in the whole wide world, for ever That’s fine, but in our set up we have given them the LEAST amount of rights in the system of all the IT users, so really they will log and flog.

OK perhaps I have painted an extreme, but how would you begin to introduce more skill in Level 1 resolution if the way the service provided platforms are built lends itself to that kind of segregation.

All too often the best intentions to ensure that solutions are well documented, that the design process is followed with no short cuts, and that everything is re-usable for subsequent implementations.

In reality, time squeezes in, corners get cut, and rather than being able to standardise documentation for re-use, and that all important knowledge sharing aspect gets pushed to one side.

Who is willing to stand up and be counted?

Perhaps this is the hardest thing of all, when the pressure is on to get something implemented, and hopefully working better than what was there before.

I wrote some time ago about the Fantasy ITSM team and stressed the need for a strong, knowledgeable, but pragmatic project manager who could act as the glue between the silos.

But let me just throw someone else into the mix (rather than under the bus).

Sometimes the project team need a good business manager to bat for them, especially against the slow death crawl of scope creep.

The kiss of death for any troubling project is someone in the business line who is not prepared to say “NO”.

And it is sadly a rare thing to find someone who actually has the balls to look for ways to circumvent the more destructive forces one can find on projects and actually say: “NO, this is the wrong way.”

Why is no-one willing to do that?

The cold hard facts of the IT industry are that organisations are constantly striving for more, with far less.

The whole raison-d’être  for outsourcing is to benefit from the economies of scale.

And it takes brave people to then stand up and say – we need longer to do this better.

But the reasons WHY are because expectations have been set and there is largely a lack of control around HOW an almost “hybrid” solution can work.

Those people who are likely to be retained in the organisation will be looking for leverage to make sure things stay that way.

Knowledge is power, so why would they try and make things more efficient?

And all the while, the name of the game is to implement a solution, adhering to standards, but acquiescing to customer requirements, trying to add value but without rocking any other boats.

Who wins?

A sad by-product of restructuring within service providers themselves means that in-house skill are taken out of the equation, and often contractors brought in.

They have developed those niche skills that make it comparatively easier for them to be dropped in, for a shorter period of time, and at a lovely high rate.

While it is maybe more prevalent in the area of Project Management, I have come across ITIL Masters/Experts  who maybe spend more time telling you how much more they know than you, rather than looking to apply those skills to what an organisation needs.

For service providers to start adding that value always boasted about in bids, and drawing on the expertise they claim to have, they need to stop shedding skin, and looking to improve the skills within.

Regardless of whether the Service Desk and Platform/Application Support Staff are in Bangalore or Bognor – have they really got the skills for the job?  Are they engaged and committed to improving and developing a career?  Are they motivated?

Stop weakening your teams and look to play to their strengths.

Encourage, don’t stifle.

Innovate, don’t restrict.

It IS a challenge in this economic climate.  Is any service provider willing to take it on?

Image Credit

Rob England: What is a Technical Service Catalogue?

Amtrak 14th Street Coach Yard (Chicago, IL, US): A railway provides other functions: track gangs who maintain the trackwork, dispatchers who control the movement of trains, yard crews who shuffle and shift rolling stock. It is clear that these are not services provided by the railway to its customers. They are internal functions.

We are looking at railways (railroads) as a useful case study for talking about service management.

Last time we looked at the service catalogue of a railway.

We concluded that first and foremost, a service catalogue describes what a service provider does.

How often and what flavour are only options to a service or package of services.

ITIL refers to a technical service catalogue (TSC).  Where does that fit?

One thing everyone agrees on is the audience: a TSC is for the internal staff of the service provider, to provide them with supplementary information about services – technical information – that the customers and users don’t need to see.

But the scope of a TSC – what services go into it – is a source of much debate, which can be crudely categorised into two camps:

  1. TSC is a technical view of the service catalogue
  2. TSC is a catalogue of technical services

Those are two very different things.  Let me declare my position up front: I believe the answer is #1, a technical view of the service catalogue.  ITIL V3 was ambiguous but ITIL 2011 comes down clearly with #2.  This is unfortunate, as we’ll discuss.

Go back to what a service catalogue is: a description of what a service provider provides to their customers (and hence their users).  A good way of thinking of a service in this context is as something that crosses a boundary: we treat the service provider as a black box, and the services are what come out of that box.  A service catalogue is associated with a certain entity, and it describes the services that cross the boundary of that entity.  If they don’t come out, they aren’t a service, for that entity, depending on where we chose to draw the boundary.  To define what the services are, first define the boundary of the service provider.

Think of our railroad example from last time.  A railway’s service catalogue is some or all of:

  • Container transport
  • Bulk goods transport (especially coal, stone and ore)
  • Less-than-container-load (parcel) transport
  • Priority and perishables transport (customers don’t send fruit as regular containers or parcels: they need it cold and fast)
  • Door-to-door (trucks for the “last mile”)
  • Livestock transport
  • Passenger transport
  • etc etc

A railway provides other functions:

  • track gangs who maintain the trackwork
  • dispatchers who control the movement of trains
  • yard crews who shuffle and shift rolling stock within the yard limits
  • hostlers who prepare and park locomotives

It is clear that these are not services provided by the railway to its customers.  They are internal functions.

A railway provides track, rolling stock, tickets and stations, but these aren’t services either: they are equipment to support and enable the services.

A passenger railway provides

  • on train security
  • ticket collectors
  • porters
  • dining car attendants
  • passenger car cleaners

and a freight railway provides

  • container loading
  • consignment tracking
  • customs clearance
  • waybill paperwork

These all touch the user or customer, so are these services?  Not unless the customer pays for them separately as services or options to services.  In general these systems are just components of a service which the customer or user happens to be able to see.

So why then do some IT people insist that a technical service catalogue should list such “services” as networks, security or AV? (ITIL calls these “supporting services”). If the networks team wants to have their own catalogue of the services that only they provide, then they are drawing their own boundary around just their function, in which case it is not part of a technical service catalogue for all of IT, it is a service catalogue specifically for the networking team.  It is not a service provided by IT to the customer.

A technical service catalogue should be a technical view of the same set of services as any other type of service catalogue for the particular entity in question.   The difference is that it provides an internal technical view of the services, with additional information useful to technical staff when providing or supporting the services.  It includes information a customer or user doesn’t want or need to see.

A technical service catalogue for a railway would indeed refer to tickets and porters and stations and yard procedures and waybills, but only as components of the services provided – referred to within the information about those services – not listed as services in their own right.  I’m all for “supporting services” to be described within a service catalogue, but not as services.  They are part of the information about a service.  Supporting services aren’t services: they are component systems – CIs – underpinning the real services we deliver to our customers.

By adopting the concept of “supporting services” and allowing these to be called services within the catalogue of a wider entity that does not provide these services to a customer, ITIL 2011 contradicts its own description of “service”.

Service Design says:

Supporting services IT services that support or ‘underpin’ the customer-facing services.  These are typically invisible to the customer… such as infrastructure services, network services, application services or technical services.

Yet the in the prior section, such IT systems are clearly not a service:

IT staff often confuse a ‘service’ as perceived by the customer with an IT system.  In many cases one ‘service’ can be made up of other ‘services’ and so on, which are themselves made up of one or more IT systems within an overall infrastructure…  A good starting point is often to ask customers what IT services they use and how those services map onto and support their business processes

And of course it contradicts the generic ITIL definition of a service as something that delivers value to customers.  This is important because the concept of “supporting service” allows internal units within the service provider to limit their care and concern to focus on the “supporting service” they provide and allows them to become detached from the actual services provided to the customer.  There is no SLA applicable to “their” service, and it quite likely isn’t considered by service level reporting.

A railway ticket inspector shouldn’t ignore security because that is not part of his ‘service”.  A yard hostler should make sure he doesn’t obstruct the expeditious handling of rolling stick when moving locomotives, even though rolling stock isn’t part of “his” service.  The idea of “supporting service” allows and encourages an “I’m alright Jack” mentality which goes against everything we are trying to achieve with service management.

It is possible that Lou Hunnebeck and the team writing Service Design agree with me: that they intend there to be a distinction between supporting services and IT systems.  If so, that distinction is opaque.   And they should have thought more about how the “internal” services model would be misused- the problem I’m describing was common before ITIL 2011.

There is the case where the supporting services really are services: provided to us by a third party in support of our services to our customer.  For example, a railway often pays another company:

  • to clean the carriages out
  • to provide food for the bistro car;
  • to repair rolling stock
  • to provide the trucking over “the last mile”

Where we bundle these activities as part of our service to a customer and treat them as an Underpinning Contract, then from the perspective of the services in our service catalogue – i.e from the perspective of our customer – these are not services: they are CIs that should not be catalogued here.  If this – and only this scenario – is what Service Design means by a “supporting service”, I can’t see that called out explicitly anywhere.

Technical service catalogue should be a technical view of the services that we provide to our customers.  I wish ITIL had stuck to that clear simple model of a catalogue and kept IT focused on what we are there for.

Photo Credit