Slashdot Mirror
Ask Slashdot: How To Teach IT To Senior Management?
New submitter gagol writes "I recently took a position at a small industrial equipment manufacturer. We are looking to buy a new ERM software package and my boss, who is looking forward to buy the thing, knows nothing about computers or software. I will be providing basic IT training to the senior management and I am looking for your input on the scope and content of said training. I am thinking: basic components and architecture -> networking -> software -> proprietary vs open source. What do you think?"
to get what they want done. My experience is adults learn best when a clear reward is in sight. Also, don't forget the tried and true method of adult education:
1. Tell them what you're going to tell them.
2. Tell it to them.
3. Tell them what you just told them.
I know, it sounds silly and redundant, but it's effective.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
If you are going to be training senior management, focus 100% on the ERM software and how they can use it for their business needs. They could likely care less about the underlying plumbing and it would take much more time and effort than they'd be willing to undergo, plus it's not in their interests to do that. That's why they hire smart IT guys, right?
...that when most people ask, "How does it work," what they really mean is, "How do I work it?" i.e., they really only want to know which buttons to push to get their desired result. It's like the Automat: you put a nickel in the slot, turn the knob and pull out the sandwich. How the sandwich got there in the first place is of no interest.
Computers are magical objects to most people, inscrutable machines which perform mystical tasks if the propler incantations are performed. And most people seem to like it that way.
The closer you are to the code, the happier you are. - Ancient Geek Proverb
you don't.
Fair warning: these people don't want to be taught about IT. They want a powerpoint presentation about why the choices they have made (ie, you have made for them) are the right ones (other hint: "our competition is doing that" is the best argument, by a mile). That's a good place to sneak in a few limitations you anticipate to cause issues too, so you have an "I told you so" fallback.
The Cloud - because you don't care if your apps and data are up in the air.
They care about three thinks: cost, results, and risk. Don't waste time talking proprietary vs open source. They don't care about software ideologies. They need to know what infrastructure upgrades may be required (in both networking and hardware). They need time estimates. Get their requirements first. Then do your homework and put together a proposal. Then go into pitch mode, not instruction mode. Be ready to defend your decisions, but don't spend alot of time upfront explaining your decisions. Focus on what the software is going to accomplish, not on the details of how it works. Focus on asking what they want. Perhaps you can already tell that a major network upgrade is going to be required. Fine. Be ready to speak to that, but have ONE high-level slide ready to describe what they need. If you make it into a seminar, then you've already lost your audience and your project is off to a horribly rough start.
Here's an example of how this works.
Suppose you are trying to sell a new computer to a company - an older machinist's shop whose office is still using Dos.
You *could* say "these new computers are dual core, 3 GHz, running Windows XP and Office suite". Their eyes will glaze over and you won't make the sale.
You *should* say "these new computers will save your company $2000 per month. Here's how:" ...and list the ways that the new computer will save them time. An hour here, an hour there - it adds up.
Present things in ways which are important to the listener. The big three are 1) Saves money over the long run 2) Saves time over the long run, and 3) Saves effort over the long run. Frame your information in those terms.
None of those issues matter to them at all. Unless you get to lead the requirements discovery process, odds are the decision will be finalized in haphazard manner without much thought about the technical details or the final desired outcome. As the technical guy, they'll leave it to you to sort out the details, so beware of becoming their scapegoat or janitor later on. They have a hope that this software will provide value to the company. Your job is not to squash that hope, but bring expectations down to realistic levels and make sure plans and commitment for the future is peroprly in place.
The best thing you can do, is demand to be in charge of the full requirements gathering process. If you are only technical, it should be in cooperation with someone who knows the functional requirements of the company, which will and should be given higher importance.
Point is, the more you take initiative early on, the more you get to shape the process and highlight what is important early on. On the other hand, if you come off as a techy smart-ass, that'll backfire sooner than you can say "sorry". There's very little that can substitute loads and loads of experience with clients here, so if you're not that experienced, better play it humble and try to seize opportunities only where you are sure you can make an impact.
As a spur: Who will support this software when it comes live? If it's you, you have every reason to tackle this as early on as possible. However, if you're going to get them to listen to your technical details, you'll have to leave out the details and come to the gist of it in 2 minutes. That's why they hired you, not to be taught lessons.
Imagine giving those lessons to your grandmother. What use will she make out of it?
It sounds to me like you're trying to sell them on how 'well rounded' and 'IT-intelligent' you are versus actually knowing the business you were for that your IT department supports to make the business successful. If you want to get them comfortable, then perhaps you are the one that needs to be educated in 'suit/business talk'. IMHO, all you're asking for is two things that will totally work against you:
1) Loss of interest after about 10 minutes because you're either in the weeds too much and you eventually work you way back to the IT closet you came from
2) That 'one' management component that slightly cared about your teaching tutorial, has an internal epiphany, and now uses their scratch-on-the-surface knowledge to contract all your future ideas, decisions and pitches.
I think it would be your best interest to figure out the cost savings, increased productivity, product improvement, upgrade/growth/implementation strategy, ect. ect. ect. and maybe go back and find out the mission statement you are working for to begin with as well. You seem to only be concerned with getting that new, fancy IT toy at your place of employment and less about how it helps the company that employs you.
Exactly. In reality, it is YOUR JOB to insulate the CEO and other upper management types from having to deal with this sort of bullshit. This is why Apple sells a shitload of gear to people like your CEO. They just want stuff to work and don't care about the implementation details. Window colours? Irrelevant. Theme on their phone? Irrelevant. Ringtone? Irrelevant.
Bringing petty technical decision making bullshit to upper management level types is failing at your job. Unless they ask for more detail, abstract it away into dollar figures and man-hours required.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.