Late for a very important date - again?

Say what you will, most projects don't get delivered on time. A critical appraisal might include the word late. I'm starting to think however that the terms 'on time' and 'late' are worth consideration. And maybe, if enough consideration is given to the subject perhaps there might be something genuinely novel and interesting to conclude about the nature of projects generally, the frailty of current management approaches and what can be done about it.

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

1. Preliminary planning fails to identify accurate the work that needs to be undertaken or the time it will take to complete it.
2. Failure to accurately identify dependency relationships, leads and lags
3. Blunders, poor forecasting and re-work
4. A change budget (£/$) but no corresponding schedule allowance
5. HR Management issues (absence, incompetence and ineptitude)
6. Failure to manage complexity
7. Criminal or unlawful activity
8. 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.

1. When is this sort of critical appraisal essential as opposed to desirable or superfluous?
2. What could the job of analysis of a project scope / schedule entail?
3. What could the output be used for?
4. Who would do it? When? And for what purpose?

Forecasting - part four

Ironically in my first post on forecasting I cited the following points which I would aim to cover.

1. Parametric or reference class forecasting
2. Guessing, uncertainty and pragmatism
3. Never mind 6 Sigma - 1 will do you quite nicely
4. The PM's job in fighting for exactitude and rigour in the planning process
5. Some helpful language and strategies to challenge sub-standard practice
6. Some real life scenarios and tools consistent with other articles in this blog that I hope will add a bit of value

And here we are on the fourth post on the topic and I think I still have pretty much the lot still to get through. Something relevant to the topic of forecasting in their somewhere methinks.

Let's hustle on a bit. 

Parametric or reference case forecasting is simply the process of using historical events to inform forecasting. Let's go back to our example of changing a car tyre. I discussed some useful stratagems on getting to a more accurate forecast, but ultimately you can't beat having changed a tyre yesterday to inform a useful forecast on how long it might take today.

Guessing? Don't do it. If you don't know how long something is going to take, set a duration on your project plan and commit to using a schedule performance index to track progress and assign more (or less resources as appropriate). Or, some other similarly pragmatic approach.

Standard deviation isn't something we've talked about before and I think it would be worth keeping this back for a specific post. (That's the point on 6 Sigma / 1 Sigma above). What I think I will do for the remainder of this post is focus on point 5 above.

There are undoubtedly a great many opportunities for the activity of forecasting to fail. I'm going to describe a few ways that (I've seen) project delivery deviate wildly from the forecast and then highlight some stratagems to help avoid it doing so.

Shoddy project planning - I don't know how many more project plans I'm going to have to work with that comprise 1000+ lines, rely wholly on duration based (rather than effort based) planning and (to top it all) incorporate 50%+ of hard coded dates.

I don't have the knowledge, capacity or inclination to write at any length on the topic of project planning and good practice using MS Project (or other). However, allow me to suggest that the inputs to creating a project plan include the following;

• Experienced planners who understand critical path analysis, activity on node / on arrow techniques
• Knowledgeable staff who have either been through a structured programme of learning or other activity necessary to equip them with the knowledge needed

And some general useful pointers while we're on the topic

1. The near term should be at a far greater level of detail than than the mid- or long term
2. Decompose tasks to an 'appropriate' level of detail
3. You don't have to, but project plans comprising tasks which track back to product break down structures and product descriptions tend to have a much firmer foundation
4. Supplement your forecasting with appropriate controls so that if you're wandering off schedule, your have good information early
5. Make sure public holidays and staff leave are configured within your resource planning
6. Agree up front what the resource capacity is (70%-90% - typically 80%). Never 100%.
7. Practice rigorous change control. You may (or may not) be able absorb additional tasks of less than 0.25 days effort. Make sure you have a mechanism to manage anything that exceeds what you can comfortably accommodate.
8. Building (clandestine) budget contingency into business cases and budget forecasts is wrong (and can be fraudulent). However, I'm pragmatically fairly well disposed to building in a degree of flexibility / contingency into forecast schedules. You'll be able to cope with a greater degree of unforeseen events and I've yet to find a client who complains when you bring something in a bit early. You'll also be able to give the client an answer other than no when he asks if you can bring something in a bit quicker.

Supplier management issues certainly figure highly in my short list of frustrations most likely to unhinge a project plan. You're embarked upon a project and chances are, so is your supplier with all the vicissitudes to which projects in general or prone. Some points intended to enhance stability follow.

1. Don't blur the lines between dependencies. If you have a dependency for which the supplier is responsible, don't start to re-plan and re-forecast (unless absolutely necessary) when the supplier starts to slip. That's a recipe from a problem shared is a problem doubled.
2. Make sure your contract and commercials with the supplier are appropriate
3. Make sure you have the appropriate written and agreed documentation to support the supplier's statement of work and scope of supply. 
4. Verify your supplier has instated 'good practice'.

Governance or lack thereof. Get the right decision made, at the right time to the right criteria. Incidentally, it's worth mentioning IT Governance in here - this is distinct to the typical corporate and project governance insofar as it's principal objectives are maximising value and minimising risk. Technical design assurance, testing, change management and a solid approach to service transition all comprise elements of good IT governance.

A little more yet to cover on this topic generally. If I'm feeling suitably whimsical, I may relay at some future point my thoughts on the role of analogue computing to forecasting in project management (another first for PMfizz surely?)

Proportionality in controls

Early identification of the 'pinch' points and putting more effort towards controlling those elements is, in my opinion, time well spent.


In the example below, we're 5 months in on a project, the customer isn't too sensitive to cost, but is extremely sensitive to delays.

Doubtless there are a few ways of tracking quality. I've often thought that if you're handing over  project deliverables sequentially, CPI and SPI sort of give you a 'QPI' or quality performance index since your customer is signing off acceptance of products as you go. 


With IT projects you do involve the customer in test and review activities throughout the design and development work, but sign-off tends to be a bigger bang type activity. The PM of any IT project needs to be fully cognisant of the customer's wants, needs and any deficiencies as an ongoing process. This activity is encompassed within testing and defect management.


I'll do a post at a later date on the range of metrics relating to defect management which I like to capture but here I've singled out something I've always been very keen on. See the bottom of the three charts above. Something not entirely clear is that that the graph isn't cumulative. Each month the number of defects identified that month is plotted against the number of defects fixed that month. At a glance, this shows whether or not you have an unsustainable, worsening or improving state with regard to defect identification and resolution.

Note the control charts above, not only are these easily maintained and communicable, they illustrate trends and the tolerances to which the project is expected to adhere. Incidentally, I'm a fan of publishing this sort of material directly to the project team - it encourages shared ownership and good alignment of decisions throughout the project team.

As can be seen above we've got more tolerance on cost than time. Take the cost (CPI) plot, we went from a good start, to holding steady, followed by three consecutive periods of deteriorating performance. With the benefit of hindsight it would have been useful to have a more frequent reporting interval - if we'd had fortnightly reporting - somewhere between month 2 and month 3, it would have become apparent that corrective action was required, and consequently far more easy to justify.

While the time (SPI) plot serves to illustrate this point very well, what we could have seen in advance was the very limited tolerance on schedule would have benefit from more regular reporting for precisely the reason above. The emergence of a trend would have happened far more quickly.


These sort of indicators are one approach to helping ensure that within any given project, benefits are maximised and risk is minimised. The best indicators are those that inform timely decision making before things go off the rails, not simply reporting on the fact that they have.

Turning data into information with earned value management

While a firm believer in earned value management I have a confession to make. I've never joined a project or programme in which earned value management is in use. Either within my specific work stream or any other that I have been able to get sight of. I estimate there are potentially three likely reasons for this.

1. There is no requirement to track cost or schedue performance in fine detail
2. There is no capability or inclination to use earned value management
3. There is no market for the specific outputs of earned value management

I might be able to help with number three.

I'm a fully paid up member of the Association for Project Management (APM). The APM has several publications and its Earned Value Management Guide is (I think) one of the most thorough and clear pieces on the topic by anyone anywhere.

The document covers a great deal of material but I include here what was, for me, an entirely novel approach to illustrating earned value - namely the bullseye chart. See below.

Now, for earned value advocates I appreciate that some of the trending and intuitive extrapolation is less apparent. However, for sponsors and stakeholders not well versed in earned value management, I think its appeal is self-evident.

Equally once the initial spreadsheet is assembled, it uses precisely the same data as traditional earned value charts so really, its very little extra effort.

I owe a huge deal of credit to Jon Peltier of peltiertech.com, an MVP with superlative Excel knowledge for providing a step-by-step on his site for how to create a bullseye chart. It is remarkably finicky. You'll be pleased to know, I've saved you all the hard work by including an Excel file here which you're free to use.

I believe it's possible to add date markers to the series labels on the graph which I think would be an enhancement. And for those of you with an appetite for such things, you could publish this via Excel Services in SharePoint and, using external data sources for the bullseye chart, have a real-time dash board for all your projects.