Do you have too many IT projects on the go?

How many IT initiatives should you have on the go at any one time? Not a simple question to answer but you need to consider the trade-offs between resource utilization and elongation of individual projects.

Let me illustrate the consequences of poor optimization through a simple example. Let’s suppose I have one IT analyst at a cost of $100,000 per year. I have five projects I wish to undertake each requiring one person year of effort and each producing $150,000 of benefits per year starting the year following project completion. Let’s look at two scenarios. First we undertake each project serially. At the end of the first year I start reaping the benefits of the first project. In the second scenario I work on all five projects simultaneously and (assuming no switching effort) I will reap the benefits of all five project starting in year six.

We can calculate the discounted cash flow for both scenarios. These are illustrated in the graph to the left (I’ve used a discount rate of 5%). Obviously in these contrived scenarios the first provides a much more attractive cash flow and the second, as each project is elongated to five years, defers the benefits. The first scenario provides a net present value that is almost 25% greater than the second and the cumulative cash flow becomes positive much earlier.

There are other consequences to project elongation. Project risk is increased (e.g. a critical resource is more likely to leave a company over five years than one). Switching costs are incurred as resources move from project to project. And more management overhead is incurred managing five concurrent projects rather than one. Perhaps less sooner is a better strategy.

As an IT leader the business may not give you a choice as to how many projects you are required to run simultaneously. What you can do in these situations is to use the above analysis to argue for additional resources to ensure that projects are not unduly elongated with the attendant deferral of benefits and the increase of risk. Even so you need to be extremely aware that you are likely to depend on a small fraction of your permanent staff for all projects and think carefully about how many initiatives these individuals can undertake before they become the constraint.       

As an analogy with computer operating systems you will have heard the term multiprogramming or concurrency level — simply how many tasks are executing at once. Too few and resources are wasted — perhaps the processor is doing nothing waiting on slower disk operations. Too many and the costs of switching tasks overwhelms the system and /or each task becomes elongated beyond service goals. Finding the right multiprogramming level optimizes the trade off between resource utilization and timely task completion. Somewhere there is a sweet spot and the same goes for your portfolio of IT initiatives.