Honest Communication: the Road to Continuous Improvement in IT
Thank you once again for your patronage into our blogosphere. Stop by anytime. We’re tackling a tough topic this week, but one that’s necessary to have a tactical understanding of continuous improvement. Most of us in IT operations and support recognize how necessary continuous improvement is (at the strategic level), but the front lines can be rough sometimes.
So while we know much of this might sound like common sense… Many times common sense requires a thoughtful description… and we hope this article is.
At times, we walk into companies that want to shy away from reporting the poor/negative results that are almost certain to show up when you start implementing external metrics. Of course all companies have issues, but it’s tough to hear specifically what they are!
As an example… many times, it can be shocking to learn that your first call resolution is actually 48% when you have been reporting 80% to management for several years. Or, that your changes take longer to implement (and fail more often) then you actually knew.
But, it’s important to know where you’re falling short and ensure that your IT department doesn’t develop a culture of fear in reporting bad news. It’s best to know your weaknesses, reflect on them, report them and consider how to improve. What are some of the ramifications of permanently delaying communication?
– Lower Customer Satisfaction
– Function outsourcing
While there may be short-term benefits, or even good reasons for holding off immediate communication to a broader audience, there are also major benefits in responsibly communicating results such as:
– Hearing a unique perspective on the causes of failure
– Learning what is inside your control and outside
– Finding unique solutions from other individuals coming from an unbiased perspective
Given that the stakes are high… be proactive! IT is a tough place to be these days. Companies are still looking to cut costs. If management feels that you are doing all you can to stay on top of performance, you’ll be in better shape!
So what do we recommend to soften the blow? Proactively communicate principles on what is acceptable and unacceptable for the IT department. The specific definition might be different for your organization, but the principles outlined by examples below can be a simple guide:
Here’s what should be acceptable (for the Change Process):
– An unintentional technical mistake during a scheduled change window.
– If you’re an IT Analyst, admitting that you don’t have all of the skills necessary to perform the change (when you realize it).
– Mistakes due to extended work hours.
What’s not acceptable?
– Lack of communication about a mistake during a scheduled change window.
– Misrepresentation of actual change implementation timeframe post completion.
– Failure to ask for help the moment you realize you don’t know something.
So, encourage your teams to be humble in reporting their mistakes. Truly, the biggest mistake is intentional mis-communication… and not asking for help!