IT Service Management Blog

Is Product Placement Growing?

2008-10-27T10:17:00.000Z

An article in the Independent discusses the growing prevalence of product placement amid declining ad sales. In the US, McDonald's has bought the right to have two cups of their branded frappuccino appear on the desk in front of the anchors on Fox 5 News. Product placements have become common in movies, with multiple mentions of Starbucks in The Devil Wears Prada and use of Vaio laptops throughout Casino Royale. The article concludes by noting that perhaps product placements are a normal part of life...

But what's the powder-blue sports car that Andrew Marr is seen driving over Westminster Bridge at the start of his Sunday show? A Nissan Figaro. Did Nissan pay the BBC for the plug? Once you start looking for product placement (no matter how innocent, as here), you see it everywhere. Almost as much as the viewers of Fox 5 News.

Problems, problems, problems...

2008-03-31T19:44:00.003+01:00

... they're everywhere, aren't they?

You're on your way to work and you find that there are transport problems: the train is late again. Once at work, because you are late for your meeting - your boss is angry. Worse still, you are not given the pay increase you were promised.

All this, and more, are typical of the every day issues that come up for employees and which managers sometimes have to 'manage'. The emotional twists and turns can be unhealthy for your morale and the energy you need to be successful.

A few years ago I came across a course, "The Power to Choose", by chartered psychologist Graham Price. Research that Price had done with colleagues at Birkbeck (University of London) found that there are three main ways in which people accomplish substantial goals. The first is the well known method of goal-setting: this made up around 40% of participants in the research. The second method was some kind of spiritual enlightenment, making up close to 10%. In the region of another 40% was a third method: people somehow accepting things as they are and their goals materializing.

Price's course explained the working of this third way of reaching goals and dealing with life. The most powerful concept of the course is that you have the power to choose. When you come across a situation that is unpleasant, such as a late train, you can choose not only your reaction to the situation, but also how you feel about it. Too often people let themselves get into auto-pilot chains of thought that lead to anxiety, depression, anger or a range of other unhealthy emotions. If you can get out of auto-pilot, you can put yourself into modes of thought and then action that are more productive.

Recently Price has released an e-mail based version of the course he normally delivers in-person to audiences around the UK. Because email is a more limited form than real life, Price is currently offering this version of the course free. Available at www.helpwithyourproblem.com, I recommend taking a look at this e-mail for anyone interested in taking greater control of their life.

One on ones

2007-11-20T12:59:00.000Z

One on ones are crucial for obtaining feedback on how employees are doing and also giving them feedback. I've found some templates and podcasts that look interesting on this subject.

http://www.manager-tools.com/one-on-one-key-points-and-template/

Integrity, intelligence, and energy: if they don't have the first, the other two will kill you.

2007-10-16T23:22:00.000+01:00

An interesting excerpt:

Warren Buffett said something similar (from Thoughts of Chairman Buffett), "Somebody once said that in looking for people to hire, you look for three qualities: integrity, intelligence, and energy. And if they don't have the first, the other two will kill you."

Why incidents occur. What we are doing to prevent them.

2007-09-23T00:41:00.000+01:00

I've come across an interesting video that highlights in the simplest terms possible why incidents occur: because a change has been made to the system.

The interesting segment is from the time 2:20 onwards:

They key parts from the video are where they mention:

Change is what leads to problems and incidents. The vast majority of incidents are due to someone making a change, mistakenly believing that the change is not going to lead to an outage.

Being intelligent about change will make a big difference to IT.

25% of problems come from infrastructure... the vast majority of the rest comes from changes that are wrong that have been made with the best of intentions.

The speaker goes on to tell a story about 3 programmers working together producing punchcards for a system. Taking punchcards they had, they made very careful, thought out changes. However, still things went wrong.

We have been experiencing a number of problems in the environments managed by the Operations team I lead. These environments are a series of components, software applications as well as hardware, with particular inputs and outputs. These components are connected to each other in various ways and configured through configuration files. To get a particular service playing through the TV, an engineer will need to hand craft the configuration of these series of components, ensuring the inputs, outputs and configuration of each component is correct. This is much like the story of the punchcard system that is described in the video.

The problems that we experience on our environments are almost certainly due to slight mis-configurations that are sometimes made by the engineers. As a consequence, we have started looking at automating these changes. If we are successful, we will be able to use a web interface to make the changes that are normally hand made. In doing this, we should be able to expect that the changes made by this automated system will be accurate and correct every time. This in turn should dramatically reduce the number of problems experienced due to mistaken human changes.

Getting the team talking through The Daily Scrum

2007-09-22T21:44:00.000+01:00

Communication is key to a Service Desk - team members need to feel comfortable exchanging ideas about how to solve problems. However, working in a flexitime working environment, one by one the members of the team crawl into work. Some start studiously looking through their email. Others put on their headphones as they get on with their work for the day. In an apathetic environment like this, the practise of having a Daily Scrum meeting becomes the heartbeat to kicking off talking and chatter among the team for the rest of the day.

The Daily Scrum is a concept taken from Agile Scrum project management method used most frequently for software development. There are plenty of articles on the Internet that describe how it works, like here and here, as well as articles on how it does not work. In essence it is a daily round circle, stand-up meeting where each member of the team goes around in a circle and tells the team what they have been working on since the previous daily scrum, what they plan on working until the next one and any blockages they have to completing any work.

Unlike long running projects, a Service Desk environment is based on incidents so it is often difficult to predict what team members are going to be working on. However, the meeting acts as a useful way for members to synchronise with the rest of the team, giving everyone greater visibility of each others' work and providing an opportunity for them to help each other. Particularly when there are major incidents, the meeting keeps everyone focused and aware of progress.

A glimpse of a slick, professional team

2007-09-13T18:15:00.000+01:00

I consider note taking to be a key behaviour of members of a world class service management desk. Note taking while investigating issues creates an audit trail that easily gives the engineer working on an issue, as well as others in the team, a trace of how something has been investigated. It allows others to be included on the investigation, allowing them to make contributions.

Without the key behaviour of note taking, the service management desk becomes prone to common problems that frustrate stakeholders of less well managed service desks:

Lack of visibility of issues raised by end users
Engineers progressing issues in isolation and difficulty in tracking the progress they have made on issues
Difficulty in different engineers picking up and progressing issues worked on by other engineers
Difficulty in work done by an engineer to be peer reviewed and retrospectively reviewed
Over-reliance on specific engineers for specific tasks

I am currently building a service desk team, with many members of the team inherited from elsewhere. Getting their adoption of the note taking practise has been slow to happen, but today I've started to see a glimpse of the kind of slick, professional team we are working towards: able to pass issues between engineers easily, with clear visibility to anyone interested of the technical investigation done and confidence in the capability of the team rather than individuals.

Specifically, the glimpse that I "saw" was that

Engineer 1 completed some work to build a new server to a very particular specification. He had recorded the details of his investigation on the ticket that was raised, #12. At first glance, the notes on the ticket seem excessive and as though not much thought had gone into them. They usually never are excessive and that there are notes always is the key, not necessarily the quality. The build of the server took almost 3 weeks to complete, between Engineer 1 working on other things.
Recently, almost 3 months later, a similar request, #354, came in for machine of the same specification to be built. In the past the engineer picking up the issue would have had to reinvestigate and re-determine how to build such a machine. In fact, the task of building this machine might have fallen to the same engineer who had previously worked on the issue, as that engineer might remember some of the details of what they had done 3 months previously in the previous occurrence.
However, because there are sufficient details on #12, a new engineer (Engineer 2) was able to pick up the new ticket, #354, and complete the work for the new server. I'm sure he sought clarification from Engineer 1 on some things, but there is enough in #12 to confidently work on this new similar issue on his own. He was also able to complete the work for ticket #354 quicker than the time taken to complete #12 – days rather than weeks. This is because he did not have to do any rework or reinvestigation done for #12.
This alone I thought was a great improvement in working practises…. But it gets better! Engineer 2 was away today and a further request was made on #354 by the user who logged the issue. In the past, this might have had to wait for Engineer 2 to return to work because no one would have been quite sure of what had been done. However, Engineer 2 had also made notes on #354 as he progressed the issue meaning a third engineer, Engineer 3, could respond to this and progress the issue further.

We still have some way to go for stories like this being true of every incident that we deal with. However, I think it is encouraging that we are now starting to the note taking behaviour being adopted and the benefits of this.

Jack Welch: Mountains Do Move

2007-09-09T23:43:00.000+01:00

In his book titled Winning, Jack Welch dedicates a chapter to Change, subtitling it Mountains Do Move. Welch distills his wisdom for bringing about change into four practises:

1. Attach every change to a clear purpose or goal. Change for change's sake is stupid and enervating. People need to understand in their heads and hearts the need for change. This is easiest when the reason for change is obvious, for example bad media headlines. When it is not obvious, it becomes necessary to collect data and relentlessly communicate the rationale for change.

2. Hire and promote only true believers and get-on-with-it types. To find these change agents, Welch points out to look for their characteristics: being brash, high-energy and more than a little paranoid about the future. They tend to be curious and forward looking, asking questions that start with the phrase "Why don't we...". They often invent their own change initiatives or ask to lead them.

3. Ferret out and get rid of resisters, even if their performance is satisfactory. Welch believes it is necessary to get the right people by your side and to get rid of those resisting change. These resistors usually lower the morale of those who support change and foster an underground resistance. They waste their own time in a company where they don't share in the vision - they should be encouraged to find one where they do. Even if they have a specific skill-set, they should not be held on to: they only get more die hard and their followers more entrenched over time.

4. Look at car wrecks.
Make the most of opportunities, even capitalising on other people's unpredictable disasters. It is possible to acquire resources cheaply from bankruptcies, for example.

These practises, though they may seem simplistic, do make sense. As well as point 1, behavioural change in the team should be the priority. From point 2, the person in my team who is embracing change the most is of the type Jack describes - always asking questions about improvements. Point 3 confirms a suspicion I have that if the person who is the biggest resister to change stays on my team, I am not likely to accomplish the change I need. Point 4 is definitely something that I will bear in mind.

Recruitment: Would you marry someone based on a one hour interview in a singles bar?

2007-09-09T00:58:00.000+01:00

A reoccurring theme in the new jobs that I take on seems to be hiring new people to accomplish significant goals. Seth Godwin asks, "Would you marry someone based on a one hour interview in a singles bar?", and then explains that far too often people are hired because they interviewed well - not necessarily because they can do the job well. A bad hire can be a significant cost in terms of resource and investment spent on them that proves to be fruitless. Instead of interviews, Godwin recommends actually trialing potential new hires on the job:

There are no one-on-one-sit-in-my-office-and-let’s-talk interviews. Boom, you just saved 7 hours per interview. Instead, spend those seven hours actually doing the work. Put the person on a team and have a brainstorming session, or design a widget or make some espressos together. If you want to hire a copywriter, do some copywriting. Send back some edits and see how they’re received.

If the person is really great, hire them. For a weekend. Pay them to spend another 20 hours pushing their way through something. Get them involved with the people they’ll actually be working with and find out how it goes. Not just the outcomes, but the process. Does their behavior and insight change the game for the better? If they want to be in sales, go on a sales call with them. Not a trial run, but a real one. If they want to be a rabbi, have them give a sermon or visit a hospital.

Yes, people change after you hire them. They always do. But do they change more after an unrealistic office interview or after you’ve actually watched them get in the cage and tame a lion?

Cultural Change as Behavioural Change

2007-09-04T22:10:00.000+01:00

In a previous post I discussed the need for cultural change as the necessary underpinning of any implementation of "best practise" and how I have tried thus far to overcome the resistance to change. Without some level of cultural change, the team or organisation becomes stuck in "current practise", not "best practise" and the implementation will not succeed.

In researching this area, I've come across Dr Leandro Herrero's Chalfont Project. Dr Herrero's perspectives on the area of cultural change are a contrast to other thinking, for example challenging the view that cultural change has to be slow and painful.

Dr Herrero's site has a video and a number of articles, but the highlights are:

Cultural change programmes concentrate on creating new mindsets and attitudes. A lot of time and effort is spent in rolling out new processes and tools. There is also a lot of communication and training, rationalising the logical need for change. In all this, an assumption is made that the new behaviours will follow to support these changes.
In reality, behavioural changes have to come before "cultural change". People need to be performing behaviours that are specifically "collaborating", for example, and this behaviour encouraged and spread. Once the behaviour becomes widespread, it can be considered that cultural change has taken place.
In this form of change programme, it is necessary to identify the key behaviours that will produce the required change. These behaviours must be reinforced and encouraged.
To make cultural change happen across an organisation, it is necessary to take advantage of the few people in the organisation who are connected to many people. These people need to be demonstrating and spreading the behavioural change. Dr Herrero compares this to the spread of an infectious disease, virally through a network.
The best thing that can happen in this kind of programme is dropping the terms "culture" and "change". People have preconceptions about these labels. Instead, people's natural tendencies to copy well regarded behaviours is used.

The content of Dr Herrero's ideas, which he calls Viral Change, make more sense to me than anything else I have come across in the area of cultural change. Perhaps what is more impressive is that I have previously seen a team undergo dramatic changes in working practises and the observations from just seeing that at a distance fit quite well with Dr Herrero's thoughts.

Customer Service Reviews

2007-09-01T13:35:00.000+01:00

When I was a Support Engineer, my manager would make a point of visiting as many customers as possible to find out what they thought of the department's service. He would not just visit the senior managers at the customer, but more importantly he would want to talk to the people who used the service of the Support Department on an every day basis. At the time, when he would do all this, I would think to myself, "Are these visits necessary? Surely it is obvious whether you are providing a good service or not". Later on, when I managed the department, it became apparent that I sometimes did not have sufficient visibility of the pain experienced by the customers or even how and why they were using the service of the Support Department in a particular way.

I'm five months into my current role in a new company and I am realising that these kinds of "Service Reviews" are more important than ever. It is easy to drop into a false sense of security, because the "customers" for this Service Desk are internal. I speak to the managers and team leads of these "customers" regularly, but I am only now realising that I don't get from them the full detailed picture or understanding of the customer's requirements.

The elements I am covering in these reviews include:

How the customers find dealing with the Service Desk. Some of the typical feedback I have got includes things like "not being given estimates of how long things will take;this means the customer is not sure whether to get on with other work"
Frustrations the customers are finding with the applications/services supported by the Service Desk. Feedback in this area includes issues relating to the instability of the applications and certain reoccurring incidents in the infrastructure.

The feedback from these areas feeds into the continual improvement of the Service Desk. Ultimately, it does not matter how elegant the infrastructure is or how well things work - the real measure of your success is dependent entirely on what your customers think of you.

Cultural Change: The most fundamental task. The most difficult task?

2007-08-29T00:17:00.000+01:00

It is one thing to talk about "best practises". It is quite another to have them implemented and working effectively within a team or organisation. Since the end of June, when I took a team on to shape and mould into an Operations team, perhaps the most striking problem has been some members' shear resistance to adopting new working practises. This has to be a problem in any organisation attempting to improve.

In particular, I want the team to make notes on their incident investigations. There are a multitude of reasons for this, such as allowing other engineers to review and continue the work if necessary and allowing the notes to be reviewed retrospectively if similar incidents occur in future.

My first and default method for getting the engineers to follow this practise was to tell the team quite simply what my expectations were and that we should be doing with respect to taking notes. This was enough for one of the team of 5 to take it all on board and start working as expected.

I then worked through some problems and showed how this could be of benefit. No further engineers were swayed to this new way of working.

The next step was to organise a "training". In this, I invited the users of the Operations teams - project manager, developers and others who would be using the services of the Operations team. I asked them to tell me what they thought would make a great Operations team. They came up with suggestions like "knowledge sharing in the team", "clear idea of where an investigation is and the process". I then went through how I would investigate a problem using this note taking working practise and how this satisfied their requirements. Almost all the users liked what they saw and approved.

The training had an interesting affect - one of the engineers requested to change teams soon afterwards, leaving a team of 4. The others became more convinced of the usefulness, but after an initial stab at trying the new method, soon reverted to their old ways.

After a major incident, a retrospective was held and some of the same themes re-emerged: the need to knowledge share, the need for more logging/notes on the investigation. These themes came from the team members themselves, yet still behaviours have not changed and the working practises have not been adopted.

During and after other incidents, users have sent emails relating to these same points and themes. The team members have seen these mails, yet still continue to work in the same way.

Changing working practises and creating a working environment where this is possible has now become the major and most fundamental issue. Everything else, such as what kind of things are "best practise" or IT Service processes, is a secondary issue.

Giving customers visibility of issue progression - Skype example

2007-08-23T02:46:00.000+01:00

A week ago there was a massive outage at Skype - none of their 9 million users could use their service for 2+ days. You can imagine that if Skype is one of the central ways in which you speak with your friends, you would have been very frustrated - the frustration you would feel with an outage to your mobile phone network for a few days.

What is interesting is that they used their blog to keep their users updated on progress: http://heartbeat.skype.com/

If you look at the entries for the month at
http://heartbeat.skype.com/2007/08/
you can see the entries they made throughout the incident to keep their users posted on what was happening. I've copied edited down snippets here and I really recommend going through these updates pretending to be one of the frustrated Skype users wanting their service working. I have further comments below.

Problems with Skype login
By Joosep on August 16, 2007.
UPDATED 14:02 GMT: Some of you may be having problems logging into Skype. Our engineering team has determined that it's a software issue. We expect this to be resolved within 12 to 24 hours...

Thanks for your support
By Villu Arak on August 16, 2007.
We'd like to thank everyone who has taken the time to send us their thoughts...

The latest on the Skype sign-on issue
By Villu Arak on August 16, 2007.
... we wanted to dispel some of the concerns ... The Skype system has not crashed or been victim of a cyber attack...

Further on the sign-on issue
By Villu Arak on August 17, 2007.
...We feel that we are on the right track to bring back services to normal. (Updated at 2:15am GMT)

Where we are at 0400 GMT
By Sten on August 17, 2007.
...We're fixing issues in our networking software and monitoring the clients getting online with increased success...

Looking slightly better at 0700 GMT
By Sten on August 17, 2007.
...even though it is too early to call out anything definite yet we are now seeing signs of improvement in our sign-on performance...

Where we are at 1100 GMT
By Villu Arak on August 17, 2007.
...We're on the road to recovery. Skype is stabilizing... Neither Wednesday's planned maintenance of our web-based payment services nor any form of attack was related to the current sign-on issues in any way.

Update at midnight GMT
By Villu Arak on August 18, 2007.
...Skype presence and chat may still take a few more hours to be fully operational....

The words we've all been waiting for
By Villu Arak on August 18, 2007.
Take a deep breath. Skype is back to normal.

What happened on August 16
By Villu Arak on August 20, 2007.
...The disruption was triggered by a massive restart of our users' computers across the globe within a very short timeframe as they re-booted after receiving a routine set of patches through Windows Update...

Now, as you were waiting for your Skype to start working again... How did that make you feel, reading those updates (compared to not having anywhere to look to see what was going on)? What if they were updating the blog every few minutes as they worked on the problem rather than every few hours and added technical detail which you may or may not understand - would that have made you feel more or less happy that the problem was being investigated and resolved? Then compare that with the service from, for example a bureaucratic government organisation or even your lawyer during the process of buying/selling a house. There is no place to go and see what is happening with your issue and you feeling you are banging our head against the wall - constantly chasing for updates through phone calls or other means.

This Skype example gives a glimpse of what is possible through using a ticketing/bug tracking system when engineers working on the problem update those tickets with notes. The dramatic increase in visibility of an issue being progressed gives greater confidence to customers, reducing their anxiety.