The most powerful step in software development

What’s the most powerful step in a software development process?
It’s not uncommon for analysts to label steps in a process. The critical path, bottlenecks, waste, and non-essential steps come to mind.  So I would say that common wisdom agrees that all steps in a process do not hold equal weighting of importance. Maybe there isn’t a single most powerful step in the software development process you follow or maybe it depends on the context of the situation.

For what it’s worth, a few weeks ago it occurred to me that the act of estimating was perhaps the most powerful step. Estimating is completed at the ground level, by those that do the work, not by the executives or managers. Most decisions to do or not to do a project are within the hands of executives and managers. But it’s those closest to the work that influence the decision with their estimates for cost and return.

Mike Cottmeyer, a leading Agile development thinker and trainer, acknowledges that estimating for numbers is a tough step in software development in his post The Real Reason We Estimate. But Cottmeyer’s main point is that  “Estimating is about creating a shared understanding of the requirements, and a shared understanding of the solution. When teams have problems estimating, its almost never an estimating problem, it’s a shared understanding problem.”

I like that line of thinking and agree that estimating provides the benefit of shared understanding. But most shops I know use estimates to determine if a project will even exist.

Estimating determines if work will begin
The power of estimates is clearly visible when a large estimate for work cancels a project or a particular solution to problem before it’s even started. To be fair, that’s part of the purpose of the exercise. If a work effort to bring a solution to a business problem is so large that it doesn’t make sense to do then you would want to consider alternatives or move on to the next business problem. That’s just sound financial discipline.

But I’m thinking so much about the extreme estimates as I am about the typical project. The number of hours estimated is eventually turned into a cost and the cost is compared to the dollar figure from the estimate of benefit. That’s basis for the return on investment calculation. Bottomline, estimating is used as a decision point if the project will begin or not.

Estimating determines the budget
If the project is considered to be a good business investment then the estimates are used to set the budget. That’s important for obvious reasons of people payments or equipment purchases. But the budget also determines if additional work is required in the future. If the team goes over budget it triggers other processes, meetings, and decisions to get in alignment with a budget. That’s additional work, which while necessary, is also expensive and not directly related to creating the solution for the customer.

So that’s my case. Estimation is the most powerful step in the process because it directly influences if the project will exist and if it does exist it influences the budget.

Let me know if you have any other thoughts on this topic.