Software Estimation and the Business-Technical Conflict

by Krishna on November 21, 2007

People often talk about the 5 day workweek, but in reality, such a division of time and work is only applicable to hourly-paid workers. Financial people divide time into quarters of the year. Marketing folks divide time into advertising campaigns and trade show events. The technical crowd divides everything into projects. The IT support crew divides everything into periods of relative calm punctuated by hectic fire-fighting.

Most companies are dominated by people who work on the business side (sales, marketing, finance, etc.). And like it or not, their milestones tend to become the milestones of other people in the company. For example, if the marketing vice-president has an exposition coming up, that event acts as a point in time around which product deliverables get done. If the finance head needs to meet certain targets before the date of filing results, newer versions have to released and sold before then.

This causes significant conflict between the business and technical sides in the company. The delivery dates to which the technical team can commit and the order in which they want to work on the deliverables have no relation to the business deadlines. Unfortunately, neither side knows the language of the other. The businesspeople don’t understand the technical difficulties involved. The technical people don’t know how to express their concerns in an understandable manner or how to negotiate deadlines well.

Often, the business people accuse the technical team of padding the estimates. In my experience, this is very ironic because

  • Software developers and teams are more likely to underestimate the complexity of building an application, especially during the initial rounds. This is because they have been given “high-level” product features and have not understood the implementation details.
  • Software development invariably tends to run over budget and over time. The accusation would make sense if the business folks could point to any project that did the opposite. You cannot win this argument though — someone always points to Parkinson's rule.
  • Experienced engineers with less management experience are likely to over-estimate their capability of building the application. When formal estimation techniques are not used, they will try to relate the project to some other work they have done and provide an estimate.

Business people are more persuasive and more aggressive at getting what they want. If they talk loud enough, even the most confident engineer has self-doubts and tries to figure out how much he can bend the estimate. For example, he thinks, “If this deliverable takes 2 months, I could probably bring it down to 6 weeks by using tool “X” and maybe working a few extra hours every week.

The problem is that an under-estimated project is further under-estimated, resulting in a Death March. The tragic aspect is that everyone knows that the goals are not realistic, but are so committed to the project that they put extraordinary effort. In the end, all they get for their hard work is blame and the bitterness of failure. Sometimes, people can be burnt for life after going through such an episode.

My point is that if you are a business person with little understanding of technology or project management, do not presume to know better. You must trust your technical people when they give you estimates. If you don’t like the estimates, it does not mean that they are wrong, just that they are inconvenient to you. If you over-promised someone, go back and re-negotiate. It is better to lose your face in front of someone than to submit your team to weeks of hell.

In a future article, I will suggest ways for technical people to avoid committing to difficult or impossible deadlines.


Kalpesh November 21, 2007 at 9:58 pm

this is a good one on somewhat similar theme.

Krish November 22, 2007 at 5:13 am

Thanks for the link, Kalpesh. Good one!

Comments on this entry are closed.

{ 1 trackback }

Previous post:

Next post: