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?"

Focus on what they want to know

[rsilvergun]

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.

None of the above

[GerryGilmore]

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?

Re:None of the above

[Ravensfire]

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.

Keep in mind...

[ExRex]

...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.

Same way you teach Accounting, Sales, HR,... to IT

[obarthelemy]

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.

Don't Prepare a Course

[OG]

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.

Example of focus

[Okian Warrior]

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.

Don't waste your time

[Anonymous Coward]

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?

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Keep in mind...

[egcagrac0]

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:Trust

[smash]

Exactly. In reality, it is YOUR JOB to insulate the CEO and other upper management types from having to deal with this sort of bullshit. This is why Apple sells a shitload of gear to people like your CEO. They just want stuff to work and don't care about the implementation details. Window colours? Irrelevant. Theme on their phone? Irrelevant. Ringtone? Irrelevant.

Bringing petty technical decision making bullshit to upper management level types is failing at your job. Unless they ask for more detail, abstract it away into dollar figures and man-hours required.

Re:Don't waste your time

[HornWumpus]

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.