Pulling the plug on IT projects

In a prior post, I talked about conducting triage on your IT projects — that is, deciding which projects should (or must) go forward, and which should (or must) be shut down. The next question is: what do you do with the projects that are to be shut down?

These IT projects typically fall into three different categories:

• Projects that are being suspended for a relatively brief time, but then need to be restarted quickly.
• Projects that might be resurrected at some future date.
• Projects that are really, truly dead (or deserve/need to be dead, e.g., “death march” projects).

The shutting down process for these three categories differs not so much in the general steps as in the specific actions and decisions in each step. For example, the “environmental impact statement” for a project being briefly suspended will likely be more brief than one for a project that is completely dead.

Step 1: Create an Environmental Impact Statement

During the IT project triage process, you may have already done some analysis to determine the impact of shutting down this particular project — let’s call it “Project X”. Now is the time to complete and document that analysis.

Let me stress now the importance of documenting why Project X was shut down and what the likely consequences will be. At some point in the future, you may find this decision to be called into question. Even if the decision wasn’t yours to make, you may find yourself asked why Project X was ever shut down. If there were adverse consequences, you may find yourself asked why you didn’t warn anyone about them. So now is the time to get that information down onto hardcopy and into electronic form, and in protectable, recoverable locations. (Note: I have more than once been saved by being able to reach into a file cabinet and pull out a copy of a memo or e-mail written and delivered months earlier.)

So, what are all the impacts of shutting down Project X? Here are some important ones:

• Loss of possible business advantage. Project X was likely approved in order to provide some new line of business or more successfully (i.e., profitably) compete in some existing line of business. The delay or death of Project X likely means the delay or death of that expected business advantage. That should be clearly documented.
• Extended support and maintenance for the legacy system. Project X may have been intended to replace an existing “legacy” system (let’s call it “System W”), which was to have been retired with the deployment of Project X. Now System W will have to continue in operation for some definite or indefinite period of time, with the associated maintenance costs and other disadvantages.
• Possible dependence upon end-of-life technologies. System W, the legacy system, may depend upon third-party commercial technologies – operating systems, programming languages and environments, libraries, application – that are facing their own end-of-life, that is, end of support from their respective vendors. In fact, that may have been a key reason why Project X was started in the first place. The delay/death of Project X and the extended life of System W means that you will have to deal with these end-of-life technology issues, such as support and bugs fixes (or the lack thereof), ongoing limitations of the old technology, and increasing incompatibility with newer technologies.

There may be other impacts specific to your organization.

Step 2: Capture Lessons Learned

The next step is to document the lessons, good and bad, learned from Project X — in effect, to conduct a post-mortem on Project X. A good reference for this effort is Chapter 8, “Postabandonment Review: Learning from Abandoned Projects” from the book Software Development Failures by Kweku Ewusi-Mensah (MIT Press, 2003). In particular, Ewusi-Mensah lists (on page 193) a series of questions under three broad categories: project planning and initiation; project management and control; technical know-how and technology base.

But you can also gain a lot of valuable information by simply gathering project personnel in a room, serve them pizza, and ask: “What worked well? What could we have done better? What caused problems for this project?” And if Project X may or will be resurrected at some future date, ask “What should we do differently when this project starts again?”

Step 3: Harvest Valuable Intellectual Property

This can be a useful step even for projects that are being suspended relatively briefly. Having worked in major corporate software reuse initiatives, I am something of a reuse skeptic, at least as far as working core code goes. The classic reuse paradox states that the more suited a given piece of code is to a specific use, the less likely it can be reused elsewhere (and vice versa). On the other hand, software services, libraries, and shell scripts often have utility independent of any given application or system. Beyond those, key architectural and design concepts and patterns can be very useful in other current and future projects. Finally, to the extent that you have solved hard problems, be sure to document how you solved them and the deliverables (source code, algorithms, database schema) involved.

Step 4: Preserve Project Deliverables

In theory, you should have a full-blown professional configuration management (CM) system that holds all the Project X deliverables: analysis documents, requirements and specifications, architecture and design documents, source code tree, test plans and scripts, test databases, and so on. This should be backed up in a few different ways (tape, DVD, hard drive) and carefully stored in a secure location.

Given the relatively inexpensive cost of hard disks, you should also consider just yanking the hard drives from the Project X development and test environments and likewise storing them in a secure location. This is especially true for projects that may be started up again. As good as your CM and backup processes are, it’s just hard to recreate a functioning development or test environment from backup media.

Step 5: Reassign Personnel

The people working on Project X have to go somewhere else.If Project X is only being suspended for a relatively short period of time, then you want key personnel to remain available to come back. On the other hand, if Project X is dead or will be dormant for some time, then you need to find more permanent slots for them. Unless, of course, you’re having to reduce head count as well – but that’s the subject for my next post.

[Adapted from an article originally written for the online version of Baseline.]

About the Author: bfwebster

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.