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?
Give them as little training on IT stuff as possible. There's a reason they don't already know it by now (either they don't want to, they don't care or they can't grasp it).
Make yourself available to anyone in management who may have questions or the desire to learn more, but for the most part train them on the software but not on things that they don't need or want to know.
What do I think? Lots of luck!
You can start by not buying one that only works with IE 7 and XP after blood, sweat, and tears, getting off IE 6 and XP to Windows 7 only now to reverse a whole years worth of work to downgrade because the CFO read about it in skymail on his flight to Brussels!
http://saveie6.com/
Tell them to trust IT to make the right decision for them.
Just research the best option and present that. Don't give them a choice between the ideal solution and a runner up because it will just make them argue and possibly select the wrong product.
The only thing they should bring into the decision making process are the business requirements. You set the technical requirements and then find the package that covers them both.
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?
"How to teach IT to Senior Management" - I think the question is wrong.
You cannot teach anything to people who call themselves "Senior Management" or in a company where such terminology is used.
If people in executive level positions are not genuinely interested in what you do or don't have a technical bent of mind, I think one should look for a change of job..
Seriously guys, don't waste time fighting bureaucracy or reading documents written by 'architects'.
If CXO/'senior' level people walk by your cubicle/desk/hole and seem genuniely interested in what you do , work for the company or quit.
No point increasing your stress levels for people who do not want to understand what their employees do.
OK, start with the file system, possibly explaining with real-world files.
Next, move onto what each part of the computer does (the CPU is the brain, the RAM is a scratch pad, the long-term storage is like your filing-cabinet, etc.)
Then move onto turning the machine on. Then explain WIMPs, and (if you want) the differences between GUIs and CLIs.
Look at word processing and spreadsheets (be sure to explain styles, and the difference between look and semantics). That leads into HTML (but briefly, so they don't get scared when they see it), and the web and networking more generally.
Explain the Internet, and how it's made up of various things, such as email, the web, IRC (and other chat systems) etc.
Explain the specific concepts related to the software you are going to be using.
Finally, teach the ins and outs of that software.
Most of all, stay clear of focusing on a particular piece of software. Don't teach MS Word, teach word processing. Don't teach MS Windows, teach WIMP and GUI. And only once they grasp the basics, do you teach specifics of software packages. Test them, make them produce a document that looks identical (when printed) in two different word processors. Have them provide a balanced budget for a trip, in two different spreadsheets. Etc.
And sucks to be you, to have gotten the short straw.
HELP MY ACCOUNT HAS BEEN HACKED BY AN ILLIBERAL ART STUDENT SET TO DESTROY THE INTERWEBZ!
...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.
Is to frame the whole thing from their perspective, i.e. businessmen competing in a certain market, who need access to timely information and to have data stored in a reliable fashion. They don't want to know too much about the technical details, just enough to give them a warm fuzzy feeling that their money is being well spent. And an elevator spiel on each of the important buzzwords.
Then tell them grades will be posted on the bulletin board. Then tell them if they get less than a B they need to take the class over again.
There might be a valid reason to explain the plumbing, and that's if what's being proposed might have problems. Then you'll want to explain just enough to them so they can understand what the issue are, so that they can decide if it's an acceptable problem, or something that needs to be dealt with.
Of course, if they've already decided on the ERM software, and all you're doing is criticizing their choice, this might not be useful.
This is *not* a time for proselytizing about open source software ... that's just going to make you look like a nutter and might ruin your credibility. Establish yourself as an expert first, and sometime down the road you can casually mention those sorts of things.
Build it, and they will come^Hplain.
A shock collar might not be sufficient. Seriously, in my considerable experience with this situation the biggest problem is their expecting a quick sound-bite to tell them everything they want. When that fails, as it must, they will blame you.
A second issue is their weak math/logic skills for mentally organizing complex new information. Your one-sentence syllabus is already far too much information for any C-level person to absorb in one sitting.
Rather than trying to be complete and accurate, you should identify a list of simple facts you want them to know. Express each fact in a simple sentence with visceral impact. Emphasize it with a physical prop. Example: "Real-world software is more complex than most people realize." Related prop: Source listing, on paper, of software they can relate to their own work life. (Strap it onto a dedicated $25 hand truck for easy re-use.)
Do not try to paint a big picture, it will just annoy them and they will direct that annoyance at you.
Bent, folded, spindled, and mutilated.
You're going to end up teaching him enough just to get yourself in trouble.......
"The average reporter we talk to is 27 years old......They literally know nothing." - Ben Rhodes
This Buzz Lightyear laptop should do it. It has all the fun games and lessons a PHB will ever need,
Stick Men
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.
I hope you get paid a ton.
Teaching IT to managment... Your job just got 1000x harder..
Bet your pay didn't go up even 2x.
What you really want out of this is these senior management people will do their best to make this ERM a success. So you can start with what do they feel as success for the ERM, and then ask them to see what must happen to make it a success, and then what they need to do to to to ensure that it is a success. During this discussion, you can tell them the features of the system that will help them to make ERM a success, and what IT can do to help them.
It is important for them to realize that it is their job to make it a success. It is their system, and not IT's.
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 realized that in almost every job I've had, there was one person (OK one guy) who was an absolute genius at this kind of assignment. They were socially dominant and socially aware (i.e. not video game addicts) talkers, who often took it upon themselves to give training to the newbies.
The funny thing about it is that if you transcripted what they said and read it back, it would look terrible. It wasn't because they didn't know anything - they did know something, but were hardly experts on the subject. None of them were star engineers. But somehow these guys had confidence and presence and made people feel like they were getting something of value, even if that was an illusion. If someone asked a question about something they didn't know about, rather than look puzzled or admit they were stumped, they would segue into a topic on more comfortable ground, like a politician.
BTW you might guess that these guys were fast trackers to senior management, but for most of them I've look up in linkedin, it hasn't turned out that way. After they turn 40 or so they have to start scrambling to stay employed, like a lot of us I guess.
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?
Don't waste your time teaching ideology. Just teach them what they need (the ERM)
Open Source Java Web Forum with LDAP authentication
They don't need to know most of the details. You need to present it as an assortment of rectangles on a diagram with lines between them. Make sure everything that will need funding or time spent on them is represented by a rectangle. You can then do the entire discussion at this level (if you've got it right). If really necessary then you can drill down to the details of what is inside the rectangle, but that shouldn't be necessary if you've presented it right. If their job is to manage, they don't want to know details, they just need to know that everything is covered or planned for. If it looks like you've got everything covered, they will be happy. You may need to learn their way of thinking / talking in order to translate your requirements into a form that they will understand.
I recently took a position ... I will be providing basic IT training to the senior management
You might think that's what you're doing, and you might even make a spectacular job of it, but there's a reason why they're where they are and still don't know anything -- That's what they do. If they knew anything they wouldn't have those jobs. Good luck.
Whatever you do. DO NOT TEST THEM to ensure they know what they've been nodding their heads and agreeing with.... That's why it's you, the new guy, who's tasked with this job. The folks they'd actually listen to are wiser than to risk their job by showing just how dumb the management is. When they come and ask you questions about things that YOU JUST "taught them" about yesterday, just grin and politely show them how. Enjoy your life at the bottom of the totem poll. If you survive the ordeal, maybe you can convince HR to find you an underling you can feed to the wolves one day too.
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.
With a cluebat.
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
This book is all you need.
There is good description on Nestle's SAP - Implementation around, it talks about how they approached the project (review and simplify business procedures, 'why do we need 10 different ways to write a PO?), how they picked the project team (that could implement the changes AND keep the business on board), and what is in it for them (Nestle earned a considerable investment back in just a few years). IT stuff yes, but preferably in the form of decision support ('go open source because flexible/cheap/transparent, alternative SAP possible. More established, but usability/cost/integration make it less preferable. Or the other way round, if that is your recommendation)
Should they ask a lawyer to teach them enough about the law to make a decision about a legal matter? No, they should understand that Law is a complex and difficult field that they know nothing about and it takes many years to master before they could possibly make an informed decision.
Should they ask a doctor to teach them enough about medicine to make a decision about a surgical procedure? No, they should understand that Medecine is a complex and difficult field that they know nothing about and it takes many years to master before they could possibly make an informed decision.
Should they ask a CPA to teach them enough about high-end accounting to make a decision about a compicated financial situation? No, they should understand that Business Finance is a complex and difficult field that they know nothing about and it takes many years to master before they could possibly make an informed decision.
So why do these "senior managers" think that they can somehow learn enough about IT to make informed decisions about complex IT matters? Do they really have so little regard for the professionalism and depth of knowledge of senior IT practitioners that they really believe they can learn all there is to know in a few short lessons? That is the apogee of hubris!
What you should do is:
1. It's much easier if you put together a list of possible solutions with a cost/benefit analysis of each, then they can make the decision. They get to stick to what they know and aren't required to think outside their comfortable little boxes.
2. Always give them several solutions to choose from. Then make sure that the solution YOU want has the best cost/benefit outcome.
Sometimes the "writing on the wall" is blood spatter...
And a trip to Vegas is they are in doubt about what to buy.
TCAP-Abort
I don't know how many of these types of projects you are going through, but the short answer to what you're asking is the business you are working for is already failing before it starts. IT should not be driving these projects, nor should you be training any stakeholders or managers on what it's about. This is the quickest way to cause any of these projects to fail.
You are quite literally doing this backwards. They need to be involved up front, with a champion from any relevant department. If you're "training them" on what to know, you should expect IT to be blamed in the absolutely normal period of frustration after any large project is rolled out.
For both the sake of the business, and for the sake of your own career, I would highly recommend that you back up, go through the research of how projects like this should go, including looking at successful and failed ones, and attempt to emulate the successful method. You'll discover quite quickly IT being in the position you seem to be in -- even if the IT person is the greatest IT person on Earth -- is one of the immediately precursors to the project failing. The only thing that will make it worse for you is if both IT and Accounting are in that position at once.
But don't forget that they need to be aware of the things that impact their ability to use it. Getting all 10 meg Hubs and running it on an old white box P3 will destroy their ability to do anything with it at all.
They won't have a clue.
See, knowledge that we take for granted, like Open vs Closed source, has been accumulated over years. We have seen the pros and cons, the abuses, why it's good, etc .... They won't even be interested or willing to take the time to read the WikiPedia entry for it. All they want is something that works and will give a decent ROI.
Try explaining all that and everything else in a 15 - 30 minute presentation - because that's all you're getting, if that.
The GP is spot on. I've been there and I can tell you if you get technical at all, they will tell you to move on. Occasionally, you'll get a geek in Sr. Mgt and they'll ask you if they want more info.
To us, tech is our lives. To them, the tech is just to solve a problem. They have other things to worry about.
Quit
If they already think of IT as an 'expense' and not anything that adds value to the business you're wasting your time there.
Or you can waste five years of life trying to "teach them," and become frustrated and disgruntled over their bad decisions.
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.
"Teaching" implies a teacher-student relationship, where the teacher has the authority. This is not that.
You don't "teach" your boss anything.
You "advise" your boss. But only when they request it. And then they choose to ignore the advice, or not.
If your boss actually gave a shit what you have to say, he'd be talking to you one-on-one in person. He wouldn't be asking you to give him and his coworkers a formal class.
So basically you're fucked. But at least you're getting paid for it, right? Here's what you do about it:
Go through the motions. Present material, answer questions, but don't test anyone. And at the end, give everyone a certificate stating that they have attended the class. Expect no one to learn anything. Hold no on accountable to any kind of standard.
Don't spend more effort on this than it's worth - focus on other, more important, parts of your job.
Run down the clock.
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".
Senior Management won't listen to IT people unless they are told the Value of what you're about to tell, and the Risk of ignoring it. The more you can relate to the moneymaking process, the better. Keep the more technical stuffs brief, and if possible liken them to the business process they understand. Other important thing I learned, never make Senior Management looked stupid, no matter how clueless they are, especially in the company of their peers. Good Luck!
The truth about management is this: Whatever you pay attention to seems important to the rest of the workers
Management decides what the company culture is.
If management decides IT could provide a competitive advantage, then it will.
If management decides IT is a cost center, then it will be.
The actual technology has nothing to do with how a company uses it.
Teach them that.
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.
If the company is small, then you probably have the original owner of the company as a part of senior management. If the company is successful, then you likely have the founder. Founders are great. They are usually willing to learn new things, work hard and listen to what you have to say. If the company is run by professional managers, then you are hooped. All you can show them are a bunch of widgets and gadgets and dashboards. They don't want anything else, don't care about anything else. They aren't interested in growing the business or improving its dynamic with the use of computers and software: they are interested in making their next quarter by whatever means. And if these computers can help them do their job, then they will get computers that help them do their job. With the founder, the focus is company. With pro-managers, its paycheck (and indirectly quarterly returns). Having said all that, if it is a founder then you can introduce the concepts generally, tell them that computers are tools that aid, but cannot lead a company (yet). They can find optimal solutions provided they have all the information required plus the software. It all depends on what you want to do. Open Source is an optimal solution for a green field. Its much less expensive, more reliable, and doesn't lock people in. (Run out the clowns who shout "I need feature X", and I reply "Its in there already!, and if it isn't, since its open source we can add it easily, and you can't. Even things that yours doesn't have, we can easily add, and you can't!")
hmmm...tell me how to use IT to make money
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?" This has less to do with tech, than it does with salesmanship. What you are selling here is information - you have to teach them in a manner they will "buy" it. To start, in order to be successful, you should learn who you are "selling" to. Some SM's will want to know everything, some just want to know how much it will cost and how much trouble, other may want to know how it will improve the company. Know your audience is the first step to successful "sales". Save your tech jargon and KISS, and keep your pitch in terms a 7th grader can understand. PP is a good idea, but I think it would be good as a simple back drop, if you use PP, then PP should serve only to reinforce your points. Don't be the guy who puts up a PP slide, then reads off of it - you'll lose them quick that way. My suggestion is to build your presentation and allow for a Q and A, maybe as you go along, or maybe at the end, but I think it is a must that you allow them to ask questions and then answer in front of all of SMs. I suggest a step by step response, so you can make sure they understand it as you go along. One SM may not want to see it the way another does, or may not know how to ask the right questions, biut another does, so this will help you make your case without risking blowback, like "you never told us that in presentation."
Republican leadership = Idiocracy
Senior management? They don't give a shit about you or what you do or how it works. Nor do they want to know. All they want to know is you are making things work and that they aren't bothered.
If you think they actually care about what you do then youre stupid.
Look, how much does the IT department know about accounting, sales, marketing, or a dozen other features of a company? Get real. We specialize.
Management's specialty is management. Yes, they need to understand their business and if senior management doesn't grasp core business services then they're not fit to hold the position. But if the company isn't an IT service business then they don't need to know that stuff. That's what they pay you to know.
What you need is respect and/or trust from management. So that when something happens or you need something to work a certain way they listen to you. Possibly not just blindly do whatever it is you said but treat your recommendation with a high degree of weight.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
First things first, ask all the adult learners to give themselves a 1337 handle (N00b4L34rn is a good example), then make them watch Hackers the Movie, and later quiz on the correct ways to disable a Trojan from a Gibson (as shown in the movie)...
All seriousness, I would just walk through the program step-by-step on a whiteboard and give them notes printed out for later study. They can always bring up issue they have with you later on.
Sort of. What they really want is a presentation about why the choices they made are the right ones, and what they DON'T want is any suggestion that they may have made a wrong choice. That applies even if the choice was so bad that it threatens the company's future. Modern MBA type managers suffer from this delusion that you can change reality by wishing, and it has already otherwise been shown that for most people incapable of critical thinking (that is, most people) showing them why they might be wrong in their beliefs using actual facts often makes those incorrect beliefs stronger. When you couple that with the absolutely insane levels of ego and paranoia in your typical executive suite, you have the utter madness that is modern American business.
Why does anyone, outside of the computer industry, need to know any of that?
The basic components of a computer are the computer, and the keyboard. There may be a box under the desk somewhere, about which no one cares. They have a gas pedal, and a steering wheel. The car goes, and it goes in the direction that I steer. Everything else is optional -- including the gas itself.
Networking is a term that's meant nothing for decades now. The same document can be viewed from multiple computers. That's networking. That's it. No one cares about the speedometer networking with their brakes. No one knows what ABS means.
Software, unless you're creating it, buying it, selling it, or testing it is meaningless. Computers can do things. They can be upgraded to do more things. No one cares about the software in their car.
Proprietary vs open source is industry jargon. There are six types of each, and unless you understand all twelve types, the only thing you can do is get screwed by someone who does. This coffee maker takes coffee. This coffee maker only takes little cups and no one knows what's in the cup. This coffee maker takes these puck-like things. This one has more buttons. This one filters your cheetah-anal-coffee through tampons and the flavour really comes through -- by the way, that exists, seriously.
Just teach them how to read a computer screen in general, if they don't already know how two-dimensional rectangles can overlap -- it's a "three-dimensional-surface", a cool physics paradox. Then teach them that each rectangle is a scope, and how to determine which one they're "in" at any given moment, so they don't always start reading from the top left of the monitor, instead of the window. Then teach them how to explore any random interface, so they feel comfortable browsing drop down menus and lists of links and right-click menus. Then you're done. Let them explore. As long as they don't take out their credit card for anything ever, they're good to go.
Sr. management have a limited amount of time to devote to this and they want to be trained in the system and will allow them to do their day to day tasks better. Take one of them aside (after asking for a volunteer, or who ever the project sponsor is) and run them through your training, exercises, reports, etc. and validate it is what they want. Based on their feedback, you can deploy that training (with tweaks from feedback) to the rest of management. You don't want to spend your time telling them superfluous information, just the facts as they want to know what it will do, what buttons to click, and what it will do for them. If they want more info, say you can be reached for info about this or any other IT questions.
What on planet Zapata is ERM software package? Having worked on large backend ERP business systems (mostly SAP) for past 15 years, I am hearing ERM for the first time in my life.
because everyone hates boring presentations and also people generally already know at least a little pro: 1) you don't have to pick them off from anywhere because they will naturally ask questions starting at their own horizon 2) similarly, you will not by accident kick them into the deep end because you skip stuff that "everybody already knows" 3) probably better participation and rememberability then when doing a lame presentation con: People have to actually prepare, i.e. think for 15 minutes before the meeting about what they might want to ask. Really depends on what is usual in your company, eg. I am sadly used to people showing up for really important meetings pretty much unprepared :P
I've never heard of senior execs that want to learn basic IT, they're not planning to staff the helpdesk. If they want training in anything, it's either
a) Basic use of the ERM package, what it will do for them, where they can find things and such or
b) To better understand the pros and cons of the ERM packages, if the selection hasn't been made yet.
Under no circumstances are they interested in the IT plumbing, so talk to your boss again and figure out what he really meant.
Live today, because you never know what tomorrow brings
Exactly. Getting technical is pushing your job onto them, and that's what they pay you for. If they wanted to learn about IT and get involved in that side of the decision making process, they could quite easily take the pay cut and be doing your job instead.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Any change is very complex. When creating a design agreement, there are inputs from many different groups (not just engineers). You have to take into account legacy systems which interact with the system. One of the biggest eye-openers, was because the old software we used was great at data acquisition, other groups started to usurp that data for their own business groups. Suddenly any change as much as it makes sense breaks those kludged systems and management started pushing a roll back because the headcount and training no longer made it commercially viable
D6 63 0D 70 89 81 BB 8E 7B 7C 5F 5D 54 EA AB 73
LBT -- Listen Before Talk.
I have always found it best to understand users' problems first before trying to teach them what they need to know. Part of that is to learn their language. I spent a number of years working with environmental scientists, and after a few years it was quite common for scientists to assume I was a biologist who happened to do information technology, because I learned to speak the language of biology fluently. In an earlier job I worked with accountants, and learned their language too, all the way down to the in-jokes accountants tell.
I'll give you two really good reasons why you want.to do it this way, rather than try to teach management to be IT experts. First, success in this approach depends entirely upon you: your patience, your motivation, your thoroughness. It doesn't hinge on the eagerness of management to learn about software architecture. The second reason is that you don't want management to think they've become IT experts and mess around with stuff that's over their head. Understand the asymmetry in your relationship with your management: your boss can stop you from acting like you're an expert in his job, but you can't.stop him from acting like he's an expert in your job.
I'm not saying to keep your management in the dark, or not to teach them what they need to know. But first *understand what they need to know*; they've got their own work to do. What they need to know is what they need from you (or your successor), how to get it, and what is reasonable to expect. If you've got the balls to do it, teach them how to hold you responsible -- that's the most important thing they need to know and it shows you're confident in your competence.
The fact that you're contemplating this means your employer is not in some kind of IT field. That means you, as IT guy, are in a support position, not a "line" position. Your job is to take care of other people's needs, just like the janitor is, only you're much, much better paid and so a higher level of professionalism is expected. I know this, because I've been in that position. Take it from me, if you want to be happy in that position, embrace your role as support for the main show. You wan't be happy otherwise. If you want to run your own business, then start an IT business, but if you're doing IT *in* a business, your job is to help the organization do its thing. Your job viz the management is to get them out of trouble, steer them away from trouble, and provide them with the tools they need to succeed.
If you're smart, one of the most things you'll teach them is how to recognize what an amazingly good job you're doing. But teaching them to do your job? It's a waste of their time and asking for trouble.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Are you talking risk management? Or did you mean one of ERP or CRM?
the worst ones are the managers that get too bogged down in the details and don't trust their subject matter experts. The best know to let the people they hired do what they were hired to do and provide an opportunity to expand what they do best.
Managers need to know just enough on a subject to know when they are being bullshitted. Other than that, all a manager is good for is signing vacation requests and approving expenses.
As far as training managers, put together a presentation of what you're doing, why your doing it, two or three options for other ways to do it. the benefits to each option, and have a meeting on it. Smaller companies seem to be a bit tighter on money for somethings, other times not so bad. as long as there is a benefit. Everyone runs an ERP of some sorts whether its SAP, or Excel. They have to have a way of planning and tracking what is being done.
1. Don't teach IT to Senior Management. The plumber does not teach them plumbing neither. You are paied to be IT'er.
2. Analyse the needs. Interview users, senior Management and make a matrix of existing programs using a MoSCoW analysis.
3. Make a bussiness case. Eplain benefits and costs if you get the new ERM and the costs and weaknesses if you don't change to thenew ERM. Make some propositions based upon the MoSCoW analysis. This is language Senior Management does understand.
4. leave final decission to them based upon the bussiness case. Apply the same analysis to their propositions, if they should have some.
You refer to the audience as "senior management," but then you have framed this entire discussion around you -- the enlightened one -- trying to "teach" the bumbling, ignorant executives while tiptoeing around their childlike attention spans. A quick look at your pay grade should reveal the exact opposite. You each have a specialty, but /yours/ is the narrower mindset with the smaller impact on the organization. And they may be bored by technical details, but when it comes to the operational and strategic details that drive the day-to-day success or failure of your company, /your/ attention span is the childlike one. Want to see a bunch of snoozing engineers? Put them in a training session about how to extract more money from customers. :-)
In order to be truly successful with your goal here, you need to step out of your world of IT and let your audience teach you something. What were they doing before they came to the class? What are the problems facing the company right now? Why are they requesting the training? If there is an optimal outcome -- publicly congratulating you and asking to do a follow-up training -- what would that look like? (In other words, what was a similar past event that everyone remembers as being a great success?) Sometimes these questions have hidden answers, like people not wanting to be made to feel stupid, or wanting to learn a few simple tricks that will impress others, or merely needing to fulfill a mandate from higher up with the least effort heheh. To be really successful, you need to give them exactly what they want, not what you think they need.
You can ask these questions directly at the start of your session, but a better approach is to talk informally with some key people beforehand. Show them the material you plan to present, and ask for suggestions and feedback. Make them feel like you will implement their advice, so they have a personal interest in the outcome of your event. Technology is absolutely not the point of IT, don't let the conversation dwell on that. Instead, ask about the bigger picture, and try to understand the human perspective and reward mechanisms.
Above all, recognize that you have a blind spot that is twice as large as any executive's blind spot for technology. Accept it, develop some techniques to help yourself work around it, and you will find yourself light years ahead of your IT peers.
If your bosses were going to buy a corporate jet would you want to teach them about the mechanics of flight? Why do they need to know about how computers work in order to buy a tool to solve a problem?
They need to know not only the benefits of the software packages they are considering but also the limitations and the cost of each option. They should also consider the need for outside consulting work to implement a solution, as well as the possible need for an on-going maint./support contract and what that will cost/provide the organization.
I'm certain your employers have bought lots of machines they don't understand the operation of - that is why they hire subject matter experts (like you), If they wanted to learn about computers they'd take a class or read a book or two, not hire you.
Ken
To sit on their laps and take dictation in Gregg Shorthand?
My immediate response to the title was "don't".
From the longer text it appears that you have been asked by management to teach them. If you haven't, then my immediate response stands. Don't teach management about IT unless they asked for it, because a) they won't care if it comes unasked and b) knowing about IT is what they hired you for.
But if you were asked to teach management about IT, then ignore everything you learnt. Don't try to compress a computer science curriculum into a few hours. Teach them only what has immediate practical application for their day job. Unless they are a very rare breed of managers, they'll care little for anything else.
Assorted stuff I do sometimes: Lemuria.org
Ask 'em what they want to find out. It's always the best way of making sure their expectations are met.
"The greatest lesson in life is to know that even fools are right sometimes" - Winston Churchill
Start the session by going around the room having each person introduce themselves, and to state the one thing they most want to get out of this meeting.
If you're good on your feet, that will give you everything you need to move the discussion in the right directions and make you a success.
I'm out of my mind right now, but feel free to leave a message.....
Tell them what they're going to achieve from a business perspective by using the system correctly. They really won't care about what happens behind the wall.
When you go to eat a burger, do you really care about the way the meat processing is performed? Or the way the tomatoes are picked? You trust them to do it the right way, but you don't really want to know the gory details. What you want is to have a good burger, and they have to deliver. Same with IT.
Senior Management wants the ERP system to do stuff. You enable them. Show them how that happens on their terms, not yours.
the future is but past forgotten
and address those fears.
In the early '80s I was Assistant Program Manager for Software on a large project for the government. The development was being done using the same mimicomputers that would be shipped as embedded components of the system. There were more workers doing development than there were to be users of the finished system. We were having more and more trouble meeting our development goals because the load just could not be accommodated. We did a fair bit of analysis and decided that the major problem was there was just not enough RAM.
I requested that more RAM be purchased and the Program Manager repeatedly balked and said No. Meanwhile he kept the heat on us for progress on development. This Program Manager was an experienced aerospace engineer with lots of satellite launch experience. He was totally dedicated to the idea that the "launch window" was fleeting, and it had to be met. When development lagged and making the window was threatened, he knew how to make one squirm.
Finally I went to him and explained that without the additional RAM we would have increasing difficulty meeting the deadline, and why was he so opposed to adding it? He revealed that he was mortally afraid that adding more memory would slow the computers down, and the system would miss its performance targets. i.e. "miss the window" He did not understand how RAM worked!! In his mind if you made the memory bigger, then it must take longer to find and retrieve data. He was jeopardizing the project out of FEAR!
I was able to explain how it worked and convinced him to order more RAM. He did, and we went on to a very successful completion and delivery of the system.
Most in upper management are incapable of learning due to limited intellectual capacity. It would be much simpler (and more fun) to mount a hostile takeover.
...matters. if they're male (90% probability), hire strippers to take him golfing...
Your first mistake is asking Slashdot for input on training instead of the suits (who sign your cheque) what they want training in. Do you think they hired you because they want you to teach them IT, or because they want you to do it for them?
You need to teach senior managers what the nature of IT projects is, and manage their expectations. Assuming you mean ERP (enterprise resource planning) and not ERM (enterprise risk mgt): * manage stakeholder expectations. If there is momentum to do such project, it's usually because everybody is emotional: we need to do something, we need to act now! You need to render this much more objective, so everybody is still on the same plate one year down the road: clear objectives, how success will be measured ...
* (as suggested before) clarify why this momentum is there, each stakeholder has her reasons. Formalize these.
* these projects tend to cost 3-10 times the license cost of the package: integration, change management
* it takes senior mgt commitment: adopt the package, don't adapt the package (customizations are difficult to maintain in the long run: loss of internal knowledge, package upgrades ...). But adopting the package means changing the way things are done today.
* define the top 15 (or so) processes for the company, and based on these select the best-fit package, then be rigorous on minimizing customizations afterwards (again senior mgt commitment)
Expect a bumpy ride.
You need to teach senior managers what the nature of IT projects is, and manage their expectations. Assuming you mean ERP (enterprise resource planning) and not ERM (enterprise risk mgt):
Expect a bumpy ride.
Users at companies just want to know how to use their computers so they can finish work by 5. A little bit of background training is okay, but if you get into the whole proprietary/FOSS stuff you'll get a lot of yawns and dogs-turning-their-heads-45-degree type looks.
Make a box with a large switch on it and a light. Label it "The Internet". Have a presentation on the internet.
It would seem like the right time to pick an open source software (over a closed source) would be at the beginning, when things are starting from scratch. That way, the company wouldn't have to worry about migrations and the like. But there are two things to ensure before advocating that
On the larger question of whether to explain the plumbing, tell them what and how much they want to know. If they are a hands-off management, give them the numbers, and tell them that the proposals/justifications are all there in writing. If they want everything explained, have a bunch of proposals on hand, do a TCO analysis on all of them and submit them to management. That would be ideal, and that way, management can make the best informed decision, and IT can then execute on that.
You don't want to teach them IT at all. They don't care and don't want to know about IT. They only care about "the business" and it's financial performance. So you have to be able to demonstrate and prove that:
1. There is a problem and it is quantifiable and quantified to $$
2. That you have a solution that can provable solve the problem
3. That the solution economic cost and benefit can be quantified in $$
4. That the solution risks and timeline can be quantified and meet the company's needs
There is nothing here about IT you'll notice. The technical details are irrelevant. The benefits your IT group are irrelevant. It's about the business and about money. Period.
Senior management are in a class known as business morons. They are far too stupid to ever understand IT stuff. Why else would the ship all the knowledge of how to operate their companies on a day to day basis to Bangalore, or where ever? The fact that as of yet no company in Bangalore has cloned a big American company is further proof the people they sent the code too are also missing a few synapses ...