Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Businesses IT

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?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How To Teach IT To Senior Management?

Comments Filter:
  • by rsilvergun ( 571051 ) on Sunday May 05, 2013 @11:31AM (#43634713)
    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.
    • Example of focus (Score:5, Insightful)

      by Okian Warrior ( 537106 ) on Sunday May 05, 2013 @12:22PM (#43634987) Homepage Journal

      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.

    • Teaching is selling. Take a cue from the salesmen with the benefit of your well functioning B.S. filter.

    • by jamstar7 ( 694492 ) on Sunday May 05, 2013 @12:27PM (#43635025)
      4. Use a large club. Remember, first you have to get their attention...
    • by gagol ( 583737 )
      Thank you very much for this reminder. It may be the single most important cue in all the comments.
    • I first heard these rules back in the early '60s when I was in ROTC during my undergrad years. The crusty old seargeant was teaching a class on "Military Teaching Principles", and those 3 were the principles to be learned. I used those principles throughout my career, and they work!

      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
    • 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)

    by GerryGilmore ( 663905 ) on Sunday May 05, 2013 @11:32AM (#43634719)
    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?
    • 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

      • by 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 r

        • by HornWumpus ( 783565 ) on Sunday May 05, 2013 @03:50PM (#43636165)

          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.

      • by smash ( 1351 )
        None of that is senior management level decision making. All they need to know is "this program can do this, requires this level of spend to make work". The lower level technical shit should be abstracted away from them, all they need to know is something like "we'll need $50k to upgrade our hardware to run this properly". That's all that is relevant.
      • by kenh ( 9056 )

        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.

        • by gagol ( 583737 )
          We are a small organization, I mainly want to make sure my boss don't get overwhelmed by techno-blabble. I will surely attend the meetings but the final decision is not mine. Also, I worked in IT in the past, but my main job is in <demonic voice> marketing...</demonic voice>
          • 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

      • by AK Marc ( 707885 )
        None of that matters.

        "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.
    • by Ravensfire ( 209905 ) on Sunday May 05, 2013 @11:40AM (#43634767) Homepage

      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.

    • 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

      • 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

        1. 1. Check that the company already has people who can code, and maintain that software, or to factor the cost of hiring such people into the overall process
        2. 2. Spell out only the key reasons why the company wants it - ma
    • 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.

    • by smash ( 1351 )

      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

      • I've seen IT brought in and fuck up decisions as well because the technical people were only "technical" in hardware/software configuration and mucking with their network. They didn't have the qualifications or knowledge to discern the technical merits of various software architectures. It is this technical part that matters. Would you buy a ERM system that used an outdated underlying software framework that was not going to support enhancements or features needed in the future? It would matter if you bo

    • by kenh ( 9056 )

      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

  • by whizbang77045 ( 1342005 ) on Sunday May 05, 2013 @11:35AM (#43634733)
    What do I think? Lots of luck!
    • by pswPhD ( 1528411 )

      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

      • It seems to me that this is the typical task of trying to explain technical issues to people without the background and education to understand them. The chances for misunderstanding far outweigh the chances for understanding.
  • Trust (Score:2, Informative)

    by RenHoek ( 101570 )

    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.

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

    • 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

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

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

  • by Freddybear ( 1805256 ) on Sunday May 05, 2013 @11:44AM (#43634783)

    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/d

  • Keep in mind... (Score:5, Insightful)

    by ExRex ( 47177 ) <[ten.eruoja] [ta] [toille]> on Sunday May 05, 2013 @11:46AM (#43634803) Homepage
    ...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.
  • by obarthelemy ( 160321 ) on Sunday May 05, 2013 @11:47AM (#43634807)

    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.

    • by smash ( 1351 )
      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.
  • 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.
  • 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're going to end up teaching him enough just to get yourself in trouble.......

  • This Buzz Lightyear laptop [tesco.com] should do it. It has all the fun games and lessons a PHB will ever need,
  • by mark_reh ( 2015546 ) on Sunday May 05, 2013 @12:13PM (#43634947) Journal

    series on Netflix, then demonstrate that you know what the letters "IT" stand for.

  • by OG ( 15008 ) on Sunday May 05, 2013 @12:19PM (#43634963)
    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.
  • 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

  • by voice of unreason ( 231784 ) on Sunday May 05, 2013 @12:23PM (#43634997)

    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.

    • by snadrus ( 930168 )

      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

      • The last is really the biggest advantage of this, and should be emphasized. Also important is that if the company ever at any point buys a cool new platform, it can port the software to that, and not have to give up on some of the performance advantages. The second point - market to support - needn't be there, if the company is insourcing, rather than outsourcing its IT requirements.
      • It can be made to fit the job, instead of employee training to force people to fit the software


  • Don't waste your time teaching ideology. Just teach them what they need (the ERM)

  • 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)

    by michaelmalak ( 91262 ) <michael@michaelmalak.com> on Sunday May 05, 2013 @12:28PM (#43635037) Homepage

    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.

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

  • by walmass ( 67905 ) on Sunday May 05, 2013 @12:35PM (#43635067)
    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:
  • Run away now. Run far! It will save you grief in the long run. Managers who know nothing about IT are never going to learn enough about IT to make a decision: If they had the ability or inclination then they would have already done so and if they think they are then they are incompetent. There's nothing worse than a senior manager who knows just enough to be dangerous. Also known as "does not know what they do not know."

    Should they ask a lawyer to teach them enough about the law to make a decision about

  • And a trip to Vegas is they are in doubt about what to buy.
  • by FuzzNugget ( 2840687 ) on Sunday May 05, 2013 @12:51PM (#43635169)
    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.
  • by SuperCharlie ( 1068072 ) on Sunday May 05, 2013 @12:57PM (#43635193)
    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.
  • by adosch ( 1397357 ) on Sunday May 05, 2013 @01:06PM (#43635241)

    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.

    • This has always been true. But it finally looks like the IT industry has matured to fully understand it's not about the solutions, but the results. IT people need to be more MBA oriented and last technical. And as BYOD devices and cloud based services become more predominate, there will be a need for less and less specialized hardware folks. And if you need them, you outsource the problem like you would a phone vendor.

      • by dbIII ( 701233 )

        it's not about the solutions, but the results. IT people need to be more MBA oriented

        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

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

  • 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 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.
    • by gtall ( 79522 )

      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.

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

  • 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 he
  • 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 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

  • 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

  • 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

  • Ask 'em what they want to find out. It's always the best way of making sure their expectations are met.
  • 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.

  • 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 ma
  • 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.
  • Make a box with a large switch on it and a light. Label it "The Internet". Have a presentation on the internet.

I've got a bad feeling about this.