An interesting article over on the Hashrocket blog a couple of days ago grabbed my attention as in it they detail how they think upfront estimates (I’m assuming in both time and money) for projects are not only infeasible but also unfair to clients as, ultimately, they will be incorrect. Given that I’ve spent over seven years working in the web industry and can count on one trotter the number of projects that have ever been delivered bang on schedule, I’m inclined to agree. Yet still, we find ourselves doing it time and time again.
The simple and obvious answer to all our woes is simply to tell the client that we honestly have no idea how long something is going to take to create beyond a mild inclination in the deep recesses of our Senior Developer’s brain and that they should just accept this and pay for every day’s work until it’s done. Now, whilst approach might work for some people (can I have the names of your clients? Pretty please?), I’ve yet to personally ever encounter anyone who would accept those terms. Everyone I’ve ever met and every project I’ve ever worked one, ranging from small private clients to large public sector ones, have all adamantly requested fixed, upfront costs.
Whether or not this phenomenon is restricted solely to the web industry, the UK (I have a funny feeling there’s a different attitude towards fixed budgets in the States – feel free to cast some light on this), or me personally, I think we can all agree that it’s a bit bizarre. How on earth can anyone accurately estimate the time – and thusly cost – of a project before they’ve even begun working on it? How can we be asked to put a time frame and price tag on something that, at that stage, we know very little about?
setting expectations at a point where you are not informed enough to know the full scope of what you are estimating is essentially lying to your stakeholder
This isn’t to say that I don’t understand the reasoning of fixed costs because I do. In fact, I understand it completely and, if situations were reversed, I’d request the exact same thing. Still, it puts a lot of pressure on the web contractor to deliver the right solution for the job on time and within budget. And that’s not easy.
As is common knowledge amongst the programmer world, it is a practical impossibility for developers to accurately estimate work for a variety of very good reasons. A lot of them also just don’t care that much about deadlines (which isn’t always a bad thing). Scope creep, bugs, design set backs, unforeseen issues, the natural rise and fall of productivity and the simple fact that you and the client may have had completely different ideas about functionality from the get go are individually all other very valid, and very likely, reasons for a project to overrun. Combined, they are also all reasons why it’s impossible to give precise estimates.
This isn’t to say that the process of estimation is pointless or unnecessary because it is still very important. You need some sort of guide to knowing how long something should take and what tasks are necessary in achieving it and, without a detailed estimate, you would just be building blind without restraint. Likewise, experience, knowledge, decent investigation and a little bit of a caution added to a reasonable contingency can make estimates a lot more accurate than you might actually think. After that it’s then up to solid project management, upfront designs for as much as possible, detailed specifications and good client communication to ensure that what you create is as close as possible to what you planned.
But like I said at the start, it’s very, very difficult to get upfront estimates right, impossible even. Of course, once you’ve accepted that fact then everything becomes a bit less painless from there on. Planning for the unknown, managing clients and their expectations, and generally running projects gets a lot easier once you stop fooling yourself that those initial numbers of a piece of paper were anything more than a simple educated guess.
Original photo credit: wwarby