How to Deliver On Time (Even with Changing Requirements)
James Barr
TAGS
James Barr
TAGS
If you have any experience working on software projects, you’ve probably missed a deadline—sometimes the same one more than once.
Why is it so hard to stick to a schedule?
Projects are squeezed by multiple forces: Stakeholders want the things they originally asked (and are paying) for; new requirements come to light in the middle of the process; hidden challenges take extra time to overcome; and at the end of the day the software still has to work.
There are two ways to deliver a project on time.
The first is to ignore everything that happens along the way: build an exact definition the work (with a lot of buffer around it) and follow through exactly as planned. No new ideas permitted, no scope creep. If something important comes up: too bad. This works on the most routine projects.
For everything else: align on outcomes, and continuously adapt along the way.
Scope can change in the face of new information and unexpected challenges, as long as it’s in service of the outcome. But when something is added, something else has to be removed. This forces difficult decisions, that tend to make the product better in the end.
To deliver outcome-based projects on time, there are a few things to do.
Planning matters, but you’ve got to plan the right things. It’s not what you’re building, it’s the goal you want to achieve that matters.
Start with the business model.
What will your product do that’s worth money to your users? How will you know when you’ve achieved that? What are the jobs to be done that are valuable to users, and how will this product, when it’s done, achieve that outcome?
It’s easy to picture features, because those are the things we interact in other people’s software. They’re visual, interactive, and memorable. But features aren’t the point—they serve an outcome, and outcomes are abstract and hard to visualize.
But getting the outcome right is the most important step if you want to deliver on time. It forces the product to pay attention to what the user needs and takes the focus away from ‘features’.
Planning for outcomes makes pruning a lot easier.
With outcomes (and their measures) understood, it’s time to do the research.
The research process should be lean and repeatable. It should include at least 12 prospective users, and more is better. Ask the same questions to all of them. For this particular job to be done, what do they enjoy? What are the points of friction? What is the most painful thing that might be solved with software?
If users are reasonably qualified, enough of them are interviewed, and the script is standardized, a hypothesis will arise. Either there’s no solution, or there are a bunch of themes that, combined, might be worth paying for.
Document the themes as User Stories—still aligning on outcomes rather than features.
Then give the users a chance to weigh in on those outcomes. What’s important? What’s inconsequential? Call or survey as many folks as you can.
Now: collect the top user stories into features. Find the feature that drives what looks like the greatest user value, and get into the weeds.
Design it. Spec it. Make it happen.
Focus on the feature’s outcomes, and organize the work around them. Technical tasks to support the feature will come up: link those back to the original story/stories, so it’s crystal clear what value is being delivered by any piece of work.
Going deep on a single outcome like this allows the depth of thought needed to get it right. It also expands the list of things to do, which could risk the timline—unless it’s properly dealt with.
When the first feature is done, tested, and produces the desired outcome, it’s time to rebuild the priority list.
Ask: “What’s the most important feature left to build now?”. Re-order the list so focused work can start on the next item. At this point the list has likely grown, and may be too long. It’s time to deal with that.
New information will surface all the time. User feedback will trickle in late. Unexpected technical challenges will come up. The list of things to do, based off the initial plan and discovery, will continually grow.
If scope continues to grow, there’s no way to hit a deadline—unless the list is pruned.
Plans built around features are hard to prune. Because features are so easily imagined, they’re hard to let go. But a plan built on outcomes only serves the goal, not the features. The outcome is rigid, but the execution is flexible.
As the list grows, it’s repeatedly sorted in order of descending user value. By definition, things at the bottom will have been passed over, probably more than once, because they are low value.
Prune them—every time the list is sorted.
The only way to hit the deadline is to do the amount of work actually possible in that amount of time. Cut the things that don’t matter, and the product will be better for it, anyways.
Delivering on time isn’t a by-product of being good at what you do, it’s a strategy.
When the team doesn't have a strategy, the strategy is "do it all!". This is the worst of both possible worlds: a scope that only grows over time, and a product that’s delivered really, really late.
For even the smallest projects: start with outcomes, and document it all. Do the research, and identify themes from the user’s perspective. Collect themes into features, and then focus intensely on one—and only one—at a time.
Every time the list is sorted, prune things that are low value, and put more effort into the real priorities.
All of this taken together keeps focus on what matters. This process allows us deliver above and beyond the goals of a project every time—maybe it’ll help you too.
James Barr founded Strata Research in 2019, and he just won't leave.
