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?
What do I think? Lots of luck!
Your first priority should be to interview people about their needs. Try to get one-on-one face time, and talk about what kind of challenges your company faces. By going to the end users you'll be better equipped to both help management select a suitable package, and motivat people to use it by being able to say: "Remember that problem we were talking about? You can use this software to solve it now, let me show you how."
Another very important thing is to do regular follow-up on how people are using the software. A common mistake is to provide the tool only to realize months later people aren't using it.
Far too much in IT is techology-centric. Techology should be people-centric. By going users first I can practically guarantee you'll have a greater chance of success.
.: Max Romantschuk
Stick to the particulars of the software. What are the technical requirements (hardware, network, etcetera)? What level of support staff (DBA's, data entry, etc). What, if any, changes to work flow? Keep that to a minimum if possible. And how does all that affect the bottom line?
...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.
series on Netflix, then demonstrate that you know what the letters "IT" stand for.
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.
I'm a business guy with an IT background, so I've worn both hats here. The key difference between you and the people you're teaching is that they are almost entirely results oriented. As IT people, we like computers. We want to know everything about them. We like tech oriented solutions to a problem that are fun and cool even if they're not that practical. Execs are different. They want to know things that will make their company run better and improve the bottom line. Understand this, and plan out the course accordingly. Focus on the key stuff they need to know, and explain why it's important they know it. If you can't explain why they need to know it, they probably don't. Also understand with regards to Open Source that they aren't interested in ideology. They want to know what the advantages are for open source, and how to make it work for them. If there are drawbacks, they want to know them too and how to get around them. Also understand that they don't want to know really low level detail. They've got developers to handle that stuff. They don't need to know how to code, just like you don't need to know how to write and analyze a cash flow statement. What they want to know is the information they need to make informed decisions.
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?
The most important thing to do at this stage is to set expectations:
1. What ERM will streamline (including headcount that could possibly be eliminated)
2. The investment required: the customization needed to match the current business process (or even more complex: taking the opportunity to streamline the business process at the same time). The investment is not just $, but also time for requirements gathering, UI mockups, etc.
3. Most importantly, the problems that can be expected: downtime (and whether there is any fallback plan to paper?), and kludges due to failure to capture all requirements (e.g. putting critical information in the "Notes" field).
In short, management needs to know ERM implementation lifecycle, not nuts and bolts.
but she drives it quite well and she DOES not need to know about how engines and transmissions work. Yes, it would be nice, but it is NOT necessary
You are going to lose your audience if you give them the "basic components and architecture -> networking -> software -> proprietary vs open source".
Without knowing your product, I am betting most people will use it using a web browser.
Here is an outline:
What the ERM will do for the company (I presume they already know this, so no more than a few minutes on this.
To run the ERM, we will need:
new server? (why?)
new computers? (why?)
new network? (why?)
This is how you will use it:
A
B
C
As in dollars, quarterly earnings and PowerPoint charts. Product X will cost Y to purchase and take Z amount of time for configuration, training, etc. Here are some charts showing the projections of each of option in pretty colors. Communicate everything in dollar amounts, time and direct visual aids.
We upgraded a dinosaur legacy system for all the functions..yes.. ALL.. at the University I worked for.
Give a brief how great the software is schpeel then teach the boss-appropriate functions/screens (reporting mostly I would assume) and expect to live a life of "whats this?" and "I need a special report".
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.
The reason they don't know it by now is because it is totally irrelevant to their job. They employ nerds to handle that shit, and all they need is a "yes, we can run this", a "we will need to spend $X to run this" or similar.
All you're doing by trying to explain the technical side of things to them off the bat is offloading YOUR JOB onto their shoulders. The technical stuff is none of their concern. As far as management are concerned, IT stuff should be like magic. They don't need/want to know the details, they have other things to worry about.
If they want to know the technical details, they will ask for more detail, e.g. "Why do we need to spend 50k on hardware?" and even when explaining that, be brief and non-technical. E.g., "our current storage capacity is insufficient" or "our hardware was never specced for this kind of workload and needs upgrading".
If and when more details are required, go into more detail. But likely, more detail will seldom be requested because the details are supposed to be handled by the IT guys.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.