Rob England: The People in ITSM

Maori proverb: "He aha te mea nui? He tangata. He tangata. He tangata." What is the most important thing? It is people, it is people, it is people.

It’s all about the people.

A service exists to serve people.  It is built and delivered by people.

Even in the most technical domains like IT, the service is about managing information for people to use, and managing the way they use it.

When we change IT, a lot of the time we are ultimately changing the way people behave, the way they do things.

There is an old mantra “People, Process, Technology” to which I always add “…in that order”.  By which I mean prioritise in that order, and start in that order.

People, Practices, Things.

Actually I don’t like that mantra; I prefer “People, Practices, Things” as a broader, more inclusive set.  Either way, it all starts with people.

We’ve been using railways (railroads) as examples for this series of articles.  Ask a railway how important the people are.  Railways are complex and very dynamic: they need to adapt to constantly changing conditions, on a daily basis and across the decades.  We are slowly getting to the point where we can automate the running of railways, but only because the trains run in a tightly designed, constructed and operated environment that relies on people to make it work and keep it safe.  Much like IT.

I’ve never bought into this feel-good stuff about successful companies being dependent on a caring people culture.  Some of the most successful railroads in the ultra-competitive US environment have pretty rough people cultures – they treat their staff like cattle.   And other railroads are good to their people – though most of them are off to what we would consider the tough end of the spectrum.  I don’t think it correlates.  I could say the same about software companies I have worked for:  from second family to sweatshop.

However it is probably true that all successful companies have a strong culture.  Staff know how it works.  They may or may not like the culture but if it is strong they identify with it and align to it, to some extent.  So culture is important.

And cultural change is hard – in fact it is a black art.  The bad news is that changing the way people behave – remember our first paragraph? – is cultural change.  Behaviours only change permanently if the underlying attitudes change.  And people’s attitudes only change if their beliefs move at least a little bit.  Culture change.  Fifty years ago railroads were places where men – all men – died regularly, learned on the job, and fought as hard as they worked.  Now the people are trained professionals and the first priority of most railroads is safety.  Twenty years ago the New Zealand Railways had 56,000 employees, couldn’t move anything without losing it, lost millions, and wouldn’t know what to do with a container.  Now 11,000 move record volumes of freight and do it profitably.

“Just because you can change software in seconds doesn’t mean organisational change happens like that”

You can’t make those transformations in short timeframes.  Just because you can change software in seconds doesn’t mean organisational change happens like that.  You would think railroads take longer to change hardware technology than we do in IT because it is all big chunky stuff, but really our hardware and software platforms change at about the same pace; years and even decades.   Plenty of Windows XP still around.

Technology is the fast changer compared to people and process.  Just because you rolled a flash new technology out doesn’t mean people are going to start using it any differently unless you ensure they change and their processes change.  That human rate of change is slow.  People  will change quickly in response to external pressures like war or threatening managers, but that change won’t stick until their attitudes and beliefs shift.  I bet the safety culture on US railroads took at least one generational cycle to really embed.

In response to a few high-profile crashes, governments in the US, UK and other places have mandated the introduction of higher levels of automation in train control over recent decades (despite the much higher carnage on the roads but that’s another discussion).  Much of this push for automation stems from frustration over driving change in behaviours.  Does any of this remind you of IT initiatives like DevOps?

Culture can change, and sometimes it can change quite quickly, by human standards.  It takes strong and motivational leadership, a concerted programme, and some good cultural change science.  The leading set of ideas are those of John Kotter and his Eight Steps to change, but there are many ideas and models now in this area.  In IT, everyone should read Balanced Diversity by Karen Ferris.  And you will find a multitude of suggestions on my free site He Tangata.

Whatever methods you use for change, pay attention to three aspects:  motivation, communication and development.

Motivate them in these ways:

  1. by getting them involved and consulted;
  2. by showing how they benefit from the change;
  3. by making them accountable and measuring that accountability;
  4. and by incenting them.

Communicate early, communicate often, and be as transparent about decision-making as you can.  Tough decisions are more palatable if people understand why.  Communication is two-way: consult, solicit feedback (including anonymous), run workshops and town-halls.

Development is not just one training course.   Training should be followed up, refreshed, and repeated for new entrants. Training is not enough: practical workshops, on-the-job monitoring, coaching support, local super-users and many other mechanisms all help people learn what they need to make change successful.

One final thought: examine your current and planned IT projects, and work out how much effort and money is being spent on the people aspects of the changes the project wants to achieve.  I’d love to see some comparative research on the proportions of money spent on people aspects of projects in different industries like railroading, because we in IT still seem to suffer the delusion that we work with information and technology.

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.