Handling Multiple Small Projects

Anyone who has worked in IT has had the situation in which you are assigned to more than one IT project. For this post I will use the term IT project to mean a body of work needed to accomplish a recognizeable business function. It may touch one system in one file and it may touch 7 systems in 11 different ways each. Typical IT management thinks like an accountant:

Let's see, I have 6 1-month projects and 3 developers  (Mark, Luke & John). I'll give 2 each and tell the customer that they will all be done in 2 months! Man I'm good.

Obviously this is a straw man, but it is the general thinking I have seen and read enough times to believe it is prevalent. The only way I know to analyze this is with some basic math. Let's assume that the estimates are accurate. Let's assume that each developer is equally productive (lets call it P). Let's call the work to be done on each project W1, W2...W6. Lets call the time to complete each project T1, T2...T6. So the basic formula is Tn = Wn/P.

All seems good, but IT work doesn't work like painting a fence. In painting a fence if you have painted 1/10 of the fence in one day you are pretty sure than in 10 days you wsill be done. IT work almost always follow an S curve.

You start off getting little done, followed by moments of massive productivity, followed by some painful moments of finishing/fixing the project. Agile/Lean techniques can help straighten out the curve, but it still isn't a line and I'm not sure it's a healthy goal.

So if Mark is working on projects 1 & 2 and 1 happens to get hard Mark is likely to spend more time on 1 than 2. Which means 2 suffers becuase 1 was got hard. So instead of finishing them both in two months they both slip a week or three. The other problem is that it is a known fact that focusing one one project at a time is fater than focusings on 2.

Another problem is the poor return on investment. By definition, IT projects are being funded by a business of some sort. This business usually spends money for one of two reasons, either it will save money or increase sales. Accounting 101: Time vlaue of Money (PV = FV/(1+i)^n) means the early you save/make the better off you are.

Scenario A (projects in parrallel)

PV1 = FV1/(1+i)^2

PV2 = FV2/(1+i)^2

Scenario B (projects serial)

Project 1 goes first

PV1 = FV1/(1+i)^1

PV2 = FV2/(1+i)^2

PV2 in both scenarios are equal and it we assume i>0 (which is true except in cases of deflation) then PV1 for scenario A is always less than PV1 for scenario B. BTW this even assumes the two scenarios take the same amout of time.

Therefore delivering 2 projects in 2 months is worse than delivering 1 project per month. The key in any time management course/book/workshop/blog is focus on the important things first. The key to multiple projects is getting the business to prioritize and have IT to focus. 

In my little example let's assume the number represents the priority. I would get the 3 developers together and have them decide the most productive way of tackling the list. They might decide they all can contribute to 1, but only one has the knowledge for 2 and while that is going on the other two can tackle 3 and so on and so forth. Then have them use an estimation technique (e.g. planning poker is fun and has on-line support).  Do some simple planning to come up with estimated completion dates for the customer and you are going to do better than most. Of course, if you have a true Agile team then simply work them in priority order.