It’s Tuesday, and your manager has just called you into the office. “We are appointing you to a new role within the IT support team. I would like to you to be the incident process owner.” After a moment of shock, surprise, and excitement all at once, you listen to the details and how your manager views the importance of the position and the major goals and objectives of putting you in charge. “Do you have any questions?” You pause...“No, thank you so much for your confidence in me. I won’t let you down.”
Now what?
Moving into a new role is challenging enough. As the incident management process owner, you will be responsible for getting a cross-functional team to believe in the importance of managing customer expectations, work together to drive a reduction in incidents, and improve response times—not to mention driving consensus and adoption of managing from a service perspective. No big deal, right?
One technique to drive change is to map out the incident process. The goal is to identify what steps are essential and get consensus for a new closed-loop process that is measured and managed to deliver better results. But a process mapping exercise has very little to do with actually mapping the process steps. Process mapping is a tool to drive sustainable organizational change. If you want your manager to be impressed, follow these steps for mapping out the incident management process and take the first steps to driving real organizational change that sticks.
A process mapping exercise has very little to do with actually mapping the process steps. Process mapping is a tool to drive sustainable organizational change.
Let’s begin by asking a series of important questions that should be your first initial point of action.
What Role Will You Take in Driving Change?
A successful process mapping project requires participation at many different levels within the service delivery organization. To determine who needs to be involved, identify the way that incident tickets or requests flow today. The key roles include the process owner, the IT functional unit managers (such as networking, data center, desktop), and management.
Management Commitment. When your manager asked if you had any questions, you should have responded with “What role will you take in driving change?” A manager who recognizes the importance of having a role dedicated to the success of managing incidents should also be ready to take action and support the organizational transformation that needs to occur. A manager’s support is vital to the participation of the cross-functional team and eliminating barriers to the adoption of a consistent incident management approach. The first step to being successful is to identify what you need from your manager.
Establish a Transformation Team. Successful change in the iterative process of managing incidents requires that a broad cross-functional team identify what is not working, what does work, and ways to innovate to drive higher levels of success for the business. Don’t make the mistake of going into your office and mapping out a “perfect” process and bringing it back to the team and telling them that this is the new and improved incident management process that the organization must adopt.
For real change to stick, everyone who works with incidents today must buy-in to doing a new process. The cross-functional team must air out all the dirty laundry to change behaviors. Where is the dysfunction today? Which contributors lack trust in the process? In the background, it is the organization’s dysfunction that attributes to failures in the process. When you successfully uncover the pain points, you are going to open the door to overcoming the dysfunction and move closer to developing work methods that serve the business and not processes meant to control the dysfunction.
Own the Process. IT service management defines the process owner’s role outlining all your new accountabilities and responsibilities. But when it comes to mapping a process, the most critical skill is negotiating. The current process is probably broken, over-engineered, or driven by your service management tool. But it is the established process, and people are following it in an ad-hoc fashion. Your job is to streamline the activities of nearly every functional unit in IT in a way that everyone is happy. You will need to compromise, add steps to solve the conflict between teams, and at just the right time, remind everyone that you are trying to provide a better service to the business.
How Do I Map a Process?
Once you have established a cross-functional group and secured buy-in at all levels for improving incident management, the next thing you must decide is what method and tools will you use to map the process.
Choose Your Method. While there are many different techniques for mapping a process depending on what you are trying to achieve, the incident management process typically uses two methods to map the process: Top Down Flow and Cross-Functional Flow.
The top-down flow (pictured above) is a fundamental mapping technique that is used to map the sequential steps from the top of the page to the bottom. The method allows for simple branching and looping, and it is easy to understand.
Notice however that the functional flow can also show the sequence of events and identify roles and responsibilities for each step in the process. If your organization is struggling with accountability and lack of trust, the cross-functional flow (pictured above) will not only help you achieve a better process design, the method will also help to eliminate conflict and define clear responsibilities.
Choose Your Tool. Two tools that are widely available are PowerPoint and Visio. There are many other mapping tools available. Remember that the tool is for depicting the agreement of the decisions of the cross-functional team. You don’t want to get caught up in finding the right tool because mapping the process is more about the people and the cultural change and less to do with the process diagram that is created. Visio does without a doubt make it easier to create and manage changes to cross-functional flows.
Identify Functions. Incident management is a process that flows across functional lines in an organization. The cross-functional team that should be responsible for engineering a new process must have representation from all functional groups within IT. The figure below represents a typical structure. In this case, representatives with authority to make decisions should be selected from the infrastructure, application development, operations, support, security, and client/server units.
Map the Functional Flow. A functional flow maps the high-level flow of information across the key stakeholders and provides a starting point for understanding the customer’s relationship with the IT functions. Additionally, the functional flow defines the relationships internally within IT. If we can collectively agree on the overall flow, then mapping the sequence of events within the flow will be much easier. The figure below shows a sample functional flow.
Map the Incident Management Process. Once the team has decided on the high-level flow, the work can begin by mapping the specific steps in the process. The icons used in the process flow all have a particular meaning in addition to what is accomplished within the step. Using the right symbol is important. The figures show the most common symbols used in the incident management process.
Begin mapping the process by creating a lane for each functional group. The process begins with and ends with a terminator. As roles and responsibilities change, the process symbols will move to the responsible functional group as shown in the figure below.
The figure below shows the first page of a typical incident management process. Notice in the example, a tool lane shows how the technologies are used to support the process. The figure shows the customer experiencing an outage and contacting the support organization through the telephony systems and connecting with the first available technician.
Don’t forget to create a key and track all the symbols, abbreviations, and custom icons. Be sure to provide a description, agreed to by the process team, for each of the icons used. The figure below shows a sample process key.
Wrapping Up
Finalize the flows that are developed by getting consensus from the cross-functional team on the new way to work together to serve the customers. Work with the system administrator of the incident tracking system to make the changes as needed to support the new process. Conduct awareness training within each of the functional areas and make the process documentation available to the broader IT organization.
Remember the goal of mapping out the incident management process is not about pretty pictures and process flows. Mapping the process is about creating accountability, clearly identifying roles and responsibilities, and getting the organization to work together to provide the best service possible to the customer. Once the organization agrees to work together in a more effective and streamlined way, the IT organization can better establish and manage customer expectations.
As the process owner, it is also critical to identify a clear measurement strategy that provides feedback to the functional teams on how well the process is working. The reports will not only help to ensure process adherence, but measurements can drive continuous improvement and demonstrate the value delivered to the customer. Being a process owner is a great role to begin moving up in the IT organization. Your success depends upon your ability to negotiate across a diverse team of managers who have other goals and objectives. Use mapping as a tool, not as a control over organizational dysfunction and you will be successful in your new role.
Julie is a dynamic, engaging change agent who brings authenticity, integrity, and passion to practitioners worldwide. Through her books, articles, speaking, consulting, and teaching, her purpose is to spark change in the world with thought-provoking dialog and interaction on topics of authentic leadership, business strategy, knowledge management, organizational culture, and innovation. Julie has a B.S. in computer science from The Ohio State University and an MaED from the University of Phoenix and is currently pursuing her Ph.D. in Management and Organizational Leadership in Information Systems & Technology from the University of Phoenix. She is an ITIL Expert, Certified Help Desk Director, and Certified Governance IT Professional. She is an HDI Business Associate and teaches training and certification classes for service and support professionals. Visit her website, and follow her on Twitter @JulieMohr, YouTube, and LinkedIn.