Challenging Software Project Estimates: A Path to Productive Dialogues
In the world of software development, estimating the time and effort required for a project is a crucial but often contentious task. What I’ve always found interesting is the pushback and skepticism that frequently arises when the software project estimate seems too high. (I can count on one hand the number of times I’ve gotten pushback on an estimate that is too low).
This dilemma frequently involves stakeholders who lack deep technical knowledge or insights into the codebase, attempting to drive the estimates down, all in the name of a “better” estimate, where “better” typically means lower. Unfortunately, these negotiations often lead to strained trust and lingering issues.
Now, don’t get me wrong; there are instances when challenging software project estimates and seeking a lower projection makes sense, especially when discussing a project with a colleague within the development team and when such challenges are substantiated with facts.
But, when a stakeholder who isn’t directly involved in the development process insists on a lower estimate without providing any new information or insights, it’s akin to approaching an odds-maker and declaring, “Hey, your prediction for the Kansas City Chiefs game tomorrow is wrong. I just know they will score more points than that.” It’s an absurd notion that often leads to unproductive exchanges.
So, why is this approach misguided, and how can we shift the conversation in a more constructive direction?
The critical point here is that the odds-maker doesn’t control the outcome of the game but relies on their knowledge and observed data to make forecasts. Similarly, development teams don’t exert complete control over the effort required for a project; rather, they base their estimates on factors such as team velocity, historical data from completed stories, and ongoing process improvements.
While teams can sometimes choose to expedite certain phases or compromise on quality, this isn’t a recommended practice, as it often leads to issues down the road. Besides, software project estimates should be based on current throughput rather than optimistic future expectations.
Hence, next time someone questions your team’s estimate, especially when pushing for a lower one without contributing new insights, consider responding with a query: “Do you ever tell an odds-maker, ‘Your prediction for the game tomorrow is wrong, I need a better one’?”. It’s a line of thinking that doesn’t hold water and diverts us from a more meaningful discussion.
Addressing challenges to software project estimates with a more productive conversation
Building software is a complex endeavor, often taking more time than initially anticipated. Stakeholders may wish for reduced effort and have budget constraints to consider. In such cases, a productive dialogue should center around questions related to:
- Addressing uncertainties and unknowns
- Determining the time and budget that can be allocated to the project
- Identifying the most time-consuming aspects of the project
- Exploring alternative approaches for time-consuming components
Additionally, consider ways to:
- Divide the project into manageable parts, delivering them incrementally
- Validate each part early, preferably using prototypes
- Identify non-essential features that could be left out or postponed
The key to a more productive dialogue between stakeholders and development teams lies in shifting the focus from futile attempts to lower software project estimates to discussions that revolve around budget constraints, uncertainties, and creative problem-solving. By embracing this approach, software development projects can move forward with greater clarity and alignment.
Do you have a Microsoft Dynamics NAV or Business Central project in your future? Learn more about ArcherPoint’s software development and integration services, then contact us to discuss your needs.