If you come from a process-based culture, you probably are familiar with the methods surrounding defining new processes. In brief, people frequently begin this type of process reengineering by examining the processes they are performing today (the Current State) then create the new processes (the Future State) that will fix the problems found in the current processes. As an alternative, you can flip the analysis order by first looking at the future desired state, then comparing it to your current state.
Whether you start from the present process or the desired process, you must identify the gaps between the two states. The gaps form the basis of your project's work. Each gap will require a task or group of tasks in your project plan to remediate.
As you analyze the gaps you've identified, you will discover how well you have defined your current practices. If there are holes in the documentation supporting your current processes, you'll need to fill those before you can define your project plan with any certainty. Alternatively, you may choose to document your processes as you go, accept the uncertainty this poses as a project risk that affects the comprehensiveness of your task list, and adjust the associated task durations.
Keys to building your best practices
The process of defining your Future State provides you the chance to make a dramatic improvement on your company's ability to deliver services to its customers. However, you must overcome several challenges in order to capitalize on these opportunities. While I don't want to downplay the technical hurdles you may face (and you will run into technical problems), many people I talk with cite organizational obstacles as the most difficult to overcome. With that in mind, here are four considerations to help you in your best practice exercises.
1. Develop strategies to overcome resistance.
You will want to create strategies to manage around the resistance from those who don't adapt to change so easily. There are several ways to address resistance. One technique from the psychology realm is called "going with the resistance." When you use this technique, you listen to the person's recitation of their objections without disagreeing. You allow them to complete their inventory of problems. You follow up with questions to elicit further information. By following this process, you reduce the threat level the change represents. The questions you ask allow you to lead the individual to new ways of considering the proposed changes.
Other frequently used strategies include using process defining as an opportunity for team building. By participating as a group, you can align the team members against the shared process problems rather than against one another. You may find that it pays to meet with specific people in advance of your meetings to determine their views. It's a good idea to investigate and line up support in advance but you don't want others to see you as manipulative. Always allow for the possibility that the solution you think you will reach, going into a meeting, won't be the same solution you settle on—address your own resistance to change and attachment to ideas.
2. Ask your group: Why choose ITIL's best practice?
Your company's processes form the basis of its current level of success. If your company is successful, you may feel comfortable with the status quo. However, this very success may hold you back from making changes that would further enhance the company's ability to deliver improved services. One of the questions to ask is "Why would we choose our practice over the ITIL best practice?" A knee-jerk reaction might be to respond, because our practice is best practice. But remember, the ITIL best practices have been developed from the input of thousands of companies. While you may have pockets of best practice within your organization, the ITIL framework seeks to link the flows between the individual practices. Challenge yourself and your team with the question "Why shouldn't we adopt a defined best practice?" or at least do the work to identify why your process is better for your company compared to the ITIL best practice.
3. Document the decision-making thought process.
Well-run projects use agendas to detail discussion topics and meeting minutes to capture decisions and action items. But documentation is frequently time's casualty. One crucial element you should consider tracking as you document decisions are the options you considered to reach your decisions. People will have to rely on the decisions they make but, over time, they'll forget why they made the decisions. They'll forget the facts they considered and the options they discarded. Without capturing the thought process, you may find yourself revisiting questions you thought had been answered. This type of information forms the project's knowledgebase and is key to reducing project thrashing and bringing new team members up to speed quickly.
4. Plan for cultural change—getting the process implementers on board.
I'm sure you know that it's important to train the core project team members to have a deep knowledge of the ITIL framework so they can run the project. However, it's just as important to provide an awareness of the ITIL project and an overview of the ITIL processes to the rest of the affected people in your company. They will be the ones that have to follow the new processes you create. Providing awareness ensures they are in a position to support your objectives and not hinder or sabotage them. Not every company manages cultural change well.
Determining how you approach the task of process building impacts your success because you have to consider the competing goals and objectives of other people. Allocating time to build the processes isn't enough. You should consider how you are going to get the processes designed before you sit down at the table. Your project stands a better chance of succeeding if you consider your company's culture, prepare specific strategies to overcome resistance, commit to implementing a standard and keep track of how you defined your process,