Project management is always guaranteed to bring out some strong opinions, and a recent Twitter discussion was no different – but, while the core discussion on Twitter was great, it really deserves a much longer-form treatment. Paul Johnston wrote up his thoughts about getting people to talk about predictions instead of deadlines – and much of it is hard to argue with, but I have a bit of a different perspective.

To my mind, there tend to be approximately two types of deadlines:

• fixed deadlines: these involve an independent event which must be met. A caterer who is supplying a wedding, for example, has a fixed deadline. In the product world, these tend to be rare – writing a mobile app for the Olympics 2016 would be a fine example, but writing a mobile app for Athletics news would not. Sales/marketing would definitely want it out before the Olympics, but that’s not the same thing.
• soft deadlines: there is no independent event that must be met. This is the usual type of deadline; often a piece of work needs to be done for a deadline in order to co-ordinate with other work happening (press releases, other product development, rebranding exercises, etc)

The core difference between these two things is Paul’s “after deadline epoch”: in the case of a fixed deadline, we’re really saying (in the case of software) that the artefact will have little or no value past a given date. This is like a punnet of strawberries; once it’s gone past the use-by date, it’s no good.

In the soft deadline world, this is not the case – the potential value of the artefact is largely unchanged. However, value is only one side of the equation; a deadline moving backwards represents incrementally increasing cost. And this is where we get to the nub of the business problem: what is our opportunity cost?

A quick aside: I had a wonderful conversation with a recently-qualified project manager a few weeks ago. We were talking about the benefits and drawbacks of a framework like PRINCE2 for running projects, and to what extent using it in real-life looks like the theory. I made one claim that shocked her, though: that I had never, ever seen a project manager shut down a project of their own volition.

Those with extensive commercial experience are probably entirely unsurprised by that statement. But, to a PRINCE2 “theorist”, this is amazing: a core tenet of PRINCE2 is the continual checking and questioning of whether a project will deliver its aims, the planned value. This is called “Continued Business Justification”, and it should happen throughout the project lifecycle – and if there is no justification, you stop the project.

People who have interviewed project managers will often hear the refrain, “Well, my PID (Project Initiation Document) is my Bible”, but when talking of the PID the interviewee rarely mentions the business case – which is practically the most important document in PRINCE2

It’s easy enough to understand why. We’re all subject to the Sunk Cost fallacy, and particularly because it’s more obvious if projects are failing toward the end of their plan (because people are also great at deluding themselves), it means the sunk cost tends to be pretty large.

What do this have to do with deadlines? Well, when a business decides to initiate some work – whether it’s in a project format, or somehow else – it generally should have some kind of business case, whether formal or not. But if you cannot articulate the cost of doing something, it’s difficult to articulate the net value, and it’s difficult to compare to other options. That’s why people often want a deadline – the project costs need to be constrained, so that different options can be evaluated and the business can take a view on what to actually invest in.

Equally, when it comes to delivery, missing a deadline usually means additional cost (which implies declining business value), but the additional cost tends not to be incremental: it’s quite often catastrophic, in fact, particularly if recognised late in the day.

So, all this together, I think deadlines are inevitable, a fact of life, and I think in many cases the word “prediction” is wrong: while that’s fine for the development side of the deadline (it is indeed an estimate) it’s wrong to think of that goal as a whole as a prediction.

I think the better question is, in the context of software development, “How do we do this better?”. And there’s a few suggestions I have, most of which I try to put into practice (although often there are antagonizing factors that weaken them – that’s a whole blog post in itself).

First, separate the development estimates from the deadline. A set of development estimates should never, ever be a single value – it’s not possible to say “We think we can complete this functionality in two months”. We can (or, should be able to) make statements like, “On balance, we believe it is likely this functionality can be completed in two months” – and it should be possible to put some kind of likelihood on that. 90% probability sounds pretty good, but it means in practice we still expect one project in ten to be late, and most estimates are not 90% certainty. The rest of the business needs to understand that.

Figuring out the likelihood is tough. I like the “triangular estimate” practice for individual stories, but when combining these together we actually need a little bit of statistics. I prefer to pretend they’re a Poisson distribution (and this tends to fit in practice), but equally you could turn them into pure PDFs and run Monte Carlo. I could go into a series of posts about this, and probably will, but you can also just look at some historical projects to get a feel: take the estimates for previous projects, and compare to the actuals. You’ll have a probability distribution there that you can just reapply to your current estimates to give you a feel for worst-case and likelihood.

Second, slack people, slack! Lots of project managers will build slack into a project, but don’t understand it. A common mistake is that people come up with a development estimate, and they say “Ok, let’s turn this into a deadline. But we know just taking this date (as it is) is wrong, so we’ll stick some slack on the end”. Padding, it feels so good! You did a great estimate, and then you gave yourself room to move. Problem is, it’s not actually slack – the critical path is almost certainly still too tight, so it sits like a pot of free time that tends to get used up rapidly.

The correct mechanism to use slack is to sprinkle it through the project. You actually need more up-front, because that’s where the team are settling into the project and progress is most unpredictable. There should be lots of little pieces of slack, and then – critically! – if you use up any piece of slack, that causes an immediate and automatic change to the delivery date.

This is a great control point to revisit your project justification: if I’m 10% and 30 days through my project, and I’ve used all 5 days of slack available at this point, it doesn’t matter if I still have another 20 days of slack in the remainder of the project – the project is way off schedule. I expected to do this work in 25 days, not 30, so I’m over by 20%. I can expect to be 50 days late.

Lastly, agile practices. I am absolutely a subscriber to agile methodology in the right place and time, especially on those projects where the end outcome is not yet really known. It’s much easier to plan out a project where the steps are reasonably well-known; true R&D projects are nothing like that.

I still maintain that the guiding principle here is one of business value. At the point at which we don’t think we’re going to achieve value, we shut the thing down: crucial here, then, is our definition of Minimum Viable Product (if that’s the process we’re using), or the conversations with users. The first point of the agile manifesto contains the (para)phrase “deliver valuable software early“, so while we might not have a deadline for the end artefact itself (delivery when it’s ready/done), we certainly should have deadlines along the way by which point we’ve delivered some measurable value. If we don’t meet those, then again, shut the thing down.

I’m a big fan of Dan Ward’s writing since being introduced to it, and I have been particularly inspired by how he talks about deadlines. The F.I.R.E. book is excellent, and if you haven’t read the book then Dan’s “Change This” manifesto on Igniting Innovation is a good precis. I will quote this little bit, but the whole thing is a must-read:

Last point. I don’t think deadlines are, in themselves, a brilliant metric. As a judge of whether or not business value has been delivered, they’re exceptionally poor – anyone can ship a pile of rubbish to a deadline. Where any delivery involves significant challenge or unknown, it’s ridiculous to set a date as being bullet-proof. But all that said, the commitment of a deadline is extremely useful, and using them as a proxy for the likely delivery of value I think can be powerful.