7 Simple Rules to Design a Process

{ article }

Business Process Design

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 few specifics on how to implement those processes in your 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., and used 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 to design process:

1. Find out where the gaps are

Before you set out to design your process, it’s 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 their gaps with escalation to second level support. Is there inconsistency in how the process is currently executing?

Are the users happy with the results of the process? It is also critical 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 baselining 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 organizations already have fundamental 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 conferences 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 necessary, 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 to not 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. 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 developing 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 the stakeholders have issues with it. I highly recommend that you 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 screenshots, 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 a process, and I 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

David Mainville, CEO and co-founder of Navvia, is a passionate advocate of Service Management and a frequent presenter, blogger and well known member of the ITSM community. With over 35 years of experience, David has held progressively senior technical and management roles allowing him to "connect the dots" between the Business and IT. At Navvia, David leads the charge to bring innovative ITSM solutions to market focusing on Product Development, Marketing and Operations.

• Posted by David Mainville on Nov 07, 2012
• Filed under Articles
• Tagged with

Share this post