Take the Stakeholder Strain out of IT Firefighting
For many IT professionals, there’s one ongoing sore point in their stakeholder relationships—IT firefighting. Your stakeholders hate being bothered when IT services don’t work, and, even when you rush to fix the issue, your stakeholders still feel IT was to blame in the first place. To make mattes worse; when your stakeholders want these problems fixed right away, the last thing they want to hear is how busy you are and how many other problems you have to deal with first.
No wonder IT feels trapped in “response mode,” caught up in the drama of trying to keep their stakeholders happy by constantly diving into the chaos of these fires. For both IT, and their stakeholders, it feels like everyone keeps running into the same problems over and over again.
And as hard as you work to prevent problems from occurring in the first place, let’s be real—there will always be IT fires to put out. But that doesn’t mean these fires need to be a constant friction-point between IT and the business. Prevention isn’t enough. You also need to create processes to make inevitable problems less of a strain on your relationship with your stakeholders. And the key to creating these processes lies right in front of you…
Revisit Your Issues Log
Yes, most IT groups already run some sort of issues log, but few utilize it in a proactive, quantitative manner. Record all of your problems and firefighting activities in this log, and make the log public and easily accessible. This turns firefighting into a collection of concerns, rather than a problem-by-problem flow of drama.
Go In-Depth
And make sure it’s a detailed collection. Diagnose the issue. Note the steps you took to resolve the issue. Include steps you took that did not resolve the issue, so you know what not to waste your time repeating next time. Write out both in-depth, and include a column for preventative measures you can take to keep this problem from repeating.
Open Issues vs Resolved Issues
In addition to logging your resolved issues, log open issues as well and keep a count of open issues vs. resolved issues. For open issues, assign priority and status “stop lights” to each. Track and identify trends in both open and resolved issues.
Be Transparent
Finally, don’t just make the issues log accessible—report your open and resolved issues to your stakeholders and internal IT. (Chances are IT doesn’t really know what’s going on either if your stakeholders don’t.) You need to be transparent with this log and these publications. So as you publish your logs and trends, report a summary of both.
Don’t Butt Heads—Collaborate
When you report your summary to your stakeholders, do so in person. Set up a regular meeting once a month to do so and make sure they both see and understand each issue and trend. And when you do—be more quantitative and less qualitative. Focus on the numbers, not on the work being done or the complaints of either side. Do this, and IT firefighting becomes an ongoing project that you and your stakeholders are working on together, rather than a constant set of friction and finger-pointing!
