Slashdot Mirror
Ask Slashdot: How Do You Tell a Compelling Story About IT Infrastructure?
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?"
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?"
It's highly unlikely they will care, but try to make it fun and use lots of specific numbers, management types like that.
I hate sigs.
give them a system that doesnt function how they want.
When they complain, give them what they want
profit!
have you seen my sig? there are many others like it but none that are the same
Talk about how servicing web requests pounded your application servers long and hard during peak hours.
You can't cut back on funding! YOU'LL REGRET THIS!
You get a paycheck, right?
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.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
Knock all their electronics offline and then deliver your monthly report by printout.
Then they might learn to respect the network.
If you can relate the work to how it is saving or making the company money that would likely be well received.
Hire Morgan Freeman or Patrick Stewart to read your presentation. They can read a phone book and still give folks pleasant, comforting feeling, reassuring your audience that all is well.
Or if you need to terrify the motherlovers into never crossing you, get Samuel Jackson.
Why is it that they need to be told a compelling story? Appreciation is nice, yes, but is it necessary for them to be wow-ed in every future report? Like OP said, they expect functioning systems and get functioning systems, and people get mad when things don't work right.
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?
In my many years of experience none of this will ever change until a mass exodus of the IT department occurs and all the unappreciated talent leaves. And even then executives will probably never be able grasp how good they really had it because they'll be in recovery mode for a minimum of the next 3 years.
The only other situation I've seen is when the CTO is a really charismatic guy who can describe the most simplest of task in the most interesting way and can play enough politics so people kiss his butt to make sure he's happy. Then the CTO tells his underlings how appreciated they are by the executives even though they themselves never thought to say so.
...because the moment you start trying to talk about anything technical, their eyes glaze over. They often don't give a shit how it works, or what you had to do to make it work. They only care if it works. The only time they seem to pay attention is when whatever you do impacts the bottom line. So if you can show numerically that something you did saved them a lot of money they will love you for that .... but not much else.
It sounds like you're upset because upper management is treating you like infrastructure, rather than the heroes you are?
You made the point yourself - nobody cheers when the lights come on, they get pissed when they go out. IT SHOULD be boring and dull. To an average person in your company, they shouldn't - EVER - care about how or why their systems work.
Do you think providing electricity isn't a difficult enterprise, requiring a huge number of highly-trained people doing a bunch of things right, 24/7? And I bet, a hundred years ago, people looked at people working in "electricity" the same way people looked at "IT" twenty years ago.
It's not 100 years ago. It's not 20 years ago. And we're not heroes or geniuses. We're plumbers. (Except that we're too dumb to unionize.) If anything, we are incredibly lucky that our uses are satisfied with the - in most cases - poor level of service they receive. Think about it - in all the time you've worked in IT, how many times have you seen the electricity in a building just go out, without explanation? Now, how many times have you seen major server outages, costing more than a million dollars in lost productivity? For me, I have never seen an electrical outage not related to a major disaster that kept everyone out of the building anyway. I have seen at least 5 outages that led to $1m or more in losses - and three of them were for stupid, easily preventible things. (Really? You upgraded both the primary and backup SAN at once, and killed the entire network for six hours when the patch turned out to not run properly?)
Take another look at your question. It's premised on the proposition that IT SHOULDN'T be boring and dull - which I disagree with entirely - and that IT should get more appreciation than it does, which is questionable at best. What's driving you to ask those questions, in that way?
... about how the DNS server grew up without its parents and went on to become a tycoon that dispenses vigilante justice at night.
Damn right they expect a functioning system. If it does not function, you failed. How are your expectations of your plumber, your HVAC guy, your electrician, your Doctor, your mechanic. All services that have considerable cost, they are professionals are are IT folks, be professional, live up to the expectation!
Example: Systems installed or modified which will cut expenses and/or increase capacity for generating revenue.
It's best if you can express this in real $.
Otherwise, report in terms of how you are supporting management's current goals.
If you're just sitting there keeping systems running, then you should just be happy you're getting a paycheck.
.
WHY WON'T YOU LOVE ME, CHIEF DADDY OFFICER?
Pay attention to meeeeeeeeeeee!!!!!!!!!!!111111eleven
Don't listen to all these bitter pricks.
Execs know the job of IT is to maintain systems and to increase work-efficiency through collaborative technology.
Instead of being boring "yeah everything fine, piss off" announce internal initiatives and goals that even a commoner can understand. Talk about important milestones or stories of exceptional (and actual) personal achievement. If you track your hours, announce how many man-hours were placed into a particular project. Show me the numbers.
If you fall into that "we work hard" crying bullshit, fuck you. My cat works trying to get that god damn dot with no results. I want to see results that people OUTSIDE OF IT actually like. If you did something that took 5,000 hours and everything sucks and the users don't like it... why did you do it in the first place? That's when the inquisitions start.
How do you tell a compelling story about IT infrastructure?
Once upon a time, there was a filing cabinet. This was no ordinary filing cabinet, for it sat beside a large server rack, and every day it gazed longingly at the shiny, blinking machines and wondered what it was like to be in the cloud storage business.
How's that, OK for a start?
I don't know how you tell compelling stories getting into actual details without jargon and descriptions that will probably cause management to shut down and stop listening. ("He's going on again about some electronics crap I've never heard of...")
But one can easily create analogies. Your infrastructure is like your house, for example. You need to maintain the shingles on your roof, paint the wooden siding on your house, caulk up the cracks when they appear. Occasionally, you get a rotten board and you replace it. You get a leaking roof and you patch it. Occasionally, you need to deploy more extreme measures when the rats get in or termites are in the walls -- but if you put out the bait traps first, you might avoid expensive repairs to begin with.
Is it possible to do nothing on your house for a little while and it will keep functioning? Sure. But the longer you go without painting the siding and patching the roof, the deeper the problems get as wind and water and mice and termites start eating away... and suddenly you're stuck taking out a home equity loan just to do repairs.
I don't know if this is the kind of "story" you're looking for, but you can probably come up with some sort of analogy using anything that requires regular maintenance to explain what you're doing. It may not be the kind of language you'd use in an official report, but if you're chatting with the management, it can at least get across the necessity of the kind of work needed in the background to keep stuff working.
To this "story," you can add the use of graphs and visuals. "Look at this trendline -- this is how much money we start to lose if we didn't do X, but we implemented a new policy, and now look at the savings!" Emphasize measures of "efficiency," and make comparisons to what would happen if you didn't pay attention to whatever routine things you do (with graphs illustrating the difference).
Visuals + compelling (though potentially inaccurate) analogies in plain language will generally get your point across to non-tech specialists.
Do you need their admiration in order to boost your confidence? Are the other kids mocking you? AFAICT you're meeting your objectives, and you perceive your job as dull, so you're not stressing about missing funds and stringing together inappropriate hardware to keep the system going for a couple more months. What is the problem, exactly? If you need an adventure, go bungee jumping.
http://www.youtube.com/watch?v=UTBsm0LzSP0
"Kill 'em all and let Root sort 'em out"
Churn the network, storage and server vendors to constantly reduce costs. Money talks.
I have never seen an electrical outage not related to a major disaster that kept everyone out of the building anyway
Oh, man, that must be nice. In the USA we have outages every few months as there's no redundancy on the grid.
and that IT should get more appreciation than it does, which is questionable at best
While it's silly to need such appreciation, humans do. Do they want to get accolates from the CEO? Just tell him that employees who feel very appreciated will work for up to 20% less. True story - it's fiscally irresponsible to allow any of your employees to feel unappreciated as they will demand more money and have lower productivity. And also it's not very kind, but if your CEO is a high-functioning psychopath, that doesn't carry much water.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Nice to see someone who gets it. I've been in the IT infrastructure business for many years now, and I think that plumbing, electrical, or another skilled trade is exactly the right analogy.
That said, the answer to the question that I've found is that the compelling story you tell about infrastructure is all about the future. Specifically, how you plan to evolve that infrastructure to support the changing IT environment and needs of the business while staying within reasonable and predictable budgets. 'Predictable' can not be overemphasized.
At any time, you should be able to tell the business managers what your infrastructure will look like in 1, 3, 5 years, what that will cost, what alternatives you have considered, and what the major risks are.
The problem is that if it runs without issue, then there is a tendency to assume that IT is just doing nothing, and the top brass will start cost-cutting by dropping headcount, outsourcing jobs, and so on.
Pennywise, pound foolish, but that is how a lot of companies work.
Infrastructure is boring and complicated. It's like a bridge: it takes smart people, good engineers and science to build one, and then ten-thousand people a day drive across it and most never notice. To really appreciate it, you need to have a great deal of specialized knowledge.
Your management doesn't care. They care if the bridge falls down, but not if it stays up. So, change the conversation. I bet there's a ton of stuff you do that they -do- care about. Have you saved money? Have you delivered a new business intelligence metric? Have you made the office environment nicer to work in? Have you automated a process and saved some labor hours? Have you made sure all the higher-ups have the best new tech gadgets?
Your management cares about the core business operations. Learn from them what they think about, what's on their minds. Read the same trade journals they do. Learn the buzzwords. Then proactively think of IT solutions to business problems. If your IT department isn't cash-positive, think about how it could be.
If all you really do is infrastructure, you're boring and replaceable. Strategically locate yourself closer to the center of the business, get off the fringes, and participate. That's what will get you seen and appreciated.
If the IT Infrastructure is working, then why are you needed?
If the IT Infrastructure has problems, why are you not fixing them for what we are paying you?
Many companies despise the IT dept because it doesn't generate revenue. It's a parasitic requirement knowing they must sink money to maintain and keep up with the rest of the business world. Queue the worlds tiniest violins.
Life is not for the lazy.
You did what we expected says a lot. But it will never get you the gold star. two things that will are 1. relevant comparisons to industry standards, competition (if known or possible) or to well known organizations; and 2. identifying specific activities that prevented particular issues in the news this month.
For instance: All systems and applications have been updated and retro-fitted to prevent any vulnerabilities to the Heart bleed bug.
Or
We have 98% uptime across our network with x number of computing man hours. This is greater than the industry standard of 96.5% and even better than X competitor who only had 94% according to industry insider news.
Give out an annual award to someone on the IT staff who jumped on more Severity 1 tickets than anyone else. When everyone else wanted to be in bed asleep, this person was the one who tirelessly answered the pager and ran into the burning buildings to rescue the crashed servers. The holder of the award is your best first-responder. Having this plaque on the wall reminds management of the crises that were resolved in heroic fashion.
Sure, there's no award for the person who prevented drama from happening in the first place. But that's kind of the way it goes with heroes.
$5 / month hosted VPS on linux = awesome!
to do it for less money.
Check out this Forbes web-article re: "The Way Americans Die" as (what I beliueve) is a fastastic way to convey (boring!) information in a web-based compelling way: @ http://www.bloomberg.com/datav... If you view-source they are using D3.JS to do the charting (in a great way, I proclaim) Thats what guys like me 'do' if you need help in creating such a thing. I say this is how 'all' info will need to go to management, eventually (but inside a mobile-tablet app) over a secure connection will become the norm over time. Just my 2 cents. Cheers //GH
Months since someone made us your problem: 3
Months until our budget must go up 8.67%: 7
Months until somene makes us your problem if we don't get our budget increase: 8
Uh, I live in the USA, and I've worked in IT or other fields in three different major metro areas, and a dozen or so smaller areas. I've never - NEVER - seen this happen. I'm not saying it never happens, just that I've never seen it. Major, crippling IT outages happen all the time.
I even live in an area right now with a power provider to my home (Pepco) who is absolutely awful. Never seen an electrical outage take out an office I worked at.
Your second point is a good one, though one that's easily generalizable. EVERYONE should get more appreciation than they do. Janitors work a lot harder than I do, their work is worse and they get paid a fraction of what I get paid. But boy do I bitch if I come into an office that looks filthy. (Although, to be fair, I do go out of my way to say thank you.) So, yes, it's true, IT should be more appreciated. So should everyone else.
And - if we're being honest - then we should ask ourselves if, in general, we deliver a product that's so good that we deserve commendation for it. In my experience, this is rarely the case. In the industry - IE, when talking to other IT people - we know the difference between a good shop and a bad shop. But for someone on the outside, 99% of IT shops provide a bad user experience. We're ALL bad shops. So yes, it might be better to pat the plumber on the head - but honestly, if I'm the CEO, I really just don't have time to salve the feelings of a whiny plumber.
sorry spell-check greg, spell check "what I believe") LOL
No, it's because management is likely to treat them as disposable and excess expenses that need to be cut. Being boring and dull is not necessarily cheap, it can be quite expensive, and to the average person, they don't care, even though they should realize that somebody has to care.
And no, the submission didn't indicate that providing electricity was easy. They indicated it was thankless when it worked normally, but only when bad things happen do people care.
So yeah, the question is actually premised on the opposite direction than you think, and the driving force is probably a thoughtless management that wants to be dazzled or it shuts off the money tap.
You will rue the day!
RUE!
Never answer an anonymous letter. - Yogi Berra
This has never been my experience. This sounds like the kind of thing a lot of people SAY happens - but I've worked at enough places, in and out of the server room, that I question whether it actually DOES happen. Does IT need to justify its budget? OF COURSE. Everyone does. Every single department, every year. But in most places I've been, IT budgets go in one direction only - up. (And in the federal space, where I've been working recently, they go up hugely, for a terrible product.) And I've never been in a functional company where the people making the budget decisions don't recognize that infrastructure has value.
The best IT shops - the few and far between where things truly "run without issue" (and I've never been in such a place, though I was in one or two which were pretty close) are like that because management DOES recognize the need for the proper investment and support for these mission-critical systems. Frankly, I'd LOVE to see a counterexample. While we love the idea of the bastard systems engineer who keeps his systems running like clockwork despite being hated and despised... that's not the reality. If things are working well, it's because there's support at every level.
Again, your mileage may vary - and if you have been in a shop where this was in fact the case, I'd love to hear the actual story.
But the OP didn't suggest that the money tap was being shut off - just that they weren't getting their RDA of head-pats.
From Slashdot, or any other place where people complain about horrible incidents that should have been prevented, but weren't (e.g. lack of power backup plan takes local hospital offline for hours, or severe data breach costs local company their customer's trust.) Of these stories, keep a list of the ones YOU took the appropriate steps to prevent. Then tidy these numbers up into a graph that shows the total number of potential incidents versus your total number of actual incidents. The ratio should be good, if things are boring.
This puts it in concrete numbers that you're doing your homework and preventing the fires from even starting.
Occasionally living proof of the Ballmer peak.
The first step is to determine the purpose of the reporting: (why do they care?).
- Educate: Help them understand what IT Infrastructure is and what they are getting for the money.
- Persuade: Identify gaps or issues (under the covers) and secure support to improve.
- Inform: Put the one negative event they see within context (1 change of 1000 fails), show progress over time
- Update: Provide progress on key activities, or the status of measures which they care about (best if linked to other business or corporate measures)
- Explain: Answer key questions like in house vs. partner vs. cloud, how much do we spend by business unit or by business platform
The second step is to provide information which supports the purpose, here are some samples:
a) Industry Baselines. Look at how you compare with your peer groups ($ spent, availability, density). This also ensures that your targets are appropriate and provides context. (for what they are paying, what are they getting and how does it compare to similar sized entities)
b) Measurements: Go beyond availability:
- Service Delivery: What are the services you provide, how long do they take, and is that within the business' expectations
- Incidents: Number (by severity), time spent, first call resolution, etc. Split out hot button areas (ex. customer incidents, security incidents, etc)
- Defects: Speak to the value of patching (issue prevention). Highlight responsiveness to events (such as the recent heart bleed event)
- Non-IT time: Such as resources seconded to projects (what is the actual amount of resources working on IT operational activities)
- Training and Development: To ensure it is getting done (often lost in the effort to get better at the others)
- Utilization: What's your density for virtual servers, how much capacity do you have available (disk space, network bandwidth) - both save surprises later when a small project requires a major infrastructure overhaul because you are at capacity
- Degree of standardization and costs of deviation (often occurs as a result of vendor "special" requirements)
- Cost Models - Charge back (to various internal divisions or user groups if you do it) or Show back (how much of your infrastructure costs - are tied back to a platform or service)
c) Risk Profile: Identify infrastructure health (currency / availability) in terms of risk (ex. Green is vendor supported now, under maintenance, etc. Yellow is off support in X months, has had recent incidents, or is generally showing cracks and we should be planning to fix it right now. Red is off support now, has risks which are difficult to solve, etc). This can justify time spent patching, reviewing event logs, etc. It's tough, but also look at measuring the proactive (how many issues were overted, how much downtime was avoided, etc). For example, if event X occurs then Y business system could be down for up to Z hours. (Ask them what that means from a business impact perspective in terms of lost revenue, operational costs, etc.). This is where business continuity / disaster recovery programs get buy-in.
Hope that helps.
Start with, what is the hard work that you're doing, and why -- specifically -- are you doing it? Installing patches? Writing scripts? For what reason? And never just "because that's what we do" or "because that's just what you do to keep things good" Describe everything as "What we did" -> "Why we did it" with a specific goal for each action. "Installed Acrobat and Java patches to keep desktops secure against 4 new exploits found this week." "Wrote a script to deploy patches in an automated fashion to reduce the risk of errors during deployment that would lead to downtime." "Added 10 TB to the SAN to provide necessary amount of redundant storage to meet current needs." I mean, some of the stuff will never sound exciting, but if the reasons you're doing them are understandable, that should help. If you're lucky, some of the things will be exciting with a big payoff: "Wrote a new bookkeeping app to cut the time needed to process timecards by 50%."
In all honesty, it is like trying to describe what a utility does, or what any normal person would do in their day-to-day life. "Replaced carbon in filter to prevent people from getting sick from drinking water." "Put gas in tank so I would continue to be able to drive places." "Cleaned my room to make it easier to find things later when needed." Maybe not exciting, but if it's understandable, that's a start. For everything you do, there needs to be a result, and the result should either be a benefit, or a necessary action to maintain a certain level of functionality. Spell it out every time.
Yes, it'll sound to yourself like you're just finding 100 different ways to say "I did my job because it needed to be done", but if that's what you need to do, that's what you need to do. I have to do the same kind of BS for my yearly job-performance stuff -- setting goals and then assessing myself. It's painful because my job just boils down to "Do whatever my boss says needs to be done", but I have to phrase it like it was my magical idea to get data from one system into another. "Created and implemented a plan to move data from A to B so the accounting department could continue to function" -- ugh. But it's what they want to hear.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
...but nobody ever reads those.
Lots of them...
Having produced these for many years, the compelling story management wants is how your department impacts the overall business.
Tie your report back to the business because that's the only thing management cares about: people, time, costs, risks, major or significant projects / changes, future plans to improve the business or reduce costs and risks.
Develop metrics so that you can show how well you're doing on your current SLA's, downtime, hours / incident, etc. You can provide a graph week over week to show improvements. You can also show how user / customer incident volume goes up over time, and how much time you're spending on specific projects.
Specify new goals - "reduce SLA response by 5%", "build new system to mitigate this new risk you guys made"
Your in the drivers seat to show how you're doing the best for the overall business.
Present them with some situations that you alleviated and what the consequences would have been if things hadn't been handled correctly.
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I used to work in an organization associated, primarily, with aviation. Many of the projects had nothing to do with actually doing any flying but the director of the organization was an avid pilot with a gazillion hours of instrument flight experience. Any projects that offered an opportunity for him to contribute by doing some flying seemed to always get his attention. My projects tended to be simulations or other studies that resulted in a lot of equations, charts, and graphs but no chances for flight time. One day, to pass the time during a flight to Washington, I took along a couple of binders of source code (printed on the old green bar paper, of course) that I annotated during the flight with notes about changes to make, places where more comments were needed... boring stuff like that. In the following monthly progress report I noted that my software had been flight tested and the results were promising. The director was not particularly amused.
CUR ALLOC 20195.....5804M
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.
So...bear with me here:
- If your team worked their tails off to make sure things ran smoothly...tell them what you did to make it run smoothly and why it's helping.
- If your team kept the lights on and averted disaster in some way...tell them what your excellent monitoring facilities helped to detect in advance and exactly how you prevented the problem before it started
- If your team responded to tickets / infrastructure requests from development and helped other teams reach their goals...tell them how you did that
Is it so much of a stretch to not just say "Well, nothing died. You need not know why." and actually tell them WHY everything runs so well?
In company meetings and reports you aren't supposed to be humble. You're supposed to brag on yourself and your team because whoever is giving the report is the sole advocate for why your team is valuable. If you have somebody who is not doing that, then you need somebody else representing your team at these meetings.
"Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
xx
Bukowski said it. I believe it. That settles it.
Engineers are great at math but you need someone who excels with language.
Competition Good, Monopoly Bad.
Electricity is, outside of the actual generating plants, just wires. It's not often that a piece of conducting metal... stops conducting. And when it does, it's probably because it's physically broken somewhere.
IT, on the other hand, is completely different. Yes, you have your servers (aka 'generating plants'). But the users each have a computer, too. And there are literally hundreds, even thousands of programs, and DLLs, and add-ons, and drivers and such that both the server and the client are running. ANY of those can cause a problem. ANY router between the two can cause a problem.
tl;dr- IT is NOTHING like electricity. The analogy is invalid.
I really, really, really hope you're just joking/trolling. Because if not, I think "electricity is just wires" is my next "the internet is a series of tubes". :-)
Start billing other departments. No seriously, track projects and maintenance tasks to a bare minimum so you are able to do some mock calculations how much you would cost if you were outsourced. That is the only language they understand.
baffle them with bullshit.
- W. C. Fields
Think about it - in all the time you've worked in IT, how many times have you seen the electricity in a building just go out, without explanation? Now, how many times have you seen major server outages, costing more than a million dollars in lost productivity?
Uh, my infrastructure has a MUCH higher uptime percentage than the local grid, we've had to send home the entire main campus workforce 3 times in the last 2 years due to power issues, we've had to do that once in the last 8 years due to IT issues (SAN meltdown due to poorly designed switches).
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
99.998% uptime, 974 exabits moved without error, 56 firewall intercepts of phishing variety, 12,467 blocks to blacklist sites, 14,273,996 successful shopping cart transactions with 2 abandons, 67 helpless desk calls with cust satisfaction of 99% on survey, 3 new C-level gadgets installed of 3 requests, projects on or ahead of schedule... aw, what the heck, 2 BOFH reports and 3 replacements hired...
if this is supposed to be a new economy, how come they still want my old fashioned money?
We have power go out at least three times a year, in our mid-atlantic US coast business park, and at least five times a year in our Boston location (happened just this morning in fact).
We average much less than one business-impacting server outage a year. Now that we've got our redundant virtualisation infrastructure humming, we expect that number to go down.
Does that make us heroes? Because our bosses don't seem to think so.
And there are literally hundreds, even thousands of programs, and DLLs
Well, only if you use Windows. Or OS/2, right? I so hated those years of OS/2 related network outages...!
Today was our 47th day of uninterrupted service without any unplanned maintenance. Our highest yet to celebrate this blessed occasion we are happy to announce the results of our tech games. We drew names from a bucket and pitted those. Involved in a controlled environment against penetration tests and various stagger failures. Bill sadly was the first to down when our Houston office was hit by a meteor and allowed his service to be interrupted. We have notified his family that he has been euthanized in his preferred method. This concludes our 47th day of faithfull service and hope that you accept our loss of Bill as tribute to inspire the rest of us about the cost of service interruption. Sincerely, Game Master
Assuming management will go for it, do a survey every quarter which identifies (from the customer perspective) the positives and negatives of the services that IT provides.
Take the results of the survey and identify the five areas in which you do well. Also Identify the five areas which you do most poorly. Define continuous process improvement (CPI) plans to address the areas you do poorly, and clearly document the areas in which you do well. Each month, provide a rolling update on the progress of the CPI and each quarter, after the new survey has been completed, report on your progress.
N.B.: This will only work well if you *actually* improve service from a customer perspective. However, if you do this correctly you will improve IT's standing in the organization, and give top management a rollicking good story each and every month.
Posting anon so as not to lose my mods on this thread.
don't bother. Their kind is too stupid to understand what we do. More than likely, they'll revert back to their violent tendancies and lash back out at you. It is dangerous to attempt o engage their kind. Just cash your pay check and don't attempt to interact with them.
Electricity is, outside of the actual generating plants, just wires.
And transformers. And lots of electronics to monitor things, all geographically distributed. And interconnects (with lots of transformers), which will be remotely controlled to shunt power between sub-grids. And fancy algorithms to monitor demand, and weather, and predict future demand, and start bringing generators (and sometimes entire plants) on- and off-line with enough lead time to meet actual demand. And the bringing of generators on- and off-line can be a very complex process in itself.
And I don't even really know anything about the power grid--I'm just a consumer. So you have given us a shining example of the classic IT nitwit arrogance: "anything I do not do is trivial" ;-)
"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...
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
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.
My mom says I'm cool.
show them how competitive you are vs outsourced IT.
You know they are thinking about it so show them the grass is not greener..
your uptime, your sla metrics vs others may be similar
but your costs, overhead etc. is way better than external hosting.
IT is a tax to the business, minimize it and deliver value..
Perhaps throw in some differentiating innovation or some basic what are we doing for you .. what's has multi-site dedup done for you, river bed.. etc...
education
how about security side... 8,475 attacks detected and fended off per week., 4 litigation
discovery data dumps....
to worker efficiency - 1.6M spam emails/tweets filtered out per week.. That's some $$ savings..
Data volume shipped between sites. internal emails/day... give them a sense of the scale of IT
that just hums along fine. I saw someone do this in a top 10 IT facts format.
an interesting one was payroll can now run in 100x less time than 10 years ago and
costs z% less compute cost. At the same time the company has grown y% so we
are delivering massive efficiency...
now you can't do this every month but at least they may respect what IT does more than before.
Uh, I live in the USA, and I've worked in IT or other fields in three different major metro areas, and a dozen or so smaller areas. I've never - NEVER - seen this happen. I'm not saying it never happens, just that I've never seen it. Major, crippling IT outages happen all the time.
I have held my current job (I am also in the US) for about 2.5 years, and in that time we've seen 3 non-disaster caused blackouts. I work in an office park in a small city.
We have seen around 10 service-provider outages impacting WAN, internet, or both. At least 1 of these outages was caused by a major disaster.
We have had 1 internal issue that could be characterized as a "major, crippling IT outage."
Keep in mind these comments are all anecdotal, as are yours. I do agree with your premise that IT systems seem to experience significant outages somewhat more frequently than utilities do. I would explain this by noting that IT infrastructure is generally a little more complex than utility infrastructure (though usually on a dramatically smaller scale), with less reliable hardware and significantly more frequent changes.
Here
and
I will street the day? Damn you French-Canadian wannabes.
What the fuck are you taling about? I can recall 3 power outages in San Diego since 2001 when i moved here (2 were caused by raging wildfires, one by a power company fuck up).
turn your metrics filled reports into softcore office erotica.
something like 50 shades of gray if your management is female.
and just something like the send in letters to the playboy if your management is male.
then if it catches on stop writing the reports like that every time they dont give you a larger budget.
Just start your presentation with the line "And then this one time, at band camp..." and you'll have their undivided attention.
Ken
A compelling story? Okay, I'll get it started for you all:
"On a dark and stormy night, as the release deadline loomed..."
Meeting SLAs is just meeting expectations; there really isn't much to report. Instead of trying to find new ways of describing what you're doing, consider finding new ways to do the work or new things to do. Now may be a good time to start finding ways to innovate in your space. Could you continue to meet your SLAs, but chearper, or with fewer people, or with a more robust backup/DR strategy? Could you prepare an analysis of moving elements of your infrastructure to the infamous 'cloud'? Create something worth reporting on, don't search for new adjectives.
Disclaimer - I run a team managing datacentre installations / removals for a blue-chip IT company. I'm also a CDCD and a CDCMP
First of all - do you actually want management looking at what you do that closely. The best departments should be along the lines of 'you need to fund this many heads or else bad things happen'. If you want to put numbers in front of them you can talk about DCiE / PUE, and point out that the multi-million energy costs actually went down in relative terms due to adherence to best practices. You can also talk about ASHRAE, the EU code of conduct for datacentres, and every other 'badge' that you've signed up to as this makes management feel happy and they have something to compare with.
If you really want to make a point then talk about just how many other projects across the company relied on your team to deliver new infrastructure or services, how much new revenue was based on your hard work.
Of course, the longer you do the job the more you realise that all the awards and accolades end up with the guys there at the end of each of the project. And they all conveniently forget that it's your team that's installed 200+ servers, laid 50km of data cabling, and connected every single system correctly before the application guys could even start their job.
On the other hand, you have job security, you have one of the few jobs they can't outsource to India, China or Poland, and provided you keep your nose clean you'll still be there when they turn the lights out. So be happy being considered part of the furnture because in todays society the benefits of your job security far exceed any need for recognition.
Management only cares that the business is running efficiently and profitably.
Your IT infrastructure is an integral part of that but it is a means to an end. You need to relate how the work you do impacts the business.
One way to do that is to show how the infrastructure affects the ability for staff to do their jobs or affects how your customers (if you have customers, otherwise the company's staff are your customers) interact with your company.
[slashvertisement]
The company I work for, Actual Experience, can take metrics from your network and servers and provide a simple score that management can use to determine how well the IT infrastructure is performing from a human experience perspective. If the Beijing office is getting a low experience score because of a slow network link to the servers in the US you can prioritise a link upgrade and show an immediate improvement on the Actual Experience Beijing Dashboard page. Management just see a single number and some pretty graphs while the IT department can drill down into the data and pinpoint the exact part of the infrastructure that is causing the impairment in human experience. Everyone is happy.
[/slashvertisement]
As others have said, the less visibility you have the better. Mention things like how your system is not vulnerable to something like Heartbleed when the execs read headlines, then go back to playing minesweeper.
it appreciates teh IT infrastructure or it gets the cattle prod again
mindless outsourcers, contract buyers, and CIO magazine readers
In other words jobs and people you know nothing about, sort of like how executives know nothing about network infrastructure, right?
Disclaimer: I'm not "picking on you", I'm acknowledging you are human.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
Nice to see someone who gets it. I've been in the IT infrastructure business for many years now, and I think that plumbing, electrical, or another skilled trade is exactly the right analogy.
The problem with that analogy is that plumbing, electrical, and HVAC are all extremely front loaded costs with relatively fixed (predictable as you said) long term expenses.
IT is a constantly moving target, subject to hardware refreshes every X years and likely software refreshes every Y/X years.
And no one ever said "hey, we can cut back on the maintenance for our HVAC because what does that guy do anyways?"
[Fuck Beta]
o0t!
Coincidently the electricity went out at my home last night (after the pole went off like a giant bug zapper). A truck turned up within 30min, someone had told them I had seen sparks so they knocked on my door to ask me what I had seen. The lights came back on soon after. it was cold and raining pretty hard, I put a jacket on went up to where they were working and shouted "thanks gents", the enthusiastic reaction from the group of wet and miserable men told me it doesn't happen to them everyday*. It's not hard to put a bit of cheer into someone's day, especially when they are having a rough one and still get the job done, but don't fuck it up by expecting, me to go out in the rain and thank you for doing your job.
* I already knew that - the first half of my working life was day labouring and blue collar jobs, if you have never been part of the "working class" then you don't know what "underappreciated" feels like. After 15yrs "digging ditches" the first thing I noticed when I moved into an office job was that people said please/thanks just for doing your job. I know they don't really mean it, it's just good manners.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
Meanwhile, the janitorial staff are over on their blogs asking "how can we present a compelling story to management?"
I would explain this by noting that IT infrastructure is generally a little more complex than utility infrastructure........
I'm an IT geek by trade (embedded systems) but in a past life I have a degree in electrical engineering. It's STUPID SHIT like this I here all the time. Straight IT guys thinking they have the hardest job in the company, only because they have no f#$@%ing idea what's involved with anything else.
Software guys occasionally have a clue, but admins can be completely clueless about how much damage some of their relatively small stuff ups can actually cause.
Infrastructure should be boring. Cheer the boring. If there is a time period where things just went smoothly, put a big exclamation point on it. And, then list why.
Things like clean failovers.
System patches without downtime.
One other thing that is a pain at my company that you could also show it provisioning speed. When requests come in for VMs, or hardware upgrades how fast a re they served. How many are queued, how many are awaiting management approval, waiting on vendors, waiting on quotes, POs, etc... That is also a great thing to show improvements on. Because if infrastructure is slowing new money making projects from getting off the ground then that is a problem. And, those projects are going to move to cloud services in an attempt to get around infrastructure for good or ill.
Move over to the Engineering/R&D en masse, then they'll really appreciate your work when nobody is doing it (or at least doing it correctly).
Have a squat over at the hobo house.
Wish I had points to mod parent further up.
Yes, IT infrastructure is complex. So is electrical, HVAC, plumbing. As with those jobs, some of the work is simple maintenance that can be done by almost anyone who has received the proper training, some requires large amounts of experience or talent or both.
The relative complexity of the systems depends on the installation. For some engineering firms, the IT infrastructure may be quite complex relative to the other systems. For some industrial applications (like chip fabs), the environmental control may be extremely complex.
I'm not saying this to diminish IT, it does require excellent people who put in a lot of effort. Its just that other infrastructure support also requires very skilled people, they just happen to have to literally get their hands dirty.
Those who truly remember the problems when "the lights were off" are happy when the lights continue to remain on without incident for long periods of time.
This is the age of big data and statistics, and it sounds like your succeeding at keeping your company running, but failing at providing insight and understanding. Learn about statistics, run some analysis, and provide some historical trends. Bonus points for then taking those trends and translating them into projections, and giving your senior management something they can use, instead of drivel they don't care about.
IBM has lots of smart people who try and do this. What they've found across their client base is that
IT spending = minor adjustment * vertical percentage * revenue .5-2.0
minor adjustment is company specific level of enthusiasm: usually
vertical percentage is a percentage of revenue spent across the vertical
revenue is the company's revenue.
Tableau.
Great for storytelling!
Come to the developer party. Work towards enabling your customers so they can deliver faster, more frequently, with less risk for less cost. Get involved in the development process. DevOps!
"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?"
I think that's suggesting that money is a concern, but maybe you read it without seeing the last bit of the sentence there.
I remember a while back that a major bank in my city had a huge incident where one of their admins accidentally triggered a deployment that formatted the disks of a significant number of their desktop fleet.
A story like that will soon convince the higher-ups that the lack of a similar event is a good thing.
Give up. The battle you're trying to win is lost and it can't be re-fought.
Think of IT as a business. I mean a real business, with marketing, expenses, revenue and profits. This is for the sake of argument only. Now understand that most businesses, they want competitive advantages and barriers to entry. They want an infinite range (theoretically) of services, at an infinite range of costs. That means they can enter any market in their segment at any time. They can grow immensely. And most importantly, they can always defend against competitors.
So for instance, suppose a customer comes to mythical IT Inc. and says, "Hey, JoeIT Corp. over there, they sell Service X for 15% less than you do! Are you trying to rip me off? Give me 15% off my contract or I'm leaving you and going over to JoeIT Corp." If you sell a commodity, then all you can do is stand pat and hope that your customer is bluffing, or chop 15% off your price. If you have an infinite range of service variations your options go up dramatically though. Now you can respond, "Wait a minute. We give guaranteed 30 minute callbacks, we handle 3D printers, and our staff specialize in your industry. JoeIT Corp. doesn't have any of that. In fact why don't we talk about handling some real business value-added problems for you. We think we can increase your revenue stream by 20%!"
See what I mean?
The problem that IT has, in many cases, is that they have allowed themselves to become commodity service providers. We sell a standardized, boring, reliable service. However we can be trivially compared to other service providers and the main differentiation is price. This is the utility model. It subjects IT to continual cost-cutting pressure because IT is not in the loop to make value-added revenue contributions to the business.
This sounds like the OP's case. And the thing is, once you're in the commodity business, it's extremely difficult to break out of. In order to do it you need to:
A). Convince the business that you can handle significantly different problems;
B). Spend more money on you.
Usually this will require a different head of IT with a completely different message for the business. And the business has to be ready to hear a different message. Good luck with that!
There is alot here, but doing the following stuff is key to showing management in a concrete way how the work your team is doing translates to the health and performance of your infrastructure.
Upper management loves to see metrics. Think of it like the financial side of a business, one that they usually understand really well. There are tons of pertinent numbers in financial reports that detail how healthy the company was during the previous months or quarter. The servers are there for a purpose; for instance, a SaaS company that has a website has the servers to support a website. In this example, there are tons and tons of metrics that should be recorded that detail how healthy a website has been in the previous quarter. You should be recording stuff like website response times, HTTP return codes, website up time/availability, network traffic going in/out, database response times, and you should also be recording metrics on the business side as well like monthly fixed costs (like datacenter rent) and variable costs (like new hardware purchases), maintenance periods, projects completed, man hours spent on projects, and man hours spent on firefighting.
If you don't have anything for recording tech metrics, look at something like zabbix (zabbix is pretty easy to setup, uses a gui for configuration changes so its easy to become productive, and you can use mysql as a backend for storing the metrics, which would allow you to run adhoc queries to generate aggregate stats that you can't easily see by glancing at the graphs that the tool produces). With all of these metrics, you can produce reports with graphs and numbers that management can digest, and it has the added benefit of giving you the larger view of your site to help you identify problem areas that can't be identified by stuff like nagios (e.g. problems like response times that go up during high traffic times can identify issues like bottlenecks or overloaded systems that either need more resources or more nodes).
Again, the purpose of these reports is to show how healthy the site was and hopefully how the work that your team is doing is improving the customer experience. So, you should show how happy the customer was with graphs and metrics that show stuff like http response times mapped against site load and how your team has improved response times compared to the previous periods/weeks/months/quarters even as the site load has increased from the previous periods. You could also graph http return codes aggregated for each day and hopefully show how 200s steadily increased and 500s/400s/etc. have steadily decreased from the previous quarter. There are a ton of different cool graphs like these that you can produce. You should also look at the metrics graphs and try to create bullet points where you explain site behavior by correlating the work you have done with marked improvements in the metrics. For example, if you have a graph that shows non-optimal response times in the previous time periods and if you addressed the response time issue by adding nodes, you should be able to point out the point at which the project was completed and show the improved response times. You could also show how money spent on improving the site has had a positive effect on the customer experience, for example, if you bought and implemented new database servers because the old ones were causing slow response times, you could graph database response times and show how those times have improved after the new servers were implemented. It is also good to be able to show management how IT costs correlate with site load and site performance (e.g. at larger time scales, show the number of requests your site is receiving or the average response times of the site mapped against costs on a daily/weekly/monthly/quarterly time scale. If the site is healthy, growing, and managed well, and given the previous example you should see how the increase of costs of IT map to more customer traffic (and hopefully if you scale the site well, your average cost per request should be decre
If your execs don't understand tech. That's your choice to work for overpaid unengaged people. I suggest you'd be happier working for a company that actually understands what you do in the first place.
If we techs work for people who don't care about technology, that's our fault.
Why do you give status updates? What does it tell them? Nothing. That is why they are so bored.
... You notice that I put the word management behind every aspect. That is because all these aspects require activity on your part (and choices are to be made). Choose your aspects in a practical manner (lets say between 20 and 30 items).
What they really need to be able to do is 'manage'. Giving them status updates (about service levels) are not the information they are looking for. Managing is about achieving a goal having certain risks and costs. Your goal is having happy customers about the service you provide. Even though that is formalized through SLAs, that will never be why a customer stays or goes.
The reason that it is difficult to tell anything about the 'process' 'providing service' is because it is a very undefined business process requiring skills on all sorts of areas. I prefer to say something about the aspects of the process. These may include e.g.: security management, incident management, hardware management, external supplier management, hr management, personnel knowledge management, building management, computer system management, release management,
The next thing is that you identify the following for every aspect: You describe shortly the current situation (e.g. operating system mgmt: We are running Debian Wheezy with automatic updates on wednesday because that is our service maintenance window. Sometimes packages are necessary from upstream). You describe the 'ideal situation' (e.g. for personnel knowledge mgmt: We would like all tasks to be able to be completed by two persons because people have holidays or may be sick. We have weekly knowledge sessions). You describe already known issues that need to be fixed. And lastly you give a grade: 1-5 if this aspect is a risk getting you goal achieved and 6-10 if you are (firmly) in control of the aspect. Remember: A 10 is probably a waste of money and other resources.
If you covered your area well, described all relevant aspects, you will then get something new: You are able to identify the largest risks (even if they did not go wrong) and unique selling points. In 9 out of 10 cases you will realize you are far from done with your work. In the 10th case you realize you can do your job with fewer people. When you have identified your aspects you should (partly) report on that.
Btw A great marketeer once held this speech. Since you are presenting something you should know a little about marketing (which is about making people enthousiastic).
nosig today
"This month, we set up a new system for department X that helps them accomplish task Y in 50% less time"
Work to build an understanding of senior management business objectives, work to align your scorecard to key business goals and initiatives and focus on performance against these in your report, senior management will be able to relate to your contribution and may start to see IT as a value partner in achieving business agility and industry leading performance instead of as a utility provider.
it might be tough to start with as you will be starting to report on their expert area and from time to time they will have a different perspective on success to you but if you declare what you are trying to do up front then you can likely buy the cooperation of a key business sponsor that can help you speak their language and make it work.
You made the point yourself - nobody cheers when the lights come on, they get pissed when they go out. IT SHOULD be boring and dull. To an average person in your company, they shouldn't - EVER - care about how or why their systems work.
Electricians don't accept that state of mind when people overload a circuit, stick their tongue in a light socket, or open up a neighborhood transformer with a crowbar to steal the copper coils. Ignorance of good computing practices thankfully isn't quite as dangerous, but it can become very expensive when someone decides to copy confo-info data to a personal system "to work from home" or the like.
And we're not heroes or geniuses.
Except due to the nature of our profession, a disproportionate number of us are geniuses or at least way above average. It takes some serious intelligence to be an effective IT worker, whether a desktop repairman, software developer, or server admin, whereas it really only takes average intelligence to be an effective electrician or plumber. Below average for effective janitors (another term applied to IT occasionally).
We're plumbers. (Except that we're too dumb to unionize.) If anything, we are incredibly lucky that our users are satisfied with the - in most cases - poor level of service they receive.
This is newer, and a combination of two factors: the influx of people into the lower levels of IT who really should be janitors or plumbers, and the increasing complexity of the systems themselves. Add specializations into the mix (as new as computers in the workplace are, it's even newer that the "desktop guy" doesn't understand networking, security, server administration, etc.
Think about it - in all the time you've worked in IT, how many times have you seen the electricity in a building just go out, without explanation?
Several times. Once, the backup batteries caused everything to go down for several hours.
Now, how many times have you seen major server outages, costing more than a million dollars in lost productivity?
When it wasn't caused by electrical or outside factors? Never in a company I've worked.
For me, I have never seen an electrical outage not related to a major disaster that kept everyone out of the building anyway.
The electrical outages I've seen were never the result of major disasters, and didn't force people from the buildings except to go to lunch or leave early. I've seen plumbing disasters cause hundreds of thousands of dollars of damage (to service and infrastructure) in a server room. I've also seen a backed up toilet clear a business' floor of workers, causing a huge loss in productivity (to be fair, that was the city's fault not the plumbers who installed the toilet).
by Tracy Kidder. It grabbed my attenetion.
Recruit a popular scriptwriter and cast hot, young leads.
Ignorance of good computing practices thankfully isn't quite as dangerous, but it can become very expensive when someone decides to copy confo-info data to a personal system "to work from home" or the like.
http://yro.slashdot.org/story/...
IT now gates an organizations' product and marketing strategies. If the IT infrastructure inhibits rapid development of the applications that keep the organization ahead of competitors, ...
And if IT is not gating those, they are't using their IT correctly.
As has been pointed out by yourself and plenty of others, most people really don't care until it's not working. Pretty much the only thing you can do to give them some appreciation, without actually breaking it yourself, is to tell them about somebody else's that broke. When you go to make requests and recommendations, look for stories justifying them. For example, if your backup structure isn't robust enough, tell the story of Tim Lloyd and Omega Engineering; the guy got fired, wrecked a company server and cost them $12 million, in part because he took out the only backup they had. A more robust backup solution may well have saved all that money.
AC OP has overstated the simplicity of the electric grid but his main point is still valid. Power is a bit like cable TV, everybody gets the same subscriptions. People don't care what power plant has generated their energy. As long as power is available within certain parameters it's good. People do care a lot which bits they receive from a network. If they get their colleagues email instead of their own it's mostly worse than not getting email at all. The storage and processing of information is continually changing to adapt to needs of all kinds of organisations and people. If you compare the number of people working in electric utilities to the number of people working in IT I'd say IT is about 10 times as complex.
utility workforce http://energy.gov/sites/prod/f...
IT workforce http://www.globalization101.or...
I had to do weekly status reports once - after a couple of months, no one had ever looked at them, and I stopped, and no one ever said anything.
not to mention banks of giant capacitors to keep your voltage and current in phase, reclosers and other safety systems to enable quick recovery from interruptions due to small trees or animals on the line, and humans who can respond quickly to more severe and dangerous problems.
If you must moderate, please moderate as irrelevent, not something bad, because I'm sure someone will find this interest
Actually, the analogy ISN'T valid. While electricity generation is reasonably complex, delivery is relatively simple and there is a singular product. Additionally, consumer demand on electricity is on or off, and perhaps if you're thinking that way, "more".
They don't provide highly complex systems. IT does. I can set up a file server in ten seconds. But it takes a little more work to maintain a complex hierarchy of user permissions, grouped appropriately to business needs. Which, of course, change daily. Or I can provide internet access to the office easily, but blocking some sites for some people - in different groups that change regularly - requires a complex system. Complex systems are prone to failure in any industry. Can the electric company put in a system that only lets me turn the power on in my bedroom, and prevent unauthorized access? I do that every day.
In short, the products and services infrastructure provides are highly complex and ever changing. Electricity simply isn't.
That's kinda backwards except at unusually ignorant companies. When a system works without fail, that means it is properly funded and staffed. It is possible that it is over-funded and overstaffed, so it is something that would likely be reviewed. But, few managers thing that a system that crashes regularly is normal. That would indicate incompetence or or possibly good people not allowed to do their job. So if a good system deteriorate and it correlates to changes in staffing and/or funding, that would be noticed. If it isn't noticed by higher management, IT management should have the metrics to make a report showing it over time. I know correlation isn't causation, but it makes for a decent argument.
If you must moderate, please moderate as irrelevent, not something bad, because I'm sure someone will find this interest
Like the electric company, yes, you should strive for 100% uptime. But that should be a footnote in your report. The main report should show how you have leveraged IT to lower costs in other areas, make the company more efficient, and you've improved the customer experience in a meaningful way. Stop thinking your job is to keep the computers running. Start thinking your job is to help the company run better.
What have you done outside IT today?
LOAD "SIG",8,1
LOADING...
READY.
RUN
I used to work for a large "test equipment" company and a friend of mine related this story when he was on a sales call to the IT department of a top-3 US bank. His job was to demonstrate/sell a new telecom analyzer so while on-site to the entire IT department and management at HQ in San Francisco (narrows the perp down for you), he hooked up the analyzer to one of their T1 lines and proceeded to show how you could strip off any channel or bonded set of channels in the T1 stream at will.
One could hear conversations going on with employees as they skipped through the channels. One of the lines had a modem connected. Management was clueless and asked "what's that sound". "Oh that's a modem". So he immediately launched into an added feature which allowed the modem data stream to be split out and decoded. Text started passing by on the screen. "Oh, that's an account number" some bank minion helpfully volunteered. "And there's the bank and teller IDs" and then a 4-digit number went by. "That's the PIN!" the same naive waif volunteered.
A senior manager with more awareness immediately piped up: "No one saw that!" and then "This demonstration is over. We never want you to ever return nor will we ever buy such equipment!" My buddy and the sales guy were promptly escorted out and sure enough, they and our company was "black listed" by the bank.
So the point of this is that the top banks in the US primarily believe in and operate under "security through obscurity", and would rather cover-up security problems and risks than either plan for them or react constructively to them when uncovered. The bank in question also does not have a patriotic name though it's likely that particular "patriotically named" bank would't have reacted any better or wiser.
it strikes me that if you have to ask, there probably isn't a compelling story to tell. why do you feel a need to tell one? the best IT is an IT that no one is aware of. IT *should* be an utility. if it's not, you're not doing your job.
Tell them that the XYZCo. just hired 5 more workers, increased uptime by 5%, AND increased ROI by 12%. Hell, use my numbers. Unlikely they'll know how to check.
Electricity is, outside of the actual generating plants, just wires.
And transformers
which are just... wires wound into coils.