There's an interesting blog post here that I read sometime ago - you should read it but in absolute summary - there's no such thing as slipping dates, just bad forecasts. I remember this really making an impression with me when I read it. I don't just think its a good point, I think its a potent entry point to a much richer discussion.
A while back I prattled on about an idealised constant 'K', which represented all the work that was required to be done to complete your project assuming no waste. I've re-rendered the drawing below.
There's some simplification here. There's no discussion of change requests, procedural acumen or PMO statistics for this sort of project run in your organisation but broadly;
Work that needs to be done to complete your project is K
Work that you identify to be undertaken for your project is Kb
Magnitude of error in plans is K - (k2) + (k1).
k2 is interesting as you may or may not end up doing it and to some extent it cancels out k1 which you'll always have to do.
What's our list of variables then? Things that might influence k1 & k2. I suggest the following
- Preliminary planning fails to identify accurate the work that needs to be undertaken or the time it will take to complete it.
- Failure to accurately identify dependency relationships, leads and lags
- Blunders, poor forecasting and re-work
- A change budget (£/$) but no corresponding schedule allowance
- HR Management issues (absence, incompetence and ineptitude)
- Failure to manage complexity
- Criminal or unlawful activity
- Acts of nature
Of the 8 points above, I would suggest that item 1 is far and away the most significant. Some other time I might take the time to blog on the predilection of homo sapiens to focus on outliers at the same time as dismissing the significant but for the time-being I think I'll simply focus on items 1, 2 & 3 above.
Let's take a moment to summarise and take stock. Project delivery consistently moves to the right (perhaps systematically so) and there is (I suggest) some consistent harbingers of this movement. Interesting this isn't it? We've got a consistent output (delays and destabilisation of the project schedule), consistent inputs (I'll continue to subscribe to points 1-3 above - other views almost certainly exist). Shouldn't this mean we can do something to quantify and assess the potential impact to our projects?
There's a little bit of overlap here potentially with the schedule performance index which I mention here. But its not quite the same animal. Firstly, you've actually got to implement some rudimentary earned value management and (somewhat shockingly) almost no one ever does. But it will only help you so much as it will only use a sample of work done so far rather than a more useful measure the project in its entirety. This means you'll get increasingly good data as your project progresses but at the outset, it'll be highly unreliable.
At this point, I feel I want to talk about cooking for a while.
Cookbooks are full of recipes. They describe the ingredients and implements required, the steps, temperatures and techniques to use and usually describe the output. They do this consistently well otherwise people wouldn't buy them.
If you follow the instructions and you have a little culinary acumen you can have a high level of confidence that what is delivered will be edible. Delicious even. If however, you use second rate ingredients, rush the prep, burn the food and respond to a late request to remove the anchovies, there's significantly less chance that what you deliver will be fit for purpose or on time.
Cookbooks are a good illustration of our idealised constant 'K' that I mentioned above. They do have the advantage however that a) they're not a unique undertaking and b) almost universally they'll have been reworked and rehearsed perhaps over several generations. So, they're not projects are they. But they do highlight the importance of knowing everything there is to know at the outset and what the benefits of knowing everything are.
Continuing on our epicurean line for a spell longer. If we removed some of the ingredients and steps from a recipe we'd be doing something to model in abstract the deficiencies in planning to which many projects (all?) find themselves prone. Would we be able to identify the omissions? What could we do with them if we did identify them?
We'll, there's one sure way of identifying that there are omissions (as opposed to what they are) and that's cook the dish. I don't think its too much of a stretch to suggest that any omissions could be identified and quantified. So what's the benefit of investing this time and effort? What can we do with the information we're now in possession of?
Can we extrapolate anything about the remainder of recipes in the cookbook (project)? Can we play any discrepancies across the remainder of the project? Well, maybe. Omissions from the fish section might not be applicable to the dessert section and should you take your cookbook to your aunt's for Sunday roast, all bets might be off when comparisons are made with cooking in your own kitchen. This is where the schedule performance index (and cost performance index) fall short for our purpose here - they focus exclusively on the sample of work that has been done, not a proportionate sample of the whole piece.
What I am tilting at here is that if we cook a few recipes up front we'll be better able to assess the cookbook in its entirety. The more recipes we test (the greater the sampling) the better picture we'll develop of the overall scheduling, scope and procedural quality.
So what next? I'll seek to elaborate the points above and answer the following questions.
There's a little bit of overlap here potentially with the schedule performance index which I mention here. But its not quite the same animal. Firstly, you've actually got to implement some rudimentary earned value management and (somewhat shockingly) almost no one ever does. But it will only help you so much as it will only use a sample of work done so far rather than a more useful measure the project in its entirety. This means you'll get increasingly good data as your project progresses but at the outset, it'll be highly unreliable.
At this point, I feel I want to talk about cooking for a while.
Cookbooks are full of recipes. They describe the ingredients and implements required, the steps, temperatures and techniques to use and usually describe the output. They do this consistently well otherwise people wouldn't buy them.
If you follow the instructions and you have a little culinary acumen you can have a high level of confidence that what is delivered will be edible. Delicious even. If however, you use second rate ingredients, rush the prep, burn the food and respond to a late request to remove the anchovies, there's significantly less chance that what you deliver will be fit for purpose or on time.
Cookbooks are a good illustration of our idealised constant 'K' that I mentioned above. They do have the advantage however that a) they're not a unique undertaking and b) almost universally they'll have been reworked and rehearsed perhaps over several generations. So, they're not projects are they. But they do highlight the importance of knowing everything there is to know at the outset and what the benefits of knowing everything are.
Continuing on our epicurean line for a spell longer. If we removed some of the ingredients and steps from a recipe we'd be doing something to model in abstract the deficiencies in planning to which many projects (all?) find themselves prone. Would we be able to identify the omissions? What could we do with them if we did identify them?
We'll, there's one sure way of identifying that there are omissions (as opposed to what they are) and that's cook the dish. I don't think its too much of a stretch to suggest that any omissions could be identified and quantified. So what's the benefit of investing this time and effort? What can we do with the information we're now in possession of?
Can we extrapolate anything about the remainder of recipes in the cookbook (project)? Can we play any discrepancies across the remainder of the project? Well, maybe. Omissions from the fish section might not be applicable to the dessert section and should you take your cookbook to your aunt's for Sunday roast, all bets might be off when comparisons are made with cooking in your own kitchen. This is where the schedule performance index (and cost performance index) fall short for our purpose here - they focus exclusively on the sample of work that has been done, not a proportionate sample of the whole piece.
What I am tilting at here is that if we cook a few recipes up front we'll be better able to assess the cookbook in its entirety. The more recipes we test (the greater the sampling) the better picture we'll develop of the overall scheduling, scope and procedural quality.
So what next? I'll seek to elaborate the points above and answer the following questions.
- When is this sort of critical appraisal essential as opposed to desirable or superfluous?
- What could the job of analysis of a project scope / schedule entail?
- What could the output be used for?
- Who would do it? When? And for what purpose?
