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

Supplier Relationship Management – An emerging capability in the ITSM toolbox

"Development opportunities can be completely missed because the two organizations have not properly explored how to grow together, indeed contractor enthusiasm may be misinterpreted as land grabbing."

Paul Mallory is VP Europe and Africa for the IACCM, with responsibility for member services, training and certification and research.

The recent article on the role that SLAs play in the relationship style between two organizations made me think. For some relationships, SLAs replace or even reduce the effort that an organization puts into managing the strategic development of opportunities between client and contractor.

If the contractor is seen to be achieving their SLAs then they are considered to be doing their job effectively.  If they are missing their SLAs then there is a large focus on understanding why they have failed and potentially much discussion around any mitigating circumstances the contractor puts forward.

SLAs definitely have their place as they allow the client and contractor to look at service development and continuous performance improvement through stretch targets based on the existing contractual agreement.

However, supplier relationship management (SRM) comes into effect when you want to truly transform the way in which you work with your suppliers.

So first up, how should we define SRM?

In our recently launched SRM training course, the IACCM defines SRM as:

“The function that seeks to develop successful, collaborative relationships with key suppliers for the delivery of significant tangible business benefits for both parties”.

Why is SRM important?

The average tenure of a CIO is about 4.5 years.  Most IT Service Management contracts (be it for any of the ITIL disciplines, applications or data centre outsourcing) are for between 5 and 10 years, with public sector contracts often reaching and even exceeding the upper end of that range.  Therefore it follows that those people who were in place at the outset, and developing the IT strategy, may not be there further down the contract lifecycle, yet the contractual relationship continues to exist and needs the right management practices to bring the expected benefit to both sides.

Furthermore, with the cost of IT services re-procurement often being around 30% of the annual contract cost (once transition, exit and procurement time has been taken into consideration), implementing a successful contract extension becomes a financial KPI.

Keld Jensen, Chairman of the Centre for Negotiation at the Copenhagen Business School, has identified that 42% of contract value is left on the table and not even addressed or even recognised by either party during the initial negotiations.  This means that in ITSM contracts there is great opportunity for both parties to access that 42% once the negotiation and procurement teams have left the room.  The supplier relationship manager is part of the mechanism to enable that.

What does a Supplier Relationship Manager do?

First, we must remember that IT Service contracts can incorporate a number of inter-related disciplines (especially if we take the ITIL view).  Each of those teams is going to be heavily focussed on their immediate needs and how their portion of the supply chain is delivering to them.  They will also be interested in where there are process hand-offs, but my experience has shown me that often there is a poor, singular joined up view across IT disciplines.

If this is the case, a weak supplier will maximise this to their advantage, especially where they are delivering many facets of ITSM.  They will minimise exposure to their service shortcomings and keep their network of relationships separate and distinct.  A good supplier though may just accept the frustration of dealing with a discordant IT department and focus its development opportunities on its other customers, the “customers of choice”.

In both scenarios the client does not access the 42% of value that Keld Jensen discusses, it may be from fire-fighting performance issues or an inability to properly interact with the supplier through a lack of focal point.  This is where the supplier relationship manager steps in, because they are there to:

  • Manage all aspects of the inter-company relationship, especially where the supplier’s remit goes beyond ITSM
  • They look to build trust through open communications, both internally and with the supply chain
  • They understand the full capability of the supply chain and will seek to develop successful, collaborative relationships with key, strategic suppliers
  • They share company strategy, mission and values with the suppliers
  • They ensure that the relationship follows appropriate governance requirements
  • They have ready access to, and influence from the top levels of management
Paul Mallory, IACCM
Paul Mallory, IACCM

By understanding not only the strategy of IT but also of the company as a whole, they are in a position to create a collaborative relationship with the strategic suppliers where mutual win-win opportunities are developed and encouraged.  Innovation can be targeted at the right teams, process efficiency can be realised and cross fertilisation of ideas can occur between teams who may not have realised they were working towards similar outcomes.

The supplier is turned into a strategic asset that can positively affect your organisations success, rather than an entity whose invoices are paid each month if service targets were met.

Through the conversations that the IACCM is having with its membership, we see that SRM is an emerging discipline which is becoming more important in these times of austerity.  There needs to be value for every pound, dollar or euro an organisation spends.  Effective SRM is there to ensure that value is realised.

Paul Mallory is VP Europe and Africa for the IACCM, with responsibility for member services, training and certification and research.

Do SLAs hinder collaborative relationships with our supply chain?

Pretty much all outsourcing contracts in the IT Service Management world rely on, or at the very least, utilise the Service Level Agreement (SLA).

Certainly they are important as they are the physical representation of performance of the contracting party and used as the measure by which trends in supplier performance is understood.

But is there too much reliance on SLAs as a measure of performance and are they often inserted by the eager contract or procurement manager to mitigate risk or provide a means for the insertion of penalty / reward clauses because “that is what is expected in a contract”?

In my personal experience SLAs are often poorly defined or their alignment to the realities of IT service delivery misunderstood.  Because of that, there has been many mitigating circumstances offered as to why an SLA has been failed by the contracted organisation, followed with significant discussion as to whether the mitigation can be accepted.  This has a tendency to suck up both time, effort and therefore money, from both organisations into managing the performance measures, drafting contract change notices and often not looking at the root cause of why SLAs are being missed or in one case I have dealt with perpetually exceeded (plainly in that case the SLAs were too generous or measuring the wrong outcomes).

Problem 1

The vendor will look to win the opportunity and subsequently concern themselves with making the delivery side work (especially when the bid team is not going to be involved in delivery).  They will obviously try their utmost to meet the targets set, but also expect to provide mitigations in the event of failed SLAs.  They have the experience of dealing with a number of clients and so have reference points to support them, whereas the contracting organisation does not have the same level of experience or number of reference points.

A common resolution is the instigation of a continuous performance improvement plan, and when that has been met redrafting of workable SLAs agreed by both parties, or if it fails penalty clauses or litigation.

Problem 2

Poorly defined requirements from the customer.  Either they are unsure what they want, have over / under specified the level of service really needed, they are looking to outsource a problem, or the business units have been poorly engaged, if at all, by procurement through the tender process.  In such circumstances the supplier is almost being set up to fail from the outset (which from their experience they will probably realise) and therefore they will look to manage their way around the issues as they arise.

The common resolution is a redefinition of the SLAs probably with an element of contract renegotiation once the customer has determined the service it expects or requires.

So what should a good SLA really be about?  A well constructed SLA should be seen as an important measure to support a positive contractual relationship, it should also be periodically reviewed for its applicability in light of changing business demand.  However, the SLA should not replace or overshadow the development of the relationship between the customer and supplier.  Rather, the SLAs in place should support a collaborative attitude towards delivering a contract outcome that benefits both parties; the customer receives the service they need, the supplier makes the profit margin they expected and the customer is satisfied with.

Neither party should be wasting time and money negotiating mitigations, instead the time saved can be spent on delivering future value.  Unfortunately developing proper, mutually beneficial collaborative relationships in a business environment is not easy where customer and supplier aspirations are not aligned.

“May You Live in Interesting Times” – The Impact of Cloud Computing

Changing of the Guard
Changing of the Guard

Kylie Fowler is a regular columnist for The ITSM Review, see previous articles from Kylie here.

It’s not often that most people get to experience a true paradigm shift, even in IT where change is endemic and part of the lifeblood of the industry. However there is no doubt that cloud computing and the commoditization of processor power and storage represent a true metamorphosis in the way we think about and structure IT services.

Cloud computing is actually the next step in a long series of IT developments which have promoted the decentralization of computing in businesses. The gradual decentralization of corporate IT can be tracked from highly centralized mainframes with their bespoke software, through the development of client server computing, the commoditization of software and finally, with cloud computing, the commoditization of processor power. This shift will have dramatic implications for how and where IT professionals will carry out their roles in future,

Right back at the beginning of corporate IT (in the dark ages known as the 1970s) computing power was served up from giant mainframes to users sitting at dumb terminals who carried out business functions using highly centralized in-house applications. Believe it or not, some of these old systems, developed on punch cards by engineers are still in use today, generally because they are too expensive to redevelop on a more modern platform, or the risks of doing so are too high.

The first steps towards the decentralization of IT came in the next era of computing, the one most of us are familiar with – the era of client-server computing. Significantly lower processor costs mean that processor power can be co-located with users (although largely separated from storage to ensure data security), while large clusters of servers provide basic services such as network access and email. For most businesses, day to day IT operations are still architected, managed and controlled within the organisation, albeit on highly commoditised hardware. In contrast, software has been largely commoditised, with powerful software publishers selling software for use under license. Complex applications are still modified in-house to meet corporate needs, but the underlying intellectual property is owned by the software vendor. This is the era of Microsoft, Oracle and SAP.

However we’re gradually moving into a new era, where the configuration and day to day management of hardware, software and the actual processing of bits and bytes are moving out of the corporation altogether. More and more organisations are asking themselves whether it is really cost effective to host basic services like email or word processing or spreadsheet analysis in-house when high quality services are available on-line for minimal cost.

Don’t get me wrong, there will always be servers and desktops and laptops, just as there are still mainframes, while large organisations may decide to develop private clouds to take advantage of economies of scale while reducing the risks inherent in trusting data to a third party, but the paradigm shift, the change in the computing world view that we are experiencing at the moment, is every bit as profound as the shift from mainframes to client-server computing was 20 years ago.

So what will the impact of this paradigm shift be for real people like you and me? Here are some of my predictions.

Service Operations will migrate out of the business

The essence of cloud computing is that what we have traditionally thought of as ‘IT’ has become a commodity. Most companies will no longer find they have a requirement for staff who can build a PC or a server as this requirement will have either been outsourced, virtualized or hosted on the cloud. But as is the case for mainframes, there will always be the odd niche where techies will thrive, so don’t despair!

Despite the growing importance of the actual connection to the cloud, network operation skills will also be outsourced, despite the fact that a secure, robust network to access cloud services will be even more critical than it is now.

Service Strategy and Service Design will become the core competence of IT Departments

The main business of IT is providing services that meet the needs of the business, but the new world of the cloud means most of those services will actually be provided by external companies. Logically, then, the core function of an IT department will be to decide HOW to provide the services to the business. Questions for Service Strategists and Designers will include: Which services do we put on the cloud, and which do we keep in house?  How will we ensure there is a seamless blend between the two? Which services should be provided as a unit, and which can be provided be different suppliers? How do we manage our suppliers to ensure they work together to ensure effective provision of all the services we need?

Service Transition will be vital for keeping suppliers on their toes

One of the biggest risks inherent in cloud computing is the danger of being locked into poorly performing, costly services which are either too risky or too expensive to escape. Service transition skills will be critical in keeping suppliers on their toes by giving management the confidence that it is possible to walk away if the service isn’t up to scratch while ensuring that new services are up and running as quickly and smoothly as possible.

Peripheral skills will move to the core

Areas which are currently considered peripheral to the operation of an IT organisation will become more prominent. The ability of Strategic Procurement to negotiate contracts that create value and minimise costs and risks will determine whether IT brings competitive advantage to the business, or, at the opposite extreme, becomes a costly white elephant that reduces productivity. IT Vendor and Asset Management will focus on ensuring the business achieves the value it expects from its Service Providers and will manage the fall-out when things go wrong, while Information Security will become more akin to Business Risk Management, assessing information risks and ensuring safeguards are in place to protect the organisation’s reputation.

How to survive the coming change?

The move to cloud computing resembles the slow grind of tectonic plates rather than a sudden tsunami devouring everything in its path. As with the movement of the continents, the shift to cloud computing will be slow but both inevitable and unstoppable. There will be the odd earthquake, of course, devastating for those on the fault line, but many people will find it has no major effect on their careers, and in some instances, may even enhance them.

IT folk are inured to change, but it has to be said that many of us lack flexibility. Be willing to shift sideways, or into a different industry (or onto the cloud itself) and be open to alternative ways of using your existing skills – perhaps move into consultancy or (shudder) sales. Broaden your skills base and see continuous professional development as a fundamental part of your working life – on a par with your morning commute or annual review.

Develop your soft skills, particularly communication. It’s hard to be a consultant, for instance, helping organisations change, unless you can communicate effectively and work with a wide range of people on many different levels.

Make it your business to understand the business. IT exists only because it offers businesses competitive advantage. The higher the competitive advantage provided by IT, the higher the rate of investment – you just need to compare the level of investment between the Finance and Construction industries to see clear evidence of that! Understand how IT offers your business competitive advantage and make sure your work supports this. If the business asks you to change because you are no longer helping it succeed, then change!

Find a niche. There are still jobs out there supporting mainframes, and there will always be jobs maintaining server based in-house applications. The jobs will be limited, but if you find a niche or have an obscure skill that a particular company can’t survive without, then the rest of your career could be very comfortable indeed. But don’t forget to be flexible! If your bosses out-source 90% of the niche jobs to India, it will be your ability to manage the outsourcer effectively that means you keep your job!

Kylie Fowler

It’s an exciting time to be working in IT, and although some people will suffer from the shift to the cloud, I am optimistic that the old Chinese proverb ‘may you live in interesting times’ will turn out to be a blessing rather than a curse for most IT professionals.

Note: if you are interested in reading more about the impact of the shift to the cloud, the Silicon.com website has an extensive special feature on the impact of the cloud which can be accessed at the link below.

http://www.silicon.com/special-features/cloud-security/

Kylie Fowler is a regular columnist for The ITSM Review, see previous articles from Kylie here.