There are just some projects that refuse to die. They take on a life of their own. At some point, you just have to cut bait. But how do you decide when it's time to quit and just go on?
You've probably had at least one of these in your IT career — the IT project that refuses to die. These are usually projects brought on for "strategic reasons" by people in upper management who have no idea what they really want to accomplish nor what the limitations of technology are. The project starts out small and then just keeps growing.
Over time, the project gets so big and takes up so many resources that there's no going back. It winds up being too big to fail. That's when, as an IT leader, you have a hard decision to make. How do you make it work or make it go away?
The Y2K problem
Back when I was a network administrator at the turn of the century, the company I was working for, like many companies at the time, was concerned with the Y2K problem. They had a manufacturing system running on an IBM mainframe. It wasn't designed to handle the date problems that Y2K was going to cause.
Starting about 1997 - 1998, they decided the best way to solve the problem was to retire the mainframe and develop a new system. They could realize the savings of leasing mainframe hardware and software, replace an aging system with something customized to their needs, and overcome the Y2K problem in one fell swoop. Genius solution.
The problem was that the chosen solution was a customized Oracle application that ran under Windows entirely under Terminal Services. Because this was 1998, we're talking Terminal Services 4.0 under Windows NT. You can imagine the power of the hardware and software on the server side that was to undertake this solution. Beyond that, the remote sites were all connected via Frame Relay, which was running about 256Kbps. As you can probably guess, the screens on remote terminals were exceedingly slow, only to be matched by the sputtering backend database server.
As the year 2000 drew closer and closer, the company invested more time and money into the new solution. Meanwhile the mainframe kept humming along, cranking out orders and directions to the plant floor.
Eventually, it was mid-1999 and the Oracle solution was doomed to not be ready to launch January 1, 2000. The solution, of course, was to work faster, but now it was mated with a furious attempt to remediate the Y2K problem on the mainframe and patch it up to make it last awhile longer.
Fortunately by the time this occurred, I was already here at TechRepublic. I missed the subsequent fireworks, but the CIO wasn't there much longer needless to say. They finally abandoned the Oracle solution and continued on with the mainframe application until they finally shut the plant down — the ultimate solution to the problem.
The cost of continuation
As an IT project lurches toward ultimate failure, the amount of money it costs you to continue doesn't increase in simple linear fashion. There's the lost time and money invested in the project to begin with. Beyond the obvious, there's the costs of the NEXT project that will have to be put in place to repair the damage created by the first one. On top of it all is the revenue your company continues to lose going forward from not stopping sooner and finding another solution.
All these opportunity costs mount in a geometric progression that can become crushing. All management notices at first is the obvious costs, but those other costs still lurk in the background and compound the problem.
Forming an exit strategy
When an IT project starts going downhill, as an IT leader, it's your job to slam on the brakes. The sooner you, do the better. You can then avoid all those compounding costs of continuation.
Obviously it can be career suicide to try to slam on the brakes, especially if the project is driven by upper management and is largely out of your control. However, getting swept up in the riptide of a sinking project can be just as bad, if not worse.
By at least going on record to objecting to the continued course of action, you at least help to inoculate yourself from ultimately being blamed for failure. By continuing the project and hoping things turn out well, you go from IT leader to IT scapegoat. The failed project will be firmly attached to you by others, and not only can it destroy your reputation in the company you're in, it can follow you to subsequent companies.
So, don't be afraid to state your opinion when things are going poorly. But at the same time, don't just be a naysayer. If you're going to be negative about a project everyone is pushing for, you should have an alternative solution prepared. Some steps you can follow include:
- Outline what's wrong with the current solution, being sure not to assign blame for any problems. Doing so will only antagonize people and cause opposition to your solution.
- Identify the costs of continuation along with the costs of your solution.
- Play devil's advocate against your own alternative and get ahead of any counter-arguments.
- Find key stakeholders who feel the same way you do and try to get them on board with you.
Ultimately your only solution may be to tender your resignation and state why you're doing so. It may be accepted, in which case you don't have to worry about it anymore. It may also shock the powers that be into realizing that something's seriously wrong.
In bad economic times like this, that's not always a viable solution, but you should always have a plan B thought out for your career anyway. That's a good time to use it.
The bottom line for IT leaders
When it's all said and done, you have to realize when it's just time to quit. You can't continue to expend time and resources on a solution that isn't going to work. It's not always easy to admit defeat and failure, but when you do, you can finally carry on and hopefully get it right the next time around.
No matter what the outcome, don't forget that you're an IT leader and that sometimes means accepting the consequences of defeat. It can be more courageous and show more leadership by forcing the end to a bad initial decision and changing direction than it is to just keeping on doing the same thing over and over again.