Fumbling the Flow of Information Can Lose the Race
by Michael Barna, Kepner-Tregoe
Fumbling the baton in a relay race costs precious seconds; dropping it means disqualification. In gridiron football, completing a downfield pass can mean the difference between victory and defeat. Of course, incomplete handoffs are not limited to sports. Like dropping the ball in a game, fumbling the flow of information in business is a losing proposition.
In IT Service Operations, where technical teams can face major incidents that risk millions of dollars, improving the flow of information is critical for improving the customer experience. Essentially IT Service Operations can be observed through three lenses.
Lens 1 – Respond/Restore
When a particular service drops out unexpectedly, Incident Management responds to control the bleeding and return the customer to a level of normal performance. When users can again do what they need to do, Incident Management closes the case or transitions the issue to Problem Management for post-mortem review.
Lens 2 – Resolve/Fix
Problem Management then works the “symptom” through to a true root cause, closing any remaining knowledge gaps from Lens 1 and compiling a solution of action items to eliminate the root cause and set the stage for continuous service improvement (CSI). They then transition these action items over to the Change Management and CSI functions, who work to implement them and enhance the business environment.
Lens 3 – Prevent/Improve
Change Management, following good project management practices, implements those action items into the production environment with the goal of leveraging the knowledge gained to reduce recurring incidents and go from saying, “We’ve solved it!” to, “We’ve learned from this and can optimize the customer experience.”
Each of these three lenses creates reusable knowledge to help deflect future incidents and help customers solve more issues for themselves. At least, that is the goal.
However, all this is predicated on effective collaboration and end-to-end information flow, across all three lenses. Good information flow requires that data is captured in a cohesive, easy-to-follow format as it journeys through the IT service process.
The journey begins at the frontline with the SOS call from the customer. Team members should ask open-ended discovery questions that clarify the customer’s situation and separate facts from assumptions. If a true performance degradation has been verified, the incident team should then document a clear object/defect problem statement (or incident symptom statement) and begin classifying what facts are known about the issue.
We advise incident teams to organize information into What/Where/When/Extent. Presenting the information in this way helps teams eliminate false causes, by creating a relevant list of things to check that quickly leads toward the right restorative action to repair service, ideally, on the first try.
Having all data logged in a structured workspace makes it a lot less burdensome when executives jump on the bridge to get an update, minimizes confusion when shifts change and helps ensure there is no lag in making progress.
Determining The Appropriate Handoff Path
During the lifecycle of an incident, an Incident Manager may need to pass control of an ongoing incident to another team member at shift end, when other duties interfere or if the incident needs to be escalated to a more experienced facilitator. For an incident that is complete, there are three paths for handover. Close the case and move on, hand it over to Problem Management, or hand it over directly to Continuous Service Improvement/Change Management.
Every incident does not get passed onto Problem Management. While the test of Incident Management’s success is the user’s verification their service has been restored, there are two follow-up questions to determine if a problem record must be opened:
- Is the cause of the incident still unknown?
- Do we actually need to know the root cause to take effective actions?
Both questions must be answered “yes” to trigger a handover to Problem Management. Not every incident requires a post-mortem analysis. Technical organizations should balance the need for further information, relative to the effort it would take to pursue it. What will we do with the knowledge of true root cause if we keep digging? How will we leverage it? Is it imperative we know root cause to be able to take effective actions at improving the business environment, or would it simply be a data expedition for inquiring minds and likely nothing more? In some cases, it may be more productive to close the ticket and move on. In others, the Problem Management team needs to step in.
Ideally, Incident Management logs the information in a way that not only helps stabilize the environment but enables Problem Management to do their job. The Problem team should not have to ping the customer again to re-ask data-gathering questions that should have been asked during Lens 1. They should be able to take the storyboard directly from Incident’s hands and continue building on the template. To optimize the handoff, the Incident team should document their thoughts around cause, where else there could be problems because of the incident and what identical things may require the same fix. Setting up the Problem Management team for success involves the Incident team taking a “brain dump” of what they know at that time. Their insights can help reduce time spent in post-incident and root cause analysis meetings.
Regardless of whether one Incident Manager is handing off to another, the Incident team is passing the baton to Problem Management or Problem Management is escalating its solutions to Change and Release Management for implementation, the output should be data captured and uploaded to the Knowledge base. Each “lens” of IT Service Operations has a critical role to play in writing the story that answers, “What happened?” and “What did we do about it?” To that end, it will not do anyone justice, including the customer, if each lens fumbles the hand offs and must reset and re-do the last team’s work. Asking effective questions and documenting the answers well can improve communications, make handovers less painful, increase shared knowledge, decrease future incidents and, ultimately, improve the customer experience.
About Kepner-Tregoe
Founded in 1958, and based on ground-breaking research regarding how people think, solve problems and make decisions, Kepner-Tregoe provides a unique combination of training and consulting services to improve quality and effectiveness while reducing overall costs. The KT methodology is used at every level of client organizations: to implement strategy, achieve continuous improvement, increase customer satisfaction, and drive effective issue resolution throughout the organization.
