IT retrenchment: performing IT project triage

The on-going economic turmoil in the U.S. and global economies over the past several years continues to force many organizations to freeze, trim or even dramatically slash internal budgets. If you’re an experienced IT manager, you already know that your budget may be among the first to be affected. And that means making hard choices, particularly involving IT projects, both planned and under development.

The concept of triage comes from medicine, and in particular medical treatment under difficult circumstances — war, epidemic, disaster — where the number of people needing treatment exceeds the resources available. In such situations, the sick or injured are typically assigned to one of three groups:

1. Persons who are likely to live even if they don’t receive immediate treatment
2. Persons who are likely to die even if they do receive immediate treatment
3. Persons who are like to live only if they receive immediate treatment

The goal of triage is to focus scarce medical resources on the people in group 3, since the people in groups 1 and 2 are likely to live or die, respectively, regardless of what the medical team does. And, as a person in group 3 receives medical treatment, that person usually ends up shifting into group 1 or group 2, depending on his or her response to that treatment.

As an IT manager facing a budget freeze or cut, you will likely have to carry out a similar process of IT project triage. The analogy isn’t exact, but you will also have to assign each existing or planned IT project into one three groups:

1. Projects that are either so critical that they have to go forward, or that are funded (and funded adequately) outside of your IT budget
2. Projects that simply are not feasible or fundable under the new budget
3. Projects that can still be carried out under the new budget, albeit possibly in a reduced form

Let’s talk about each of these three groups.

Group 1: Projects that can or must survive

In any corporation or government agency, a given IT project is frequently funded not by the IT department but by the “customer” — the business unit or division — that wants or needs the project. In such cases, the project may be able to go forward, even in the fact of IT budget cuts, provided the customer continues to supply the necessary funding.

However, even that is no guarantee if the IT department’s new budget doesn’t support the necessary IT personnel and resources (hardware, software, etc.) required for that project. In such circumstances, to close that gap, the customer may have to scale back the scope of the project and/or increase its funding for it.

And then there are those projects that simply cannot be killed or postponed. Such a project may be a contractual obligation for an outside party. It may be an upgraded or replacement system that’s needed to meet legal or regulatory requirements. It may be a true mission-critical system required for the firm to function, though the real question is: If the system is so mission-critical, how has the firm survived without it until now? I have watched organizations spend years of effort and vast sums of money on “mission-critical” systems that were never deployed. So be prepared to argue whether a given proposed system is truly “mission-critical.”

Group 2: Projects that can, must or should die

One of the hardest things to do politically in an IT department is to kill an IT project, even one that deserves to be killed. It can be a “death-march” project that is clearly headed for disaster (if not already there) but that upper management or the internal customer decrees should go forward. It can be a prototype, proof-of-concept or proof-of-technology project that someone is threatening to turn into a production application without taking the time to go back and build a solid foundation under it. Or it can be a decent, well-thought-out project that has taken just too long to develop and deploy, missing its targeted window of opportunity.

Your triage effort can give you the leverage and political cover to shut down — or, at least scale back — such IT projects. Don’t be afraid to use it, because this may be your only opportunity. However, don’t simply announce your list of cancellations. You will need to lay the groundwork ahead of time. Be sure that you can make a solid argument; then spend time establishing the political backing that you’ll need. (Read this earlier post for suggestions on how to do this.)

Group 3: Projects that can still be carried out in some form

After classifying projects into groups 1 and 2, you may have some IT projects left over. These are worthwhile projects that have a reasonable probability of success and a compelling return on investment, particularly within the context of your organization’s economic retrenchment. They have to fit within whatever budget or funding you have left after taking care of all the projects in group 1. And they must have the necessary political backing from upper management or internal customers to go forward. If they don’t meet all those criteria, then they probably belong in group 2, however painful that may be.

Even after this screening, you may find that you have more projects in this group than you can fund. And now comes the truly painful part: deciding which of these projects go forward and which ones are put on hold or canceled altogether. Those decisions may truly be above your pay grade, since they will likely tie into new business priorities or drivers also affected by the current economic turmoil. But for a given project, you should be prepared to offer cogent and well-founded arguments regarding its probability of success, its anticipated effectiveness and its ongoing maintenance costs.

And there you have it. Likely, it won’t be easy. But it will be less painful if you are proactive and preemptive on doing the research and analysis ahead of time.

[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.