If ‘Can I Get my Project Done Quicker’ is the Question, then Planning at the Day Level of Detail is the Answer

If ‘Can I Get my Project Done Quicker’ is the Question, then Planning at the Day Level of Detail is the Answer

If you think about it in its simplest terms, when any project is executed – something tiny like making dinner, all the way up to something massive, like Brexit – the project happens because a sequence of jobs is carried out.

To be even more precise, each day of the project, each one of a group of people do one or more things, until eventually (hopefully!) the project is over.

Figuring out this sequence of jobs [i.e. who does what on what day] in advance is known as planning. Figuring it out as you go along is called firefighting. Figuring it out after the fact is often known as a project post-mortem – but more often as a cockup. (See earlier reference to Brexit.)

When you come to carry out your project – any project – there are three possible ways you can build this sequence of jobs [who does what on what day]:

A.   You can have no plan and just let the project unfold – see what happens. Now, apart from the ‘we don’t have time to plan it, just go do it’ merchants, of which, unfortunately, there are still far too many about – no sane person would deliberately do this. But I would bet my house (and I would win the bet) that in your organisation today there are people doing precisely this. They’re doing it not because they’re stupid or incompetent but because they’re overloaded; they’re too busy – with the result that essential planning on a project gets overlooked completely or only done partially or not done at all.

B.   The second way to build the sequence of jobs is to do it in real time – to make it up as you go along. This is known as firefighting.

C.    The third way is to build the sequence of jobs at the beginning.

There is also the very real issue of what level of detail the sequence of jobs should go to. But clearly, the only level of detail that ultimately matters is the day [i.e. who does what on what day] level of detail.

In reality, most people don’t just do one, but rather, a combination of A, B and C above. Here are some typical examples:

1.    A ‘high level plan’ is built [C – sort-of] and then the day-to-day decisions on who will do what on what day are decided … well, day-to-day [B].

2.    ‘We use Agile’. A ‘high level plan’ is built [C – maybe] and then the day-to-day decisions on who will do what on what day are decided day-to-day [B]. 

3.    ‘We have constantly changing priorities’. No plan is built [A]; the project is just started and then the day-to-day decisions on who will do what on what day are decided day-to-day [B].

These, and any similar approaches guarantee that the project will take longer rather than shorter: Precious days will be wasted, the project will go down dead ends that will have to be retraced, scarce resources will be frittered away as problems – many of which could have been anticipated in advance, if we had planned at the day level of detail – are discovered for the first time.

If you build a plan at the day level of detail, it is like you have identified one possible way the project could be done. You have made all the decisions about who is going to do what on what day – decisions you would have to make some day anyway.

But in terms of A/B/C above, you have made these decisions in a (relatively calm) C setting – critically – before you’ve made any commitments to any stakeholders. This is as opposed to the A and B settings where these commitments have been made long ago and the setting is anything but calm.

So, to build a plan at the day level of detail, we need two things:

1.    We need to be able to estimate accurately.

2.    We need to have a way of representing the plan we come up with.

Happily, both these things already exist:

1.    I’ve been teaching people how to estimate accurately for nearly thirty years.

2.    There is something known as a ‘strip board’ – something that has been knocking around in the movie-making industry, pretty much since its origins.

Need to shorten a critical project of yours? Give us a shout fergus@fastprojects.org.


Comments are closed.
%d bloggers like this: