ISO/IEC 20000 – An Opportunity to Grow

Drago 3This article is a guest post and has been contributed by Drago Topalovic, ITIL & ISO20000 expert.

 

The first thing to consider when implementing best practices and standards in service management is motive.

Why Should We Do It?

When you provide IT services, you have to be the BEST you can. In other IT areas like development, infrastructure, and business system deployment, you can perform slightly under par and still add perceivable value to a customer’s business. In service management, your good performance is usually taken for granted, and every error is highly visible. Service downtimes adversely impact a customer’s business, and SLA breaches are penalized.

Every resource and every configuration item (CI) has to be utilized efficiently. Business processes and functions have to be organized with defined roles, responsibilities, and action sequences. Ambiguities and a lack of definitions and organization promptly lead to user dissatisfaction. So, IT service organizations should take any help they can get.

 

Is ITIL Enough?

ITIL is abundant with best practices, describing life as it should and could be in IT service management. You have all the options laid out in front of you – the sky is the limit. Like living in a big city, you can go to theatres, fancy clubs, and whatnot. But, do you? Living with ITIL alone tends to move you to roads more travelled, and to neglect service management components you don’t feel comfortable with. Knowing your ITIL is good; you can competently implement all the interesting processes and functions, and safely ignore the other ones, knowing that you can turn to them when the time comes.

It differs from one type of service provider to the other, but typical evaded processes in IT are financial management, supplier and customer management, and Documentation management.

For some insight on ITIL benefits, please have a look at the article Why ITIL?.

When you live with ITIL long enough, whether you are a managed services company or internal IT in a small/midsize/large company, you start to realize a few downsides of doing ITIL alone:

  • ITIL certification is personal, and as people come and go, you start to wish for a way to keep your organization’s intellectual property more anchored, instead of being strongly affected by the fluctuation of your staff.
  • With all the options of best practices, it is hard to get the firm management commitment to what really has to be done, and without it, you are on a slippery slope. There are always more urgent things to attend to.
  • ITIL 2011 addresses more processes and functions then before, and implementing all of them seems like mission impossible.
  • It is really difficult to say when enough is enough.

Once you have improved those processes that cause you the most pain, you may realize that your focus shifts to things you didn’t consider important at first. For example, you implement Incident and Change management, and it suddenly becomes obvious to you that your Configuration management lacks the power to support these processes. That’s a good sign that your organization is growing. And, it’s usually a sign that you should start considering ISO/IEC 20000.

 

ISO20000 – An Opportunity to Grow

ISO/IEC 20000 provides a very strict set of requirements for implementation. The scope can prove to be very demanding for most of the growing IT service companies in the beginning. But, as you mature, you start to consider the advantages of a service management system that takes care of what SHALL be done in order to make you a competent IT service management organization, as opposed to what could or should be done.

At some point, this set of opportunities will start to feel more appealing to an organization.

SMS
ISO/IEC 20000 process groups

 

ISO 20000 Benefits

By implementing ISO/IEC20000, the organization benefits from the following:

 

  • Integrated Service Management System (SMS) supporting the vital service management functions.
  • Organization focuses on all key processes. Measurements and control of integrated SMS brings new perspectives and ideas about organization’s service management business. Since all 16 processes are implemented, combined results from say, Budgeting and accounting with Capacity management will give you the better idea on which customers are more valuable to you.
  • Better alignment of IT services and the business it supports. Adopting the common language and the knowledge about processes usually helps in building trust and confidence of customers.
  • Better reputation on the market. Having an ISO20000 certificate is still not a very common thing; it proves you are serious about your business.
  • ISO/IEC 20000 certificate stays with the company, not individuals. The SMS helps to keep knowledge about service management business within the company, as its intellectual property.
  • Roles, responsibilities, and ownership of all processes remove bottlenecks and ambiguities in service management domain.
  • By defining key processes and agreeing about them internally, ISO20000 helps to overcome natural barriers between organizational units. For example, Sales is forced to cooperate more tightly with internal IT in order to offer more cost-effective services to external customers.
  • Vertical communication in the organization is usually greatly enhanced. Management is involved in the process from the beginning, and the feedback they receive regularly enables better quality of tactical and strategic decisions.

 

I am fully aware that the above benefits are primarily aligned with an IT management perspective. These are the pains immediately recognized by the IT members of the community. So, I intend to provide a separate post where they will be properly addressed from a business point of view. I would love to see some of the visitors’ comments regarding this.

 

Conclusion

The certification process for ISO/IEC 20000 is not an easy one. It’s a very demanding project, requiring a lot of resources. That is one of the major reasons it is not a common certificate. On the other hand, this makes it even more appreciated on the market.

If you are an experienced IT organization with good internal knowledge of key ITIL processes, the above-mentioned benefits should be inspiring to consider ISO20000. From my experience, it looks harder than it is. Just take the first step.

 

 


Drago is an IT Business Consultant oriented to Service Management and Customer Relationship Management, project management in SW development.

Specialties: ITIL Expert certificate, Implementation of service management tools, methodologies and processes. Preparation and implementation of ISO/IEC 20000.

You can follow Drago on Twitter here

 

Running Your Change Management Process

"When implementing Changes it’s not just a case of hitting a bit red button and shouting “fly my pretties, fly” to an imaginary army of flying monkeys"
“When implementing Changes it’s not just a case of hitting a bit red button and shouting “fly my pretties, fly” to an imaginary army of flying monkeys”

Following on from my previous post about surviving implementation, here’s some advise on running your Change Management process aka The Day Job.

In Change Management your key areas to focus on are:

  • Recording and processing the Change
  • Change assessment
  • Change Advisory Board (CAB)
  • Build and Test
  • Implement
  • Review

Raising the Change

So first up; recording the Change. Ensure your Change Management policy covers who can request a Change i.e. can anyone raise a Change? Just IT? What about the business? Each organisation will be different but one thing to keep in mind is making sure your policy gives clear guidelines on the difference between a Change and a Service Request i.e. with Request Fulfilment ends and where Change Management begins.

Create a Change form so that Changes can be raised in a standard way. It’s really important to have consistent information in your Change requests so when reviewing and approving Changes, you have all the facts needed to make the right decision for your customers. If you have a sparkly, all powerful toolset to do it for you then happy days. If not, and there are lots of organisations just getting started with Change Management, then it’s time to get creative. In the past, I’ve set up Change request forms using Word or Excel (tweet me if you would like to see some examples).

Things to consider for your form:

  • —  Title
  • —  Description
  • —  Reason
  • —  Service affected
  • —  Impacted Cis
  • —  Will the CMDB (if you have one)  need to be updated afterwards
  • —  Risk
  • —  Implementation windows
  • —  Implementation teams
  • —  Pre implementation testing
  • —  Implementation plan
  • —  Post implementation verification
  • —  Back out plan
  • —  Impact to other environments
  • —  Will the change be replicated to your DR environment?

You need to have a lifecycle approach for raising Changes for example; the process for a standard Change will be very different to an emergency, sorting something out in the middle of the night type Change. Ensure this ties back in to your policy with criteria and examples so there’s no confusion.

Look at how Changes are classified and prioritised. If every Change is urgent, high priority, which one do you implement first? Classification is also really important – make your Change owners accountable for risk and impact assessments. If your company or Change Management tool has a Risk calculator use it  as it enables  Change requestors to assign a tangible risk to the Change (it removes the “if in doubt click medium” behaviour type) if not, I have some templates that I can share.

Change Assessment

Next up is our old friend, the Change Assessment stage. This is the initial check that the Change is reasonable and makes sense, a sanity check if you will. Sounds obvious but unfortunately you can’t teach common sense. On one memorable occasion, I was reviewing a list of Changes on my pre-CAB FSC and one jumped out at me. The Change was to move a business critical server from a secure Data Centre environment to the Server technician’s desk. The Change justification? “My little legs are getting tired from walking to the server room all the time”. Needless to say words were had and the Change was removed from the schedule (I just wish I’d taken a screen shot).

Things to bear in mind when assessing a Change are benefits, both technical and to the business. There’s no point in having the newest most gadgetastic server is the world if your end users don’t see any benefit from it. Really think about the risk involved with the proposed activity for example:

  • Number of people affected
  • Financial
  • Regulatory
  • Reputational
  • Loss of productivity
  • Downtime
  • Seasonal considerations

Make sure you have clear assessment criteria for managing Changes. Some examples could include:

  • Pre implementation testing – how do we know this Change will go as planned?
  • Deployment plan – does it make sense, if other teams are involved are they aware and do we have contact details for them? Are there any dodgy areas where we might need check point calls or additional support to mitigate risk?
  • Post implementation verification – ok we’ve done the Change, how do we make sure everything is as it should be?
  • Back out plan – hope for the best but prepare for the worst. What happens if something goes wrong on the night? Do we fix on fail or roll back? Are the Change implementers empowered to make a decision or is escalation needed?
  • Impact to other environments – “who cares about other environments?” I hear you ask. Let Aunty Vawns tell you why it matters from personal experience. Once upon a time in a galaxy far, far away I worked for a large investment bank in the city. A code Change to one of the most business critical systems (the market data feed to our trade floors) took longer than expected so instead of updating both the production and DR environments, only the production environment was updated. The implementation team planned on updating the DR environment but got distracted with other operational priorities. Fast forward to 6 weeks later, a crisis hits the trading floor, the call is made to invoke DR but we couldn’t because our market data services were out of sync. Cue a hugely stressful 2 hours where the whole IT organisation and its mum desperately scrambled to find a fix and an estimated cost to the business of over $8 million. Lesson more definitely learned that day.

The CAB

So we’ve raised our Change and sanity checked it to make sure what we’re planning on implementing is sensible and won’t, you know, set anything on fire. The next step is the Change Advisory Board or CAB. When setting up your CAB, make sure you have a clear Terms of Reference statement which will give attendees a steer on how to prepare, good meeting behaviours and how to represent Changes effectively.

Not every Change has to go to CAB. In fact, I’d say you should use CAB for your big, complicated Changes that would have a major impact on the business. Monthly, BAU server patching? That’s a candidate for a standard Change. Keep CAB simple and uncluttered with an agenda that deals with Changes that are high risk, major impacting or have lots of complicated detail. Make sure the right people turn up and that all areas are represented (don’t forget Security if you have any ISO 27001 or NGN regulatory requirements).

An effective CAB agenda could look something like this:

  • Review of implemented Changes
  • Incidents (or if time is short Major Incidents) caused by Change
  • Lessons Learned
  • Forward schedule of Change
  • Candidates for templates / standard Changes
  • Improvements / CSI
  • Good news stories

Remember, CABs don’t have to be a 2 hour meeting where everyone is locked in a conference room. Look at Agile or Lean on how you can make efficiency savings, consider virtual Cabs where you can approve most things via your toolset and make full use of technology such as conference calls, WebEx’s or Skype.

The next stage of the process is Build & Test. The first thing to look at is developing standard build methods. Use automation where appropriate, it saves duplication work, reduces the probability of human area and the economies of scale can be huge. If automation is too expensive, ensure build methods are well documented and templated where possible.

Look at your testing environments and ensure they are fit for purpose. Every organisation will have different needs but when looking at this – do you have enough to cover your operational work eg a live environment for production work, a DR environment in case the worst happens and an environment dedicated to testing and training? If you are limited do you have a booking system in place so that testing / training / dev time can be allocated fairly?

What about Changes to non production environments? Are they covered by your Change process? Is there a monthly environment refresh just in case?

How do you test Changes before go live. Is it Bob from the Server team saying – “this’ll do” or so you have something more formal in place. Are the business willing to help support with Change testing? Getting the business to support testing can have huge benefits. One client I worked with has huge challenges with keeping the Marketing department happy with Changes that they had requested to the company website. The Marketing team didn’t provide any post Change validation and the amount of backed out Changes to the website or emergency Changes to fix errors such as typos were common place. By engaging with the Marketing team and asking for someone to be available for a set 20 minute period of the Change window (we called it the smoke testing phase) our effectiveness increased and so did our customer engagement.

When implementing Changes it’s not just a case of hitting a bit red button and shouting “fly my pretties, fly” to an imaginary army of flying monkeys (although that would be so cool). A professional approach and great communication are key to making this stage a success.

First up, your Change Schedule (aka your Forward Schedule of Change or FSC). Make sure it’s easily accessible to your stakeholders so stored somewhere central that’s easy to navigate. Make sure it’s dynamic and relevant – otherwise you risk your data being obsolete within minutes of hitting the print button. Make sure it’s fit for purpose, states what Changes are being carried out, when and by which Service. You don’t need expensive toolsets for this; you can do it in Excel.

Something that goes hand in hand with your FSC is your Projected Service Availability or PSA. Yes, I know ITIL 3 insists on calling it a PSO (Projected Service Outage) but lets not frighten the horses. Planned Service Availability implies we’ve got this. Everything is planned, tested and safe; you have nothing to worry about. In contrast PSO just says downtime. What do our customers not like? Downtime – no matter how well planned out. Again, Excel can be your friend here, keep it simple, a list of your Services – green for those that are up and running, amber for those due some maintenance time.

When looking at Change windows ensure they have been agreed in advance with the business and that they are codified as maintenance windows on any SLAs. Try and negotiate pre-approved Change slots where possible eg the third Thursday of every month between 22:00 and 01:00 we will be doing security patching. If you know in advance that a Change needs to take place outside the usual Change window – ask nicely! If you’re really good you might be able to get some SLAs relaxed so that as an organisation, you’re not penalised for carrying out break / fix work.

Change Reviews

Finally, we have the Review stage. We’ve done our Change and everything has (hopefully) gone to plan. So let’s carry out a review of our implemented Changes. When things go well, brilliant! You have new candidates for standard Changes, work instructions or templates. If things go badly or you really do end up setting something on fire then let’s look at how we can do better next time. Carry out a Change review to look at what happened, what went wrong, what was the root cause, how did we fix it and how do we stop it from happening again? Involve Incident & Problem Management here as they have super powers in these areas. Above all you want your lessons learned to be captured, discussed and acted on. This could be a regular agenda at CAB meetings or form part of a Service Improvement Plan or SIP.

When reviewing Changes look at the benefits. In terms of business benefits, did we achieve the expected results? Have we got any customer feedback? We also need to look at the technical benefits i.e. have we increased stability, added resilience or fixed any Known Errors. If we have – brilliant – tell the Service desk so they can let our customers know.

Final Points

I’d like to finish by saying that Change Management really is a critical process for managing controlling and protecting your live environment. As Change Managers we get to ask all the hard or awkward questions but on the bright side, we’re usually the first to know about cool new projects or sparkly new gadgets. Keep smiling, it will be fine. And if it isn’t, tweet me, I’m always happy to help!

Image Credit

How do you resurrect your processes?

Ensure processes become stepping-stones instead of stumbling blocks for your organization
Ensure processes become stepping-stones instead of stumbling blocks for your organization

Let’s face it, processes are boring at best ­ necessary yes, but not something that gets people out of bed in the morning.

Maybe it is the control it tries to exert on the masses ­ like an authoritarian adult trying to keep the kids under control. We are all a rebellious lot ­ and the same goes for our rocky relationship with processes. Unfortunately, we can’t really live without them. The best and brightest might, because they will do the right thing in spite of process, but for the other 90% of us and for the sake of scalability, there needs to be clear guidelines.

Common process pitfalls

There are some common pitfalls for business around processes.

1. People need to feel that it ‘works’ for them. In other words, they have to see that a process makes a difference, for the better, to their day-to-day operations. There is no point in creating elaborate, complex processes just for the sake of it, or to make you feel that you’ve earned that ITIL badge, or justify that expensive BPM course.

The whole purpose of a process is to break down something complex, into manageable steps for everyone to understand and follow, thereby ensuring consistent work practice.

2. If you cannot measure whether process is being followed, there is no point in having it. You won’t be able to confirm that it is working, and you won’t be able to improve, because you won’t have any baseline. Without continually refining and improving your processes ­ based on real world feedback ­ they will become obsolete, because people will either not follow them at all, or create their own ‘parallel process universe’.

3. People need to understand how a process supports the organization’s policies. If the process doesn’t enable compliance to company policy it is doing more harm than good ­ this is pretty obvious, but it is surprising how many times this happens, especially at micro or team level. People do what they consider to ‘work’ for them, but in the process they have cut the oxygen cord to the mothership…

So, what are some strategies and practical tips to ensure processes become stepping-stones instead of stumbling blocks for your organization?

Below I will briefly outline each of the components, with a common example to clarify the concepts from a practical/real world perspective.

Company Policy & Process

Start with your company policy; make sure that your process 100% supports it. The next step is to outline and briefly describe each step in the process so that people can see how and what each individual step is about and how it supports the company’s policies. Without this as a starting point your process is not worth the paper it is printed on…please don’t laminate it and stick it next to someone’s cubicle. It won’t make any difference.

Example: Company policy specifies that customers can raise a major incident or outage, and that the company will respond within 30 minutes of the incident being logged.

To reflect this policy, a major incident process step must exist in the company’s incident management process.

Work Instructions

Once you have described the steps in your process you should be able to easily identify the different work Instructions you could create to guide and educate staff on the process. Work instructions are critical for training and reference in case someone doesn’t understand how to put something into practice. Work instructions will potentially drive back towards fueling your continual improvement.

People will often not question high level process, or make suggestions at a high or abstract level about how they can improve their day to day operations. However, put something practical and lower level that they deal with every day in front of them, and they will very quickly tell you why it doesn’t work. You can then simply ask them what should be done differently with the work instruction as a practical reference, which then feeds back to process improvement. This takes continual improvement to the people, instead of leaving it with the analysts.

Example: A work instruction exists that outlines the steps a Support Consultant will follow in order to manage a major incident to completion, including escalation and communication channels within the business.

Business Rules

And, finally, for each step, document the business rules. Why is this important? To make sure you can map your processes to technology, and to ensure technology (ITSM software and tools), supports your business. This is a critical success factor, especially when choosing a new or improving an existing ITSM solution.

Example: A business rule specifies that an email alert is triggered to an executive email group when a major incident is logged, and again 15 minutes prior to the SLA of 30 minutes being breach ­ if no contact has been made to the customer.

Tip: Be careful not to document the business rule in too technical terms, i.e. how it relates to the technical aspects of the ITSM tool ­ make sure it is independent from how it is implemented in the tool. For example, don’t document the triggers and tool configurations you need to deliver the rule, otherwise your process documentation will have to be revised should your ITSM tool be updated or changed.

In summary

As the saying goes, a picture is worth a thousand words, so let’s summarize with a diagram:

Process_Rules

  • Make sure your process backs your policies.
  • Describe your process steps.
  • From the process step’s description, derive work instructions for each step.
  • Document the business rules related to each step.

And, finally, give your most important asset in continual improvement (yes, people), something practical to chew on, namely work instructions, thereby providing them with easily identifiable building blocks in your continual improvement framework.

Image Credit

ITSM User Personas

Persona: "the aspect of someone’s character that is presented to or perceived by others"

During my time in IT Service Management I’ve read my fair share of process and policy documentation. In fact, I think I’ve had the misfortune to read more than my fair share.

Process documentation is important, don’t get me wrong. Without someone taking the time to write down the intention, expected steps, outcome and quality checks within a module of work you don’t really have a process at all.

I was having a conversation this week with someone that was sure they had a process for something. It transpired that what they had was an unwritten set of best practices that everyone understood and followed. The outcome was actually fairly good and repeatable but by no sensible definition was this a process.

In fact the moment of realisation came when I asked if the best practices had changed over time. Of course they had as the team had learned and improved itself. But without proper documentation outlining the new steps to take nothing was truly repeatable. There was no real process.

Lean Process Documentation?

So, I am an advocate of writing documentation to support a process. But does it have to be so verbose, heavy in language, formal… and lets be honest. Boring?

Lean principles teach us how to identify “waste”. Any more than the responsible minimum is waste. Do we actually need to include difficult to read text in our process documentation? If they don’t add value to the reader surely they are wasteful and can be removed?

There are some practices that I use in my role in product development that I think would be really useful to IT Service Management professionals that are willing to take a fresh look at their process documentation.

User Personas in Action

A user persona is a method of representing an individual that is involved in a process. For example in your Change Management process you will have a number of different people to think about:

  • The person requesting the change
  • The person that peer reviews
  • The approver
  • The person implementing the change
  • The person who does a post implementation review

Each of these people have different requirements, concerns and objectives when working within the Change Management process. Does your process documentation accurately represent these people?

Each user persona should fit on a single side of A4 – An example, ‘Angie – Change Manager’ is below.

User personas represent real people within the process and I’d recommend using photos of your actual users. It’s a powerful thing in design meetings to have a set of personas pinned up on the wall and to actually see the faces of the people you are making decisions on behalf of.

Each persona has a short summary and then four sections.

  • What she’s thinking
  • What she’s hearing
  • What she’s saying
  • What she’s doing

The sections show the users concerns (“thinking”), the conversations that other people would start with her (“hearing”), the conversations she would start with others (“saying”) and her day-to- day actions within the process.

ITSM Caricatures

A persona should be a “caricature” of the different people that act the part within your process. You might seek out these people and interview them to discover what they are thinking, saying, hearing and doing. If you interview 4 different Change Managers and discover that they all have different concerns your “Angie the Change Persona” would be a representation of a person that has ALL of the concerns. You are aiming to discover the extreme points of view that these people exhibit and document them.

We try and use personas throughout our product development process – when we design a process defining these is a critical early step and we rely on them during Acceptance Testing to ensure we are getting feedback from all people.

Back2ITSM Personas

A few months ago I mentioned personas in the Back2ITSM Facebook group and got a good response. As a community resource I’d love to see a set of User Personas that cover all the roles in common ITSM processes. Imagine knowing that you need to write a new process for Configuration Management. Heading over to Back2ITSM to download a set of user personas for each role in the process would be a huge head start.
I’d love to see process documentation move away from mimicking legal documents with reams of dense text and move towards a more user centric representation of users requirements and concerns.

After all – your process affects real people. Lets find out who they are at the design stage and make the process more suitable for their needs.

Image Credit

The RBS Glitch – A Wake Up Call?

More than a fortnight (from the last couple of weeks of June) after a “glitch” affected Royal Bank of Scotland (RBS), Natwest and Ulster Bank accounts, the fall-out continues with the manual processing backlog still affecting Ulster Bank customers.

Now, the Online Oxford Dictionary defines a glitch as:
a sudden, usually temporary malfunction or fault of equipment

I don’t think anyone affected would see it in quite the same way.

So when did this all happen?

The first I knew about was a plaintive text from a friend who wanted to check her balance, and could not because:
“My bank’s computers are down”
By the time the evening rolled around, the issue was becoming national news and very clear that this was more than just a simple outage.

On the night of Tuesday 19th June, batch processes to update accounts were not being processed and branches were seeing customer complaints about their balances.

As the week progressed, it became clear that this was no simple ‘glitch’, but the result of some failure somewhere, affecting 17 million customers.

What actually happened?

As most people can appreciate, transactions to and from people’s accounts are typically handled and updated using batch processing technology.

However, that software requires maintenance, and an upgrade to the software had to be backed out, but as part of the back out, it appears that the scheduling queue was deleted.

As a result, inbound payments were not being registered, balances were not being updated correctly, with the obvious knock on effect of funds showing as unavailable for bills to be paid, and so on.

The work to fix the issues meant that all the information that had been wiped had to be re-entered.

Apparently the order of re-establishing accounts were RBS first, then NatWest, and customers at Ulster Bank were still suffering the effects as we moved into early July.

All the while news stories were coming in thick and fast.

The BBC reported of someone who had to remain an extra night in jail as his parole bond could not be verified.

House sales were left in jeopardy as money was not showing as being transferred.

Even if you did not have your main banking with any of the three banks in the RBS group, you were likely to be effected.

If anyone in your payment chain banked with any of those banks, transactions were likely to be affected.

Interestingly enough, I called in to a local branch of the one of the affected banks in the week of the crisis as it was the only day I had to pay in money, and it was utter chaos.

And I called in again this week and casually asked my business account manager how things had been.

The branches had very little information coming to them at the height of the situation.

When your own business manager found their card declined while buying groceries that week, you have to wonder about the credibility of their processes.

Breaking this down, based on what we know

Understandably, RBS has been reticent to provide full details, and there has been plenty of discussion as to the reasons, which we will get to, but let’s start by breaking down the events based on what we know.

  • Batch Processing Software

What we are told is that RBS using CA Technologies CA-7 Batch processing software.

A back-out error was made after a failed update to the software, when the batch schedule was completely deleted.

  •  Incidents Reported

Customers were reporting issues with balance updates to accounts early on in the week commencing 20th June, and soon it became clear that thousands of accounts were affected across the three banks.

Frustratingly some, but not all services were affected – ATMs were still working for small withdrawals, but some online functions were unavailable.

  •  Major Incident

As the days dragged on, and the backlog of transactions grew, the reputation of RBS and Natwest particular came under fire.

By the 21st June, there was still no official fix date, and branches of NatWest were being kept open for customers to be able to get cash.

  •  Change Management

Now we get to the rub.

Initial media leaks pointed to a junior administrator making an error in backing out the software update and wiping the entire schedule, causing the automated batch process to fail.

But what raised eyebrows in the IT industry initially, was the thorny subject of outsourcing.

RBS, (let me stress like MANY companies), has outsourced elements of IT support off-shore.

Some of that has included administration support for their batch processing, but with a group also still in the UK.

Many of these complex systems have unique little quirks.  Teams develop “in-house” knowledge, and knowledge is power.

Initial reports seemed to indicate that the fault lay with the support and administration for the batch processing software, some of which was off-shore.

Lack of familiarity with the system also pointed to perhaps issues in the off-shoring process.

However, in a letter to the Treasury Select Committee, RBS CEO Stephen Hester informed the committee that the maintenance error had occurred within the UK based team.

  •  Documentation

The other factor is human need to have an edge on the competition – after all, knowledge if power.

Where functions are outsourcers, there are two vital elements that must be focussed on (and all to often are either marginalised/ignored due to costs):

1)      Knowledge Transfer

I have worked on many clients where staff who will be supporting the services to be outsourced are brought over to learn (often from the people whose jobs they will be replacing).

Do not underestimate what a very daunting and disturbing experience this will be, for both parties concerned.

2)      Documentation

Even if jobs are not being outsourced, documentation is often the scourge of the technical support team.  It is almost a rite of passage to learn the nuances of complex systems.

Could better processes help?

It is such a negative situation, I think it is worth looking at the effort that went into resolving it.

The issues were made worse by the fact that the team working to resolve the problem could not access the record of transactions that were processed before the batch process failed.

But – the processes do exist for them to manually intervene and recreate the transactions, albeit die to lengthy manual intervention.

Teams worked round the clock to clear the backlog, as batches would need to be reconstructed once they worked out where they failed.

In Ulster Bank’s case, they were dependant on some NatWest systems, so again something somewhere must dictate the order in which to recover, else people would be trying to update accounts all over the place.

Could adherence to processes have prevented the issue in the first place?

Well undoubtedly.  After all, this is not the first time the support teams will have updated their batch software, nor will it have been the first time they have backed out a change.

Will they be reviewing their procedures?

I would like to hope that the support teams on and off shore are collaborating to make sure that processes are understood and that documentation is bang up-to-date.

What can we learn from this?

Apart from maybe putting our money under the mattress, I think this has been a wake up call for many people who, over the years, have put all their faith in the systems that allow us to live our lives.

Not only that, though, but in an environment where quite possibly people have been the target of outsourcing in their own jobs, it was a rude awakening to some of the risks of shifting support for complex integrated systems without effective training, documentation, and more importantly back up support.

Prior to Mr Hester’s written response to the Treasury Select Committee, I had no problem believing that elements such as poor documentation/handover, and a remote unfamiliarity with a system could have resulted in a mistaken wipe of a schedule.

What this proves is that anyone, in ANY part of the world can make a mistake.

Request Fulfilment in ITIL 2011

"ITIL 2011 sees a hefty revision for the Request Fulfilment process."

What is it?

The ITIL® Request Fulfilment process exists to fulfil Service Requests – for the most part minor changes or requests for information.

Request Fulfilment landed on us in ITIL v3 when there was now a clear distinction between service interruptions (Incidents) and requests from users (Service Requests for example password resets)

And what does ITIL 2011 give us?

ITIL 2011 sees a hefty revision for the Request Fulfilment process.  There are more detailed sub-processes involved with steps broken down logically.

Now, I like me a good diagram and finally Request Fulfilment gets a decent flow and most importantly the linkages to other interfaces to the other lifecycle stages are included in a lot more detail.

Perhaps the most impressive thing is far more detail in the section about the Critical Success Factors (CSFs) and Key Performance Indicators (KPIs) that have been included.  Having experienced the hilarity of definitions of over-complex metrics – this is a good starter for 10, straight off the bat and of course can be added to suit an organisation’s needs.

But what does all this REALLY mean?

It means nothing if the best practices cannot be applied and adapted into real life.

  • Now we all know that at the back of a Service Request is a process that will step through authorisation, any interfaces to other processes etc., but the business value is to provide a quick and easy way for end users to get new services.
  • A mechanism to reduce costs through centralising functions.
  • Understand what other stages of the lifecycles are needed alongside Request Fulfilment – this does not happen in glorious isolation.

Is there such a magic bullet?

The simple answer?  NO!

But there are a few things that should be taken into consideration when looking at implementing Request Fulfilment (often as part of an integrated solution).

Let’s look at the easy stuff first:

  • Look at starting nice and easily with simple Request Models that will happen often, and can be met with a consistently repeatable solution.
  • Look at what kind of options you are going to put in front of the user.  Most people are now familiar with the type of shopping basket type approach through the internet so offer them a familiar interface, with as many options that can be pre-defined
  • Make sure that the different stages of the request can be tracked – the purpose is two-fold:
    • End users don’t get (as) ratty
    • Reporting and routing can be made simpler and more accurate with meaningful status definitions

Getting the hang of this…

  • Give some thought to how you want to prioritise and escalate requests depending on their complexity to fulfil, and again pre-define where possible.

Let’s do the whole shebang…

  • Eventually there will be a need to include financial approval(s) which in turn means sticky things like deputies and budget limits
  • There may also be external interactions with fulfilment groups dealing with procurement

Back up a second – who now?

  • Give some thought to which groups are going to be involved.  In my experience it is sometimes easier to work backwards, from the outcome to the selection and fill out all the bits you need in between.
  • Easy stuff is most likely taken care of by a single, often centralised group – typically the Service Desk, or in some cases specific co-ordinators who work at that Level One tier.
  • Decide if your existing resolver groups are appropriate for some fulfilment tasks or where you need specialised groups and build your workflows to suit.  Typically the first-line support group handling the request always has the ability to track the progress of the request, and is the point of contact for the end users.

Is that it?

  • Whether your request is a simple How Do I to a Hand craft me a personally engraved and gift wrapped iPad the request needs a defined closure procedure.  There has to be a mechanism to validate that the request has been fulfilled satisfactorily before it is closed.

How do we go about deciding what works and what doesn’t?

There is something I will state, use and promote constantly, and that is the use of scenarios.  These are invaluable whether you are testing a deployment, performing user-acceptance testing with a client, or whether you are just evaluating products.

  • Decide on what criteria you need to establish your end goal
  • Break them down to manageable steps, and here the ITIL 2011 activities and points are very nicely presented to give a starter for ten
  • For a product review, for example, look at how easy it is to configure – can I do this myself using demos on the web, or do I need a proper demo on site/webinar with a tool administrator
  • As an aside, what kind of administrative skill is required for your tool of choice?

This is a doddle, no?

A number of things can kill an otherwise promising and/or straightforward deployment:

  • Poorly defined scope – People wanting the process to do too much or not really grasping the idea that Service Request models should be pre-definable, and consistently repeatable.
  • Poorly Designed User Interfaces – The best back end workflows in the world will not help you if the user interface makes no sense to an end user.  Too often I have banged my head against a desk with developers who love how THEY understand what is being asked, so who cares if some desk jockey can’t – they can ring the help desk, right?  WRONG!  Missing the entire point of the business benefits for removing the need to drive everything through 1-2-1 service desk interaction.
  • What is worse than a front end you need a degree in programming to work through?  Haphazard back end workflow that twists and turns like a snake with a stomach upset.  Just keep it simple.  Once it starts to get super-complex, then really ask yourself is this a minor request or something that requires specific change planning.
  • Make sure your tool of choice is capable of measuring meaningful metrics.  Remember, there are lies, damned lies and statistics.  What are you looking to improve, why, what is the benefit, and what can it lead to in terms of Continual Service Improvement

There are, of course, interactions that I haven’t gone into any great level of detail in this article; but do look at one of our latest articles by  Rob England has already touched on this in: What is a Service Catalogue? here on The ITSM Review.

Image Credit

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.

A Great Free ITSM & ITAM Process Tool (via #Back2ITSM)

Cognizant Process Model
Cognizant Process Model

This is a very cool online tool for anyone in ITAM or ITSM.

COGNIZANT PROCESS MODEL

This great resource was kindly shared by Shane Carlson of Cognizant.

Shane is a founding member of the #Back2ITSM community, whereby ITSM professionals are encouraged to share their expertise for the benefit of others (and therefore develop the industry).

The process model includes the following models:

  • Request Management
  • Incident Management
  • Event Management
  • Problem Management
  • Change Management
  • Configuration Management
  • Release Management
  • Service Level Management
  • Availability Management
  • Capacity Management
  • IT Service Continuity Management
  • Continuity Operations
  • Financial Management for IT Services
  • Asset Management
  • Service Catalog
  • Knowledge Management
  • Information Security Management
  • Security Operations
  • Access Management
  • Portfolio Management
  • Program and Project Management

Each module includes guidance on the following areas:

  • Process Diagram
  • Benefits
  • Controls
  • Goal
  • Metrics
  • Policies
  • Process Team
  • Resources
  • Roles
  • Scope
  • Specification

According to the blurb….

“PathFinder is specifically designed to those:

  • Tasked with designing an IT Process.
  • Seeking validation that a process has been validated in the industry.
  • Looking to increase effectiveness of their current process design.
  • Seeking assistance with the cultural adoption of their IT process.
  • Faced with meeting compliance regulations.”

VIEW THE COGNIZANT PROCESS MODEL

Thanks to Shane for sharing this great free resource.

Yes, free. No registration, no 30 day trial, no salesman will call. Enjoy! If you find it useful please share the link and don’t forget to mention #Back2ITSM.

Planning for Major Incidents

Do regular processes go out of the window during a Major Incident?

Recently I’ve been working on Incident Management, and specifically on Major Incident planning.

During my time in IT Operations I saw teams handle Major Incidents in a number of different ways. I actually found that in some cases all process and procedure went out of the window during a Major Incident, which has a horrible irony about it. Logically it would seem that this is the time that applying more process to the situation would help, especially in the area of communications.

For example in an organisation I worked in previously we had a run of Storage Area Network outages. The first couple caused absolute mayhem and I could see people pushing back against the idea of breaking out the process-book because all that mattered was finding the technical fix and getting the storage back up and running.

At the end of the Incident, once we’d restored the service we found that we, maybe unsurprisingly had a lot of unhappy customers! Our retrospective on that Incident showed us that taking just a short time at the beginning of the outage to sort out our communications plan would have helped the users a lot.

ITIL talks about Major Incident planning in a brief but fairly helpful way:

A separate procedure, with shorter timescales and greater urgency, must be used for ‘major’ incidents. A definition of what constitutes a major incident must be agreed and ideally mapped on to the overall incident prioritization system – such that they will be dealt with through the major incident process.

So, the first thing to note is that we don’t need a separate ITIL process for handling Major Incidents. The aim of the Incident Management process is to restore service to the users of a service, and that outcome suits us fine for Major Incidents too.

The Incident model, its categories and states ( New > Work In Progress > Resolved > Closed ) all work fine, and we shouldn’t be looking to stray too far from what we already have in terms of tools and process.

What is different about a Major Incident is that both the urgency and impact of the Incident are higher than a normal day-to-day Incident. Typically you might also say that a Major Incident affects multiple customers.

Working with a Major Incident

When working on a Major Incident we will probably have to think about communications a lot more, as our customers will want to know what is going on and rough timings for restoration of service.

Where a normal Incident will be handled by a single person (The Incident Owner) we might find that multiple people are involved in a Major Incident – one to handle the overall co-ordination for restoring service, one to handle communications and updates and so on.

Having a named person as a point of contact for users is a helpful trick. In my experience the one thing that users hate more than losing their service is not knowing when it will be restored, or receiving confusing or conflicting information. With one person responsible for both the technical fix and user communications this is bound to happen – split those tasks.

If your ITSM suite has functionality for a news ticker, or a SocialIT feed it might be a good idea to have a central place to update customers about the Major Incident you are working on. If you run a service for the paying public you might want to jump onto Twitter to stop the Twitchfork mob discussing your latest outage without you being part of the conversation!

What is a Major Incident

It is up to each organisation to clearly define what consitutes a Major Incident. Doing so is important, otherwise the team won’t know under what circumstances to start the process. Or you might find that without clear guidance a team will treat a server outage one week as Major (with excellent communciations) and not the next week with poor communications.

Having this defined is an important step, but will vary between organisations.

Roughly speaking a generic definition of a Major Incident could be

  • An Incident affecting more than one user
  • An Incident affecting more than one business unit
  • An Incident on a device on a certain type – Core switch, access router, Storage Area Network
  • Complete loss of a service, rather than degregation

Is a P1 Incident a Major Incident?

No, although I would say that every Major Incident would be a P1. An urgent Incident affecting a single user might not be a Major Incident, especially if the Incident has a documented workaround or can be fixed straightaway.

Confusing P1 Incidents with Major Incidents would be a mistake. Priority is a calculation of Impact and Urgency, and the Major Incident plan needs to be reserved for the absolute maximum examples of both, and probably where the impact is over multiple users.

Do I need a single Incident or multiple Incidents for logging a Major Incident?

This question might depend on your ITSM toolset, but my preference is to open a separate Incident for each user affected in the Incident when they contact the Servicedesk.

The reason for this is that different users will be impacted in different ways. A user heading off to a sales pitch will have different concerns to a user just about to go on holiday for 2 weeks. We might want to apply different treatment to these users (get the sales pitch user some sort of service straight away) and this becomes confusing when you work in a single Incident record.

If you have a system of Hierarchical escalation you might find that one customer would escalate the Major Incident (to their sales rep for example) where another customer isn’t too bothered because they use the affected service less frequently.

Having an Incident opened for each user/customer allows you to judge exactly the severity of the Incident. The challenge then becomes to manage those Incidents easily, and be able to communicate consistently with your customers.

Is a Major Incident a Problem?

No, although if we didn’t have a Problem record open for this Major Incident I think we should probably do so.

Remember the intended outcome of the Incident and Problem Management processes:

  • Incident Management: The outcome is a restoration of service for the users
  • Problem Management: The outcome is the identification and possibly removal of the causes of Incidents

The procedure is started when an Incident matches our definition of a Major Incident. It’s outcome is to restore service and to handle the communication with multiple affected users. That restoration of service could come from a number of different sources – The removal of the root cause, a documented Workaround or possibly we’ll have to find a Workaround.

Whereas the Major Incident plan and Problem Management process will probably work closely together it is not true to say that a Major Incident IS a Problem.

How can I measure my Major Incident Procedure?

Simon Morris

I have some metrics for measuring the Major Incident procedure and I’d love to know your thoughts in the comments for this article.

  • Number of Incidents linked to a Major Incident: Where we are creating Incidents for each customer affected by a Major Incidents we should be able to measure the relative impact of each occurance.
  • The number of Major Incidents: We’d like to know how often we invoke the Major Incident plan
  • Mean Time Between Major Incidents: How much time elapses between Major Incidents being logged. This would be interesting in an organisation with service delivery issues, and they would hope to see Major Incidents happen less frequently

There you go. In summary handling Major Incidents isn’t a huge leap from the method that you use to handle day-to-day Incidents. It requires enhanced communciation and possibly measurement.

I hope that you found this article helpful.

Photo Credit

Interview: Simon Morris, 'Sneaking ITIL into the Business'

Ignoring the obvious may lead to a nasty mess

I found Simon Morris via his remarkably useful ITIL in 140 app. Simon recently joined ServiceNow from a FTSE100 Advertising, Marketing and Communications group. He was Head of Operations and Engineering and part of a team that lead the Shared Services IT organisation through its transition to IT Service Management process implementation. Here, Simon kindly shares his experiences of ITSM at the rock face.

ITSM Review: You state that prior to your ITSM transformation project you were ‘spending the entire time doing break-fix work and working yourselves into the ground with an ever-increasing cycle of work’. Looking back, can you remember any specific examples of what you were doing, that ITSM resolved?

Simon Morris:

Thinking back I can now see that implementing ITSM gave us the outcomes that we expected from the investment we made in time and money, as well as outcomes that we had no idea would be achieved. Because ITIL is such a wide-ranging framework I think it’s very difficult for organisations to truly appreciate how much is involved at the outset of the project.

We certainly had no idea how much effort would be spent overall on IT Service Management, but we able to identify results early on which encouraged us to keep going. By the time I left the organisation we had multiple people dedicated to the practice, and of course ITSM processes affect all engineering staff on a day-to-day basis.

As soon we finished our ITILv3 training we took the approach of selecting processes that we were already following, and adding layers of maturity to bring them into line with best practice.

I guess at the time we didn’t know it, but we started with Continual Service Improvement – looking at existing processes and identifying improvements. One example that I can recall is Configuration Management – with a very complex Infrastructure we previously had issues in identifying the impact of maintenance work or unplanned outages. The Infrastructure had a high rate of change and it felt impossible to keep a grip on how systems interacted, and depended on each other.

Using Change Management we were able to regulate the rate of change, and keep on top of our Configuration data. Identifying the potential impact of an outage on a system was a process that went from hours down to minutes.

Q. What was the tipping point? How did the ITSM movement gather momentum from something far down the to do list to a strategic initiative? 

If I’m completely honest we had to “sneak it in”! We were under huge pressure to improve the level of professionalism, and to increase the credibility of IT, but constructing the business case for a full ITSM transition was very hard. Especially when you factor in the cost of training, certification, toolsets and the amount of time spent on process improvement. As I said, at the point I left the company we had full time headcount dedicated to ITSM, and getting approval for those additional people at the outset would have been impossible.

We were lucky to have some autonomy over the training budget and found a good partner to get a dozen or so engineers qualified to ITILv3 Foundation level. At that point we had enough momentum, and our influence at departmental head level to make the changes we needed to.

One of the outcomes of our “skunkworks” ITIL transition that we didn’t anticipate at the time was a much better financial appreciation of our IT Services. Before the project we were charging our internal business units on a bespoke rate card that didn’t accurately reflect the costs involved in providing the service. Within a year of the training we had built rate cards that both reflected the true cost of the IT Service, but also included long term planning for capacity.

This really commoditised IT Services such as Storage and Backup and we were able to apportion costs accurately to the business units that consumed the services.

Measuring the cost benefit of ITSM is something that I think the industry needs to do better in order to convince leaders that it’s a sensible business decision – I’m absolutely convinced that the improvements we made to our IT recharge model offset a sizeable portion of our initial costs. Plus we introduced benefits that were much harder to measure in a financial sense such as service uptime, reduced incident resolution times and increased credibility.

Q. How did you measure you were on the right track? What specifically were you measuring? How did you quantify success to the boss? 

Referring back to my point that we started by reviewing existing processes that were immature, and then adding layers to them. We didn’t start out with process metrics, but we added that quite early on.

If I had the opportunity to start this process again I’d definitely start with the question of measurements and metrics. Before we introduced ITSM I don’t think we definitively knew where our problems were, although of course we had a good idea about Incident resolution times and customer satisfaction.

Although it’s tempting to jump straight into process improvement I’d encourage organisations at the start of their ITSM journey to spend time building a baseline of where they are today.

Surveys from your customers and users help to gauge the level of satisfaction before you start to make improvements (Of course, this is a hard measurement to take especially if you’ve never asked your users for honest feedback before, I’ve seen some pretty brutal survey responses in my time J)

Some processes are easier to monitor than others – Incident Management comes to mind, as one that is fairly easy to gather metrics on, Event Management is another.

I would also say that having survived the ITIL Foundation course it’s important to go back into the ITIL literature to research how to measure your processes – it’s a subject that ITIL has some good guidance on with Critical Success Factors (CSFs) and Key Performance Indicators (KPIs).

Q. What would you advise to other companies that are currently stuck in the wrong place, ignoring the dog? (See Simon’s analogy here). Is there anything that you learnt on your journey that you would do differently next time? 

Wow, this is a big question.

Business outcomes

My first thought is that IT organisations should remember that our purpose is to deliver an outcome to the business, and your ITSM deployment should reflect this. In the same way that running IT projects with no clear business benefit, or alignment to an overall strategy is a bad idea – we shouldn’t be implementing ITIL just for the sake of doing it.

For every process that you design or improve, the first question should be “What is the business outcome”, closely followed by “How am I going to prove that I delivered this outcome”. An example for Incident Management would be an outcome of “restoring access to IT services within an agreed timeframe”, so the obvious answer to the second question is “to measure the time to resolution.”

By analysing each process in this way you can get a clearer idea of what types of measurement you should take to:

  • Ensure that the process delivers value and
  • Demonstrate that value.

I actually think that you should start designing the process back-to-front. Identify the outcome, then the method of measurement and then work out what the process should be.

Every time I see an Incident Management form with hundreds of different choices for the category (Hardware, Software, Keyboard, Server etc.) I always wonder if the reporting requirements were ever considered. Or did we just add fields for the sake of it.

Tool maturity

Next I would encourage organisations to consider their process maturity and ITSM toolset maturity as 2 different factors. There is a huge amount of choice in the ITSM suite market at the moment (of course I work for a vendor now, so I’m entitled to have a bias!), but organisations should remember that all of vendors offer a toolset and nothing more.

The tool has to support the process that you design, and it’s far too easy to take a great toolset and implement a lousy process. A year into your transition to ITSM you won’t be able to prove the worth of the time and money spent, and you have the risk of the process being devalued or abandoned.

Having a good process will drive the choice of tool, and design decisions on how that tool is configured. Having the right toolset is huge factor in the chances of a successful transition to ITSM. I’ve lived through experiences with legacy, unwieldy ITSM vendors and it makes the task so much harder.

Participation at every level

One of the best choices we made when we transitioned to ITSM was that we trained a cross-section of engineers across the company. Of the initial group of people to go through ITILv3 Foundation training we had engineers from the Service desk, PC and Mac support, Infrastructure, Service Delivery Managers, Asset management staff and departmental heads.

The result was that we had a core of people who were motivated enough to promote the changes we were making all across the IT department at different levels of seniority. Introducing change, and especially changes that measure the performance of teams and individuals will always induce fear and doubt in some people.

Had we limited the ITIL training to just the management team I don’t think we would have had the same successes. My only regret is that our highest level of IT management managed to swerve the training – I’ll send my old boss the link to this interview to remind him of this!

Find the right pace

A transition to ITSM processes is a marathon, not a sprint so it’s important to find the right tempo for your organisation. Rather than throwing an unsustainable amount of resource at process improvement for a short amount of time I’d advise organisations to recognise that they’ll need to reserve effort on a permanent basis to monitor, measure and improve their services.

ITIL burnout is a very real risk.

 

Simon Morris

My last piece of advice is not to feel that you should implement every process on day one. I can’t think of one approach that would be more prone to failure. I’ve read criticism from ITSM pundits that it’s very rare to find a full ITILv3 implementation in the field. I think that says more about the breadth and depth of the ITIL framework than the failings of companies that implement it.

There’s an adage from the Free Software community – “release early, release often” that is great for ITSM process improvements.

By the time that I left my previous organisation we had iterated through 3 versions of Change Management, each time adding more maturity to the process and making incremental improvements.

I’d recommend reading “ITIL Lite, A road map to full or partial ITIL implementation” by Malcolm Fry. He outlines why ITILv3 might not be fully implemented and the reasons make absolute sense:

  • Cost
  • No customer support
  • Time constraints
  • Ownership
  • Running out of steam

IT Service Management is a cultural change, and it’s worth taking the time to alter peoples working habits gradually over time, rather than exposing them to a huge amount of process change quickly.

Q. Lastly, what do you do at ServiceNow?

I work as a developer in the Application Development Team in Richmond, London. We’re responsible for the ITSM and Business process applications that run on our Cloud platform. On a day-to-day basis this means reviewing our core applications (Incident, Problem, Change, CMDB) and looking for improvements based on customer requirements and best practice.

Obviously the recent ITIL 2011 release is interesting as we work our way through the literature and compare it against our toolset. Recently I’ve also been involved in researching how best to integrate Defect Management into our SCRUM product.

The sign that ServiceNow is growing at an amazing rate (we’re currently the second fastest growing tech company in the US) shows that ITSM is being taken seriously by organisations, and they are investing money to get the returns that a successful transition can offer. These should be encouraging signs to organisations that are starting their journey with ITIL.

@simo_morris
Beer and Speech
Photo Credit