The article is really cool even though it is a little bit simplistic in my view (and experience). I've also made this comment on the article by the way.
The first problem is that rarely steps are independent from each other. I haven't seen hard data on this (and if they have hard data, they should look at it) but my guess is that if one step fell behind schedule, there's an higher probability for the next step to fall behind schedule. That's because the reason a step is behind schedule is not purely random but depends on the internal element of the project (it is harder than usual, using new tech, a person is overloaded and always late...) and all this problem will not magically disappear in the next steps.
The second issue is that project are not so simple as a sequence of task. They usually have tasks in parallel,with different dependencies and sync point. Accounting for time variations on each step quickly become a total mess.
Why Are Projects Always Behind Schedule?
21–30 of 111 posts
Re: Why Are Projects Always Behind Schedule?
#22There's also feature creep, which is a pretty big problem in a lot of less organised companies and organisations. The original design may well be a six page website with mostly static content, but the final version could just as easily be a web app with a built in help/support/ticket/chat system, member accounts and live updating from a third party API. One two week estimate easily becomes a six months one.
Or it's delayed because of more and more edge cases being found and someone not wanting to be consistent about them. If the first, third, ninth, sixty second and hundredth items in a loop have to all act differently for seemingly random reasons, that adds a lot of time to the development.
It unfortunately doesn't matter how good your estimate is if the company/client tosses out the orignal spec at the first possible opportunity.
But for well managed projects, yeah, it's a good writeup.
Re: Why Are Projects Always Behind Schedule?
#23There is actually a nugget of thought in the article beyond the explanations you always hear (and which make up all the comments in this thread as I'm writing this): Even if you base your project schedules on accurate estimates of the median time required for each step, you will still be behind schedule for most projects. The reason is actually quite simple: when things go well, they can only go so well, but when the…
This is very true. The best way I have found to combat it is by splitting up the tasks into many smaller pieces. If you have a task that is scheduled to take a month, then it can easily go out to 10 months in the worst case. If you have a task that is scheduled to take a day, it can easily go out to 10 days in the worst case. This allows you to make corrections to your schedule.
There are 2 other important issues. First, you need to update your schedule based on the amount of time tasks are actually taking. If you only have 10 tasks (each taking a month), the error bars can be quite significant. But if you have 200 tasks (each taking a day), the mean completion time will have quite small error bars. So if you keep a rolling average (say over the last 30 tasks), you can have a fairly good estimate for completion time (agile developers will notice that this is "velocity").
The second very important issue is to be completely anal about your definition of "done" and about making sure that the completed tasks actually meet that definition. Your mean completion time will only be useful if you are measuring the time to completion accurately (obviously).
This effect is so powerful that I recommend "same sizing" tasks and planning everything to have a completion time of somewhere between 1 and 2 days.
There is actually one last thing you need to do. Requirements discovery never happens completely before you start development. As you write the code, you discover new things to do. It is obviously important to modify your plan to accommodate that new information. If you don't, you will end up building something that nobody needs. However, the amount of new work seems to be predictable. I made graphs of new work added to projects over a couple of years and it appears that the growth of new requirements is very similar to some of the defect discovery models (for example Littlewood). Just making a graph of new stories/tasks added over time will give you a decent idea, but I have found that a rule of thumb of adding 30% or so (over the whole project) for new requirements seems to work well.
Re: Why Are Projects Always Behind Schedule?
#24There are unknown unknown in projects, people won't pay you for a full analysis and there is always the option that one library you rely on has a nasty bug you cannot foresee.
One doesn't have to go very far and look for psychological issues when a major source of indeterminism comes from directly the imperfect tooling itself we use.
Sometimes software is compared to construction, except you don't get to start with a perfectly detailed environment to build your software on. Until we have this major source of indeterminism in the tools themselves, pretending to fix issues on the estimation process alone is a fool errand.
I believe a as-400 project can be estimated fairly well now based on previous experiences. But how would you go estimating a project relying on, say, local browser storage? The only way is to go and build it and identify all the pitfalls yourself, and then the browser landscape changes and you get set back all over again.
Just following Safari rules on IOS to obtain a full screen mode sets us back a week on almost every releases. We started before they started messing with stuff, now we include a week of fixes in the schedule for every major IOS update, but we had no chance to predict this when the project started.
Re: Why Are Projects Always Behind Schedule?
#25Cheap, fast, good. You can only have two.
In practice, you can't even have two. That's because the cheap-fast-good rule assumes that you're already close to an optimum, whereas in practice, things are expensive, slow, and bad, for reasons that are unrelated to one another. As a result, a team will lower the requirements, or agree to spend more money, and discover that the project still takes just as long. I've seen this happen over and over.
Re: Why Are Projects Always Behind Schedule?
#26Earlier quoted context omitted.
This always bugged me cause it means every project estimate should be infinite in length.
Zeno's Paradox. The solution is that a series can converge.
But then you'd expect it to converge, and that would break the law.
Cost estimation is an NP problem. Perhaps it will become practical when we can use a quantum supercomputer to estimate the time needed to build a single page web app.
Re: Why Are Projects Always Behind Schedule?
#27Here's the other piece: Estimations happen prior to negotiations. This is why you see so much "buffering." A much better approach is to figure out your budget / schedule first and then work on what scope can fit within that pre-alloted budget / time frame.
Re: Why Are Projects Always Behind Schedule?
#28There is actually a nugget of thought in the article beyond the explanations you always hear (and which make up all the comments in this thread as I'm writing this): Even if you base your project schedules on accurate estimates of the median time required for each step, you will still be behind schedule for most projects. The reason is actually quite simple: when things go well, they can only go so well, but when the…
Ah I like this explanation a lot. It's almost as if project task timing distributions are negatively skewed.
Re: Why Are Projects Always Behind Schedule?
#29Earlier quoted context omitted.
Zeno's Paradox. The solution is that a series can converge.
But then you'd expect it to converge, and that would break the law. Cost estimation is an NP problem. Perhaps it will become practical when we can use a quantum supercomputer to estimate the time needed to build a single page web app.
No, because you'll just ask it to build it in constant time. Software costs more to measure than to do.
Re: Why Are Projects Always Behind Schedule?
#30Where I work we don't estimate in time, we estimate in points. Points are intended to represent engineering's view of the relatively complexity and uncertainty of a given story.
Pivotal Tracker then looks at story delivery over the past 3 weeks and gives a simple average: velocity. You can then look forward to see approximately when future stories will be completed. You can also see a volatility measurement, which characterises how much velocity is fluctuating.
Our horizon is deliberately short, because we move very quickly.
Nevertheless, it has a simple advantage: it is based on the true and most recent data of the exact project you are estimating.
Other estimation techniques are useful in other situations, but simply being able to say "those are the actual numbers for this project this month" is enormously powerful. There's no fudging. The numbers are right there in black and white.
It usually takes a little while for people new to this approach to accept that velocity is not a target; it's a measurement only. It's a unitless measurement that is only meaningful within a single project, operating at a floating exchange rate with calendar days.
One last thing that helps, as others have pointed out. Break down your estimation tasks into smaller units. Never accept the small headline that hides a big feature. Continuously look for seams to break big stories into small stories. When the pointing begins, summarise aloud with fellow engineers a rough idea of what will need to be done.
Psychologists call this the "unpacking effect", and I suspect that it's responsible for most of the estimation-increasing power discovered in more fully-dressed estimation techniques like PERT, parametric estimation tools or even good old fashioned checklists.
(I was working on an estimation tool for a while, so this subject is dear to my heart).