Ask Slashdot: How To Teach IT To Senior Management? 159
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?"
Focus on what they want to know (Score:5, Insightful)
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.
Example of focus (Score:5, Insightful)
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.
Re: (Score:2)
Teaching is selling. Take a cue from the salesmen with the benefit of your well functioning B.S. filter.
Re:Focus on what they want to know (Score:5, Funny)
Re:Focus on what they want to know (Score:5, Funny)
Re: (Score:2)
4. Use a large club. Remember, first you have to get their attention...
Club? Axe surely? (it's management, taking one of these beasties to IT spending is something they're familiar with)
Nononono. Club. You don't wanna kill them, you wanna get them to sign the authorisation forms and the checks.
Re: (Score:2)
Re: (Score:2)
I once had a manager who wanted to have a weekly status report from each of the development teams working on the product. (large scientific computer) We learned soon enough that to avoid flak and to keep the manager happy, we j
Re: (Score:2)
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.
===
Having implemented ERP systems, and designed software for manufacturing, I would hold a set of interviews to determine their pressing business irritants. From the list of the irritants, First thing in the AM I would schedule some presentations to show how the ERP system would solve or ease them. Then, after a coffee break, I would repeat what was presented, and introduce the new things that the ERP system will do, and not do for them.
And you must wind up with cost versus speed of implementation. Want a
None of the above (Score:5, Insightful)
Re: (Score:2)
Yes and no.
They care about ERM as it is what they see IT as doing for them. 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.
So things like the network and servers need to be described as important for it to function up to expectation. Doing this up front so they will be prepared to listen down the road is important.
Connectivity, availability an
Don't waste your time (Score:3, Insightful)
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 r
Re:Don't waste your time (Score:5, Insightful)
If he's not experienced enough to take control of the technical end of this project it is doomed.
That basically means he should be asking for a budget and the _authority_ to spend it, not for day by day authorization for individual components. Which means he has to be able to come up with a range of project proposals e.g. #1. Get SAP, get lubed, get raped. #2 Get Oracle, get raped. #3 Roll our own based on open source, likely fail, but still work better then SAP or Oracle. #4 insert OPs plan here.
Going from no IT to full on ERM seams optimistic. Surely they already have word processing, spreadsheets etc.
Re: (Score:2)
A tech put in charge of a pack of consultants is just as doomed as the same tech trying to build it all. Perhaps the consultants will arrange for a blow job for the tech, that's optimistic.
If they go with consultants the first thing they need is someone experienced with dealing with consultants and a good lawyer to review all contracts.
The tech should get his graft up front as he will surly 'get it in the end'. If he's not careful someone will be trying to realign the whole companies processes so they
Re: (Score:3)
Re: (Score:2)
Why on god's green earth would you have senior management determine the network infrastructure? Do they typically decide what machines to run their servers on?
The organization that put the bid together for the ERM suite you are buying should have done a site evaluation, should include specifications for all infrastructure requirements and upgrades needed to have a successful deployment, etc.
They need to approve the cost/purchase, beyond that they have to trust their employees.
Re: (Score:2)
Re: (Score:2)
How the fuck did this get elevated to ask /.?
A fucking marketer asking for help dealing with other marketers?
Step 1. Don't believe anything they say.
Step 2. Don't believe anything they will put on paper.
Step 3. Remember what you did to your last customer? They want to do that to you. No lube. SAP and Oracle are both legendary for overcommitting, underdelivering then charging 10x the original budget to complete the project.
Step 4. They aren't 'selling' you. They are 'selling' the boss. Best bet is
Re: (Score:3)
"You want ERP because it gives you XXX."
"You need servers and gigabit backbone switches because without it the ERP won't work."
What training do you need beyond that? The problem is that when they have a 10 year old ERP that's working fine on 10 Meg hubs, and someone comes up with an update that drives hardware cost. "why do I need to change servers for a software update, the old version worked?" That's the question I see the IT people fall down answering.
Re:None of the above (Score:5, Insightful)
This. Focus on what they need to know for this decision. The part part about proprietary vs open source? ONLY if you're considering a proprietary package and an open source package. If they think you are wasting their time, they will tune you out and you will all be wasting your time.
underlying plumbing (Score:2)
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 ju
How much detail...? (Score:2)
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
Re: (Score:2)
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?
No, they could not. Remember that they COULD NOT care less about the technical details. (Most of them anyway.) They bought the system for a reason. Focus on that reason. It had nothing to do with open source or software architecture. You will not be preaching to the choir on your favorite software topics.
Re: (Score:2)
Re: (Score:2)
100% that. Teaching senior management IT is a complete waste of fucking time. They are senior management because they should be spending their time making business decisions in the best interest of the company. Leave teh IT nerd shit to those who are actually qualified in it. IT is a profession, you can't teach it in a couple of sittings. All you'll achieve is give them something half-assed that they can use to make bad decisions with.
They presumably have specialist IT staff to advise them on decisi
Re: (Score:2)
Re: (Score:2)
My father was a senior cost engineer (a branch/off-shoot of civil engineering) at a chemical company.
Someone in senior management got it in their head in the very mid 70's that computers would assist them in their work, so they took all their senior engineers and signed them up for FORTRAN programming classes - the thinking was that these well-paid engineers would suddenly turn into programming wizards and crank out useful tool after useful tool, multiplying the work each engineer could accomplish. The real
Tough job ahead (Score:3)
Re: (Score:2)
What do I think? Lots of luck!
I agree. I think your project is doomed without a lot of luck or divine intervention.
I feel I can speak on behalf of the slashdot community that our thoughts are with you at this difficult time
Re: (Score:2)
Trust (Score:2, Informative)
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.
Re: (Score:1)
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.
Concealing choices does not build trust.
Re: (Score:2, Insightful)
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 de
Re: (Score:2)
Re: (Score:2)
You can bring Constance to communications but you can't make her like it :)
Sorry, but I find your typo amusing. At least I hope it's a typo and not just more evidence of buzzword bullshit from inbred idiots driving a chainsaw through communicating in English.
Re: (Score:2)
Re: (Score:2)
Thank you for espousing this approach. A great deal of my income comes from the cleanup when management wasn't presented with the available options, and IT chose the wrong ones due to concealed biases or unawareness of other requirements. The result is software churn, and large projects that soak up the entire resources of a company but miss a critical requirement that one side, or the other, didn't even know was available.
The reverse, of course, also happens as well. But since management usually does the c
Re: (Score:2)
Strangely, a large part of my income is from cleaning up when management *was* presented options and picked based on their biases, back-room deals with vendors, and outdated 'knowledge'. Mistakes will be made regardless, but at least let the people with the most applicable knowledge and experience make them.
Re: (Score:2)
Whether you (in IT) are "happy" about it or not is irrelevant. The cost to accomplish in terms of $ and hours may or may not be worth the trade off for other benefits that particular package provides to the company. It all comes back to time and money. If the IT side is going to be a prick of a job, work out how many hours, how many dollars worth of hardware and software and consulting (or additional staff required), and give them the figures.
They will either balk at it (in which case you go into deta
Re: (Score:2)
Don't look at the software yet. (Score:3)
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.
Don't teach them general IT stuff (Score:3)
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?
Wrong question. (Score:2)
"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/d
Keep in mind... (Score:5, Insightful)
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.
Re:Keep in mind... (Score:4, Insightful)
Exactly.
An engineering student asking "what's a clutch?" may want to hear about pressure plates, friction surfaces, and throwout bearings.
A driver's ed student asking the same question wants to hear "put your left foot down".
Re: (Score:2)
Hmm. Actual knowledge versus functionalism. Pity humans beings do not live love enough to completely master the former.
Re: (Score:2)
This is clearly a driver's ed. student. They're probably some dumb teenager, you can't expect them to expect answers appropriate to the topic or subject matter.
They don't know anything about the world!!!
Re: (Score:2)
A nickle? I don't want that sandwich.
Re: (Score:2)
Not even if it has a pickel on it?
Same way you teach Accounting, Sales, HR,... to IT (Score:5, Insightful)
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.
Re: (Score:2)
Tell them they will be graded. (Score:1)
Re: (Score:2)
First, get their attention and commitment. (Score:2)
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 id
You realize (Score:2)
You're going to end up teaching him enough just to get yourself in trouble.......
Buzz Lightyear to the Rescue! (Score:2)
Start by having them watch the entire "IT Crowd" (Score:4, Funny)
series on Netflix, then demonstrate that you know what the letters "IT" stand for.
Don't Prepare a Course (Score:5, Insightful)
What do they need to do to make ERM successful (Score:1)
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
Focus on results. (Score:3)
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.
Re: (Score:2)
So instead of saying 'open-source', you could sell those options as:
- Free of vendor lock-in: We will never be forced to throw it out by anyone
--- A market for support: Many places may compete for your support business
- Endless customization: IT can change it to fit what you need
- Learning curve: It can be made to fit the job, instead of employee training to force people to fit the software
Re: (Score:2)
Re: (Score:2)
ROFLMAO.
Don't bother with lectures (Score:2)
Don't waste your time teaching ideology. Just teach them what they need (the ERM)
Need to Know (Score:2)
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
You Don't. (Score:2, Interesting)
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
Set expectations (Score:4, Informative)
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.
Re: (Score:2)
also include what RISKS using a non opensource ERM solution creates.
If making the package work for that business can be solved with an open account to the local JimmyJohns (on top of what is already being paid to the workers involved) then this could be a Good Thing.
i would put together a Block Diagram of Whose(server is) On First so that they understand that skimping on Tommorow will prevent anybody getting Paid, Today prevents The Company from being Paid and I Don't give a [bleep] just annoys the lawyers.
Grandma has no idea what's under the hood of a car (Score:5, Informative)
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
Idiot management. (Score:1)
Should they ask a lawyer to teach them enough about the law to make a decision about
Hookers and booze (Score:2)
Speak their language (Score:3)
Its all about the screens... (Score:3)
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".
Teach them the Value & Risk of IT (Score:1)
Tell them the truth (Score:2)
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.
Comment removed (Score:4, Insightful)
Re: (Score:3)
Re: (Score:2)
Those two statements are IMHO contradictory. It appears that many who have an MBA and little experience or education in anything else are hell bent on sticking to processes even when that endangers results. I believe it's part of the strong emphasis on appearances and hiding from blame that an MBA teaches. A good manager needs to overcome such tendencies.
I apologise if I was meant to take the above post as sarcasm inste
my input (Score:1)
They don't need to know that. (Score:1)
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 th
Why? (Score:2)
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 networki
You Don't (Score:2)
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 super
What? (Score:2)
Re: (Score:2)
Enterprise Risk Management...i.e., a computerized way to cover one's management nakedness so the stockholders and lenders don't find out how clueless management really is.
Say again? (Score:2)
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.
My experience (hardware side to be honest) (Score:2)
Take a tip from Ethernet ... (Score:2)
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 t
You are the inferior one (Score:2)
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 strategi
What are you hoping for? (Score:2)
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
take their POV (Score:2)
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 are THEY hoping for? (Score:2)
Make them tell you what they want (Score:2)
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.
Find out what they fear ... (Score:2)
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 ma
Forget Teaching. (Score:2)
Have you tried turning it off and then on again? (Score:2)
Make a box with a large switch on it and a light. Label it "The Internet". Have a presentation on the internet.
Re: (Score:1)
Oh, and you can explain "open source" and stuff if you want, but leave it for the advanced course. They don't need to know to merely use the damn infernal machines. Similarly, while bits and bytes are essential for computer operations, they aren't really necessary to use. Teach them only in the advanced course (perhaps as part of the "no you can't stop copying, and you're a stupid fucker" subcourse).
While many people make decisions that really require knowledge beyond the basics, without that knowledge, try
Re: (Score:2)
Talk as far over their heads as possible. Give them the facts, but don't waste time dumbing it down for them. Leave them as clueless as they started. Make sure the "executive summary" states your goals clearly.
You're going to dazzle the clueless. But, they won't admit to being dazzled, they'll be mimicking your words to sound intelligent. The guys with a clue might ask you a serious question or two, but they'll probably just agree with you, because it's outside their area of expertise. You'll find tha
Re: (Score:3)
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 de
Re: (Score:2)
Re: (Score:2)