I had lunch yesterday with an old colleague and it triggered a painfully funny conversation we once had. He was putting together an estimate (in development hours) for a medium sized IT project. He was stressing because he knew that whatever number he gave for his estimate would become the exact budget number used to manage the project and that he would be held hostage by that number. I'll never forget the angst in his voice: "Dude, that's not an estimate. It's a quote!" Thus was born a new word:
estiquote - 'es-tə-kwōt' - noun. Modern IT term referring to the horribly inaccurate estimate a developer gives, is held to, judged by, and ultimately rewarded for despite the fact that requirements for the project were not available at the time of the request.
Of course, in a professionally managed IT shop with proper planning procedures in place this would never happen, right? Wrong. I guarantee every IT shop has a few black eyes from runaway projects. Nobody talks about them (a shame) because the people on the projects have either moved up (a bigger shame), over to another project (risky considering their track record), or to another company (the right choice ;).
The fact is, teams are under tremendous pressure to make sure their IT projects deliver business value. Project managers, who typically have the most face time with a customer, must provide the appearance that the team is very responsive and will turn around projects quickly and cheaply. This can become quite risky when the scope of what the customer wants and what their budget allows is in conflict. Mix in an employee (who wants to stand-out) or a contractor (who wants to keep billing) and you have the potential for disaster.
Here are a few estimating black eyes of wisdom that I can personally share:
If it takes longer than a day it's an estimate. It's impossible to provide an accurate cost or hourly quote for anything longer than one day in our business. If you can't break the work down increments of one day or smaller, your requirements are too vague. I used to use 1 week time frames for my project planing but found that the margin of error was too high. Once slippages started occurring, weeks turned into months and I couldn't account for them because the reasons were too vague to be nailed down. If you're given 10 high level features and have no idea no idea where to start, you should start by negotiating an incremental delivery schedule with budget payouts for each increment. Which brings me to my next black eye....
Fixed-bid doesn't work. Somebody always get screwed. Time and materials is always the best way to bill in our industry. It's better to treat the relationship as a partnership rather than a consumer-provider model. Get the customer to commit to a budget with an iterative investment schedule. If they feel the project is not going in the direction they want, they can cut funding as early as possible. If the development team feels that the project is going south, they can start making noise early and get the problems addressed or at least make sure all the stakeholders know that there is a problem. Ideally, you want the customer to be the one to decide the project should be stopped, but sometimes it's the technical team that needs to call it, so...
It needs to be OK to kill a project. This one always gets under my skin. I've been dinged on performance reviews a couple of times in my career for calling halts to doomed projects. There were always valid reasons to stop: conflicting requirements, poor team performance, no infrastructure to deploy to...I could go on. The fact remains that as a leader (architect or pm) there is unrealistic pressure to deliver even in the face of doom. I even had one project where both the customer and I wanted to kill the project, but my IT management didn't want the black eye. Thank you matrix management. I'll conjecture that if it became acceptable to cancel dud projects as early as possible, IT departments might even become profit centers in some companies. Honestly...$80,000 to build the corporate jet reservation system?
These are just some of my hard learned lessons about estimating. I still have hope for our industry. Agile teams with a strong process and discipline in place seem to be doing well. For my faithful readers...I've got 3 copies of Steve McConnell's Software Estimation: Demystifying the Black Art book to give away if you're interested in further study. It's one of the best books you'll never buy. ;) Just ping me through my Contact page with your mailing address and I'll send you a copy.