Why do delivery timelines change?

If you’ve ever worked on a software product, you’ve probably been there: you start working on a new feature, estimate how much time you will need, and think to yourself, “This will take just a few weeks.” Soon enough issues start to pop up. Bugs from previous releases need to be fixed urgently. Features can’t be integrated smoothly. Unforeseen dependencies create roadblocks. “A few weeks” quickly balloons to “a few months.” How does that happen? How do these small changes become such big issues? Why can’t development be quicker?

It might help you to think of the development process as a jigsaw puzzle. A puzzle is made up of hundreds (if not thousands) of pieces. One piece does very little on its own, it has to fit with the others. And just like doing a puzzle, developing software requires careful planning, “big picture” evaluation, and sometimes taking a few misplaced puzzles apart to put them back together.

The problem with estimates

Since projects usually start with estimates, problems also tend to start there. Sometimes there can be a difference of perspectives between project managers and developers versus business stakeholders. For project managers and developers it is obvious that estimates are not the ten commandments and they were not set in stone, especially if they work within agile frameworks. Being involved in the development process, they are aware of most – if not all – issues that pop up and therefore understand the cause of the delays. Business stakeholders, on the other hand, often only have the estimates to go by and, not being involved in the process, can also be unaware of changes to the plans and – most importantly – why these changes are necessary.

It’s therefore extremely important to understand that feature estimates are meant to provide a roadmap on their own. They’re a guide to an approximate timeline for new product development and budget needed to bring it to life. They help inform critical business decisions, such as whether the ROI (return on investment) of a feature justifies its development cost. But estimates are, by nature, limited. Alas, they’re just approximations.

It’s therefore important to align the expectations and reality of what a product development timeline represents between the development team, business stakeholders, marketing etc. before you start working.

Cone of uncertainty

As a rule of thumb, the more time we devote to the planning, scoping and estimation phase, the more precise the estimate for a successful product launch date. Yet even the most refined estimates can’t capture every unexpected twist and turn or last minute adjustments. This rule is represented by the cone of uncertainty – a well-established industry principle saying that as the project progresses and more is known, the amount of uncertainty diminishes. 

Many mistakenly assume that software is developed pretty much like hardware, as if there was an assembly line that executes predetermined steps and always yields the same result. In cases like this, you can very reliably estimate the time it will take to create something and the cost of it.

Not in software development, though. If there’s innovation involved, everything is so fluid that the environment can change significantly throughout the launch process. Multiple times, even. That’s why it’s important to define particular stages, acknowledge and assess the uncertainty, and work iteratively. After every stage the uncertainty will decrease and the product launch date will become more clear.

What makes estimates fuzzy?

From our experience of developing software and managing the development processes, there are three main factors that stand in the way of a successful product launch: technical debt, system complexity, and interruptions.

Technical debt

Technical debt occurs when your team, for whatever reason, writes a piece of code that they know will need fixing later. This is usually caused by pressing deadlines, so what they’re borrowing is quite literally the time.

Technical debt can delay a successful launch in several ways. For one, it may result in bugs and issues that need to be resolved immediately as they prevent users from completing main flows. But even if the bugs are kind enough to wait for a more opportune moment, technical debt must be addressed sooner or later. This means you will need to devote a portion of time to paying it off eventually – it’s up to you how structured these payments are going to be.

The challenge with technical debt when trying to plan a successful product launch timeline is that it’s sometimes tough to predict exactly how badly it will impact the launch date. Some debt may arise between estimation and development phases, while other debt will become apparent only during implementation.

To learn more about technical debt, its advantages (yes, there are some!), disadvantages, and management strategies, read our other ebook.

System complexity

Then there’s system complexity. A rule of thumb here is that the larger the system, the more complex it becomes. It’s only natural – adding new features isn’t as straightforward in a system that already contains diverse workflows and edge cases as it is when you’re working with an MVP. With each new addition the complexity grows and new features must integrate seamlessly with the ones that are already there. This requires extra time to define launch scope, design, test, and ensure compatibility.

If a certain complexity was not anticipated or properly assessed in the product launch timeline, it might become evident only during development, effectively pushing the release date further down the line. While complexities may not be immediately visible, they are crucial in understanding why development can take longer than initially anticipated. Spending time on properly refining and estimating features decreases the risk of underestimating the complexity. 

Interruptions

Interruptions also have a significant impact on product development timelines, especially in a continuous development model, where various features are at various stages at the same time. Some are in active development, others are being tested in staging by a QA, and some are already live in production delivering value to users. Bugs can be detected throughout this process.

With new features constantly being deployed, there is little room for downtime, and that’s where decisions have to be made: should this bug be fixed before launch date? Does it block users or prevent the successful launch of a new feature? Or can it wait until the next sprint or be added to the backlog?

How we answer these questions heavily depends on the context which will only be known during development, making interruptions virtually impossible to anticipate when estimating project timelines.

How to clear up the fog

Now, it is obvious that the more time we invest in pre-launch analysis, the more accurate our estimates will be, as illustrated by the cone of uncertainty. However, there’s a delicate balance between burning through money, trying to create a “perfect” product launch timeline that will account for all technical debt, interruptions, and complexity, and not spending enough, creating estimates that are so general that they bring no value to the business and the team.

Ultimately, until the product is released, there will always be some degree of uncertainty. And this affects not just the development process, but the business as a whole. How we manage and navigate technical debt, prioritize bug fixes, and make trade-offs between speed and quality will have lasting effects on customer satisfaction, team morale, and our ability to deliver on business goals also at the post launch stage.

So here are five tried and true methods for managing uncertainty and dealing with shifting development timelines:

• sustainable development – technical debt, system complexity, and interruptions are an inevitable part of the development process, so you can proactively allocate 10-20% of each sprint to address code refactoring, testing, and technical debt issues;
• strategic prioritization – by balancing the urgency of fixes with ongoing projects, teams can reduce interruptions and maintain momentum;
• complexity management – to make sure that new features can be easily integrated with the existing product, you and your team should always look ahead for solutions that can potentially decrease your project’s complexity;
• historical data analysis and risk buffers – one of the best ways to make your estimates more accurate is to draw on your experience and base them on historical performance data. In each estimate, you can also include risk buffers based on complexity and estimated likelihood of interruptions or bug fixes;
• communication – perhaps the best and most important way of staying on top of your estimates is to talk to each other. If your team communicates changes clearly, you’ll never be surprised by shifting deadlines again.

Having trouble estimating your project?

Are your product development estimates accurate? Or are they constantly changing and you’re looking for more guidance? If you’ve had enough and don’t know how to make them better, download our ebook “Why do delivery timelines change?” where we explain more in-depth the five methods of managing product launch timelines! Our product launch timelines are based on 200+ delivered projects and 15 years of experience, so you can be sure we know how to get it right.