Have you been burned by your own 'Estiquote'?

by on August 8, 2008

Source: http://www.flickr.com/photos/yakobusanI 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.



Comments

August 10. 2008 03:18

Mark Siffer

I could not agree more.  Demanding the precise amount of hours with virtually no requirements is kind of like asking a student: "I need to know exactly the score you will get on your next math test within a plus/minus margin of three points."  Any developer who can acurately make calls like that shouldn't be programming for a living, he should be picking stocks!

Mark Siffer

August 10. 2008 11:11

Mike Cleary

Great post Clint.  Personally I have always been fond of the gonkulation (noun; to gonkulate or guess at a calculation), something I learned from one of my collegues when trying to put together budgets.  Your right on the money regarding the fear of killing projects too.  Hopefully, if you have good governance processes in your organization you will have several checkpoints to stop projects before they get out of hand.  

Mike Cleary

August 11. 2008 16:06

doug b

I disagree on a couple of the "black eyes of wisdom".  Here's my commentary...
http://fastboxster.spaces.live.com/blog/cns!23A7694922D1DC43!299.entry

doug b

August 12. 2008 13:05

Clint Edmonson

Thanks for the rebuttal doug b. It's great to include a business perspective in this discussion. Here are my thoughts:

With regard to killing a project, you wrote:
"The trick is to make sure the stakeholders are happy at the end of each day."

I completely agree. My comment about killing a project refers to the situation where nobody is going to be happy with the result and the project is kept going purely for political reasons (e.g. bonus season coming up). I still say kill it to cut your losses, reflect upon your lessons learned, and move those dollars to another project. There are always a backlog of IT projects waiting in the wings.


With regard to responsibility for failure, you wrote:

"...(ideally the ring of finger pointers should be big enough such that nobody knows who's really at fault). Much like the individual executioner never truly knows who dealt the lethal shot on a firing squad, diffusion of responsibility is a necessity in the corporate realm."

I know it's the reality in many IT shops, but I think it's absurd how much effort is spent deflecting blame. Businesses take (calculted) risks all the time. Why not admit a failure, learn (and share) the hard lessons, and move on. Why do we have to make the developers feel like hell when they (think) they blew it!


With regard to budgeting, you wrote:

"Company officers *should* budget 80K for projects like the corporate jet reservation system not because the simple application is worth it but rather because they know there will be mistakes on their first attempt and the "happy path" any engineer or architect would typically plan for is highly unlikely."

Maybe I used a bad example. We're talking about two different things here. A budget for R&D type work and holding a software engineer accountable to a price tag for a project without real requirements. As a company officer, if I commit to spending $80K on something, that's fine. It's a calculated risk and if it goes nowhere I assumed the risk and I should assume responsibility. But to put the squeeze on a developer for something that's completely out of their control is cruel and unusual punishment.


With regard to fixed-bid vs. time and materials, you wrote:

"In regard to the point about fixed bids never working, I would strongly disagree. While fixed bids are limited in their applicability in the software industry, I have personally been very successful in creating win-win arrangements with many clients. Many times my clients want the exact same thing. I can fixed bid the contract and leverage my efficiencies. While I typically bill any required enterprise integration with dependencies on their existing employees and systems as time and material, the bulk of the cost is fixed. Since I'm able to provide a solution to their business problems for much less than they were prepared to pay, I don't see how anyone is getting screwed."

The reality is businesseses live and die by creating and optimizing repeatable processes. If you are hired because you're an expert at XYZ and have done it a hundred times, you should be able to give a very accurate estimate of say +/- 5% of the actual cost. However, if you're the IT generalist developer inside an IT shop and you just get tapped to quote a project with a scope bigger than anything you've done before, you'll become stressed out very quickly. With such a large margin of error, it's in everyone's interest to mitigate risks. Incremental, iterative plans with an incremental time-boxed budget schedule is the best way to tackle these kinds of projects.


Finally, you wrote...

"Overall I do agree that project estimation is extremely difficult. It is one of those necessary evils. Somebody has to go to the board and say, "Here is what we want and this is what we think it will cost.". If our expert software engineers, architects and consultants can't come up with a number then there's no chance the project will ever get started. I think the bigger problem lies in the fact that most of those individuals estimate how long it would take clones of themselves to build the project and fail to remember that they are they highly paid experts, not the coder with 1-2 years experience. Technical people tend to be way overly optimistic (I guess that's my black eye of wisdom to contribute)."

I completely agree - it is a necessary evil in order to scope out a budget. But wouldn't the better question be "Here is what we want and this is how much we're willing to spend"? It's been proven many times over that developers are the worst people to estimate the cost of a project. Conventional thinking says that business analysts are the best estimators, since they are in a position to understand the scope of the project and know the capabilities of the development team they will be working with. Why do we keep making the mistake of asking the developer for his estiquote?

Clint Edmonson