Your Project Will Suffer From Power Laws

You have this great new project. With groovy new technologies, a fine bunch of developers, and a preliminary set of requirements that looks challenging. And now the customer asks you to give an estimate for the release date.

When will you deliver the product?


So you do a bit of estimating, perhaps using the Wideband Delphi technique, and taking into account the Cone of Uncertainty, and then you come up with a target release date of, say, six months from now. And you explicitly tell the customer that the date you're giving is a planned release date, not a promised date. The actual release date can be somewhat sooner or somewhat later. Right? There's probably a margin of plus or minus one month, or something like that. Right??


You just made a terrible error.

You forgot about power laws.

Power laws are everywhere. We find them in gravity, stock markets, populations, wealth, fractals, language, geophysics, revenues, intelligence… To name just a few. Power laws are easier to draw than to explain. Here's one:


Power laws are sometimes known as the 80-20 rule, sometimes as the long tail, sometimes a Zipf's Law, sometimes as scale-free networks, etc. But all of those variants come down to the same thing:

The relationship between frequency and magnitude of a phenomenon is not linear, and does not follow a normal distribution. Instead the relationship is polynomial. It's the logarithms of frequency and magnitude that have a linear relationship.

Suppose you were asked to estimate the size of the next earthquake in San Francisco. What would you do? Would you check the size of the last ten earthquakes (= your experience), and then calculate the average out of that? I'm afraid that would be a mistake. The power law is in earthquakes too, under the guise of the Gutenberg-Richter Law.


The distribution of changes in a complex system usually follows a power law. Most often the changes are small, and in rare occasions the changes are huge. You cannot come up with an average or typical size of an earthquake, because there isn't any: "What this [polynomial] relationship means is that there is no typical size in the conventional sense." (Wikipedia)

It's the same with that great new project of yours. Your estimate of the work itself may be fine. But then the real world steps in. And you experience disturbances. Your team leader finds herself a less troublesome job, one developer gets himself a bad social disease, another developer gets himself a wife (which for some people amounts to the same), the new technologies require nuclear workstations to achieve minimal performance, some project manager sneakily snatches away your last developer, and the requirements are multiplying like camels in Australia. Needless to say, your velocity drops like Madoff's credit balance over a black hole. All this, of course, results in a few changes to your planning.

Changes in a complex system follow a power law.

Your six-months-plus-or-minus-one estimate is a mathematical illusion. Forget about it. Reality doesn't follow your smoothly curved normal distribution. Reality follows vicious power laws. There is no typical size for the disturbances on your project, so you cannot calculate an average out of them.

Your project will suffer from power laws.

Pity huh?

(images by Hey Paul, Hay Kranen, and National Resources Canada)

Twitter TwitterRss SubscribeEmail NewsletterDelicious Bookmarks

Latest, greatest and favoritest posts:
Self-Organization = Anarchy (Part 3)
Self-Organization = Anarchy (Part 2)
Self-Organization = Anarchy (Part 1)

  • Top 200 Development and Social Media Blogs (OPML)
  • Bootstrapping Our Social Media Business
Related Posts
free book
“How to Change the World”
  • Laurent

    So, instead of telling the customer that the planned release date, not the promised date, is in 6 months (plus or minus one), what would you tell him?

  • Rick

    hmmm you are now making the exception the rule, it appears to me. Sounds like a vision from the dark side, with which you create a self-fulfilling prophecy. An experienced team/pm should be able to decide an expected delivery date (if variables do not change to much). Ok, maybe the plus/minus 1 month isn’t really logical, but a deadline can be given with enough certainty. The task for the pm is also to manage the deadline, thus when new requests are are entered or the Germans invade, discuss with the customer what this impact means on the given deadline. Oh, you want our developers to join the army and protect us against the Germans? No problem, but this means that the expected delivery date is postponed with two months and you have to pay more(if we are able to scare them of in two months). You decide.

  • Dennis Stevens

    The way you manage this situation is to say – it looks like about six months. There is some uncertainty in our understanding of the problem domain that we will be exploring in the next month. I will let you know if we identify any exceptional problems that are likely to be more that a month in delay.
    By the way – I have risk that I have only one developer that knows the suchandsuch interfaces. If we loose that developer it will cause a problem – how should we handle that?
    You do the same with the other risks you know about – your reduce them early, identify them, and manage them. The problem is when the power law sneaks up on you at month six because you haven’t managed the project.
    That’s why risk management is so important and why we (managers of technology implementations and development projects) get paid for what we do.

  • Henk van Dijken

    Power law sucks. It doesn’t matter who and how the expected time of arrival/delivery is “calculated”. It remains an arbitrary deadline. You could use dice to calculate it. However, as soon as everyone – especially the customer – agrees to this arbitrary chosen deadline you have set a common goal.
    So, project management is not about delivering functionality set in stone and calculate the needed time, but delivering something that hast just sufficient functionality at the agreed point in time. In other words, in the beginning the developers think they have plenty of time and build goldplated – generic & reusable – functionality and in the end when time is scarce they compact the functionality as much as possible. Just to deliver on time.
    Conclusion: if you set a milestone in stone, your goal is that milestone and not the functionality.

  • Jurgen Appelo

    I think that will require another blog post. 🙂

  • Denis

    Obviously the Power Laws are out there, but I believe it’s the PMs job to manage the deadline. Any uncertainty should be managed through the risk management process, and it’s obviously also a good idea to emphasise strongly it’s the planned date you giving the customer, not the actual.
    The power laws may persuade you not to provide a deadline, and I think there is even greater danger in doing this. In my experience, work generally expands to fill the available time (Parkinson’s Law), and deadlines are thus important to focus the minds of everyone involved in the project and make prioritisation easier. I’ve never seen good things happen in projects which start up without deadlines for whatever reason.
    I’d be really interested to see you’re follow-up post covering how you would proceed in this situation.

How to Change the World - free Workout - free