Boiling the IT Frog
Author Harwell Thrasher takes the mystery out of IT.
Interview by Kathleen Melymuka
July 23, 2007 (Computerworld) Harwell Thrasher is an author, speaker and coach specializing in the human side of IT. His Web site is MakingITclear.com. Thrasher talked with Kathleen Melymuka about his new book, Boiling the IT Frog, which aims to clarify IT for business people who really don’t understand it, and to help IT professionals who understand it completely but don’t know quite how to explain it.
Q: What does the book’s title mean?
A: According to a myth, if you put a frog in boiling water, it will hop out, but if you put it in a pot of water at room temperature and gradually heat up the water, the frog will become accustomed to the increasing temperature and stay in the pot until it’s cooked. Change agents use this myth to describe how organizations get into situations that they would never tolerate if they knew the final result in advance. That’s what has happened in IT. Business people would never tolerate the current state of IT if they could see where they were headed, but they got used to things gradually.
Q: You write that magic in IT isn’t a good thing. What is magic in IT, and why isn’t it good?
A: This idea came from an Arthur C. Clarke quote, “Any sufficiently advanced technology is indistinguishable from magic.” Magic and IT have a lot in common. Magic has strange words: abracadabra, hocus-pocus. We in IT have SQL, ERP, SOAP. Magic has this inherent idea that you see things that happen and you don’t quite understand why but you know they do, so you suspend logical thinking. Business people tend to regard IT as something magical, and so they don’t apply their own logical thinking. This suspension of logic is why business has so much trouble with IT. It creates unrealistic expectations.
There’s also the concept of the wizard in magic: people who can do magical things. In business organizations, there are wizards — users who have gotten good at an application. And in IT organizations, there are wizards too. The wizards want to keep systems the way they are to maintain their wizard status. As a result, you get stuck with a system that doesn’t get better.
Q: You say that without trust, IT is useless. Why? And how do you establish trust?
A: Business people will never have the detailed understanding of technology that IT people have. But the business people need to feel that the right technology decisions are being made. That’s where the trust comes in. Without trust, business people keep second-guessing everything the IT organization does, and IT can’t be successful.
You establish trust by agreeing on common objectives and goals and having consistency in how you communicate with each other. Both sides do what they say, and say what they do.
Q: Why is using return on investment for project selection a ticket to failure?
A: Most people would agree that the right projects are those that are in the best interest of the company and make the most strategic sense. But there are two fallacies in using ROI to choose your projects. First is that the project with the highest ROI is best for the business. That’s not necessarily so. For example, a high-ROI project may make a process more efficient by making it more rigid, when what you really need is for it to be more flexible. The second fallacy is that you can compare the ROI of project proposals. Those who write proposals tend to overstate return, understate expenses, minimize transition costs and dependencies on other projects, and neglect risk. So the project with the highest ROI on paper tends to be the one with the most creative proposal writer.
Q: Why do most projects fail?
A: In my experience, there are six primary reasons. First, you’re doing the wrong project — it’s not what the business really needs. Second, you’re missing prerequisites in the proposal. You start and then realize you have to beef up the infrastructure, for example, so you’re in trouble right from the beginning. Third, you’re going for home runs instead of base hits; for example, a global rollout of a major system instead of chipping away at it a little at a time. Fourth, the project’s duration is greater than the job tenure of the sponsoring executive. If the project isn’t completed before he or she leaves, you may be in deep trouble with the successor. Fifth, you gather requirements instead of negotiating them. If you go around asking all the stakeholders what they want and your project goal is the sum of all those things, you will undoubtedly have contradictions — for example, a simple system that must do everything. Sixth, there’s not enough contingency planning. You’ve got to anticipate things that can go wrong and take them into account in your plan.
Q: Why is it that adding more resources to an IT project that’s running late can make it take even longer?
A: Usually, when we talk about adding resources, we’re talking about adding people, and adding more people requires more coordination. You have to rearrange the tasks being done and break them up in different ways. Reallocation of resources takes resources in itself. Also, you would probably have assigned the best people to begin with, and now you’re adding people who may not be the best, so you have to manage subpar performers.
[see the original interview on ComputerWorld‘s web site]
Buy now from