That is further compounded by the fact that ITIL, as a best practice framework, is by its very nature not implementable.  Okay, so what exactly does that mean?

Well - if you dig into the ITIL documentation you will get a lot of guidance on what should be in your processes but you will get very few specifics on how to implement those processes in your own organization.

 

A best practice by definition is devoid of any organizational, cultural and technological specifics.  It has to be.

 

What good would a best practice be if it was specific to the ACME corporation who uses the BMC Remedy product, especially if your company was organized completely differently and was using a saas application like ServiceNow.

 

So no matter what anyone tells you, you need to spend time designing your IT Services so that they meet the specific needs of your company.

As a Service Management professional with 30 years of experience I have designed my fair share of ITSM processes.  Most of what I've learned about process design was from the school of hard knocks.

 

Based on my experience I've come up with 7 simple rules for designing a process.

 

 

Before you set off on designing a process its important to understand what the current gaps are.  Let's use Incident Management as an example.  What's working with the process and what isn't?  Are there issues registering the calls or are the gaps with escalation to second level support.  Is there inconsistency in how the process is currently executed?  Are the users happy with the results of the process?   It is also very important to understand what is working well with the process - because you don't want to lose that.

 

The best way to do this homework is by asking questions, performing observations and base lining process activities against a known standard.  You can do this yourself or go out and hire a consultant to do it for you.  The important thing is that it needs to be done prior to redesigning your process.

 

 

Many people make the mistake of believing that their organization is so unique that it would be better off designing their processes from scratch.

 

While I did say earlier that a best practice like ITIL is not in itself implementable, it doesn't mean you can't leverage what is there.  ITIL does a pretty good job of identifying the things you should have in your process - it's up to you to translate that into the specifics required for implementation.

 

Start by looking at what you're doing today.  Most IT organization already have basic processes in place and you should use those as a starting point.  Reach out to colleagues within your company, other divisions or to people outside your company that you may have met through conference or user groups.  If all else fails get some outside consulting help.  There is no value in reinventing the wheel.

 

 

There is an old saying that goes something like "if you want something done right you have to do it yourself".   But that doesn't mean by yourself.

 

IT Service Management processes are fundamentally about people, and more specifically the handoffs of activities, tasks and information between people.   Sure, tools are important - but they just facilitate the communication.

 

Now if your goal is to make sure people never follow the process you design then the best approach is not to consult anyone at all in the design.  But if you want to garner support for your process, use this opportunity to consult with the stakeholders and get their buy in.

 

Building this support starts back when you were assessing gaps and continues through the design phase.  However, make sure to balance this collaboration with efficiency.

Keep your core design team to the fewest number of people as possible.  Bring in expertise as required.  Communicate to the broader audience of stakeholders through personalized updates and status reports.  Your goal is to be collaborative without getting bogged down by too much consensus building.

 

Keep your design sessions to a reasonable timeframe - this isn't a marathon.  Four or five two-hour sessions, combined with some ad-hoc meetings, are more than enough time to design a process.  Have an agenda, stay on task and don't be afraid to assign homework.  People will be appreciative if you provide structure and don't waste their time.

 

 

Yes, a process is primarily about people - but when all is said and done those people will need to interact with a tool to get the job done.  And if done right, your process design will translate into a set of technical requirements for tool implementation.  Go ahead, roll up your sleeves and get dirty.  Identify those mandatory fields, define the pick lists, figure out the start and stop triggers and make sure you capture the right data for producing metrics.

 

If you already have an ITSM tool, or you have one in mind, make sure you invite the tool specialists to your process design sessions.  There is no point designing a utopian process that can't be implemented in your tool.

 

 

Iterative process design is one of the best ways to stay focused and to demonstrate progress.  You never want to be in a situation where you've spent weeks of yours and other people's time designing a process only to find out that the management and other stakeholders have issues with it.

 

I highly recommend that your combine your process design sessions with iterative prototyping of the solution in the target ITSM tool.  Some of the newer ITSM products lend themselves better to this because of their flexibility and less reliance on developers however this is still very feasible with the legacy tools providing you have an administrator as part of your design team.

 

Use these prototypes as a way to communicate progress and to get buy-in for your new process.

 

 

One of the best ways to ensure consistency and adherence in your processes is to educate folks on what needs to be done and what's in it for them.  Whenever I delivered training on a process I made sure I had lots of screen shots, documented procedures and most importantly all the reasons why this new process will make their lives easier.

 

 

So here we are at the last of the 7 Simple Rules for Designing an IT Service Management Process and I've saved the most important one for last.  You can spend hundreds of person-hours designing a process, tens or even hundreds of thousands on tools but it's all meaningless if people refuse to adhere to the process.

 

The value derived from your processes will be directionally proportional to the degree to which they are followed.  There is no sense in having a Change Management Process if every change is urgent and few are documented.

 

Good governance requires that you establish accountability for the process, assign the appropriate tasks and measure that they are actually getting done.  It is this discipline that will ensure you reap the rewards of all your hard work.