Software

Deciding when it's time to quit

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?

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.

6 comments
reisen55
reisen55

An associate of mine got into the dread I AM GOING TO FIX THIS IS TAKES ALL DAY mode. Dangerous and a real problem for our industry. I learned that when this dread problem infects you, stand back and study the PRACTICAL solution. Corporate users do not have time for total analysis. Solve the PRODUCTIVE problem immediately and, THEN, work on the long term problem at leisure and AWAY from your user who does not have time for diagnostics and analysis.

jessicadisney
jessicadisney

I have a "20" minute rule in my department. If is taking longer than 20 - 30 minutes to identify the issue and come up with an initial solution. Get another set of eyes. Inevitably it is resolved quickly or it is determined to be a major issue and we can make adjustments (like have the user move to another machine or switch to backups, etc.). Nothing worse than having someone spend ALL DAY on something that can be fixed in 10 minutes.

reisen55
reisen55

After beating yourself for hours on a project, quit for a day and rethink the idea. I did that on a server upgrade. Installation of a new, larger hard drive with apparently just "data" on it should be easy but it was not. Every workstation in the office refused to work as it did before. Obviously something more was at work here and there should be no reason for it at all. Put the old drive in and left it alone for a day. 24 Hours later, returned and used GHOST to image a smaller, cleaner image of this secondary drive (I cleaned it out overnight through rdp) and then imaged the new drive inplace. VOILA, beautiful results. IT people love to go into slugging matches with problems. Don't do it. If something does not work, back away, get food and think about anything other than the project and I'll wager you'll find another way to attack it that reallllllly works!!! Side Benefit: I then used GHOST to make an image of the operating system hard drive. Saved it. Removed the operating system drive, set it aside, installed my previously removed hard drive from earlier and applied the GHOST image to this one. VOILA - also worked. Beautiful DISASTER RECOVERY PROTECTION for client as well. This I did not invoice them for. My own test to see if Windows 2003 Server could work with GHOST.

Tony Hopkinson
Tony Hopkinson

IT person recognisng my solution sucks (which has happened once or thrice, hard as that might be to believe. :p ) as quickly as possible has always been a job saver. In in a big IT project as a manager, it's a generally a death knell. That's your real problem. If you aren't allowed to fail, then dress it as success and get promoted/leave before anyone finds out.

Tig2
Tig2

I was on a project that was doomed to complete failure from day one. As my concerns deepened, I began communicating what I was seeing and what I believed would be the result. As time went on, it became very apparent that I was correct and that failure was imminent. So the project was halted. I went on to another contract thinking that they would at least consider what I had documented as steps that needed to be completed before they re-opened the project. They didn't. As far as I know, they are STILL trying to complete the project. The cost over runs must be astronomical by now. The good news is that I was able to get out from under it. Even more insidious are the projects that are never called projects, never directly funded as projects but have deliverables and expectations attached. These things tend to be mobius in nature and never end well- if at all. If you find yourself in one, I can only advise you to run fast and far.

networkguyinsavannah
networkguyinsavannah

It is my experience that alot of IT projects fail NOT because of poor technical qualities, but because of poor leadership and upper management's expectations that all is a go by some unreasonable date. As IT people, we need to be involved in the GROUND floor of any upgrades/moves/new construction. The second thing is to give us a reasonable date to completion., Don't give me a 30 days or else ultimatium or set me up to fail. Ask me what the time to completion is and then some. Burning people out by working 24/7 is not conducive to either happiness or employee retention/morale. The third is on our(IT) shoulders. Keep people informed and tell the uppers ahead of time any news ( good or bad) that is going on. keeping a secret til the last moment is not career enhancing nor helping you on this project. If you go with 'bad news" at least offer a solution. My favorite project management story is about Y2K. I was the Y2K coordinator for PC's at a plant and all was going well.. My evals were due in November; before Y2K but that month came and went. Everyone else got theirs on time. One day my boss saw me eying him and said ina voice for all to hear "X, I have not forgotten yours". My reply was "Mr. Y, don't joke me. You are waiting for Y2k and if it fails, you have me by the short hairs. If it succeeds, then you have all you need to write it" Y2K came, my plan succeeded, and a 20% salary raise with it!

Editor's Picks