ITSM14 Preview: Karen Brusch and Managing Multiple Suppliers from an SLM Perspective

Karen Brusch of Nationwide Building Society and itSMF UK
Karen Brusch of Nationwide Building Society and itSMF UK

In the run up this year’s itSMF UK conference, ITSM14, I chatted with Karen Brusch of Nationwide Building Society and itSMF UK about her upcoming session entitled “Managing Multiple Suppliers from an SLM Perspective”.

Q. Hi Karen, can you give a quick intro to your session at the itSMF UK Conference?

The itSMF UK Service Level Management SIG has always been keen to research and present topics that are identified as problem areas by practitioners in the industry. Supplier Management and how that impacts Service Level Management has been an area of discussion which has gained momentum over the last 18 months. This session takes a look at some key points around the complexities of managing multiple suppliers.

Q. What impact does managing multiple suppliers have on an organisation?

The most obvious impact is the failure to deliver what an organisation’s business needs. It is hard enough to understand and document business requirements when you have one supplier; but when you have a multitude of suppliers, there is a real risk that requirements become diluted, compromised, or more crucially missed. Managing multiple suppliers is a black art, where what works for one set of suppliers will not necessarily work for another; so each combination requires a modified approach. Service Integration specialists (SIAM) have helped to shape some answers, but even here, flexibility is the key. So any organisation embarking on a multi-vendor strategy has to have the knowledge, capability and determination to succeed.

Q. Where should organisations start with managing multiple suppliers?

The most important thing is to understand your business’ end game; where do they want to be in 5 years’ time, for example. Once you have this information you can begin to formulate supporting IT strategies and requirements. Too many organisation write their Invitations to Tender (ITTs) and Request for Proposals (RFPs) without understanding business strategy

Q. What are likely to be the potential pitfalls and/or benefits an organisation may experience with implementing a framework for managing multiple suppliers?

An organisation will derive real benefit for taking the time to develop an appropriate governance framework for the selected preferred suppliers. As I’ve said already, each combination requires a modified approach, so it really pays to invest some time in this activity. The fundamental pitfall that I’ve seen on many occasion is that organisations select the cheapest provider for each area/tower of service, not taking into consideration the overall impact and integration issues. It goes back to having people with the knowledge, capability an determination to succeed.


Karen is an ITIL Expert, recognised as a member of the itSMF UK Expert Faculty, and a Service Design specialist with 12 years’ experience. She chaired the itSMF UK Service Level Management Special Interest Group for several years, and has recently stepped down from this role to support the newly formed Service Design SIG. When not engaged in itSMF activities, she works for Nationwide Building Society as a Service Design Consultant.

medium ITSM14 banner aug 14

Karen’s session is on day two and featured within the Managing Complexity track. To find out more or to book your conference place please visit itSMF UK

Follow Karen on Twitter or connect via LinkedIn

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.

The ABC of ITSM: Why Building The Right Process Matters

Attitude, Behaviour and Culture (ABC) - this sets out to ensure that the human aspect of ITSM and service delivery matches that of the IT implementation.

This article has been contributed by Ben Cody of Serena Software.

In my previous piece for The ITSM Review, I examined the state of general dissatisfaction with ITSM tools at the moment.

In doing so, I wanted to question why a positive dedication to “process” should be at the heart of how organisations solve complex (and simple for that matter) IT services challenges. This time around, I want to look at the human element of process.

The new ABC

ABC (for the purposes of our story here) stands for Attitude, Behaviour and Culture — basically, this sets out to ensure that the human aspect of ITSM and service delivery matches that of the IT implementation.

One area that can help ITSM professionals today is to look at their approach to ABC in a new light, based on understanding the wider processes that are in place.

Re-evaluating processes gives ITSM teams the opportunity to look at their own ABC successes and issues again. It also represents a chance to examine how these ABC milestones can be used to improve wider service within the organisation. Without the right elements in place, those individuals working on the service desk may not be able to deliver what the business expects and requires of them. More importantly, changes within the organisation won’t be successful.

ABC is equally important when it comes to inter-team communication, as the hand-off between teams can be affected by differences in approach and behaviour. If one team is performing well on its own terms, but its output goes through another group with motivational challenges or a different work method, then the initial team’s work may be viewed as not meeting the overall requirements of the business.

The release management black hole

This can be seen in the ITSM world when an application implementation is not completed successfully across to the complete scope and breadth of the organisation. The application itself has been written to specification, thoroughly tested and was ready to go — but the team responsible for managing help-desk calls may see a massive spike in users getting in touch. In this example, the release management process has not been completed successfully, which leads to issues getting raised with the help-desk team and poor perception of IT in general.

Nothing was wrong in the development phase and the ITSM function can provide a great level of service — however, what users remember is that there was a problem in the first place.

In the user’s mind, IT is seen as being one complete unit, yet this is not often the case. Most teams within large organisations are broken down into project and technology teams, depending on how they have evolved over time. Responsibility is split across these different teams and each can have its own approach to managing work based on how it is led.

Achieving some kind of level of “unity of approach” and getting each part of IT to buy into a common set of values is a significant challenge. The responsibility for this should sit with the CIO as part of their leadership role. As business requirements change and IT has to evolve to support new demands, so getting the right processes in place to complement the right ABC is therefore critical. Changing or amending behaviour at the individual level relies on how much people buy into what is being put in place at the process level, too.

Process and ABC: a two-way street?

On the individual attitude and behaviour front, there has to be an understanding across the IT team responsible for delivering a service of how their section fits into the wider business process. This can be as simple as letting each individual know how their work contributes towards a key performance indicator or meeting a service level. For organisations that already have some degree of joined-up processes, the information given back to people can be much more granular.

At the same time, this emphasis on process can be used to remove manual work where it is possible to take it out. In the example above, automating the release of an application that has been developed and tested properly, rather than relying on ad hoc scripting and manual labour, could remove the potential for things going wrong. Not only does this speed up the process overall, it also makes the whole IT team concerned with that installation appear to be part of a uniform and co-ordinated strategy to the business.

For organisations with ABC challenges, looking at “process hand-overs” between teams is the simplest way to evaluate where these problems start and why. Is this an issue with an individual, a team or with the wider IT function within the organisation? Depending on the level at which the problem is occurring, this will change how the ITSM team looks at their processes in a new light.

The attitude and culture that a company has in place will have an impact on the overall process that is being completed — if employees feel valued and trusted, then they are more likely to care that the results of their work are good. At the same time, design of a process can affect ABC as well — a well-designed process that is fit for purpose, automated where it needs to be, and running well should support employees in achieving job satisfaction.

The business-to-IT connection challenge

One of the most common complaints around IT is that it does not match up with the business. Traditionally, IT has been separate to business functions based on the availability of the skills that were required to understand and run the technology department. This is changing with the advent of cloud computing and the growing understanding of IT within the business itself. But whether organisations want to embrace a cloud computing approach or not, the fact is that ITSM professionals have to realise that their service delivery is being judged against a different yardstick. Whereas previously, IT operations and services would be based on what direct competitors are doing, now it is more likely that the business will look at what consumer websites and portals are able to deliver.

This change in emphasis and the need to keep pace with what the business expects from IT, makes looking at ABC more important than ever. Service providers have the mantra in place that “the customer is king” – even when they either don’t know what they want, or are actively looking at the wrong approach. For ITSM, this means looking again at their attitudes to managing users and where this may have to change in future. As cloud continues to attract interest, IT will have to learn lessons from the service provider world.

Ben Cody, Serena Software
Ben Cody, Serena Software

Managing ABC in this environment should theoretically be easier — after all, IT and the business are both part of the same company. However, there can be this barrier between the two that has to be broken down. If it is not, then IT risks either remaining as a support function with little value, or instead being replaced with outside tools and services instead. This would do ITSM a grave disservice, as it should be obvious that internal IT teams have not only the interest of the organisation at the front of their minds but also the most in-depth knowledge of what the business really requires. What does have to change is that understanding of service delivery from the business perspective.

Hand in hand with this ITSM imperative is the need to get the business function’s perception of IT to change. The attitude and behaviour of the business towards IT is just as important as IT’s own ABC i.e. without the willingness to embrace IT as a strategic part of the corporate decision making process, there can be no real change in approach across ITSM. IT can aim at being customer-centric as much as possible, but if the IT team is not involved in the decision-making process from the outset, then this will remain a largely unfulfilled ambition.

Analysing the role of IT across the business process is the best way to achieve the much-needed inclusion that we must achieve here, alongside aligning the culture of the IT team with that present across the wider organisation. By understanding how work goes through the business and the ITSM resources required to support that flow, IT can claim its place at the table.

This article has been contributed by Ben Cody of Serena Software.