Software development estimates are horribly inaccurate. The business people want to know how long it will take and what it will cost to build a software system — fair enough. Businesses routinely operate with schedules and budgets.
However, because businesses have schedules and budgets, the business leaders already know how much time they’re willing to allocate and how much money they’re willing to spend on a project. Every successful business manages time and money carefully. They have to.
So, why are the business folks asking the software development team for project estimates? Is this a cat and mouse game? Are they bargaining with us, “No reasonable offer refused!”? What’s the point?
Here’s what usually happens.
- The business managers tell the software development team what they want.
- The development team comes up with a rough estimate (really an educated guess at this stage).
- The managers say it’s too long and too expensive.
- There’s some back and forth on the high-level feature set and system architecture.
- In the end, the business managers tell the development team how many people they will have and how much time they can take. (Because time is money, setting a team size and project timeline effectively determines the budget.)
- The development team grumbles that there’s not enough people and not enough time to build the system. Let the games begin!
That was a massive waste of time and brain power. Everyone was stressed out in the bargaining process. It was like buying a used car from a sleazy used car salesman!
Here’s what should have happened.
- The business managers approach the software team and describe the business problem they want to solve.
- They offer solution ideas and layout the timeline and budget constraints they face.
- The software team describes a few options with the benefits and drawbacks of each.
- Together, they work through business and technical priorities to arrive at a proposed implementation that’s expected to meet the time and budget constraints.
That was much less stressful, right? In the first case, the business managers and the technical people are adversaries. They are playing a game and trying to win. In the second case, they are a team working together to solve a business problem.
The key differentiator is teamwork. When people operate as a team, they cooperate and collaborate. When they operate as adversaries, they defend and argue.
Yeah, I know – the devil’s in the details. There are still many detailed software requirements to be worked out. The business will undoubtedly want some features that the development team simply cannot deliver in the allotted time. The development team will surely make some mistakes along the way that will chew up precious time.
Life’s not perfect. Get over it.
The key point is to get the entire process started on a positive note and build early momentum. It’s not about who wins and who loses. It’s about building a successful business, and doing that requires building great software through teamwork.