Show Me Your Work: Why Planning Drives Outsized ROI
James Barr
TAGS
James Barr
TAGS
A century of combined product experience told us time invested in planning always pays itself back. We had no idea how much we were underestimating.
Properly planning a software project (conducting research, defining requirements, designing architecture & user interfaces, documenting acceptance criteria) requires a significant time investment and can feel like treading water. But we’ve repeatedly seen it save us time in the long run. We’ve never empirically quantified it, but casual evidence was believable: a week spent planning often saved a week of implementation and bug fixes, maybe two, down the line. At worst, we finished on time with higher confidence in the outcomes, at best we’d get a week back: a two-for-one return on time invested.
A recent project made us start to wonder if that was the case in other organizations. Looking at the research, the number we found wasn’t 2:1. Boehm and Basili (2001) determined that if the cost of a defect in the planning phase is 1, fixing that defect often costs 100x in production. Even for small, noncritical projects, the ratio is five-to-one.
That research is pre-Agile, but Agile doesn’t eliminate the need for requirements clarity, it only distributes it across sprints where it may never happen at all. And the evidence is clear: more than 20 years since Boehm and Basili, software defects remain a huge cost: US developers spend an average of 33% of their time on technical debt (Krasner, 2022). Agile has not solved this problem.
The practical ROI from all this is obviously not 100x of all planning time, it’s whatever subset of that time directly equates to the reduction of “defects” down the line—some small and sub-feature level, some massive and architectural. As long as the time attributable to preventing defects is more than 1%, there’s positive return.
Although that percentage is difficult to predict, it has been separately shown that 50% of downstream product defects are attributable to failures in planning (Berenguer, Borges, et al, 2023). Defects that come from a lack of user understanding, missed requirements, architectural gaps, and other foundational elements of a project are a type that no other tool or process will easily catch, and are often the most costly to fix later. Pair this with the technical debt stat: What could your developers accomplish with an extra day a week?
This problem is only going to be amplified in a world of AI-assisted coding tools.
As AI compresses the cost of code generation, and while it can help with syntactic errors and common problems, it does nothing to resolve errors of dysfunctional planning. If anything, it accelerates the rate at which underspecified, under-planned code can enter your codebase. The implication is that the ratio, whether 2x or 100x, is going up. The value of planning only increases.
Jack Dorsey recently said 'the intelligence tools we're creating and using, paired with smaller and flatter teams, are enabling a new way of working.' He may be just waking up to it, but this has been possible for a long time: Strata's run small, flat teams for seven years, and our biggest value-add has always been the planning phase. AI isn’t a requirement for this type of structure, it’s a support.
Ultimately, we were way off. Planning isn’t a zero-sum driver of predictability: it’s the secret sauce. It can buy back more than two months (per year!) in future development, freeing organizations to take bigger swings more often.
The question we’re left with is what about project velocity itself? Most of that ROI is post-launch. What ‘defects’ come up mid-stream, and how much does planning accelerate the initial launch?
Next time, we inspect some real project data and find out.
---
James Barr founded Strata Research to experiment with leaner, faster teams in mid-market and enterprise contexts.
