An anonymous reader writes
"Every month we submit status reports to upper management. On the infrastructure side, these reports tend to be 'Hey, we met our service level agreements ... again.' IT infrastructure is now a lot like the electric company. Nobody thanks the electric company when the lights come on, but they have plenty of colorful adjectives to describe them when the power is off.
What is the best way to construct a compelling story for upper management so they'll appreciate the hard work that an IT department does? They don't seem particularly impressed with functioning systems, because they expect functioning systems. The extensive effort to design and implement reliable systems has also made IT boring and dull. What types of summaries can you provide upper management to help them appreciate IT infrastructure and the money they spend on the services it provides?"
Here's how you tell a compelling story.
By hey!
•
2014-May-9 16:51
• Score: 3
• Thread
You talk about something the listener wants to hear. Things that interest them.
It's simple in principle but tough in practice because you need to know your audience. The only way to do that is to listen to them. What are *they* talking about? What are they trying to get the company to do? Use that to frame your story. So if it's trying to cut costs, tell them a story about how you successfully cut costs; or even better, how you *failed* to cut costs and but then later on figured out a better way. If they're pushing some management theory, show how you are putting it into practice, and how it's going to solve some long standing problem you've been struggling with.
There's not a "clear bright line" between effective communication and kissing ass. Superficially it looks much the same because both involve getting the audience to connect your story to something significant to them. The difference is in what you intend the audience to take away. If they come away knowing something about IT they didn't know before, that's solid communication.
Communication requires some shared frame of reference; a common model to which the symbols you are exchanging refers. I learned that on the first page of my data communications theory text, and it's true for human communications too. To communicate effectively with an audience you have to speak in their language. If you don't, everything you'll say just sounds just blibber-blabber to them, even if they're a *smart* audience.
That's another simple-sounding principle that's hard to put into practice. If you want to communicate unfamiliar information to someone, you have to bridge the gap and familiarize yourself with their mental landscape. Imagine a cosmetologist is tasked with explaining to you how to select and apply make-up. If she talked to you the way she'd talk to another cosmetics geek, you wouldn't learn anything. If she related it to something you already understood, like the OSI network stack or the 3SAT boolean satisfiability problem, you might learn something. But it would be a lot of work on her part; it's a lot easier to pretend you understand what she's talking about and hope you come away with something.
Re:Tell them how the users screwed things up
By DoofusOfDeath
•
2014-May-9 16:57
• Score: 4
• Thread
Try this one:
Jane felt there were too many cables under her desk so she took her scissors to several of them and cut them back to the floor opening.
Our team successfully ran new cables and got the network up and running in the space of half an hour as well proactively took steps to prevent such an occurrence in the future by tossing Jane out the window.
Wrong approach. I suggest this:
The slow throbbing of the server room A/C barely distracted from the stifling heat. As Jane sat restlessly in her thigh-length, red skirt, a bead of sweat dripped onto the network cables below. Her display, a pitiful 17" CRT from the mid `90's, flickered a 404 error. Jim, the strong but quiet network repair main, soon knocked on her office door. Despite wearing a workman's coveralls, his powerful frame was clearly visible with each move he made. He casually walked up to Jane's desk, leaned in close, and looked at her intensely with his sea-gray eyes. He said casually, but close in, "Cable trouble. I need to get down there."
Management cares about the bottom line
By Just Brew It!
•
2014-May-9 17:00
• Score: 4, Insightful
• Thread
If you're primarily focused on meeting the letter of "service level agreements", IMO you've already entered what I'll call "metrics hell" -- a desolate realm where meeting some (more likely than not) ill-conceived measure of "performance" takes precedence over actually helping your users get their jobs done more efficiently. Closing helpdesk tickets within some predefined timeframe is meaningless in the grand scheme of things if you haven't actually solved the users' problems.
How are your resources used?
By roc97007
•
2014-May-9 17:50
• Score: 3
• Thread
"We have twelve thousand users accessing our resources daily. Those resources have collectively exhibited a 99.997% uptime.
"We see nine terabytes of data flowing through our networks on a weekly basis."
"We manage nineteen B2B connections representing 22.5 million dollars a month in company business."
"We process an average of 120 helpdesk tickets a day, with a mean time to resolution of eight minutes."
And so forth. I've also seen reports on capital equipment vs overhead, trending over the last X number of years. It's useful to show, for instance, that the majority of your costs are not personnel related, lest upper management get the idea that they could save a buttload of money by outsourcing personnel to a bunch of taxi drivers in Nanjangud.
Customer satisfaction surveys could also be important, especially if they're substantially better than, for instance, the average customer satisfaction for offshore IT...
Give them the numbers.
By attemptedgoalie
•
2014-May-9 17:59
• Score: 3
• Thread
Hi there, in the month of April, this is what we saw:
1. 248,000,000 spam killed at our outer gateway that never made it to employee inboxes.
2. Major security announcements verified in April: Heartbleed, we use our scanning tools and have verified that we have no exposure to this issue.
3. No down time in messaging, payroll/HR/Finance systems.
4. Moved 250 separate pieces of code into production across various systems.
5. Completed IT installation at new facility X.
6. Etc.
Give them numbers that don't mean a lot, but show that stuff is happening.