I’ve been working in the IT industry in one way or another since I graduated college in 1993. That’s 15 years now… wow, seems like it hasn’t been that long.
I’ve been involved with many different IT projects in many different organizations, and I’ve seen or heard or been exposed to a thousand more. I’ve seen successes and I’ve seen failures. Overall, more failures than successes. This shouldn’t be a surprise to anybody, the industry storybook is rife with tales of colossal failures… maybe 5 failures for every success.
Here’s why IT projects fail. I’m going to tell you all, so that you’ll know (if you’re a sysadmin or a programmer or whatever) how to avoid them, or you’ll know (as a non-IT person), how to recognize when your IT department is starting something that is very very likely to cost a bucket of money and return very little, except to give you fodder to rake them over the coals when you’re at the water cooler with someone else from Accounting.
There is no such thing as a technological solution. There is no problem that you can solve with technology. Stop thinking that you can, because when your thinking starts at that point, you’ve already started building a foundation without checking to see whether or not the ground can support any weight.
When you’re an IT worker, people bring you problems all the time. Sometimes, they’re not really “problems” at all -> there’s a bug in some software, or something is mis-configured, or some other thing that may take you minutes or hours to fix. This is really the equivalent of putting a band-aid on a wound. The real goal is to prevent infection until the wound heals. Eventually, the software will be replaced with a new version, or the main router will come back online, or whatever… and the work that you’re doing now will be essentially wasted time. Important time, granted… customer-service enabling time -> you’re saving them time at the expense of your own.
With these sorts of problems, you’re a mechanic. You’re a plumber. You’re finding out what doesn’t work in technological system and patching it or working around it. This is the grunt work, the scut work, the stuff that keeps us employed on a daily basis. You’re not providing a solution to a problem. You’re hacking. This isn’t a bad thing, it needs to be done. But this is firefighting. Optimally, you want to do as little of this as possible, because you’re at heart very lazy, and you know your customers want everything to “just work”.
Real problems start deeper. “I need a way to let people see my time schedule” is a problem which requires a solution. “My administrative assistant can’t sync my Treo to the corporate Exchange server” isn’t a problem that requires a solution -> it’s a bug that needs a hack. When people bring you bugs, hack. When people bring you problems, you need to build a solution.
This always, always, always needs to start with information gathering. Period. Always. If you’ve worked in four organizations before, and you’ve run Exchange, and someone comes to you with “I need a way to let people see my time schedule”, odds are very very good you’re going to blurt out, “Well, I could set up an Exchange server…”
Don’t. Cease. Back up. You’re doing it wrong. Period.
You’ve made the first mistake, you started building a house… and you don’t even know that what the customer wants is a house.
Sometimes, a someone comes to you with, “I want you to set up an Exchange server…” and you’re going to blurt out, “Okay, I’ve done that before, it’s pretty easy…”
Don’t. Cease. Back up. You’re doing it wrong. Period.
You’ve made the second mistake, you started building a Victorian because someone told you they think they need a house. The customer doesn’t know what they need. They know what they *want*. It’s your job to figure out if what they *want* is actually what they *need*. Moreover, it’s your job to know if what they need is possible. Sometimes, it’s not.
If you tell them that it *is* possible because your boss is scary and shouts and says, “Don’t tell me what’s impossible,” when you argue with him, I’m begging you… get into another line of work. Eventually you’re going to get fired, or you’re going to get fed up and quit, and the next poor bastard who comes in is going to spend months of aggravation trying to fix the piece of junk you built because you didn’t have the gumption to tell someone that they ought not to build a skyscraper on top of a bog.
The only thing you can do with technology is operationalize a solution. Information Technology work is *enabling* work. We take solutions and we build stuff to make them happen… but the solution has to already be known to some degree. You have to design a process before you start building an object. If you don’t, you’re going to build a really pretty object that nobody uses. You need to know what it is, not necessarily in minute detail… but you’d damn well better have a good idea that it’s supposed to be a house, if it’s supposed to be a house. Whether or not it’s a Victorian or a ranch or a McMansion is important, but it’s not as important as starting off in a residential zoning area.
You need to keep your eye, always, on the solution… and NOT on the technology. If the technology doesn’t fit the solution perfectly… well, that’s not always bad, and that’s not entirely unexpected. You can’t redefine success by changing the game to “I successfully deployed this technology” because deploying the technology isn’t what the customer wants, they want the problem solved. Define what subset of the problem the technology is fixing, and make sure your customer is satisfied with that subset before you build the thing.
And if they want you to build a Victorian and you’re in a commercial zone, suck it up and tell them “No.”