Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Businesses Books Media Book Reviews Technology

The Executive's Guide to Information Technology 108

WatkinsDore writes "The Executive's Guide to Information Technology is a book focused on the 'business' pieces of managing IT, such tasks as IT organization design, vendor selection and management, communicating with business users, IT human resource management, establishing IT steering committees and managing the overall demand within the IT department." Read on below for more of WatkinsDore's review.
The Executives Guide to Information Technology
author Baschab / Piot
pages 500
publisher John Wiley & Sons
rating 9
reviewer Quentin Watkins
ISBN 0471266094
summary A guide to the business aspects of managing IT with a focus on senior executives and IT managers

This book is interesting because it fills a well-known gap between current book offerings that address vocational issues, such as "how to program in java" and academic research such as the most effective data access algorithms.

In fact, it addresses some of the questions that have been asked by slashdotters in the previous few months for books on the general management of IT, principally in these Ask Slashdot questions: Books on IT (not Project) Management?,Best Computer Books For The Smart?, and General IT Books?

The Executive's Guide to Information Technology is targeted at IT managers, and also senior executives who want to better understand how IT can be effectively managed.

Interestingly, it starts by analyzing the question "Why have an IT department at all?" and answers the question with productivity statistics and other anecdotal evidence of the importance of IT. The premise of the book then emerges, asking "If IT is important, then why does it seem to fail so often, and cause so much trouble for companies?"

The answer, predictably, is that IT is often a poorly managed function within a company. IT managers seldom receive the appropriate business training to manage a large, mission-critical function and budget, and non-technical executives get lost in the maze The authors show that many of the symptoms of poor IT departments (overspending, overstaffing, project budget overruns and failure to complete) are caused by, or at least are related to poor management within IT.

The remainder of the book covers the key topics that, according to the authors, are the key components to the effective management of IT departments. (The table of contents for the book appears below.)

Review:

Overall the book does a good job making the case that the key principles it outlines are the best predictors of a successful IT department. The book is replete with real-life, and often-humorous anecdotes from the authors' experiences in turning around distressed IT departments. IT managers will quickly recognize many of the symptoms of an IT department in trouble. The book is written in a easily readable, conversational tone, and there are charts and graphics throughout to further explain key points.

At just over 500 pages, the book is lengthy compared to competing offerings; however, it is written in a way that lets the reader pick and choose specific chapter topics, without losing much of the context. At $75, it at first seems a bit pricey for a general management book, but low for a textbook. Compared to other books on a price-per-page basis, the book seems more reasonable based on the large volume of content and page count (over 500 pages).

The book also has a CD-ROM with documents, spreadsheets and links to the underlying research that went into the book.

Slashdot even gets a mention in a couple of chapters as a good source of "unbiased customer experience information" although the authors say that for many blogs "it can take some effort to separate fact from opinion on the blogs, and the signal-to-noise ratio on a given topic can sometimes be low."

In all, the book is a relatively easy read, thought provoking, and a great reference for IT managers (or aspiring managers) who want to learn to think like senior executives and ensure that their IT departments are firing on all cylinders. Based on previous threads on Slashdot, the book fills a clearly needed niche on the general management of IT.

The book also has a supporting website that has information on the book - www.exec-guide.com.

Table of contents:

  1. The Effective IT Organization
    1. The IT Dilemma
    2. Sources and Causes of IT Ineffectiveness
    3. Information Technology Costs
  2. Managing the IT Department
    1. The IT Organization
    2. The IT Director
    3. IT Direction and Standard Setting
    4. IT Operations
    5. Application Management
    6. IT Human Resource Practices
    7. Vendor Selection
    8. Vendor Management
  3. Senior Executive IT Management
    1. Working with the Business
    2. IT Budgeting and Cost Management
    3. Effective Decision Making and Risk Management
    4. IT Demand Management and Project Prioritization
    5. IT Performance Measurement
    6. IT Steering Committee

Highlights:

Opening chapters on "why MIS departments matter" and the symptoms of under-performing IT departments.

Vendor selection and vendor management chapters.

IT steering committee chapter - why have one, what it can help IT accomplish.

IT budgeting chapter - shows key components of IT budget, how-to's and benchmarking information.

Nice forward by Professor Lynda M. Applegate from Harvard Business school.

Lowlights:

Portion of chapters on IT organization describing in painstaking detail the exact roles and responsibilities for every position on the IT team. This stuff needs to be there to make the book comprehensive, but not new news for experienced IT professionals.


You can purchase The Executive's Guide to Information Technology from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

This discussion has been archived. No new comments can be posted.

The Executive's Guide to Information Technology

Comments Filter:
  • by BillsPetMonkey ( 654200 ) on Monday April 14, 2003 @11:06AM (#5728602)
    "A vertical integration synergy strategy helped us realise total productivity gains in the medium term.
    We still reckon little elves make it happen though."


    MD, Widget & Sprokett
    • Its alot like reading bad resumes that use buzzwords to hide there inexperience or real job titles.

    • Buzzwords? Not much but.

      I don't know about you guys, but I read all the sample pages and all I saw was vague bizspeak, anecdotes about X Corp saved Y dollars that could have been on QVC for all the useful detail they gave, and more rambling mush.
      I saw two good sentences about IT departments being left out of decisionmaking. That's it. Not a single concrete "if you see X problem then you need to examine Y points of failure for Z reason" or any other useful advice.
      This looks to me like one more high-priced, prettily-wrapped hunk o' junk to make non-techies feel like they "know all they need to" without their having to dirty their hands or strain their minds by actually learning how any of this stuff works.

      I assume that the three thousand dollar executive training session in an expensive resort is coming right behind.

      Oh, and don't forget, the cost of those "seminars" and books and training manuals and time away from their operational responsibilties will be coming out of your pocket and mine when they further raise their prices to cover yet more executive bullshit.

      I am *so* fucking glad that I don't run a corporate IT department anymore!

      Rustin
      • Unfortunately the first chapter is pretty general, by necessity (have to do some context setting, can't just jump right into pros-and-cons of open source, or obscure security protocols). The later chapters (for example, Chapter 6 IT standard setting, or Chapter 10 Vendor Selection) are very specific and prescriptive. As practitioners (we use the book for our internal training in the IT turnaround and management practice), it was important that the book contain actionable, specific advice. Otherwise it is
  • by Rick.C ( 626083 ) on Monday April 14, 2003 @11:07AM (#5728606)
    Nowhere is this covered.

    All IT managers who used to be techies are required to get a lobotomy. This is standard industry procedure, but it's not even mentioned.

    Sheesh!
    • Within my company, techs who get "promoted" to management are usualy given an "a**hole suit" as part of their promotion.

      I wonder if the lobotomy happens before that, or after?
      Maybe it's part of the pointy-hair installation?
  • by kin_korn_karn ( 466864 ) on Monday April 14, 2003 @11:09AM (#5728619) Homepage
    18. Demoralizing staff through excessively harsh IT Policy
    19. How to downsize IT for effective annual report manipulation
    20. "Waah, go back to your cave, trog!" Or, how to deny IT budget requests
    21. Quality is so Expensive: A guide to third world staffing resources
    • by fudgefactor7 ( 581449 ) on Monday April 14, 2003 @11:17AM (#5728681)
      22. "When in doubt, perform physical system relocations." Or, how to annoy IT staff by moving shit around.

      [Note: Where I am, managers if given nothing to do will order whole departments to reorganize, taking an entire day, just so the Feng Shui of the office is better...at least, that is what it looks like to us.]

      23. The Peter Principle. Ignore talent and knowledge, promote some yahoo to Supervisor and watch the carnage!

      • 24. Understand that schedules are not meant to actually reflect reality. Use them to cover one's ass, to deflect blame, or to beat up your subordinates with.

        25. There is no such thing as morality, but simply what you can and can't get away with. Concepts such as personal honor and integrity are for suckers... the real power players know that what matters is the result, not how you get there.
      • [Note: Where I am, managers if given nothing to do will order whole departments to reorganize, taking an entire day, just so the Feng Shui of the office is better...at least, that is what it looks like to us.]

        They do that because that's what they teach in B-School. When all you have is a hammer, everything looks like a nail...

    • I am starting to dispise IT in corporate America. I am by no means a left wing lunatic or someone who demands high salary. Go read my rant here. [slashdot.org]In the end we all pass away and you have to question what your talents are here on Earth.

      In regards to wanting jobs to stay here in the US for higher salaries..."beware of your enemy because if your not carefull you will become like them". If we were offered shitloads of money and over time expected to keep it anyway possible thanks to your shareholders you will be
    • by crazyphilman ( 609923 ) on Monday April 14, 2003 @02:28PM (#5730191) Journal
      You forgot:

      22. How to make your developers afraid: why layoffs should be random and unpredictable

      23. Nepotism is your friend: why your cousin and a couple of Java books are cheaper than a Real Programmer

      24. Golfing: networking for the businessman

      25. "No sushi for you!" or: why technical staff don't deserve the hiring parties you throw for salesmen and executives

    • I don't know if this helps, but I've used this quote on more then one occassion in relation to your chapters 20 and 21 and it sometimes works: "There are three aspects to every project: Time, Cost, and Quality. You can Control any two" -Ben Franklin
  • Actually.
    Was there just a need to also include 'lowlights' as I, for instance, would be interested of such chapter if I was someone pointed to manage a new IT team.
    Well ok. I haven't read the book but I can imagine what "painstaking details" means :)
    This could however be very usefull for a _manager_ who hasn't got all that much hands-on for a while. (say few years)
  • by jeffy124 ( 453342 ) on Monday April 14, 2003 @11:13AM (#5728649) Homepage Journal
    this book tells HR depts how not to ask for people with 10 years .NET experience?

    (I'm graduating this semester, no job yet, and I've seen 3 or 4 of those and things like it)
    • Heh... I get a lot of this, too.

      You ONLY have a year and a half of struts experience?? I just interviewed a guy with five years, and a guy with three!
      Umm... the guy with five is flat out lying (or the original author), and the guy with three must be a part of the struts open source development team, right (Struts 1.0 was released 6/01. I had this interview like 6 months ago)?
  • by GerardM ( 535367 ) on Monday April 14, 2003 @11:13AM (#5728652)
    There is a chapter on how to select your Vendor. This implies that proprietary software is to be selected (hence the word vendor)

    Does this imply that OSS is not on the map? If OSS is not dealt with, I would rate this book as not of this time. The challenge of IT is to make do and do well on a limitid budget. OSS does play a role in this. So does the choise for open standards; this allows for unhindered communication with the rest of the world.

    Thanks,
    Gerard
    • by skillet-thief ( 622320 ) on Monday April 14, 2003 @11:15AM (#5728663) Homepage Journal
      Red Hat is a Vendor, for example.
    • by rcs1000 ( 462363 ) <rcs1000 AT gmail DOT com> on Monday April 14, 2003 @11:59AM (#5729045)
      I'm sorry, but it's impossible to have a business that is *entirely* open source. Any large company will want to have some expensive enterprise applications that manages inventory, accounts receivable, payroll, etc. These packages are just not exciting technically, and can't (unless I'm very much mistaken) be found in the open source world.

      So, unless you want your company to write its own general ledger software (not a good idea) you will have to buy it from someone. So, dealing with vendors is inevitable.

      If its any consolation, the enterprise application vendors (SAP, PeopleSoft, Oracle) are increasingly supporting OSS. You can run SAP on Linux (and it is increasingly popular) for instance.

      Now, what I want to know is when these big (expensive) enterprise software systems will support PostgreSQL...

      Cheers,

      Robert
    • It's hard to tell how this is treated without reading the book. It's possible that "open source" is a type of vendor and the book addresses this.

      Also, remember that vendors are used for things besides software. Hardware, facilities, hosting, sub-contractors -- all are generally a vendor selection process. Even if you are committed to open source for solutions you are definately going to have some commercial products to select.
    • You're right - the book should address this. It's hard to say whether or not it does by reading the review.

      However, vendors can also supply hardware, staff and ancillary services such as off-site back-up storage and printing. Those vendors can be just as significant to an IT manager as a software vendor. I think your dismissal of the book based on only one criterion is a little short-sighted.
    • I have read the comments so far. Yes, Red Hat is a supplier, so is Zope, MySQL name them. The issue that I raise is that you select a PRODUCT and you may choose to select a vendor.

      You may and do not have to. This makes all the difference. When OSS is chosen, a company may have programmers look at the source. They may be able to contribute to the community involved, they may ask a community for support, for features.

      The issue here is that the book is a "how to, what is what". Therefore it is a legitimate q
    • Bzzzzzzz!

      Sorry. You just failed the "Am I capable at running a business" test.

      Would you also throw out your life preserver because it was produced with closed-source software?
      • These are good points. We actually included Slashdot (as well as a couple
        of other blogs like f---edcompany.com and techdirt)
        specifically in the book because they are terrific forums for the review
        and critique of ideas in the field. Slashdot posters for the most part insightful,
        intelligent and highly technically skilled.


        Many vendor (or at least standards) selections
        done in the corporate world could benefit from a few rounds of "ask slashdot."
        Advice from the bloggers might not change the outcome, b
    • Why Vendors, I hear you ask? Some IT Departments also like to purchase hardware and stationery.
  • by jj_johny ( 626460 ) on Monday April 14, 2003 @11:13AM (#5728653)
    The problem with IT executives is not that they don't have a book to bring it all together. The information is all around them but they seem to reflexively question it or say yes, yes I understand but we just don't have the time to do it right. And more often than not it takes more time because they cut corners. The book sounds good, too bad all the people who don't need it will get it and all the people that need it will not read it or use it in any real way.
    • "Briefcase"-logic. (Score:3, Insightful)

      by Anonymous Coward
      "The information is all around them but they seem to reflexively question it or say yes, yes I understand but we just don't have the time to do it right."

      Then the next question should be:
      "If we don't have the time to get it right, then do we have the time (and money) to deal with the consequences?"

      Remember when dealing with managment you (just like in IT) need to be able to speak their language, and put your persuasive arguments in business terms.

      IT
      ---
      It's cool.

      Business
      ---
      This will save the company mone
  • by drgroove ( 631550 ) on Monday April 14, 2003 @11:18AM (#5728689)
    If enough IT Managers read this book, ThinkGeek won't be able to sell one of their T-Shirts anymore...

    SELECT * FROM management WHERE clue > 0

    0 rows selected
  • by blinka ( 663970 ) on Monday April 14, 2003 @11:18AM (#5728690)
    Any IT manager needs to have exactly the following skills:

    • Ability to listen and understand his techies. This usually means he needs to have been an IT grunt at some point in his career.
    • Ability to take their advice and repackage it into something that he can present to the folks who sign the check
    • Ability to prevent anyone outside IT from intruding directly into the IT employee's time. Act as a gatekeeper unless specifically requested not to by a techie.

    While we techies know our shit, too frequently we don't know how to explain it to the people who we're helping out, and seldom can do so to those who are going to give us the money to by the equipment we need. A manager who can keep us working happily by filtering innane problems to us rather than having us spend 100% of the time helping people move their mouse is the only way to keep us from jumping ship. And having the manager communicate our needs in the marketing speak that we don't have is the only way to get us our toys so we are happy in our jobs.

    A good IT manager knows enough to understand the geeks, figure out when we're lying, and protect us from politics and direct moron access.

    • Ability to prevent anyone outside IT from intruding directly into the IT employee's time. Act as a gatekeeper unless specifically requested not to by a techie.

      Sounds like an OO approach to management...

      But yes it's true. The role of gatekeeper is also to be able to synthesize and translate the needs of the (clueless) users. Often the techies have as hard a time understanding them, as they do understanding the techies.

    • by 1984 ( 56406 ) on Monday April 14, 2003 @11:37AM (#5728835)
      You miss something out:
      • Ability to explain to his techies why something might not be appropriate without demotivating them.

      As a technical manager you often get presented with nifty "next best move" ideas by your staff. Some are great and should be executed, others would be good locally, but would cause a problem elsewhere. Your job, unglamourous as it is, is to keep up the overall batting average, whilst avoiding any egregious failings. That doesn't mean every suggestion from below should be acted upon.

      Your job as a manager is to get the best out of your technical team in the service of the business. That means fending off stupid, ill-considered IT suggestions from non-IT people, but equally means not wasting time on whizz-bang technical notions that don't (and won't) help the business.
    • by squaretorus ( 459130 ) on Monday April 14, 2003 @11:37AM (#5728847) Homepage Journal
      In my opinion and experience this is exactly wrong. This is what the lazy techie wants of a manager - NOT what a customer wants of a company.

      I want to have direct access to the guy doing the job - I want direct access to the knowledge and expertise - not some half assed (or even full assed) regurgitation. You always get the best quality from the source.

      Too many techies use the 'Im a techie!!! I cant communicate!' getout. Quality of service, AND job satisfaction can only be boosted by getting more direct contact with users / customers.

      And yes, this WILL mean dealing with jerks sometimes - but if you answer their problems you enjoy the fact the call you LESS.

      Trust me - its fun!

      A good manager is a great thing - most managers are just a waste of time and an insulator against innovation, quality and progress
      • by Anonymous Struct ( 660658 ) on Monday April 14, 2003 @12:24PM (#5729209)
        I have to disagree with this. While it's true that being a techie is absolutely no excuse for not being able to communicate, users shouldn't generally be talking to the technical staff directly in my opinion. This is primarily because they often don't really know what questions to ask or how to interpret the response, and often they're not even entirely sure what they want from a technical perspective. Additionally, it exposes the technical staff to a slew of completely unprioritized requests, some of which have to be kicked up to the manager anyway in the event that the user is asking for something that requires a great deal of time and manpower (and maybe doesn't even realize it).

        I think it's great to have a working relationship with the users, but I know that in my position, the orders come from my boss, and he filters out the things he's not willing to support and escalates the things he knows are important to the business.

        To add: one thing that I think is understated in the original post is the ability to interface technical operations with the business needs of the company. Techies aren't usually entirely aware of the business needs of the company. A good IT department can get things done quickly and well, but it will still need a manager who understands both technology *and* business to direct their efforts in a productive way. Getting an old tech grunt in as a manager by no means guarantees you an effective staff. You have to have a guy that can understand and take advantage of your technical potential and apply it effectively to what your business is trying to do. That means knowing both sides very, very well.
        • I think the real difference here is between a support and development function. For day-to-day support needs, there needs to be a well-defined and understood communication process that only brings in the technical staff at the point where they're truly needed. On the new development side, however, there needs to be more direct communication between the business users and the technical staff to make sure that what is being developed is actually what the customers want.
        • Nothing wastes a techie's time more than someone bothering them with a question. Any IT department worth their salt, has a portal containing FAQs of every detail of their current environment. These FAQs should be updated weekly. Techies should have NO relatioship with end users.

          There should be a single point of contact for addressing user issues, and that should be the IT manager and whatever system designed to accept, prioritize, consoladate(sic)and address user issues. Much of this can and should be aut

      • In a way I agree with what you say. The last thing company executives need is some middle manager putting a spin on things, and distorting the message. But there need to be some limits, too. The thing is, having the CEO or CFO come wasting your time is not an issue I've encountered. The few times I've dealt with that level of management, they were good time management people and got to the point and didn't waste my time, either.

        But the time of techies can be wasted, depending on what the job responsibi

    • I think the really interesting times are still ahead of us in the IT/management relationships. When enough IT people get older and wiser, those that are not pidgeonholed in the basement, coding Cobol or something will rise through the ranks and enter management. This, in theory, should do wonders for productivity of IT departments and project teams.

      The call shouldn't really be to try to introduce management to IT, and teach them how to treat the elusive, photosensitive and moody critter that the techs ar
    • Although this explains how I ended up in a small office 10km away from my customers, it still does not make me very happy. I can communicate just fine, and I can handle interruptions to my work. What I *cannot* handle is being alone all day every day, with noone to talk to. I'm sure it is a different problem to what some people are experiencing, but let me tell you: it sucks.
    • A technical manager who has been IT grunt at some point may help communication to their techies, but this brings up the problem of somebody who last touched the technolgy years ago but thinks they still have a (intimate) clue - or better yet make low level technical decisions.

      Either they keep a hand in the technology or know their limits (a la Clint Eastwood) and when in doubt ask.
    • While we techies know our shit

    • Your bullets are fine, but you are missing the ones where you clearly understand where the company want to go and where they would like to be, and how you can help them. I've seen these neglected in a lot of situations. If you've got a great staff your three points are fine, but sometimes it's the other way arround. Clueless IT department doing all kind of useless crap because that's all they want to do...or or because that the only thing they can do...and nobody can tell them otherwise cos "they ain't have
    • While we techies know our shit, too frequently we don't know how to explain it to the people who we're helping out, and seldom can do so to those who are going to give us the money to by the equipment we need. A manager who can keep us working happily by filtering innane problems to us rather than having us spend 100% of the time helping people move their mouse is the only way to keep us from jumping ship. And having the manager communicate our needs in the marketing speak that we don't have is the only wa

    • This is akin to saying we don't need officers in a war, the soldiers and the NCOs know their shit, just leave them alone. IT manager's responsibilities include: - Monitoring whether his department meets the BUSINESS objectives set to it - Measuring and imporoving the ROI of his projects, technologies and platforms - Making sure his department is a good place to work I.e. a good manager is MUCH more than just your gofer. No matter how much you know about your 'shit', as you put it so charmingly
    • A manager who can keep us working happily by filtering innane problems to us rather than having us spend 100% of the time helping people move their mouse is the only way to keep us from jumping ship. And having the manager communicate our needs in the marketing speak that we don't have is the only way to get us our toys so we are happy in our jobs.

      I wonder where the idea that techies are prima donnas came from.

      Seriously. How long do you think you will be able to have your job if all your demands are met


  • Microsoft Bob
  • Useful book (Score:3, Funny)

    by Anonymous Coward on Monday April 14, 2003 @11:22AM (#5728717)
    This will be a very useful book, because the only people left in IT are the managers. They had to fire everyone else to cover their own salaries.
  • the only good IT exec is a geek/techie IT exec.
  • this is something every Slashdotter should read, since it will likely inject a healthy dose of business practicality, not to mention just plain ol' reality, into their thought processes.

    Gone will be thoughts of all software being free, or Linux on the desktop, or having 1000 people in an organization using the latest K3wL beta version MP3 player. Instead, they will start talking standards, support, and managing resources.

    After that happens, we can all have a coke and a smile, link arms, and sing 'Kumbaya'.

    • Why can't people understand that for such vital software as mp3 players buisness just can't afford to use unstable software. Just think of the consequences if your mp3 player stopped working tomorrow. I mean just think about it. Could your buisness survive if the mp3 player went down?!?
  • by pubjames ( 468013 ) on Monday April 14, 2003 @11:26AM (#5728752)
    1) Change jobs regularly. don't stay in any one company for more than a couple of years.

    2) When you start at a new company, standardize! Standarize on whatever bit of technology a sales rep. has recently bedazzled you with. Standardize by insisting, for instance:
    a) everything has to move onto Lotus Notes
    b) all databases must be Oracle
    c) Everything must be Microsoft

    Score extra points for really stupid and disruptive standardizations e.g.
    a) everyone must use MS Outlook.
    b) nobody can send email attachments.
    c) all databases should be on MS Access.

    Make sure that you replace old systems that have been working successfully for years, in the name of standardization.

    Don't listen to your technical staff. They don't understand business issues. And don't listen to your users. They don't understand techy stuff.

    Assign huge budgets to standardization. Standardize on something your technical staff don't like.

    Leave shortly after your new projects have been rolled out. Make sure you get a bit of press coverage about what a great job you've done (your chosen supplier will help you with this...) Get an even higher paid job elsewhere.

    What, me, cynical?
  • Hrm? (Score:3, Funny)

    by jmb-d ( 322230 ) on Monday April 14, 2003 @11:37AM (#5728844) Homepage Journal
    Slashdot even gets a mention in a couple of chapters as a good source of "unbiased customer experience information" although the authors say that for many blogs "it can take some effort to separate fact from opinion on the blogs, and the signal-to-noise ratio on a given topic can sometimes be low."

    Signal?

    (Nods toward JB's (or was it Andy's) comment on the state of things on the 'elbows' mailing list somewhere around 1990...)
    • As big Slashdot fans, we covered using /. and other user-contributed/moderated news sources in three chapters of the book.

      If more standards committees, vendor selection boards and the like would consult /.'ers (or other vendor-neutral blogs) they would get closer to the straight story. Unfortunately, in many IT departments, the standards setting process starts with "what brand does my nephew like" and the information gathering process begins with "call the vendors since they know best."

      The signal-to-nois
  • IT Guide (Score:3, Funny)

    by tthack55 ( 472393 ) on Monday April 14, 2003 @11:48AM (#5728931)
    As someone who has recently failed upward into IT management from being a grunt (programmer) at an insurance company, the biggest problem I have encountered is translating what the business people want into terms the staff understands. There is also the balancing act of blaming my predecessors for everything that has gone wrong while taking credit for all that is good. That is hard.

    And getting money from the suits. Sheesh.
  • All we need now is a book titled "Sales and Marketing for IT Staff"
    • I second that!
      I've worked every position from bench tech to CIO with sales and marketing along the way, (don't ask, I've had an interesting career). and lemme tell you, many technical people would do much better if they could only recognise that when people's eyes glaze over it's time to find a different way of explaining something! :)
  • IMHO any IT management book that does not have a top level heading "Writing a successful IT business case" is not worth the paper it is written on....

    • Absolutely right.

      In fact, it is not only making the business case for projects, but also ensuring that demand on the overall IT department and prioritization of the projects that IT will work on (based on the business case and other factors) is one of the most important areas where IT departments go "wrong."

      This is a real focus of the book, and therefore we worked to weave the concept throughout. It is covered in some detail in Chapters 1, 2, 3, 6, 7, 8, 13, 17 and most exhaustively 15 (IT Demand Managem
  • by magarity ( 164372 ) on Monday April 14, 2003 @01:13PM (#5729590)
    IT managers seldom receive the appropriate business training to manage a large, mission-critical function and budget, and non-technical executives get lost in the maze

    It shouldn't be any wonder IT people are selected who do not understand business; they aren't allowed to! The reverse for general management. And whose fault is this? The HR people are the obstacles. With a shiny new degree in business and extensive computer experience, I thought I could get into IT management. For general management jobs HR people said I'm not qualified because because all my practical experience is technical. For technical jobs I'm told I'm not qualified because me education is in business. Fortunately I landed a somewhat IT position at a firm too small to have an HR department but I wonder at what kind of people ended up at all the big corp positions whose HR people blew me off.
  • Now they come out with this $75 book after I spent all that money and time going to college to learn that shit.
  • Thanks for all the interesting comments.

    We highlight /. (among other blogs) in the book because, notwithstanding some notable exceptions, overall the forumers are insightful, knowledgable, and helpful.

    Because of good response from Slashdot (apparently, since this review came on today) the book is right now #25 on the amazon.com business books list! Thank you.

    Since Slashdot is a personal favorite of mine, and it was a good source of information for us as we researched our book, I will also make this offe

"For the love of phlegm...a stupid wall of death rays. How tacky can ya get?" - Post Brothers comics

Working...