7 Simple Rules for Designing a Process

When it comes to IT service management (ITSM) few would argue that ITIL has become the de facto standard for defining processes. But it might surprise you to learn that you can become ITIL certified right up to the “expert level” without ever learning how to effectively design a process? This is further compounded because ITIL, as a best practice framework, is by its very nature not "implementable". Okay, so what exactly does that mean?

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 Corp. that uses BMC Remedy, especially if your company was organized around 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 (not a certification course). Based on that experience I’ve come up with seven simple rules for designing a process:

1. Find out where the gaps are - 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.

2. Don’t start from scratch - 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 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.

3. Don’t try this on your own - 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. ITSM processes are fundamentally about people, and more specifically the hand-offs of activities, tasks and information between people. Sure, tools are important but they just facilitate the communication between people.

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 time frame ― 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.

4. Don’t be a technophobe - Yes, a process is primarily about people but, when all is said and done, those people will need to interact with a tool effectively. 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.

5. Don’t forget to validate - 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 time designing a process only to find out that 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. This, however, 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.

6. Don’t forget to educate - 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 deliver training on a process, I make sure I have lots of screen shots, documented procedures and, most importantly, all the reasons why this new process will make work-lives easier.

7. Don’t forget governance - 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 hours designing a process, tens or even hundreds of thousands of dollars on tools, but it’s all meaningless if people refuse to adhere to the process.

The value derived from your processes will be directly 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

David Mainville is CEO and co-founder of Consulting-Portal, an ITSM consulting and ITIL training company focused on helping Fortune 500 and mid-size companies assess, design and implement robust ITSM processes. Consulting-Portal also offers a full curriculum of ITSM education including: ITIL, ISO and CobiT. In 2008, Consulting-Portal launched http://www.itoptimizer.com/, an online solution to help companies assess, design and govern their ITSM processes.