Nationwide Insurance began its ITSM journey in 2002, starting with change and incident management. With full executive support, a dedicated process staff, and shared objectives across all of IT, the program was a huge success, and we realized as much as a 75-percent improvement in availability across top business applications. Over the next three years, the program expanded to include problem management, configuration management, release management, service level management, and capacity management.
In 2005, once the program was fully operational and we no longer needed such strict governance and oversight, the ITSM staff was moved from the Office of the CIO to IT Operations. This move worked well for a while, but changes in priority and workload across operations created and widened gaps in our governance model. By 2009, every process owner position had been eliminated and only the change and incident processes remained operational at an enterprise level (though a series of process reviews showed that neither process had any sustainable level of governance). At the same time, we noticed a new trend: availability had decreased for the first time since 2003. This led us to refocus our efforts on process governance.
A New Governance Structure
We needed a new governance structure; that much was clear. After analyzing the results of our process review, we decided to focus on five dimensions that would allow us to close all governance gaps: people, decision hierarchy, documentation, metrics and reporting, and tools and technology.
People
We knew we needed to recreate and staff the process governance roles we’d lost to IT Operations, and at the same time protect those roles from being repurposed for operations-related work. We worked with HR to establish a formal position—within the IT organization—dedicated to process management. For this position, we created three specific roles and drafted responsibilities for each role:
-
Process owner: Defines and governs the process.
-
Process manager: Executes the day-to-day operation of the process.
-
Process practitioner: Engineers and implements the process, or performs the process in a dedicated operational role.
Once we’d established the roles and a formal, recognized set of responsibilities, we were able to create a staffing model. With this model in place, we proceeded to hire and fill positions. Based on the staffing model, each enterprise-level process would get one process owner and a number of process practitioners. IT Operations would be able to use process managers provided it could clearly delineate the need for both operations and governance roles. This made it more difficult to arbitrarily change a role overnight, and it provided more organizational stability for the process governance roles.
Decision Hierarchy
The next step in the process entailed empowering process owners to support the IT leadership community. To do this, we established a set of advisory teams that tied into Nationwide’s existing IT governance hierarchy. At the top of this hierarchy was the senior leadership governance team; beneath that team was a cross-IT governance committee that focused on the overall improvement of our core capabilities. This committee worked through a number of different capability leadership teams, each accountable for ensuring the maturity of a given IT capability (e.g., plan, build, run).
Since this structure already existed, we aligned the new process owners with the appropriate capability leadership teams. The Run leadership team, for example, sets the strategy and direction of the enterprise’s run capability. It manages objectives, defines and enforces processes, and drives continuous improvement by establishing priorities and approving initiatives to improve our operational results, and providing application and infrastructure support across the enterprise.
We then established three different advisory teams—a process advisory team (PAT), a process operations team (POT), and a process users team (PUT)—to ensure that process owners had a mechanism to get bottom-up support, augmenting our existing top-down support protocols. Together, these teams give process owners the information and alternate perspectives they need to make good decisions. They also collect feedback about the process and disseminate news and communications throughout IT.
-
PAT: The process advisory team defines process strategies and aligns them with the corporate strategy, manages objectives, defines and enforces processes, supports and engages with/in processes, and drives continuous improvement.
-
POT: The process operations team provides input on process strategies, manages objectives, defines and enforces procedures and work instructions, supports and engages with/in processes, and drives continuous improvement.
-
PUT: The process user team provides input on defining process strategies and work instructions, manages objectives, supports and engages with/in the processes, and drives continuous improvement.
After the first year, we found that the PUT wasn’t as effective in practice. Team members felt their time would be much better spent doing the work instead of talking about what needed to be done. They also believed, for the most part, that they had adequate representation through the POT, and the PUT was redundant. However, our leaders didn’t want to lose this valuable conduit for “frontline” feedback. As a result, the PUTs now hold quarterly “brown bag” sessions where all processes are represented and any interested parties can attend to learn more about those processes and provide feedback.
Documentation
Next, we needed documentation governance. Of the original seven defined processes, three processes used different templates and formats. For those processes that did use the same templates, there was no consistency in the type of content or the level of detail. We also found that the documentation was severely out of date. There were references to organizations, teams, and individuals that were no longer with or part of the company; the terminology aligned with ITIL v2, though ITIL v3 adoption was well underway; policy changes either weren’t documented or hadn’t been updated; and the documentation was out of synch with changes in our tool sets, which meant the associated procedures and work instructions were out of date.
Only two of the processes had ever been fully implemented, and implementation of the others varied greatly from department to department. Each department believed that the versions they’d evolved over the years when there was no governance were the better models, and that everyone should follow their lead and adopt those models. We had to go back to the drawing board.
To get our documentation under control and enable proper governance, we took the following steps:
- We established and adopted a common process architecture that specified the process levels that should be documented and the level of detail that documentation should include.
- We defined process standards for how a process should be documented, including the minimum required elements (e.g., policy, process model, procedures, roles, responsibilities, metrics).
- We created common documentation templates aligned with the process architecture.
- We adopted business process model and notation (BPMN) as our common process modeling schema. Although there was a bit of a learning curve for the process engineers, using BPMN ensured that all process models were consistent and compliant with industry standards. We also found it gave us the nomenclature to model very complex process scenarios in a fairly simple way.
- We created a documentation audit process that regularly reviews the currency of all documents and tracks any issues through to completion.
Metrics and Reporting
To support our new governance approach, we needed data to guide and validate our work. Many of our earlier metrics were at that point invalid, while others no longer existed. We held a metrics workshop to build a new metrics architecture, including key operational and governance metrics. This workshop resulted in the definition of three new categories of metrics: compliance, effectiveness, and business impact. Compliance metrics measure key control points or outputs to determine whether policies and processes are being followed (e.g., changes implemented without approval, configuration items with no relationships, incorrect use of incident priorities). Effectiveness metrics measure whether a process is delivering the intended result (e.g., change success, first contact resolution, known error removal, configuration management confidence). Business impact metrics measure the impact of IT changes and issues to the business; for example, end-user downtime (EUDT) consistently estimates how long and how widespread loss of access to a business service was during an outage, while degree of business impact (DOBI) rates the impact of an outage (i.e., how much it really hurt).
Tools and Technology
Because we hadn’t kept process governance in place, many segments of the user community had formed relationships directly with the ITSM tool support teams. As a result, tool changes were being implemented with no regard for whether they aligned with a given processes. Because people do what their tools make them do rather than what a process says they should do, noncompliance increased dramatically; this more than anything led to the divergence between our tools and processes. To remedy this problem, we created a new engagement model that connected process owners with application owners. Our governance teams became centralized conduits for enhancement requests, with the PATs serving as advisors to the process owners, helping them accept and prioritize those requests. Process owners are now able to ensure that tool enhancements align with our processes, and that our processes are updated as needed to keep everything current.
Process Compliance
Process governance doesn’t work if you can’t manage process compliance, and compliance is meaningless if there aren’t consequences for noncompliance. The challenge was finding a set of effective consequences. We looked at several options, including one-and-done and three-strike policies, with termination as the possible outcome. However, these options weren’t consistent with our culture of inclusion, respect, and collaboration, so we opted for a more even-handed approach.
Our compliance remediation process uses support, peer pressure, and escalation to hold people accountable. We start by communicating the issue and offering coaching and training. If coaching doesn’t work, the issue is escalated through the management chain; each level of management must address the issue before escalating it further. Throughout this process, noncompliance is documented on departmental scorecards, which stimulates positive peer pressure as team members encourage their peers to turn their negative scores around.
Assessments and Benchmarks
In addition to putting governance expectations and controls in place, we needed to understand how mature our existing processes actually were and how far we were from our desired state. We wanted to be sure we were applying the right level of governance based on the maturity of a given process. Take, for example, the multiyear strategy for our Run capability (i.e., IT Operations). The first step we took was agreeing on what constituted the Run capability. Because our internal IT capability model is based on a plan/build/run lifecycle, we had some decisions to make on how to align with ITIL processes, which are organized in a strategy/design/transition/operations lifecycle. We found that our Run capability included all of service operations but only half of service transition. As a result, we decided to split release and deployment into two separate processes, release aligning with build and deployment aligning with run.
Next, we defined the goal state for our processes and related activities, along with statements of direction and strategic goals. We also performed a basic maturity self-assessment, identifying our current and target states. To validate our results, we also performed a formal ITIL-based process maturity assessment, identifying both short- and long-term opportunities for each process. Then we assessed the importance of each process in achieving our strategic goals, as well as the current and desired levels of efficiency and effectiveness of each process. This allowed us to perform a gap analysis and create heat maps that showed the largest gaps in our highest priority spaces.
We used these strategies and assessments to start building a transformational road map that included strategic objectives for the first year of the strategy. This resulted in a common set of priorities around which each process governance team (e.g., PAT, POT) could prioritize its projects, initiatives, and improvement opportunities.
* * * * *
Our renewed focus on process governance has really paid off. We’ve found our governance hierarchy structure to be highly effective, with a significant increase in approvals and acceptance for new processes. We’ve also found that our process and tool changes have become less disruptive; tool-to-process alignment has steadily converged, and the overall availability of IT systems has stabilized. We’ve closed our governance gaps, and our process reviews continue to yield positive results. And despite multiple leadership changes, we continue to receive strong support and consistent direction. There will always be room for improvement, but we feel comfortable that our new process governance program will allow us to better handle issues when they arise. To learn more about Nationwide’s process governance initiative—specifically its noncompliance remediation process and process maturity assessment—visit www.HDIConnect.com.
Buzz Woeckener is responsible for enterprise process management at Nationwide Insurance. With more that twenty years of technology leadership experience, Buzz has lead successful teams through all aspects of infrastructure management, and he’s been recognized for his ability to create high-performing teams.
Jeff Gorby is responsible for developing enterprise-wide service transition and operations process solutions for Nationwide Insurance. A certified ITIL Expert, Jeff has more than twenty-two years of experience in the IT industry, thirteen spent managing, designing, deploying, and governing ITSM processes. He’s held various positions in software engineering, business analysis, and network management over his career.