|"The Support Center exists to professionally manage, coordinate and resolve incidents as quickly as possible and to ensure that no request is lost, forgotten or ignored."|
Incident Management may be affected by any other process. Overall, the affect of, and on, other processes will vary widely across organizations. Some considerations include the maturity level of the IT department, the complexity of the technology being provided and supported, and the level of adoption of formal processes.
Incident Management should interface very closely with Problem Management and Change Management processes, as well as the various functions of the Support Center. If they are not properly controlled within an organization, changes to systems may introduce new incidents, so mechanisms for tracking changes are required. Most ITIL experts recommend that incident records are recorded on the same Configuration Management Database as the problem, known error and change records (or at least linked somehow) to improve interfaces between the various processes. (ITIL IT Service Management Essentials Course Workbook: 91) Figure 6.1 shows some of the possible relationships with other processes.
|Configuration details||Configuration Management Database (CMDB)||High|
|Response from incident matching against problems and Known Errors||Problem and Known Error Databases (in CMDB and/or Knowledgebase)||High|
|Response on Requests for Change (RFC; to effect resolution for incident(s).||Medium|
|Resolved and closed incidents||Incident Management||High|
|Communication to customers||High|
|RFC for incident resolution; updated incident record (including resolution and/or workarounds)||Medium|
|Management Information (reports)||Medium|
|Knowledgebase and/or CMDB||High|
|Shortage of resources needed for implementation and subsequent maintenance Lack of commitment from senior management might also result in other issues/problems (i.e. difficult to obtain buy-in from stakeholders) Issues other than lack of commitment could result in shortage of resources (e.g. poor planning)?||Constant communication with senior management as key stakeholders will keep them informed of progress while regaining their current commitment. Use of robust forecasting techniques from financial, project management and resource staffing perspectives will provide a good roadmap. Obtaining feedback from all the business units and extended team members about what will be needed to complete the work estimated in the next fiscal year will help provide the needed funding and resources to cover the work planned. These might include: additional employees, system capacity, tools, consulting services, process maintenance/maturity activities and auditing functions.|
|A lack of awareness or understanding among employees about what incident management is or how it applies to them.||A successful awareness campaign crafted with all stakeholders in mind can help overcome this issue. To build awareness consider `branding' the effort through the use of targeted communication, themes, rewards and recognition programs.|
|Customer service levels are not defined or inadequately defined.||These should be established through the introduction of Service Level Management within your organization. Evaluating the customer's current perception of service levels is a place to start so that improvement can be measured once the service level agreements are in place.|
|Lack of knowledge or inadequate training for Support Center staff to resolve incidents.||Allocate funding and enlist the support of senior management to strengthen your staff training program. This alone will add credibility to the reputation of your Support Center as being knowledgeable and efficient in solving customer incidents, and increase levels of service. Provide the best training you can afford. For maximum impact and ROI, be sure to provide continuing education after Implementation training to reinforce the original training and to introduce changes.|
|Low customer confidence in the Support Center - perception that the Support Center is inadequate.||Identify the issues that create a poor perception of the Support Center among its customers. For instance, were negative comments provided in a customer satisfaction survey? The key is to define the perception issues and create strategies to build customer confidence in the Support Center. (For examples of potential questions to ask in a Customer Satisfaction Survey, refer to the Customer Satisfaction chapter in this book and/or the Annex Support Center- Customer Satisfaction Survey). Develop a marketing campaign to promote what has been done to address customer complaints, and report to customers on how the Support Center is meeting SLAs, improving in specific areas, etc., to manage customer perceptions.|
|Poor integration with other processes, especially Service Level, Change and Problem Management||Define your incident process first. Then implement an automated tool to support your incident process. Do not buy a tool first and then fit the process to the tool.|
|Resistance to change. Staff will resist changing the way they conduct their day-to-day work activities.||Incorporate principles of organizational change (ensure everyone understands the end goal vision, gaining buy-in from staff, etc.) to help to minimize resistance. (Refer to Annex document titled Organizational Change References.)|
|The same problems are being resolved repeatedly rather than identifying and eliminating them from the infrastructure.||A compliant Incident Management process will record the incident details and match them against known errors and problems, so the same ones will not resurface.|
|Workarounds are not shared with other support staff when they are identified.||Workarounds should be entered into a knowledgebase or CMDB immediately and made available to all support staff instantaneously.|
|Not being kept up to date with changes and/or Releases being made in the business..||Once the Support Center is established as the single point of contact for customers, ensure that the business reports all planned changes/Releases in a timely manner. This enables the Center to be adequately prepared to respond to enquiries about those changes.|
|No management information available, so decisions are made on what the support representative thinks instead of what they know.||Appropriate metrics must be identified, and then information about them captured. Metrics reporting will enable the Support Center to base its decisions about training needs on reliable data rather than educated guesses. If training gaps are identified through metrics reporting, Support Center management can provide direction for future training sessions for Support Center staff. This will enable them to make use of knowledge rather than guessing at troubleshooting techniques.|
|Lack of agreed customer service levels.||Build relationships with all your customer bases and begin to put service levels in place that both parties agree to.|
|Poor software tools to support Incident Management||Listen to the feedback from tool users and begin to document new requirements for a tool that will better support the process in place. Build the case to build or buy a better tool when economically feasible.|
(For additional information, see Annex A61 Overview of the Capability Maturity Model and Annex A62 Questions to Guide Sustainable Change.)
6.2 - Implementation
6.2.1 Support Center Manager's Role
Responsibilities and activitiesAn important part of the Support Center Manager's role is to define what Incident Management means to the Support Center. The Support Center Manager will also need to define how the Center's use of the process interfaces with other processes (Change Management, Problem Management, etc.), functions and/or departments. A good starting point in implementing service management is to ask the question: `What best practice elements are already established and in operation?'
The Support Center Manager should also take part in determining how Incident Management behavior can provide data relating to other processes. As the central point of contact for customers, the Manager must ensure that information detected and classified by the Support Center will be of value to other parts of the organization.
Deliverables The Support Center Manager should first conduct a current state assessment. The Manager should take into consideration what differentiates this Center from others. Implementing Incident Management is not a `one size fits all' proposition; the Manager should create a `differentiation document.' This will provide a clear understanding of the current state of the Support Center, to enable effective definition of the goal state and how to achieve it.
Consider the following questions when creating this document:
The Support Center Manager should compare the Center to maturity models. Examples include:
A Gap Analysis document should be created that identifies the current state of the Support Center and any gaps that exist (between the Center and other Centers and also between current state and desired goal state). This document will drive such activities as the creation of work instructions, training materials, job aids etc.
The Support Center Manager will probably need to develop a budget for implementing Incident Management. Additional information can be found in the Measurement, Costing and Management Reporting section at the end of this chapter.
CompetenciesThe Support Center Manager who is rolling out Incident Management should be a strong leader. The manager will act as, or coordinate with the Project Manager for all the activities required for a successful implementation. Communication and financial skills will both be assets before, during and after implementation.
The Support Center Manager should have a good understanding of the organization where Incident Management will be implemented. The Manager should have good interpersonal skills (and the ability to influence others), Project Management abilities and a certain level of authority within the organization. The Support Center Manager will need to create a team of people with representatives from each area or department that is being implemented. This team should socialize and communicate the changes ahead, working to build trust and acceptance. Most problems and difficulties in implementation are a result of a resistant audience that will fight the process changes internally.`
A Support Center Manager who is supportive and encouraging in leading the Center and organization through changes, and is able to partner closely with other departments and areas as they are implemented, will achieve more through cooperation and integration than one who does not. Specific competencies include ITIL, metrics and measurement (Six Sigma), workflow and integration points with the other processes such as understanding the Root Cause Analysis (RCA) within Problem Management.
Specific to Incident Management planning and implementation, the Center will provide input into:
High-level deliverables to be created during implementation may include:
In general, the Manager should consider the qualities needed in both first-line (and secondline as applicable) support staff, as well as any operations personnel who will help roll out Incident Management. Best practice suggests that all staff involved in supporting customers should be:
A search for staff with process design, development, implementation and application experience should also be considered. Technical skills are, of course, necessary for successful Incident Management. However, those technical skills must be paired with a general understanding of the systems and applications that support the business.
Other key roles and functions in the implementation process In addition to the Support Center manager and analysts, some additional functional roles may be helpful in the Incident Management implementation process:
Before the planning stage, make every attempt to engage top management and gain their support for implementation efforts. During the planning phase, determine the key stakeholders for implementation. Every in-scope area that will be affected by the Incident Management implementation (as well as any external projects with touch points) should be included in all communication strategies.
Improvement areas may include time to resolve, number of tickets that can be handled `first time final' versus escalated tickets, etc. Look at the lifecycle cost of the process, but recognize that costs may be high before process improvements are made. Costs will go up during implementation, but then reduce over time.
Ensure that process training is clear and concise, all gaps between current and goal state have been closed appropriately and that people understand what they need to do under the new Incident Management processes and why.
Support Center responsibilities include:
In many instances, second-line support is also included as part of the Support Center. This area's tasks and responsibilities include:
Support Center personnel should have core IT skills and a desire to interact with customers at all levels. Consideration should be given to hiring staff who already possess extroverted personality traits because the IT skills can generally be taught. '°
With input from the Support Center Manager, also consider making this data available to users and customers, as applicable. Provide the data in a format that is user-friendly to your audience.
A knowledge management specialist will help maintain all troubleshooting knowledge the Center uses in its day-to-day Incident Management operations. They can ensure that knowledge is easy to find, and also that its associated category makes sense, that it is adequate and accurate and that opportunities for improvement are identified.
Reporting specialists provide data specific to the Incident Management processes to allow for investigation into process improvement opportunities.
6.4 - Optimization
The Manager participates in an ongoing review of critical performance indicators set by the Support Center for supporting the IT organization. The Manager should monitor the status of such Key Performance Indicators as call volume rates, `first time final' rates, incidents being incorrectly assigned etc. The Manager should have a high-level awareness of what is happening within the Center, but not necessarily the details related to the key performance indicators.
Additionally, the Manager should continually update other functional and process managers on the effectiveness of current Incident Management processes, and determine whether there is anything other process owners (Problem and Change Management, etc) need from the Center. The goal is to both provide and receive any information that could help the entire Incident Management process run more smoothly.
The incident reporting and review process should produce reports that enable Support Center management to make informed decisions and monitor performance (based on Service Level Agreements).
Functions performed by this group may include determining the items to be addressed, producing requirements documents, prioritizing opportunities and testing solutions.
6.5 Measurement, costing and management reporting
Incident Management provides consistent metrics for use in problem analysis, providing greater capability for reducing or eliminating future incidents. It can also reduce the volume of incidents escalated to groups outside the Support Center. Ultimately, customers know they can expect to receive consistent levels of service, and they tend to have a higher satisfaction rate as more of their issues are being resolved quickly, or in many cases first time final.'
Consider following these steps to build the business case:
The following excerpt lists several common problems symptomatic of an organization that does not produce regular, relevant and accurate management reports:
As Incident Management processes become more mature, it also allows organizations to focus on activities to interact with other processes such as Change Management and Problem Management.
Implementing processes to help the Support Center support its customers more effectively generally results in greater customer satisfaction.
Cost-effective process changes such as cross training tend to minimize boredom within the Center. When personnel believe they have the ability to make a difference, retention levels tend to be greater.
A team of specialists might be assembled to conduct an analysis of high volume call categories to contribute to a better understanding of root cause and recommend process improvements. 'Top 10' list of those categories has been created, and opportunities for reducing call volumes have begun to be identified.
In very general terms, management information can be used to validate decisions, to direct the goals and targets of Support Center activities, to justify specific courses of action related to incident Management and to assist when intervention activities related to the Support Center are necessary (Refer to Annex for supporting documents titled Support Center Scorecard - Daily, Support Center Scorecard - Monthly, and Support Center - Customer Satisfaction Survey.)
The best way to present management information is to show charts with trending information and provide explanations where changes are above or before a threshold defined as acceptable for your organization. For instance, a goal of 95% may have an acceptable threshold of +/1%, meaning anything between 94% and 96% is attributable to normal fluctuations but anything lower or higher than needs to be investigated and a cause determined. Such information enables management to identify where changes may be necessary, e.g. processes, staffing, hours of operation, etc. Again, all key performance indicators should be included in this reporting. Look for direct and indirect correlations between indicators. For instance, is there any correlation between `Speed to Answer' and 'Abandon Rate?' Do customer satisfaction/perception scores rise when more calls are being resolved `first time final'?
Use management information to validate the IT decisions that did (or did not) make sense, to direct future goals and activities and to justify specific courses of action.
|Ratio of Minor, Significant and Major Incidents||Comparison of volumes by severity level.|
|Ratio of Incidents by Owning Group||Comparison of volumes by group creating the incident ticket.|
|Ratio of Incidents by Responsible Group||Comparison of volumes by group in possession of the ticket when the SLA becomes measurable.|
|Ratio of Incidents by Customer Type||Comparison of volumes by 2-digit code derived by BCR type.|
|Ratio of Incidents by Disbursement Code||Comparison of volumes by cost center.|
|Volume of Incident by Period||Volumes for a specified period that tally Carried Over Open Items, Current Period Submitted Items, Current Period Closed Items, and End of Period Open Items.|
|Number of Incidents Reassigned||Volume of incidents that were changed due to an incorrect identification of cause/severity.|
|Number of Incomplete Incident Tickets||Number of items submitted that were incomplete.|
|Number of Incidents Related to Implementation of a Change||Related to root cause identification and used to identify issues with Change Process.|
|Elapsed Time Between Phases in Incident Management Process||Elapsed time (hours or days) between phases in the Incident Management Process at the Business Sponsor, CAB, and Priority levels as well as compared to the SLAs (if any).|
|Variances Between Elapsed Times Between Measuring Points||Differences in time (hours or days) between phases in the Incident Management Process at the Business Sponsor, CAB, and Priority levels as well as compared to the SLAs (if any).|
Give identical scenarios to multiple testers. The idea behind this technique is that a distinct possibility exists for the testing of scenarios using different strategies (and some of these different strategies may uncover flaws in the system or processes).
Test the new tool from multiple perspectives (first-line, second-line, third-line/specialty group, etc). Build testing scenarios based on the perspective of all possible types of users.
Brainstorm about ways users may misuse the tool (intentionally or unintentionally) and document the results. Consider whether misuse cases require system modifications to prevent their possibility or whether a clear and concise communication plan may avoid the scenario.
All users should be provided advance notice of the upcoming tool change, and enough time should be allowed to properly educate users. (Plan a communication approach that will reach users multiple times using varying communications techniques/strategies.)
Consider a phased rollout or pilot release approach instead of an 'all-at-once' or `big bang' implementation approach. (This is especially important if both the process and tool are being rolled out simultaneously.)
Use the pilot phase of the implementation to identify any bugs in the tool and/or process. Take steps to alleviate these issues before the main rollout.
From the first phase of implementation throughout rollout to 100% capacity, ensure appropriate monitoring of hardware and software for efficiency, capacity and traffic management are in place.
In the System Design phase, consider having a section devoted to Reporting. Make sure the design accommodates the reports that the Support Center (and other users / customers) will need and expect. [Note]
Finally, consider balancing the need for data against the effort to collect it. Assign each reporting need a level of importance, and think about how much development effort the organization is willing to spend to achieve the creation of the report.
Additional tools/resources that may be useful in supporting the Incident Management process within the Support Center include (but are not limited to):
Annex A6.1 - Requirements Checklist
The Capability Maturity Model (CMM) was developed by the Software Engineering Institute (SEI), a federally-funded research and development center operated by Carnegie Mellon University. The definitive resource is The Capability Maturity Model: Guidelines for Improving the Software Process, (Carnegie Mellon University/Software Engineering Institute), published in 1995 by Addison-Wesley. The CMM serves two major purposes: to guide process improvement efforts in a software organization, and to assist with identifying contracting organizations that are qualified to perform software work.
The five maturity levels (Initial, Repeatable, Defined, Managed, and Optimizing) represent evolutionary plateaus on the road to a high level of software process capability. Each maturity level, except the first, defines several key process areas or KPAs - groups of related software practices - all of which must be satisfied in order for an organization to attain that level (Table 1).
Each KPA has two to four goals, all of which must be achieved in order to satisfy the objectives of that KPA. In addition, each KPA describes a number of key practices that typically lead to achieving that KPA's goals. These practices are grouped into five `common features'. The key practices of the common feature called Activities Performed define technical and managerial activities that typically lead to satisfying the KPA goals, thereby establishing a specific process capability in that key process area.
|Purpose||Why is a process performed?|
|Input||what work products are used?|
|Output||What work products are produced?|
|Role||Who (or what) performs the activities?|
|Activity||What is done?|
|Entry criteria||When (under what circumstances) can processes begin?|
|Exit criteria||When (under what circumstances) can processes be considered complete?|
|Procedure||How are activities implemented?|
Other process elements are:
Annex A6.2 - Questions to Guide Sustainable Change
John Kotter, the Konosuke Matsushita Professor of Leadership at Harvard Business School, is
a noted authority on leadership. He has written
[Ref] After conducting fourteen formal studies and more than a thousand interviews, directly observing dozens of executives in action, and compiling innumerable surveys, I am completely convinced that most organizations today lack the leadership they need ... and the shortfall is often large. I'm not talking about a deficit of 10%, but of 200%, 400%, or more in positions up and down the hierarchy. Kotter's model of change management is excellent and we contend that it, like so many other useful approaches to change, leadership and organizational development, can be usefully enhanced with the introduction of more integral perspectives.
The following table conveys our understanding of Kotter's [Ref] change model in columns 1 and 2. We have aligned Kotter's eight stages of change with potential leadership questions to guide action based on integral theory as defined by Ken Wilber. We present four categories of questions for each stage of change designed to capture the thoughts and actions necessary to implement sustainable change.
Individual thoughts and actions are captured in Column 3 (What do I intend?) and Column 5 (What do I do?)
The implementation is tailored to the specific culture when answering the questions in Column 4 (How do we talk about this?) The organization systems, processes, and infrastructure are incorporated into the implementation why answering the questions in Column 6 (How do we do this?)
When implementing a sustainable change, it is critical to consider the individuals leading the change, the culture in which the change takes place and the systems, processes, and infrastructure that either reinforce the status quo or support the change. For change efforts to deliver the expected value in a sustainable manner, the entire organizational system must be taken into account and the change management effort must address not only the system (as is common) but also the individual and the culture.
Change agents and coaches working with the individuals and teams charged with creating and implementing these changes will make the best use of time, money, energy and thought by using these questions as a way to guide their efforts. We do not prescribe specific actions. The questions will guide the user to create their own approach tailored to the specific change effort, the people involved and the organization.
|What Works||What I Intend||How we talk||Action||How it is done|
|Create a Sense of Urgency|
|Showing others the need for change with a compelling object they can actually see, touch and feel Showing people valid and dramatic evidence from outside the organization that demonstrates that change is required Looking constantly for cheap and easy ways to reduce complacency Never underestimating how much complacency, fear and anger exists, even in good organizations.||Reflect on the urgency of the change. What does it mean for you personally? What will you need to change about yourself (your approach) to lead the change effort successfully? Will you lead the same way this time or will you change from what you have done in the past?||what is perceived he the employees as urgent? Do different groups of employees perceive different things as urgent: How will this change affect the individuals in the organization? How will you create a sense of urgency for different segments of the organization (by department) based on their priorities, goals, and pains?||How will I model appropriate response to the sense of urgency by my actions? What segments of the population that will change most rapidly? How will I encourage the segment that is most likely to change without ignoring others? How will I explain the impact of change in a manner consistent with culture? What stories can I use that are linked to corporate folklore to illustrate prior examples of urgency and positive outcome? How can I convey messages that use emotion (personal stories) and external sources to demonstrate urgency'||What are the influences and constraints that will affect success (legal, financial, building, staffing mix? What resources are required to succeed and how will we secure them? What measures should we track to understand employee sense of urgency? Based on the measures, once we have achieved the correct level or urgency, move to step 2, Build a guiding team|
|Build a Guiding Team - first "who" then "what"|
|Showing enthusiasm and commitment for helping someone do so) to help draw the right people into the group Modeling the trust and teamwork needed in the group (or helping someone to do that)] Structuring meeting formats for the guiding team so as to minimize frustration and increase trust Putting energy into raising urgency if you cannot take on the step 2 challenge and if the right people will not.||Do I believe this change is possible? Do I realize that people are affected by my belief in the success of this change?||What are the social and cultural norms that dictate who should be leading the project: Do they still fit for where we are going?||How do I communication the criteria for 'right' people on the team? ('Right' includes character traits, innate capabilities, and skills and knowledge) Who are the best people and how do I place them in charge of the biggest opportunity (not the biggest problem)? What comments and actions will I take that demonstrated my belief that change is possible? Am I looking for opportunities to support the project as events unfold?||What trust building activities can we conduct to improve the team dynamics? How do I lead the team based on the task at hand? I may run the risk of appearing aloof and detached from the rest of the organization because I am so focused on the change project. What measures should we track to reinforce desired team behaviors?|
|Get the Vision right|
|Visualize, literally, possible futures with such clarity that they can be articulated in one minute or written on one page. Legacy statements with potential emotional engagement, such as a commitment to serving people Sufficiently bold strategies focused on making bold visions real Watching for objective and subjective cues as to the tolerance for and speed of chang||How do I see our organization within the larger environment: (Ranging from the company to the global environment)? What are the connections between possible business futures and my personal mission, passion, and economic goals (hedgehog principle'||How do I see our organization within the larger environment: (Ranging from the company to the global environment)? What are the connections between possible business futures and my personal mission, passion, and economic goals (hedgehog principle'||What organizational vision and strategies will move my part of the business into a position of long-term success? What are the visions and strategies within my part of the organization (departments)? How do I translate the vision into long and short term timelines? How do I incorporate specific tangible goals into the timelines? What do I fund based on the timelines and when?||How do we cascade the shared vision of possible futures (realistic and wild card options) to all levels of the organization% How do we aggregate organizational goals that align with the overall vision? What measures help the organization measure progress toward goals?|
|Communicate for Buy-in|
|Keep communication simple and genuine, sufficiently but not unnecessarily complex for the task and audience at hand. Doing your homework before communicating, especially to understand what people are feeling, sensing and saying. Being aware of and, if necessary, speaking to anxieties, confusion, anger, and distrust Ridding communication channels of junk so that important messages can go through Using new technologies to help people see the vision (intranets, satellites, etc.) Bringing forward approaches that work.||\X' hat personal stories (actions and emotions) will convey my struggles in heartfelt manner and empower others to act? What do I communicate when the situation and priorities change||What is the appropriate language and message content based on the values, goals, language and culture of each audience segment (department)? What objective and subjective feedback are we receiving from these segments?||How do I show my conviction through m; actions ('walk the talk' How do I deliver messages tailored to different segments of the organization that motivate everyone to accomplish the vision? How do I convey messages that will make a strong statement using both the languages of feelings and of logic to appeal to multiple groups? How do I demonstrate humility and give credit to others? How do I communicate the vision in a manner that is hard hitting ant realistic and still conveys our confidence that it is achievable? How do I communicate progress, challenges an my support? How do I communicate the facts and hope for the future?||What arc the different audience segments based on function, profile, and other factors (union membership etc)? What stories will convey messages effectively? Do we have any applicable stories connected with company folklore? Of our current communication methods and vehicles, what will most effectively convey the messages? Can we combine and/or eliminate any current communications? Would communication be more effective if multiple projects were communicated in a joint vehicle to help the audience understand the linkages and impacts? How do we communicate measures and rewards for successfully accomplishing the vision (ensure clear linkage between vision and rewards)?|
|Empower for Action|
|Finding individuals with change experience who can bolster people's self-confidence with we-won-you-can-too anecdotes. Recognition and reward systems that inspire, promote optimism, and build self-confidence. Providing feedback that can help people make better vision-related decisions. Clarity on the nature of change required.||What is my individual role and value within s the organization? How can I effectively grow and empower others and support their success and the success of the organization? How can I benefit from the success of the project? Do I need to change my perspective or skills to succeed?||What is the appropriate reward system based on the organizations values, goals, and culture? What are the stories of prior organizational success? How can we connect prior successes to the current change effort? Why did we have failures in the past? How do we minimize previous barriers to success? Are we building a culture that supports the behavioral traits necessary to support ongoing change such as freedom and empowerment, where employees are free to act within limits to meet their goals? Is this first order change or adaptive change?||How kill I deliver clear, concise feedback that will empower others to correct, redirect or recalibrate their behavior and feel motivated to make the necessary changes? How am I funding projects and acting to increase organizational awareness and commitment? What creative solutions can I find to increase organizational awareness? How am I following through on the preestablished consequences for behaviors that undermine our success? How can I respond to undermining conflicts as learning opportunities? How do I encourage bad news as well as good? How am I assigning work to ensure the change is accomplished?||How will the organization build a reward system aligned with the new environment and that meets multiple motivations (among people or department Have we set goals and expectations (measures and behaviors) for each individual that supports the overall organization and the change effort? Have we created evaluation and feedback processes that support new behaviors? Have we created, communicated and used processes to identify those not exhibiting or supporting the new strategies and behaviors? Why is this happening? What are we doing to measure, communicate and fund `learning organization' processes and activities without sacrificing financial security?|
|Create Short term wins|
|Wins that are visible to as many people as possible Wins that penetrate defenses by being unambiguous Wins that are meaningful to others - the more deeply meaningful the better Early wins that speak to powerful players whose support you need and do not yet have Wins that can be achieved cheaply and easily, even if they seem small compared with the grand vision.||What do I consider personal wins? What do I consider wins for my team? What do I consider wins for the organization? Why do we need short term wins? How do we incorporate short term wins into the project without affecting long term project success, schedule or cost?||What wins will be provide meaningful business results? What wins will provide emotionally meaningful results? What stories can we tell about the wins that will be shared with the organization in public settings such as town hall meetings? Who are the leaders within the sub-cultures who can best communicate wins?||What wins can I identity and support that solve "problems" for others or that are seeds for future shifts? How do I publicly recognize people who accomplish the wins? How does this communication reinforce my own values among the group?||Who do we need to support the change effort for it to be successful? How can our project help these key people meet their personal objectives? How will we identify short term wins in the context of the larger project objectives? How will we connect wins to vision and measures to demonstrate the impact of small steps forward? How will we measure (objectively and subjectively) and communicate the merit of wins in relation to overall goals? How will we support systematically achieving shifts from key people and the overall organization?|
|Aggressively rid yourself of work that is no longer yours to do - tasks that may have been relevant in the past but not now, tasks that can be delegated to those who should be doing the work. Looking constantly for ways to keep sense of urgency heightened without over stimulating. Using new situations opportunistically to launch the next wave of change Show them - show them - show them||How do I deal with both profound progress and a need for continued change? How do I deal with unresolved issues and uncertainty as we move forward?||How is morale maintained by different departments (subcultures)? How do specific departments want to be recognized beyond public recognition?||What do I communicate that conveys both progress and continued urgency Am I `walking the talk'? Am I living up to the standards I have set for others? Am I perceived as acting with integrity with regard to meeting my commitments?||What processes will we establish to identify work that is no longer appropriate or necessary in the changing environment? What processes will we create and staff to scan the environment of opportunities that can be leveraged to create additional momentum? Are we reviewing measures regularly and recognizing results toward the change goals?|
|Make Change Stick|
|Continued attention until the changes have taken root Using new employee orientation to compellingly show recruiters what the organization really cares about. Using the promotions process to place people who act according to the new norms into influential and visible positions Telling vivid stories over and over about the organization, what it does and why it succeeds Making sure you have the continuity of behavior and results that help a new culture grow.||What progress have I made as a leader/ person? Are my assumptions still valid? Am I still in the right role for my personal values and mission? When I think of my mental, emotional, moral and physical state, am I still the right person for the job ahead?||How will organization goals and values change based on the change effort? How do we shift our focus in support of long change effort without losing value of recent gains? How do we incorporate new language, best practice and human interest into emerging organizational stories? How do we reward the small accomplishments toward the overall organizational success?||What do I do that reinforces the value of the change? How do I continue to send my emotional engagement, the logical case and the senior management support for the new way of doing business? How do I emphasize the focus on systematic change that encourages but does not insist on personal growth?||How does the organization fund, staff and supply sufficient and appropriate infrastructure to support and reinforce new behaviors and culture? (These including promotions, orientation, rewards and recognition that meet people's natural way of doing business) Have we sufficiently updated employee orientations and other human resources and IT systems to support changes in goals and values? Have we reviewed objective and subjective measures regularly and recognized results toward the change goals? Are we reinforcing actions that positively influence the larger vision and inquiring into those that do not?|
Annex A6.3 - Agenda for Implementation
Annex A6.4 - Project Teams List
Annex A6.5 - Deliverables Contract
|IT Project Manager/Lead:||Business Project Manager/Lead:|
(IT or Business)
Required? (Y or N)
Annex A6.6 - Project Charter Worksheet
(High, Medium, Low)
(High, Medium, Low)
|Description||Assumption or Constraint||Importance|
(High, Medium, Low)
(High, Medium, Low)
(High, Medium, Low)
(High, Medium, Low)
|Description of Impact|
|Date||Description||Change ID||Author||Approved By:|
Annex A6.7 - Project Scope Worksheet
|Date||Description||Change ID||Author||Approved By:|
Annex A6.8 - ITIL/Support center Incident Management Implementation Workplan
|IM.5||Line of Business Implementation Plan||Start|
|IM.5.1.2||Identify specialty groups|
|IM.22.214.171.124||Identify Change Mgmt Specialty Groups|
|IM.126.96.36.199||Identify Incident Mgmt Specialty Groups|
|IM.5.1.3||Identify other affected areas|
|IM.188.8.131.52||Identify other areas affected by Chg process|
|IM.5.1.4||Identify training needs|
|IM.5.2.1||Identify existing roles|
|IM.184.108.40.206||Identify existing Chg Mgmt roles|
|IM.220.127.116.11||Identify existing Incident Mgmt roles|
|IM.5.2.2||Update roles and responsibilities|
|IM.18.104.22.168||Update Chg Mgmt roles & responsibilities|
|IM.22.214.171.124||Update Incident roles & responsibilities|
|IM.5.2.3||Identify Who will fill Chg Mgmt roles|
|IM.126.96.36.199||Identify Local Change Coordinators|
|IM.188.8.131.52||Identify CAB Members|
|IM.5.2.4||Identify project team roles|
|IM.184.108.40.206||Identify Implementation sub-team|
|IM.220.127.116.11||Identify Working Team reps|
|IM.18.104.22.168||Identify process go-to people|
|IM.5.3.1||Develop awareness materials|
|IM.5.3.2||Conduct awareness sessions|
|IM.5.4.1||Capture existing process information|
|IM.22.214.171.124||Capture existing Change Process info|
|IM.126.96.36.199||Capture existing Support Center Incident Process info|
|IM.188.8.131.52||Capture existing eComm Incident process info|
|IM.5.4.2||Capture existing policy information|
|IM.184.108.40.206||Capture existing Change Policy info|
|IM.220.127.116.11||Capture existing Support Center Incident Policy info|
|IM.18.104.22.168||Capture existing eComm Incident Policy info|
|IM.5.4.3||Capture existing work instructions|
|IM.22.214.171.124||Capture existing Chg Mgmt work instructions|
|IM.126.96.36.199||Capture existing Support Center Incident Mgmt work instructions|
|IM.188.8.131.52||Capture existing eComm Incident Mgmt work instructions|
|IM.5.4.4||Validate against core process|
|IM.184.108.40.206||Validate against core Change Process|
|IM.220.127.116.11||Validate against core Incident Process|
|IM.5.4.5||Document additional requirements|
|IM.18.104.22.168||Document additional requirements|
|IM.22.214.171.124||Document upcoming Major Changes|
|IM.126.96.36.199||Document types of Standard Changes|
|IM.5.5.1||Identify documentation requirements|
|IM.5.5.2||Develop LOB/application handbook|
|IM.188.8.131.52||Develop LOB Incident Handbook|
|IM.184.108.40.206||Develop LOB Change Handbook|
|IM.5.6.1||Identify missing policies|
|IM.220.127.116.11||Identify missing Change Policies|
|IM.18.104.22.168||Identify missing Incident Policies|
|IM.5.6.2||Submit additional policies for approval|
|IM.5.7.1||Capture Work Instructions|
|IM.22.214.171.124||Complete Chg Mgmt work instructions|
|IM.126.96.36.199||Complete Support Center Incident Mgmt work|
|IM.188.8.131.52||Complete eComm Incident Mgmt work instructions|
|IM.5.8||Use Case Walkthroughs|
|IM.5.8.1||Validate design via Use Case walkthroughs|
|IM.184.108.40.206||Validate Change Mgmt design|
|IM.220.127.116.11||Validate Incident Mgmt design|
|IM.5.8.2||Identify Use Cases|
|IM.18.104.22.168||Identify Change Mgmt Use Cases|
|IM.22.214.171.124||Identify Incident Mgmt use cases|
|IM.5.9.1||Identify Training Audience (Process, Tool, or Both)|
|IM.126.96.36.199||Identify Who needs Chg Mgmt process training|
|IM.5-9-1.2||Identify who needs Incident Mgmt process trng|
|IM.188.8.131.52||Identify who needs TCM training|
|IM.184.108.40.206||Identify who needs TPM training|
|IM.220.127.116.11||Identify who needs Chg Manager detailed trng|
|IM.18.104.22.168||Identify who needs ITIL Essentials trng|
|IM.22.214.171.124||Identify who needs ITIL overview trng|
|IM.126.96.36.199||Schedule Chg Mgmt process training|
|IM.188.8.131.52||Schedule Incident Mgmt process trng|
|IM.184.108.40.206||Schedule Change Tool training|
|IM.220.127.116.11||Schedule Incident Tool training|
|IM.18.104.22.168||Schedule Chng Manager detailed training|
|IM.22.214.171.124||Schedule ITIL Essentials training|
|IM.126.96.36.199||Schedule ITIL overview training|
|IM.5.9.3||Reserve & Prepare Training facilities|
|IM.188.8.131.52||Reserve facilities for Chg Mgmt process trng|
|IM.184.108.40.206||Prep room & materials for Chg Mgmt process trng|
|IM.220.127.116.11||Reserve facilities for Incident Mgmt process trng|
|IM.18.104.22.168||Prep room & materials for Incident Mgmt process trnl|
|IM.22.214.171.124||Reserve facilities for Change Tool training|
|IM.126.96.36.199||Prep room & materials for Change Tool training|
|IM.188.8.131.52||Reserve facilities for Incident Tool training|
|IM.184.108.40.206||Prep room & materials for Incident Tool trng|
|IM.220.127.116.11||Reserve facilities for Chg Manager detailed trng|
|IM.18.104.22.168||Prep room & materials for Chg Manager detailed trng|
|IM.22.214.171.124||Reserve facilities for ITIL Essentials training|
|IM.126.96.36.199||Prep room & materials for ITIL Essentials trng|
|IM.188.8.131.52||Reserve facilities for ITIL overview training. Prep room & materials for ITIL overview training|
|IM.5.9.4||Conduct Process Training|
|IM.184.108.40.206||Conduct Change Mgmt process training|
|IM.220.127.116.11||Conduct Incident Mgmt process training|
|IM.18.104.22.168||Conduct Change Manager detailed training|
|IM.22.214.171.124||Conduct ITIL Essentials training|
|IM.126.96.36.199||Conduct ITIL overview training|
|IM.5.9.5||Conduct Tool Training|
|IM.188.8.131.52||Conduct Change Tool training|
|IM.5.9.7||Train Implementation sub-team|
|IM.5.10.1||Roll out process to targeted areas|
|IM.5.10.2||Provide Coaching and Mentoring|
|IM.5.11.1||Review of Implementation|
|IM.184.108.40.206||Review Change Mgmt implementation|
|IM.220.127.116.11||Review Incident Mgmt implementation|
|IM.5.11 2||Revise Core Process|
|IM.18.104.22.168||Revise Change Mgmt Process|
|IM.22.214.171.124||Revise Incident Mgmt Process|
|IM.126.96.36.199||Revise Change Mgmt process training|
|IM.188.8.131.52||Revise Incident Mgmt process training|
|IM.184.108.40.206||Revise Change Tool training|
|IM.5.11 3.4||Revise Incident Tool training|
|IM.220.127.116.11||Revise Change Manager detailed trng|
|IM.18.104.22.168||Revise ITIL overview training|
|IM.5.11.4||Recommend Policy Changes|
|IM.22.214.171.124||Recommend Change Mgmt policy changes|
|IM.126.96.36.199||Recommend Incident Mgmt policy changes|
|IM.5.11.5||Build Audit Process|
|IM 5.11.6||Evaluate Rollout|
|IM.5.11.7||Modify Process Based on Evaluation|
Annex A6.9 - Steps to develop a Communications Plan
Annex A6.10 - Communications Plan
Annex A6.11 - Implementation Scope Questionnaire
When filling out this questionnaire, please be sure to include information for all areas that you are representing for your department. Questions that ask about your "area' refer to all teams you are representing in this assignment, not just to your immediate team.
|Toll Speciality Group name||Support level|
For Change Management, please list all Tool specialty groups (if different than above) that belong to your area.
|Toll Speciality Group name|
List below all other areas that are (or can be) directly affected by incidents/problems from your area.
List below all other areas that are (or can be) directly affected by changes initiated and/or implemented by your area.
List below all people in your affected areas and what type of training they For the Role column, use the following categories:
Change Management documentation
To help validate that the Change Management process will work efficiently for your areas, please list below 5-10 types of changes that we can walk through the process. These should include several types of changes in each of the following categories:
If so, please list below the locations of the documentation for this process or attach copies of the documents.
If the process is not formally documented, please identify a list of individuals who know the process and can explain it to the implementation team.
Are there any types of incidents or problems that currently do not follow this process because they are too frequent, there is no help desk support, or other reason? If so, please list those types of incidents/problems here.
Do you currently have any policies on Incident Management or Problem Management that your areas use?
Please attach the policy documents or locations, or list individuals that can describe these policies if they are not documented.
Do you have any type of Incident or Problem Management work-instructions that are used in 'our area or by users of your areas' services? These could be located in such places as team guidelines, checklists, handbooks, websites, etc.
To help validate that the Incident Management process will work efficiently for your areas, please list below 5-10 types of incident or problems that we can walk through the process. These should include several types of incidents in each of the following categories:
Who will be your go-to person(s) for Incident Management questions and coaching?
List anyone in your area currently performing any Change Management roles or functions.
List anyone in your area currently performing any Incident Management role or functions.
Who in your area will act as the Local Change Coordinators for changes in your area?
|Name||Type of Changes they will coordinate|
Identify who in your area will participate on Change Advisory Boards (CABs).
Annex A6.12 - SWOT Analysis
StrengthsWhat are we good at?
How do we help the business achieve its goals?
WeaknessesWhat do we do poorly?
Where are the gaps? (People, Process,Technology)
OpportunitiesIdentify new service opportunities.
What is happening within the industry
ThreatsWhat is happening within the business?
How will technology changes affect us?
Annex A6.13 - Proposed Metrics and Priority Codes
Workload AnalysisAmount of time required to resolve each incident
|Staff Optimization||Incident Manager||Capable|
Escalation by GroupVolume of incidents having to be referred to specialty groups for resolution
|Identifies potential problem areas where additional training or knowledge transference may be needed.||Incident Manager |
Service BreachesVolume of incidents not resolved within SLA causing service escalations
|Identifies service failures for review regarding cause of breach and future prevention||Incident Manager|
Outstanding incidentsIncidents unresolved
|Reports on incidents that are still open so that they can be reviewed and evaluated and to ensure that none fall through the cracks||Incident Manager||Capable|
Service AvailabilityReports time that system was available for use
|Performance indicator and touchpoint to Availability Management||Incident Manager|
Incident Areas VolumesReports volumes by incident type to highlight problem areas
|Performance indicator focused on volume by incident type||Incident Manager|
Incident Areas by Work Time Requirements Ranks incident types by work time to resolve
|Performance indicator with attention to time spend on incidents by type.||Incident Manager|
Incident Areas by Turn-Around Time to CustomerRanks incident types by time from outage of service to when service restored
|Performance indicator with attention on time of service outage for the customer by incident type||Incident Manager|
Trending AnalysisUtilization of current and past occurences to determine future probabilities
|Forecasting tool to help identify potential problem areas and for training or staffing requirements.||Incident Manager|
Multiple Incidents Escalated to Problem ManagementReports those incidents that are escalated to Problem Management for resolution
|Performance indicator end touchpoint to Problem Manager||Incident Manager|
Ratio of Incidents by Customer typeComparison of volumes by 2-digit code derived by BCR type
|Identifies large and small volume by customer.||Incident Manager|
Ratio of Incidents by Type
(eg. call, email, walk-up, system generated) Compares volumes by entry method for evaluation
|Comparison of reporting mediums for over/under utilization.||Incident Manager||Capable|
Ratio of Incidents Handled First-Time Final by Category. Compares First-Time Final volumes by total incidents to assess efficiency. Goal is to see FTF percentages to increase over time. On the Peregine tool. this includes items categorized as Calls and Incidents. Calls are classified as First-Time Final items.
|Measures effectiveness of first time final and can be used for trending.||Incident Manager|
Ratio of Incidents by Disbursement CodeComparison of volumes by user who reported the incident. This reeds to be further assessed as there are questions concerning low used and reported,
|Identifies large and small volume by disbursement code.||Incident Manager|
Ratio of Incidents Handled within SLA. This would involve the capability of measuring overall, by group and by priority
|Looks at no. effective we are in meeting SLAs.||Incident Manager|
Cost of Service Provision/FailureBusiness costs associated with incident types
|Assigns a cost to incident types in order to assess priorities and value of service provided.||Incident Manager|
|Incident - Note: most metrics for Incident are captured under Service Desk|
Elapsed Time of Resolution by Impact Codere Measures the length of time to resolve incidents by severity to assess performance
|Performance Indicator||Incident Manager|
First Time FinalsIndicates the number of incidents that are resolved at time of initial contact
|First Time Final measurements should be used as a timeline indicator similar to a 2 year stock history. FTF should demonstrate highs and lows with a reference point indicating why the lows. A healthy process should trend upwards.||Incident Manager|
Ratio of Incidents by PriorityComparison of volumes by according to the assigned level of importance.
|Notes trends regarding priority.||Incident Manager|
Ratio of Incidents by Owning GroupComparison of volumes by group creating the incident ticket,
|Identifies large and small volume initiators.||Incident Manager|
Ratio of Incidents by Responsible GroupComparison of volumes by group in possession of the ticket when the SLA becomes measurable,
|Used for capacity analysis of resources.||Incident Manager|
Number of Incidents Related to Implementation of a ChangeRelated to mot cause identification and used to identify Issues with Change Process.
|Used in root cause analysis and for correlation analysis to measure effectiveness of Change Management.||Incident Manager|
Number of indents not documented in Incident Database. Need to determine a way to m incidents that were not document in Incident Management database but still worked.
|Tracks items not documented in IM database. therefore, outside the Incident Management Process.||Incident Manager|
Elapsed Time of Phase Duration in Incident Management Process. Elapsed time (minutes) of phases in the Incident Management Process at the Initiators, Owning/Responsible Groups, and Priority levels as well as compared to the SLAs (it any).
|Establishes values for component evaluations for effectiveness measurement.||Incident Manager|
Variances Between Elapsed Times Between Measuring PointsDifferences in time (hours or days) between phases in the Incident Management Process at the Initiators, Owning/Responsible Groups, and Priority levels as well as compared to the SLAs (if any).
|Used to determine whether the variances in the duration at the components are within tolerances or if action might be needed to identify why out of tolerance.||Incident Manager|
Ratio of Service Requests vs. other ToolsUsed to determine impact on current probties and understand volume of service requests.
|Comparison allows for the acknowledgement of other tools and tine degree that Peregrine meets the needs of the process or when it ho longer accommodates those needs.||Incident Manager|
Ratio of Service Requests vs. IncidentsCompares volumes between SRS and Incidents to evaluate knowledge transfers vs. actual issues.
|Evaluates effectiveness of knowledge transfer and classification of incoming calls.||Incident Manager|
|Requires Research - request tracking|
Volume/Percentages of Incidents Resolved RemotelyIncidents resolved without having to visit the physical location
|Performance Indicator||Incident Manager||Capable|
Volume/Percentages of Incidents Resolved RemotelyIncidents resolved without visit to the physical location
|Performance Indicator||Incident Manager||Capable|
Trends on Post-Change Occurrence of Particular Problem Types Validates that the Change implemented to resolve a Problem actually works
|Evaluates success of Change. Touchpoint to Change Management.||Problem Manager|
Number and Impact of RFCs on availability and reliability of serviceVolume and impact description by Problem type
|Grouping problems by type, this is an indicator to demonstrate areas of focus. Touchpoint to Availability Management||Problem Management Team|
Amount of time worked on investigations and diagnoses per organizational unit split by Problem typeLength of time required to formulate solution to problem by Problem type
|Useful for workforce analysis and for determing lob costs.||Problem Management Team|
Number and impact of Incidents occurring before the root Problem is closed or a Known Error is confirmedEvaluation of the extent of incidents arising from a Problem before the root cause is determined,
|Measures the reaction time from both the Incident and Problem Management areas in determining root cause.||Problem Management Team|
Ratio of Immediate (reactive) support effort to planned support effort in Problem ManagementEvaluation of time spent conducting 'damage control' versus time spent on planned Changes
|Determines how proactive the company is regarding the mitigation of Problems versus putting out fires'.||Problem Manager|
Elapsed Time to Close a Problem Time measurement from the point a Problem is opened to the point where it is dosed. Since this includes the execution of the solution this would also include Change and Release Management elapsed time regarding the build and implementation of the solution.
|Performance Indicator. This is a Touchpoint with Change and Release Management_||Problem Management Team|
Elapsed Time to Date on Outstanding ProblemsA daily report designed to track outstanding problems and how they are progressing
|Problem Management Team||Capable|
Expected Resolution Time on Outstanding ProblemsExpresses the anticipated resolution time for an outstanding Problem.
|This is a speculative measurement which may help regarding downtime estimation or resource planning. It may point to a particular Problem that needs increased attention but is should net be considered as a trending indicator.||Problem Management Team||Requires Research|
Mean/Maximum Elapsed Time to close ProblemsCompares averages and maximum times for trending purposes. Can also be used for variance analysis.
|Performance Indicator -Establishes averages for comparisons in order to gauge the process efficient||Problem Manager|
Impact of Change (degree of Service increase}Positive impact of Change on Service (Availability)
|Performance Indicator - Touchpoint to Availability, and Problem Management.||Change Manager|
Decrease in service disruption over time resulting from ChangeValidation that the Change being implemented is positively affecting Service by reducing or eliminating disruptions
|Performance Indicator||Change Manager|
Number of Changes Implemented in the Period by CI, Configuration Type, ServiceVolume count for a particular period viewed from several categories to evaluate process efficiency..
|Performance Indicator||Change Manager|
Breakdown by Reason for ChangeAssesses the volume counts by Reason for Change to note any trends or problem areas that may require further research.
|Performance Indicator||Change Manager|
Number of Successful ChargesMeasures the success of the process components such as RFC submission. Build and Testing phases by looking at the success of the Implementation
|Performance Indicator||Change Manager|
Number of Changes Backed Out and ReasonsExamines the volume of items implemented then backed out for one reason or another. Goal is to have few of these. Reasons help to identity causes for future elimination_
|Performance Indicator||Change Manager|
Number of Incidents Traced to ChangesMeasure of Change efficiency in regards to communication training and impact analysis. To be used for risk elimination in future,
|Touchpoint to Incident Management.||Change Manager|
High Incident of RFCs to a Particular CIs and ReasonsIdentifies areas of risk by association of volume counts to particular CIs
|Proactive analysis that identifies risk and allows for appropriate action to be taken to mitigate risk.||Change Manager|
Trending of RFCs by TypeAnalysis of trends based upon past and current data by type to forecast future events to be used to address perceived issues.
|Proactive analysis that identifies potential issues or arcs of focus or investigation||Change Manager|
Previous Period ComparisonsCompare/contrast current to previous periods to gauge process performance
|Performance indicator||Change Manager|
Number of RFCs Rejected and WhyProvides volumes and reasons for RFCs being rejected for action. Allows analysis of to prevent abuse on to highlight training requirements.
|Performance indicator||Change Manager|
Proportion of implemented Changes Unsuccessful (in total am by CI)Analysis of authorized changes that were implemented but proved unsuccessful. By categorizing these numbers, focus may be pieced on individual areas requiring adjustment in activities.
|This metric identifies where training of execution may be tacking in the correct identification of requirements to provide successful Change implementations or Problem resolutions.||Change Manager|
Change Backlogs by CI and StageMeasures Changes that are taking longer than average or estimated
|This identifies possible workload issues or procedural issues that may be the cause of the backlogs.||Change Manager|
Ratio of Change TypesComparison of Change Types to understand the workloads, the reasons for change and the exposure of the CABS/Charge Managers
|Performance Indicator||Change Manager|
Ratio of Stardard:Minor:Signlficant:Major ChangesComparison of volumes by category.
|Performance indicator - Notes trends regarding category.||Change Manager|
Ratio of Submitted Changes by CABComparison of volumes by CAB.
|Performance indicator Compares efficiency by CAB.||Change Manager|
Ratio of Authorized/Rejected/Pending Changes by CABComparison based upon the CAB review of the RFCS-
|Performance Indicator- Comparison of responsiveness by CAB.||Change Manager|
Ratio of Successful vs. Unsuccessful Changes by CAB. Application & Technology Comparison of the outcomes of the implementation of RFCs_
|Performance Indicator - Quick comparison of the effectiveness of submitted changes.||Change Manager|
Number of incomplete Change RequestsNumber of RFCs submitted that were incomplete for consideration by CAB. Requires a further breakdown of the rejection code to identify why rejected (new requirement),
|Used to indicate possible training need. Evaluates the efficiency of training for tool users||Change Manager|
Variances Between Elapsed TImes Between Measuring PointsDifferences in time (hours or days) between phases in the Change Management Process at the Business Sponsor. CAB, and Priority levels as well as compared tot" SlAs (if any))
|Performance indicator - Used to analyze differences in elapsed times to identity issues. Would require the development of averages and/or SLAs.||Change Manager|
Aging By Status(Submitted/Authorized/Pending/Build/Test)- Measurement of elapsed time in each status of the Change Process
|Prevents RFC's from falling between the cracks' and being forgotten.||Change Manager|
Average Time to Create an RFCAverage time it takes to enter an RFC from the moment the screen is opened to the point that the submission is complete.
|Evaluates the user interface to determine tow fast and easy it is to use. Measures the effectiveness of the user interface,||Change Manager|
Correlation of Incidents to ChangeMeasures the number of incidents that Change use related to a change This could be done by comparing volume reports for each to see if spikes occur In incidents immediately after a change takes place.
|An increase in Incidents as a result of a Change may point to a lapse or defect in the Change process Measures the effectiveness of the Change Process via comparison to fallout on the Incident Process||Change Manager|
Annex A6.14 - Incident Metrics Report
Annex A6.15 - Support Center Scorecard - Daily
Annex A6.16 - Support Center Scorecard - Monthly
Bibliography for this Section