Translate

Wednesday 27 July 2011

Project and Programme Management #10: Resources and Levelling

The first thing to say about this topic is that it is one of the most difficult parts of project planning because often the information you need is hard to obtain.

Levelling theory

The theory is relatively simple. Once you have completed your initial project plan with task durations and dependencies (as described in my previous post) you can plot the initial critical path and thus the overall duration of the project. However without adding information about who is doing what, the critical path calculation assumes that tasks that can be done in parallel will be so. However what if the same person has to do two parallel tasks – they can’t do both at the same time, so your plan needs to take this into account as well. This is what levelling does: it works out which resources are overloaded and then moves tasks around so that the overload is removed. This usually means the overall timescale of the project is increased.

Let’s use the “cup of tea” example we’ve been following so far. The activity network from last time shows that the tasks of boiling the kettle and get cup through to get milk can happen in parallel. Well let’s just say, for the sake of this illustration (click to enlarge), that you have to watch the kettle boil. This means you can’t get the cup, etc. at the same time. If you have two people doing the task one can watch the kettle and the other can get the cup, etc., so the plan we arrived at before is viable. But if there’s only one person available, there can be no parallel activities and the duration of the project increases from 210 seconds to 258 seconds (see illustration: in the upper diagram the critical path is shown in red, carried out by “person A” and the non-critical activities done by “person B” are in blue).

Levelling in practice

So in order to carry out levelling, you need to find out what (who) your resources are for every activity in the project. But it doesn’t stop there. Let’s say that you are lucky enough to have a resource available full time on the project for a task that you estimate will take 250 hours to complete, and that they work seven and a half hours a day. Does this mean you can say that the task will be done in 33.3 days? Of course not, because people cannot work at 100% capacity all of the time, all day. They need to take breaks, go to the toilet, answer the phone, etc. Then you need to factor in any leave, public holidays, etc. So actually you may only get 60%-75% capacity out of them – your 33.3 days is looking more like 44.4-55.6 days! In real life you may not even get a dedicated resource (i.e. they have to fit in other activities as well), so you have to estimate how much of the resource really will be available: maybe only 30% – so our 250 hour task will actually take around 111 days!

So when you are allocating resources to your tasks, you need to factor in the proportion of time they can devote to it.

Then you can use a tool like Microsoft Project to calculate the levelling (it’s very long winded to do it by hand) – this will look at the resource weightings and also look at any parallel activities that the resource has been allocated against. Finally it will attempt to move tasks within their float, and then rearrange tasks to minimise the critical path impact. Normally you need to check the results as some of the automatic assumptions the software makes won’t work in practice.

In fact, it’s even more complicated in real life! This is because of factors like:

  • Some tasks may have (or need) more than one resource allocated to them;
  • Some people are more effective than others, so knowing generic resource titles may not be good enough: brick layer A may be 25% faster than developer B;
  • In some cases multiple resources can work in parallel, cutting down task timescales (e.g. three brick layers can each work on different sections of the wall), but in others it may be a team effort so its not a simple time divided by number equation.

Another pitfall is double-weighting a resource. For example, let’s say you have calculated the above 250 hour activity to need 111 days based on the weightings noted above. Let’s also say you got the initial 250 hour estimate from the person who would do the work. It’s is entirely possible that they factored their availability into their estimate, so what they meant was – “I can do this in 250 hours alongside all my other commitments”. In this scenario, for the sake of the calculation, you’d then put them down as 100% available.

If you’ve read this far and are starting to despair, this the point at which I should say not to worry, help is at hand.

How to plan in real life

So, what’s the answer?

  • My experience is that you need to know the theory, but when you apply it, you use instinct and a “pinch of salt” as well.
  • Also, you don’t estimate the task durations / resource weightings on your own: you talk to the people who will be doing the work.
  • Personally I try to get people to give an estimate of duration based on their current commitments and working practices: this means I don’t have to worry about weightings – I can treat them as 100% available because the weighting is factored in to their estimates. (But do beware: people tend to estimate on the optimistic side!)
  • The same goes for team efforts: I get an estimate from the team for the duration of the activity and then show them as a single resource (Development Team A), rather than as X number of people allocated.
  • However, where people can genuinely work in parallel (the brick laying example) you can put them down as X number of people so long as your estimate of the task duration was for one person to do it (e.g. a wall takes one person 10 hours so two can do it 5 hours).
  • There are bound to be gaps – you won’t always know who all your resources will be, so you do your best with the information you’ve got. A project plan should be continually refined throughout the project.
  • Finally, some projects just are not amenable to resource allocation and levelling. In this scenario, you just have to try and estimate task durations as best you can – and then adjust them as you go along.

No comments:

Post a Comment