Over the last 12 months, I have been lucky enough to be able to deliver business simulations to organisations who are either going through change, or who are looking at different ways of working.

These simulations have been created by GamingWorks and go by the names of The Phoenix Project and MarsLander.

The Phoenix Project simulation focusses on helping teams to explore and learn about DevOps and Agile ways of working.  MarsLander helps Service Management teams explore how a more agile approach can help them deliver faster, with more value and use the ITIL4 approach in their everyday working. However, with the latest update to ITIL taking onboard the learnings of DevOps, Agile and Lean and applying them to ITSM, these two simulations help attendees explore, experiment and learn these similar concepts but in different ways.

The teams who have taken part in The Phoenix Project have come away from the day, and it is a full-on day, telling me and their colleagues that they understand the need to collaborate better, that the “business” representatives (as opposed to the IT team members) “get” what they need to do to work better with IT, that “business” and IT people understand why they need to communicate better, that they all understand the benefits of limiting their work in progress.

The teams who have participated in MarsLander, tell me and their colleagues that they understand the need to collaborate better, they understand why they need to communicate better within teams and with their customers (internal or external) and suppliers / partners, that they all understand the benefits of visualising their work and limiting their work in progress.

Senior participants - CIOs and IT Managers - tell me that they want to promote greater visualisation or work and encourage greater preparation, not just planning, within their teams.

Those at the pointy-end of delivering IT services tell me that they want to get their management teams on the simulations so that they understand the need for improved ways of working.

Non-IT attendees go away with a greater respect for their IT colleagues and talk to me about running the simulations within their teams - non-IT teams.

All team members also come away from the simulations as closer teams. Some were brand new teams only meeting for the first time on the day, but after an hour or two, you wouldn’t have known that.

So if you are looking to improve collaboration between or within teams, looking to explore different ways of working, or to understand how the DevOps principles or ITIL4 approach can help your teams deliver better services, get in touch. I may have just the simulation for you.

​

Recently we ran a number of Phoenix Project simulations for an organisation who are in the process of developing product teams, which the CIO noted “...will be self-contained, self-managed and empowered to deliver services associated with critical business value streams”. Part of this transformation involved the IT department’s lead team experiencing The Phoenix Project simulation for themselves and then, having agreed on the benefit, running a further two, so far, for two of the new product teams.


Both groups who took part in the simulations included technical roles (Developers, Testers, Support, Monitoring, etc.) and representatives from the business teams for each product, including CIO and Directors. One of the teams was new; so new, that the day of the simulation was their very first day working together.


I’m not going to provide any spoilers about how the days went, other than to share some findings.


With a mix of IT and Business representatives taking part, we made sure that IT team members took the roles of Parts Unlimited business representatives (CFO, HR & Retail Operations) and those from the wider business, took IT roles. Within the IT representatives, we made sure that nobody had a role similar to their day job. That mix created some good talking points from the very start.


As round one was started some people dropped into their day job role and took control of certain aspects of the round. For one team, this worked really well and round one was a roaring success. For another group, less so. However, following the reflection and some advice provided on how improvements could be made, the team who didn’t do so well in round 1, listened and used their preparation time to improve their approach. The other team, who did well, didn’t prepare as much and struggled in the second round.


As the day progressed, it became apparent that those IT representatives in Business roles in the simulation were learning much about the value of planning, and they were sharing what they learned. All, eventually, understood the value of preparing along with a few other key things which I won’t share here. The Business representatives in IT roles for the day were able to see what was required from them in their usual roles and identified improvements they could make.


The days went well with both groups having many takeaways which would help them establish their new teams and drive collaboration and improvements based on the principles of DevOps. The team who were together for the first time, started as a room of individuals and left as a team, made up of IT and Business people. Both groups left as more cohesive and collaborative teams than when they started. 


So what can you get from participating in The Phoenix Project?

• Your teams can learn how to use the DevOps principles and ideas to improve their way of working, whether they are currently involved in development or not. 
• Teams can bond over shared challenges, whether they are established teams, or brand new teams. 
• You don’t need to be involved in IT to get value from the day, or DevOps. DevOps, after all is enterprise wide, so anybody involved in the development or support of business value can benefit from this simulation. 
• Senior leaders in organisations can get hands-on high level experience of Lean, DevOps, Agile and Service Management principles. 
• Teams starting out on the DevOps journey can experience the essence of what it means and take away ideas to use the next day. 

If you are interested in running The Phoenix Project simulation at your organisation, get in touch.

A while ago I responded to a statement that millennials and Gen Y people expect to be able to use any device of their choosing at work. My response (and I can't remember where I had this hissy-fit) was along the lines of "Tough! Once we grow up, we have to toe the line, and sometimes that means using and doing stuff that seems daft". However, going through the VeriSM BoK and there is a statement that goes:
"the nature of teams is evolving, moving away from the traditional hierarchical structure, to empowered and collaborative work units. The workers of today and especially tomorrow (Gen Y & Gen Z) have been raised in the teamwork culture and organisations need to be prepared to offer that same work environment." (emphasis mine)

Now, as a dad, I know everything, right? Nope. My initial reaction to the above statement was along the lines of "Pish!", or to be less English and more Kiwi "Yeah, Nah!" but then I got thinking. When I was at school, we sat at individual desks, in columns and learnt. Science classes were the only ones where we sat and worked in small groups. My daughters at Intermediate School and College (high school) only seem to work in groups. It's what they know. Could they join the workforce and be expected to work individually? Yes. Would they excel in that format? Probably not.

So we do need to change the way that work environments are created, not just because they are "self-entitled" Gen Y people, but because we have created that environment in schooling.

Does you work environment allow for a culture of team working (not just "in a team" but actually part of a team)? Or do you expect people to be doing their own job while working in the Finance team, or the HR team, or the Asset Management team? And I'm not saying open plan offices are the answer.

When consulting with clients about DevOps, I reinforce the culture, collaboration & teams aspect, which of course if you are considering becoming part of the DevOps movement in your organisation, means changing the culture across the whole organisation, but this needs to work across all teams in all organisations whether DevOps is something being considered or not. I also always like to create self managing teams when helping organisations to identify and drive improvements of any kind, but this has just been a lightbulb.
​
​Maybe I am late to the realisation party, but that one sentence has made me take stock of everything I have ignored about the way most organisations work. I don't have all the answers, but I'm thinking about it.

I recently wrote about the differences between leaders and managers, but since then I have been thinking more about the type of people we interact with, rather than the role itself.

Whether you are a member of a team, a manager, team leader or any other role in an organisation, is the way you act having a positive or negative influence on those around you? Over the years, I have been lucky enough to work with a variety of different people in many organisations across the globe, some huge companies of thousands of employees and some small local organisations with less than two dozen employees.  What stands out in all of them is how some people influence their colleagues positively and others manage to bring the mood down immediately.

Is that important? As Phineas from Phineas & Ferb would say, "Yes, Yes it is".  I have worked with some people, at varying levels of hierarchical influence, who have made people glad to be there because they always have a cheerful demeanour, they are happy to help anybody out with any task, and when they aren't around, they are missed by the teams.  Others start to moan about something as soon as they walk through the door, whether it is the traffic, politicians, how much they ache from the gym, their partner or anything else that pops into their heads.  We all have moments where something winds us up and we want to vent, but if it is all the time, it brings people down.

So what should you do to make sure you influences people positively? My personal recommendations are:

• Be aware. I'm not suggesting you take up yoga on a mountain top, but be aware of how you sound and come across. Are you complaining too much? Are you the negative one whenever there is a team meeting or announcement? Take a breath before opening your mouth; try to be more positive in your comments
• Be positive. If anybody is positive all of the time, suggest random drug tests at your place of work. It's not humanly possible without some kind of assistance. But you can try and find the opportunities in the challenges or difficult situations you discover. Focus on what you can do, not what you can't.
• Be empathetic. Try to understand what others might be feeling. Listen - really listen - to what they are saying and try to see things from their perspective. 
• Show humility. If you don't know something, say you don't. If you know who knows more, let others know. Encourage others to get involved and give them the credit. Don't be too senior to get your hands dirty and do tasks perceived to be menial. 
• Be professional. Small actions can make all the difference here. Get to meetings on time; dress appropriately. You don't need to wear a suit, but clothes that fit and are clean is a good start (brightly patterned and coloured lycra active-wear is probably not appropriate for any position other than spin class teacher!); communicate appropriately; be reliable and show integrity.

All of the above are key to creating a positive vibe in the workplace.  Whether your day is turning up, doing your job and going home, leading people through organisational change, running a company or looking after children at home, you need to display positive attributes to ensure that you are a good role model.  Empathy is, as I have hinted at previously, a key skill. However it seems to be lacking in many people. So can I ask that if ALL you take away from this post, is that you will focus on being more empathetic? That will help you become the right kind of role model that many people need. 
​
If you feel you or your colleagues would like assistance with anything mentioned, please do get in touch. I can help.

I have been having a brief chat with someone about whether they should be hiring a leader
or manager and the discussion seemed worth sharing.

So, is a manager or a leader right for a role?

These two terms often get used interchangeably, or even by people who consider a leader to be less than a manager. After all, you progress form a Team Leader to a Manager, don't you? But what is the difference, if there is one?

There are a plethora of sites and articles out there defining the difference between the two types of role, but in the end it doesn't really matter what you are or have, as long as it is right for the position.

Manager
In very simple terms, because you will be able to find something on the internet that disagrees with me, a manager is one who ensures that things get done and focuses on tasks.  So if, for example, you have a position which needs to ensure that certain services or products are delivered in a set way by a set time, and the team just need to do that, you probably need a manager in that position.

Leader
Again, in simple terms, a leader understands and shares a vision and encourages or helps people to deliver it. Another example might be where a team needs to deliver certain services to a customer but it is not prescriptive in the way that the services is delivered, then a leader might be right in this situation. "We need to clean this house. Make sure that there are no dirty carpets, curtains, windows and the oven is clean". The vision has been set, and all get on to deliver that service. The leader might help to move furniture and do some of the tasks, but doesn't tell the team how to clean the carpets, unless they are struggling and need help.

Servant Leader
This is a relatively new term to many people. Within agile teams. Servant Leaders, such as Scrum Masters or Agile Service Managers, in that environment will lead the teams to become self-organising and remove any impediments that might slow down or stop delivery.  They are part of the team and not separate. As Robert K Greenleaf puts it
"The servant-leader shares power, puts the needs of others first and helps people develop and perform as highly as possible."

So should you have, or be, a manager or a leader? Well, I am a consultant, so my response would have to be; it depends.

Managers will probably be more focussed on getting tasks delivered in an agreed way. e.g. Finance Manager or HR Manager.

Leaders will be focussed on helping a team to deliver against a vision. I believe that IT Operations Managers or Development Managers should be leaders more than managers.

Servant leaders will be focussed on helping the team become self-organising and enabling them to deliver with minimal hurdles. Think Scrum Master or even Service Desk Team Leaders.

There is no right or wrong role. It really needs to fit the position. A leader won't always fit in a management role, and a manager won't always fit in a leader role.  Work out what you need, and then find the right type of person to fit that need. And if you are a natural leader, understand that if you move into a management position, it just may not suit you and you might become frustrated.

Mike Elgan wrote an article about the fact that, in the US at least, laptops will not be allowed in cabin of aeroplanes and of the demand, whether current or future, for access to smartphones by border patrols.

While this is worrying for many people, businesses need to plan for this. Those organisations that have staff members travelling to and fro from the USA, and many other countries soon, need to be prepared.

The equipment mentioned is, for those travelling for work, likely to be owned by the organisation.  So what happens for that business traveller when the laptop is irreparably damaged in the checked-in luggage, or stolen? What happens to the data stored on it? What happens if border patrol demands access to the smart phone?  This isn't a case of "Call IT and get it replaced". This has a huge business impact.

Business Continuity Plans are (supposed to be) written by business units to document how to handle and recover from threats to an organisation or business unit. They are generally written as a response to major disasters, or issues that stop staff from attending offices (flood, fire, disease, etc). Most won't consider this as a large enough impact. They should.
 
Business continuity planning (or business continuity and resiliency planning) is the process of creating systems of prevention and recovery to deal with potential threats to a company.  Any event that could negatively impact operations is included in the plan........

Businesses cannot, nor should they, expect IT to be handling this for them alone. IT will be able to respond with an IT Service Continuity Plan, based on the Business Continuity Plan, but not second guess the impact to the wider business.

If you are a senior manager in an organisation where anybody travels overseas for business, you need to consider the impact, what your staff will do if they lose the laptop or smartphone, and what you will do if the data stored therein is compromised.

Should staff have company data on the laptop or phone?  If so, is IT aware of this and have you asked them to come up with a way of protecting that data?

This is no different to staff having laptops stolen out of cars, but it now needs to be front of your mind.  Don't expect IT to know what you want. IT are a part of the business and you need to work together to ensure that you have considered the impact, understood the risks and planned for it.

Prepare your plan and provide all travellers with a towel. Then, you can, as Douglas Adams advised in The Hitchhiker's Guide to the Galaxy

Some days it feels like everyone is talking about Devops. If you read industry blogs, follow groups such as Back2ITSM on Facebook, or talk to people in our industry, someone will start to mention DevOps fairly quickly. That’s fine if you work in an organisation that does software development, but surely it doesn’t matter to you if you don’t. Or does it?


A year or so ago, I was talking with Rob England about Devops and I couldn’t see how it would affect the types of organisations that I generally consult to; small, “traditional” IT shops with off the shelf software being used, with no development. We had a great discussion about it as part of an ITSM Crowd recording.


I now feel that I understand DevOps better, although there is still plenty more to know as DevOps evolves and more people get involved in it, but my understanding is still very much on the Ops side of DevOps.


So, if, like me, you have your heart in Operations, what does DevOps mean, why should you care and can it help you?

What does it mean?


According to DevOps.com:
"The first sentence on Wikipedia defines DevOps as “a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals.” Well, that’s a fairly dense definition, yet still pretty vague. I think DevOps can be explained simply as operations working together with engineers to get things done faster in an automated and repeatable way."


DevOps, at it’s core is all about bringing together Dev & Ops and the wider business and ensuring that the cadence of development delivery can be matched and managed at the same pace by Operations. DevOps also encourages the use of the goals of CALMS; Culture, Automation, Lean, Measurement and Sharing.


Very (and I mean very) simply, they mean:


Culture; The culture of collaboration is one of the key ones and guides the bringing together of Dev& Ops and the wider business. It’s not about them and us, but about us all working together to get things done better, quicker and cheaper. It doesn’t happen overnight though.
Automation; Wherever possible, automate tasks. Automate testing, deployment, integration, incident resolution, everything that can be.
Lean; Reduce waste. If it doesn’t need to be done, don’t do it. Move quickly and continuously learn and improve. If you try something and it fails, never mind, try something else quickly. You are allowed to fail in DevOps.
Measurement; Measure what you need to to ensure that you know that you are improving.
Sharing; Share responsibility & knowledge between Dev & Ops. It’s what it’s all about.


Why should you care? Well, the world is changing. While there are still many organisations out there who “only” do traditional IT and use the ITIL framework as the loose guide to handling calls and changes, we need to acknowledge that there are different and often better ways to do the job. So you need to be aware of what is happening and be open to changing the way you work. Do you want to be that person who says “We’ve always done it that way!” or “ That’s not how we do it here”?


Can DevOps help you? Yes. It can make you work together and remove some, if not all silos in IT. It can also help you work closer with the wider business so that everyone understands the drivers and priorities for the work that IT does. It can help you to trust each other more and move away from the blame culture that still persists in some organisations. It can allow you understand that it’s ok to try something and fail. It can make you think about automating stuff through scripts or pre-approved changes. It can encourage sharing.


There is a lot of good stuff in DevOps which can and should be adopted by those with no Dev. 
So how do you start the thinking? 


There is training in DevOps, which provides you with an understanding of the principles and the language used, DevOps Foundation, which I can provide through on-line training.

There is also the Phoenix Project business simulation workshop which is based on the book by Gene Kim et al and takes you through the usual issues experienced by IT and guides you through applying DevOps principles.


Get in touch and see how we can help.

So you want to work on a service desk or customer support centre?  You want to recruit somebody to your support team?  What sort of skills are needed?


All too often I see job adverts for people who "must have" good customer service skills and ITIL Foundation certification (if on an IT Service Desk). But are these essential and what are they?


Communication
If you are working in a front line role you need to be able to communicate well. That means you must be able to talk to the caller in such a way that they don't feel threatened by overly technical or commercial talk and you must be able to listen and understand what the caller is saying. They generally aren't calling because they love calling your team, rather they are calling because they need something / something doing and they can't do / find it themselves.


Empathy
Now I'm not suggesting that if a caller says everything bad under the sun about your organisation or team you agree with them (that could be career limiting) but that you try and understand WHY they feel that way and think about what you can do to rectify it.  You may not be able to do anything, but if you can demonstrate that you have understood their concerns or issues and will attempt to do something about it, that will be a big step forwards.


Cheerful manner
Please do not go over the top.  I'm not suggesting that you should be "Have a nice day!" or "Missing you already", but smile when talking (even on the phone) and be polite.  If you have just had the call from hell, and the phone rings straight-away with no opportunity for someone else to take it, then take that deep breath, smile and answer the phone.  The caller doesn't want to know how bad things are - imagine how bad it is for them to have to call and ask for help.


Good telephone manner
Most support roles are telephone based now and so this is a critical "skill". The ability to feel confident when on the 'phone is important in most roles, but probably more so here. You need to be clear and confident.  And if anybody complains about the quality of your headset, change it immediately.  That is a piece of hardware that is as important as your computer and OSH approved desk & chair.  If you are recruiting somebody for this role, make sure that first interview is a 'phone interview. If that doesn't impress you, go no further because they won't impress your callers.


Polite
Under no circumstances should you be rude to the caller. This may be hard sometimes, but if they are rude to you, just ask to put them on hold and pass the call to your supervisor.


Ability to follow processes
Support teams have processes in place so that a similar level of service is provided each time a caller interacts with them.  You need people who can follow these processes.


Ability to think for themselves and not follow processes
Processes aren't always right.  To have people blindly following processes is wrong AT TIMES. The support team members need to know that if they feel a slightly different approach is called for (and it doesn't breach any company policies) then they will be rewarded for that thinking, not admonished.


Everything else can be taught / learned on the job.


Have I missed anything?
​

With all the hype recently around the release of Apple's new watch, there appears to have been a plethora of blogs telling us how the helpdesk needs to be ready for the influx of calls from people wanting to use the benefits of wearable tech for work and how the helpdesk needs to address issues like security, compatibility with existing software and hardware and the information "stored on them".
What rubbish.
None of this is a role for the helpdesk.  Just as with smart phones and tablets or people's personal laptops or palm pilots, this comes back to governance.
Do the governors of IT want IT to allow smart watches to be used in the workplace? I doubt they would be able to consider all of the risks and benefits so this is where IT (maybe in the form of the CIO) needs to advise the governors.  When they have all the information, they can make an informed decision. Then they can direct IT to allow certain things.
Without this direction, IT don't allow anything.
If the governors decide that they do want to allow wearable tech within the workplace, then it is still not the helpdesk that addresses the issues mentioned above. Information Security will consider and address information and security concerns, compatibility will be undertaken by architects.  None of that is the helpdesk.
When everything has been considered and all risks mitigated to an acceptable level, then the helpdesk and other support teams (who we hope have been involved in the design of any changes) will receive all the appropriate information BEFORE go-live, so that they can support the users.  Until then, nothing is supported.
So pundits, before you start scaremongering, just consider who DOES need to address concerns and when.  Let's get the governors governing and IT managing.  It's like Government and Police. The Police (IT) are suppose to uphold the law, and the Government (Governors) set the law. (To follow that analogy a bit, see the IT Skeptic's To Protect and Serve)

Many organisations know about this thing called IT Service Management and hear consultants claiming to have the come up with THE silver bullet to take away all your pain, or the new shiny, washes whiter than white approach, but ...this is article is about the things that can go wrong and the successes in the real world.

I would like to discuss some areas where things can go right and be worthwhile, where things can  and have gone wrong (speaking from experience) and what lessons can be learnt.

The initial areas are:

• Resistance to Change
• Implementation of Event and Availability Management
• Major Incident Management

Resistance to Change
Resistance to any type of change can come about through many different ways.

1. – Cultural changes - This can range from the implementation of new team structures or shifts to new management coming in or a reduction in team sizes. Many different areas cover cultural changes and can lead to resistance. We’ll cover this is a bit more detail further on.  

2. – Resistance by customers or users. Change can be seen by customers or users as just another way to make life harder for them, or to remove their favourite support technician from their grasp.  

This is a key area that needs to be addressed as early in the change process as the team members being affected. If you get this wrong at the start, it can take a lot longer to put right later.

3. -  Something I have seen but did not expect was around changes to Service Management toolsets. One of these issues was partially of my own doing and one was at a client site before I started there.  

I’m sure we have all worked somewhere where the main Service Management toolset has not been to everyone’s liking. Either it’s not intuitive, there’s too many fields  / not enough fields, reporting is cumbersome, the screens doesn’t look pretty enough…..

Yet I have been in organisations where changes of toolset have brought about resistance from the most unexpected areas.  Many people just don’t like you to change the tool that they like to complain about. The best way around this resistance is to engage as many people as you can.

Key users will, of course, be involved in the process of understanding what was wrong with the old one and what is trying to be fixed.  These people will be the main inputs into your requirements gathering exercise. (You are doing that, aren’t you?) However, don’t forget to ask the team that use the tool occasionally.   Their input is just as important to the success of the project, as anybody elses.

Also, don’t expect that just because people sign off on a new toolset and agree that it will deliver all of their requirements, that they will be happy. We are dealing with people here.  Of the holy trinity of People, Process and Tool, People are the hardest ones to get right. But also the most important.

Pain
The pain of this resistance to change; what can go wrong?

Poor team spirit
If this isn’t handled correctly, one person’s negative view of a change can bring down the rest of the team’s view.  Too often I have seen a minority, change the majority’s mind-set through continual complaining and negativity.

This poor team spirit has the ability to also be concentrated on the management or leadership of a team. “Why are you allowing this to happen to us?” It may have one positive aspect, of pulling the team together, but if it is still in a negative way then that helps no-one; you still have resistance to the change and that can take months to put right.  

If you discover a negative aspect to somebody’s attitude, address it a quickly as possible. This does not mean that you crush them, but rather you understand the issues and address them in the best way possible.  This might require improved communication or training, or a complete re-evaluation of the approach and change of direction.

Customer Resistance
Potentially the worst of these areas of resistance, however, is a breakdown between the teams and the users or customers.  

This is generally for a couple of reasons:

Your customers won’t talk to or work with the team because of the negative attitudes or disruptive ways of working (see above), or the customer will ignore new ways of working because they “liked the other way”.  

If customers won’t change and they continue to do things like ring their favourite person direct, then that is harder to address.

Many years ago I worked for an organisation where support across multiple sites was being centralised through a single service desk and the on-site support technicians were only supposed to respond to calls through the system.  Of course, all users were told what was happening and why, but for some it made no difference. As a technician, it became difficult because our raison d’etre was to help people. Eventually after few weeks of new processes being ignored by some users and senior IT managers complaining that we were bypassing processes to help these people, we discovered a way forwards. Each user that approached us, we would go and help, but ask them to log the call while we were there.  Next time, we would advise them that they would be there shortly, could they log it. Then a few minutes later, go and help. The next time this happened, we would say the same thing, but as soon as they left to log the call, we would pre-warn the Service Desk and give them hints on likely fixes / knowledge articles. This enabled the Service Desk to fix the call while the user was on the phone, creating a good impression. Within a few short weeks of this type of approach, we managed to get over 95% of “walk-ups” to go via the Service Desk first.   The other 5% took months to train properly!

Good ways to prepare for this are through good planning and considering all ways that the teams might either be, or feel affected.  

The Pleasure

Now, the pleasures of these changes that people can be so resistant to.

If you get your changes right, and bring people, teams and users, along on the journey it can be so fulfilling.  You have improved ways of working which the majority of people within your teams and user or customer base will acknowledge.

You will get respect from your customers, because they can see what you are doing and why. If they understand and respect what you are doing, it will become so much easier to keep the momentum up.  You will be able to demonstrate the improvements.


Implementation of Event & Availability Management
These two are often a pair. It’s unlikely you will do availability reporting without event management.  They provide visibility of what is happening, or going to happen, to support teams and if set up in such a way, to customers as well.  

It can also provide assistance to support teams, to enable them to see what else may be affected in an incident or change.

The Pain
The pain of not having effective event management is something that I would like to guess, we have all been through. As a support team member – Service Desk, technician, problem manager, change manager, IT manager, - you need to know what is going on.  If you don’t have those tools, it can be a nightmare.

The phone rings and a users asks if something is wrong with web access.  Straight away you are on the back foot. Service Desk agent tries it and it works.  Another one tries it and it doesn’t. What’s going on? Is it the site? The computer? The switches? The web monitoring application? The server? Firewall?  (we all like to blame the firewall).

I have seen and been part of teams where it has taken what felt like hours to diagnose the issue before the resolution could be considered.

You have no idea what is happening. What went wrong? The correct SME (Subject Matter Expert) is not around, because they were working late last night doing a change, The majority of the support team are investigating so that they know where to go to fix the issue.

No communication can be sent out because nobody knows the full extent.
You are cuffed and blindfolded.

As for availability management or reporting, how can you tell your customers how wonderful you are if you can’t prove it?

The Pleasure

Get it right however, and it just feels, Good!

Firstly you need to know how you want to do it, and then get your tool in place. Spend the time to define a process and then spend more time getting the tool set up right and it will be worth it.  It is worth noting that it isn’t all about the big expensive shiny tools. There are some very good, cheap and easy to set up ones which deliver just as much for an awful lot less outlay. However, as with anything, you need to understand your requirements before you buy. Free or cheap may suit you, but another organisation may find that they have a need for a large enterprise wide, multi-national tool.

This will enable you to be prepared – most of the time – because your tool should be able to tell you, somehow, when something untoward is starting to occur. Is it a hardware component? Event log? Traffic between 2 points of the network?  You will be able to see it before the users, if all goes well. If you get really good at it, you can even investigate and resolve BEFORE anybody even realised it.

Maintaining them is another. They do not come without an overhead.  Change Management / Projects will need to consider monitoring thresholds, licensing, etc. prior to handing over to Operations and somebody will need to maintain it to ensure that the information received is accurate.

But when done right, they are fantastic.


Major Incident Management
To my mind the three areas, outside of event management, that really improve the way that major incidents are handled, are communication, learning from the incident and being transparent.

In IT, we are not an island. We are a core part of most organisations now, whether they and we like it or not. We have to share what is happening, what we have learnt from the incident and what is going to happen to reduce the chance of it happening again.  Otherwise, how can we even hope to be trusted?

The Pain
I have seen IT teams embrace the opportunity to operate, during major incidents, with heads down in a locked room keeping information secret thereby increasing the chance of recurrence.

The trouble with being like this is that the wider organisation starts to accept that this is the way it is. So they don’t complain formally, they just moan to each other.  

And in fairness to IT, how often do you see a review of a failed marketing campaign? Or a full and frank review of a failed pay run (apart from to blame IT; who ever heard Finance say that they should have had business continuity plans in place because they accepted that the system was not resilient when it was implemented?)

The pleasure

Get it right however and the pleasure is shared amongst all concerned parties.

Communicate with your customers and users. Let them know what is going on, even if that communication is just to say that you are still working on it. Set up lines of communication. Make sure that the technicians working on the fix are left alone to get on with it, but have one person who gets updates. If you commit to telling users every 30 minutes or hour, get an update 10 mins before.  Keep telling people what is happening. AND keep the Service Desk updated.

When the service is restored, carry out a full review. What went well and what didn’t. Keep to the facts. No emotions.  What infrastructure components failed. Can resilience be done better? Should the service be resilient if everyone in the rest of the business was jumping up and down?   Should processes inside or outside of IT be amended? Set actions. Set timeframes. Follow up on them.

Share the outcome with as much of the rest of the business as possible.  If there has been a failure and you have a plan to mitigate the chances of this happening again, tell everyone. If you have a piece of work in place and it is being progressed, but the issue reocurrs sooner than you can finish the remediation, less people are going to complain than if you had done nothing.

Use the incident as a driver for good.

Service Management Life Lessons Learnt
Some key lessons that I have learnt that I would share with you on removing some of the pain from Operations and Service Management.

Don’t be afraid to bring in consultants, but find ones with real world experience.  You probably know what needs to be done, but do you have the time to think it through and implement the change, while also doing your day job? Probably not.

Don't be afraid to take advice and use a mentor. Other people's thoughts are sometimes the clarity you need when the trees are hiding the woods.

Don’t forget to ask the people on the ground what is wrong or what can improve. They have good ideas; often the best ideas.

Ask a lot of questions before starting.

Don’t try and do too much too quickly. Keep going for the “low hanging fruit”. It’s always there and it’s always easier to do that than try and pick all fruit in one day.  Look up Tipu by Rob England.

As a consultant, remember, you don’t know it all. You can learn from each client. Admit it to them and yourself. Also, use your peers. Accept that other people can sometimes do things better, and generally will help.