This is the first in a series of posts where I actually digest and write about articles I’ve read elsewhere. What better way to understand something you’ve read than try to write about it? Of course, with this blog’s track record, it may well be a series of one. :)
Source: All late projects are the same by Tom DeMarco.
Tom’s been working with software for the last 50 years. For the past couple of decades he’s been involved in supporting litigation for software project delivery failures. In this article, he eschews his original, pithy, reason for software projects being late:
I thought all late projects were the same in that they were really estimation failures, not performance failures.
He goes on to explain why that’s not really true – mostly because people never really do estimations in the first place:
This was cute but not very accurate at a deep level because so many projects don’t really do any estimating at all. Rather, they propose a goal and then get someone to espouse it as an estimate. Delivery by January of next year? Sure, why not?
Sounds about right in my experience. In fact, it rings true for a current project, in that the delivery is set for July 2013 and we’re all to work to that target. I’ve said, “well, let’s see what we can build in ~70 days of effort.” I mean that we need to vary the scope (never the quality!) if the schedule is fixed. I’m being up front about that (I hope).
Of course, I never like to bring up estimation as an excuse for late delivery because I hate estimating and I’m terrible at it. ;)
But Tom goes on state a simpler maxim for why software projects are late:
All projects that finish late have this one thing in common: they started late.
Personally, I’d question whether this rule is peculiar to software projects. It seems generally true. Which then gets you to wondering why software projects still have a peculiar tendency to be late.
Who says software projects tend to be later than other projects, anyway? Anecdotally, if you watch Grand Designs every single building project turns up massively late and over budget. There have been one or two high profile non-software delivery failures just in Edinburgh recently, too.
Anyway, Tom then posits three reasons for projects being kicked off late:
Nobody had the guts to kick off the project until the competition proved it doable and desirable; by then, the project was in catch-up mode and had to be finished lickety-split.
If the project were started long enough before its due date to finish on time, all involved would have had to face up to the fact from the beginning that it was going to cost a lot more than anyone was willing to pay.
No one knew that the project needed to be done until the window of opportunity was already closing.
He called BS on the third one – citing Google as being 15 years “too late” to the search engine market – and suggested that it really disguises one of the first two.
The first reason is a clear business failure, and attaching responsibility for the failure to the software delivery team does seem somewhat like blame shifting. Of course, the company that kicks off risky projects before they’ve identified a market need (before it’s been proved “doable and desirable”) is often the company that doesn’t survive long enough to get into litigation with their suppliers, so there’s an element of self selection in Tom’s samples, I suspect.
The second one is the most compelling, to my mind. If a project has a 100x return on investment, people aren’t going to get too upset if it takes twice as long as originally estimated; you’re still getting a 50x ROI, which isn’t to be sniffed at. But if the project only has a 10% return on investment, lateness will be disastrous!
Maybe the rule is that the rigour of estimation should be inversely proportional to the expected return on investment?
He finishes off with a nicely quotable line, so I will too:
What’s really wrong with us software folks is that we’re continually beating ourselves up for something that’s somebody else’s fault.
No, not that one. While I get the sentiment, and I totally get that we shouldn’t be beating ourselves up over other people’s failures, it still sounds an awful lot like:
A big boy done it and ran away.