How unrealistic roadmaps cause delays

Using of bad data for timeline estimation inflates real schedule boundaries

Very often data, such as high-level estimates of features or initiatives, are used for time estimation without any connection to uncertainty, team expertise or scope assumptions. In that situation that data may be inaccurate and misleading, as it represents an unrealistic path to feature delivery. Additionally, if data were produced by using low-precision planning techniques such as pure judgement, it would be subject to optimistic bias and elevated risk outcomes [1].

Lack of rigorous teams alignment creates bottlenecks

Many planning facilitators neglect calculating how multiple teams should be involved in different initiatives on a roadmap. When not aligned properly, multiple initiatives may collide and cause bottlenecks, and teams will simply burn out by trying to complete multiple things at the same time [2]. The bottlenecks by themselves lead to postponed deliveries, performance crisis, and scope reduction to meet the deadlines [2].

Absence of risk buffers creates a cascade of issues

Often risk management and calculating risk is not part of creating roadmaps. However, it poses a large threat to roadmap performance and deliverability. In an environment of a limited number of teams, even a single feature delay can cause a cascade effect on the delivery of the whole roadmap, which may then lead to significant performance issues and subsequent feature delays, if the appropriate safety buffers are missing [3].

Infrequent updates create stale roadmaps with teams starting to waste resources for irrelevant activities

In the software business, new requirements can arrive all the time. A need to seek new opportunities or make important tradeoffs is high and happens regularly. However, many companies choose to fight for the original roadmap rather than change it. If roadmaps are not updated with new requirements constantly, teams just start to ignore them altogether, creating their own roadmaps that accommodate the new requirements that management ignored in order to adhere to the original, outdated plan [4]. Such roadmaps crafted by teams often don’t completely match the company’s strategy and lead to wasting company’s resources for non-relevant activities, ignoring company’s initial strategic goals [4]. Despite the company fighting for the original roadmap, an outcome opposite to their goal is achieved.

What delays mean for stakeholders and customers

Many companies believe that delivery issues are “normal,” however it’s questionable whether customers or stakeholders share the same opinion. Let’s review a few obvious side effects of missed deliveries.

Project failures and budget overruns

When roadmaps are unrealistic they can run into budget problems and ultimately fail without being completed [0]. When vendors fail to deliver the promised features, customers may become dissatisfied, question the vendor’s credibility, or lose trust in its ability to meet future commitments. [5]

Slow growth

One of the consequences of unrealistic roadmaps is a slow down of growth, which occurs when a promised functionality is not ultimately delivered. As a result, the value is never monetized. In software companies, growth velocity directly impacts valuation metrics like the “Rule of 40;” when revenue growth stalls due to delivery bottlenecks, companies lose credibility with investors and struggle to secure future funding rounds [6].

Losing momentum to competitors

Speed is one of the most valuable components for success for both big and small companies. If a roadmap is constantly delayed, the company can lose momentum to competitors and experience seized opportunities and strategic failures [7].

What should be done instead

Companies should pay heed to creating well-balanced, properly aligned, and realistic roadmaps. Neglecting diligence in the strategic planning process simply isn’t worth it. The mistakes and risks mentioned earlier will cost a much higher price. Spending a week gathering requirements and aligning teams, and then dedicating one day a week to make operational roadmap updates will cost companies much less than losing to competition or the next investment round [4].

A reliable roadmap should:

• Use realistic estimates that account for uncertainty and assumptions and clearly connect to a specific scope

• Align teams and dependencies before committing to delivery timelines

• Account for risk rather than assuming everything will go according to plan

• Define the scope and expected outcomes clearly enough to distinguish genuine delivery from scope reduction

• Be updated regularly as new information, requirements, and opportunities emerge

A good roadmap does not mean that nothing will ever go wrong. Unexpected events will always happen: people leave, requirements change, dependencies fail, and new risks emerge. The purpose of a reliable roadmap is to account for known uncertainty and provide a mechanism to react to new information before it turns into a missed commitment. If a significant event makes the original commitment unrealistic, the roadmap should be adjusted and the commitment renegotiated before the delivery date is missed.

All-In-One Solution for Honest Roadmaps

If you need a complete all-in-one solution to build reliable roadmaps, check out the free method developed by our team of experts: https://honestroadmaps.com.

Links

[0] - BCG Group (2024) . Software Projects Don’t Have to Be Late, Costly, and Irrelevant

https://www.bcg.com/publications/2024/software-projects-dont-have-to-be-late-costly-and-irrelevant

[1] - Steve McConnell (2006). Software Estimation: Demystifying the Black Art, 1st edition. Microsoft Press

https://www.pearson.com/en-us/subject-catalog/p/software-estimation-demystifying-the-black-art/P200000009047/9780735637030

[2] - Matthias Patzak (2025). Deliver Faster by Limiting Work in Progress. AWS Executive in Residence Blog

https://aws.amazon.com/ru/blogs/enterprise-strategy/deliver-faster-by-limiting-work-in-progress/

[3] - Ellinas, C. (2019). The Domino Effect: An Empirical Exposition of Systemic Risk Across Project Networks. Production and Operations Management, 28(1), 63-81. https://doi.org/10.1111/poms.12890

[4] - Trieflinger S, Münch J, Bogazköy E, Eißler P, Schneider J, Roling B. Product Roadmap Alignment – Achieving the Vision Together: A Grey Literature Review. Agile Processes in Software Engineering and Extreme Programming – Workshops. 2020 Aug 18;396:50–7. doi: 10.1007/978-3-030-58858-8_6. PMCID: PMC7510781.

https://pmc.ncbi.nlm.nih.gov/articles/PMC7510781/

[5] - John A. Hoxmeier. (2000). Software Preannouncements and Their Impact on Customers’ Perceptions and Vendor Reputation. Journal of Management Information Systems, 17(1), 115–139.

https://doi.org/10.1080/07421222.2000.11045635

[6] - McKinsey & Company. (2021, August 3). SaaS and the Rule of 40: Keys to the critical value creation metric.

https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/saas-and-the-rule-of-40-keys-to-the-critical-value-creation-metric

[7] - Paternoster, N., Giardino, C., Unterkalmsteiner, M., Gorschek, T., & Abrahamsson, P. (2014). Software development in startup companies: A systematic mapping study. Information and Software Technology, 56(10), 1200–1218. https://doi.org/10.1016/j.infsof.2014.04.014

Start with Ranges

For the sake of analysis, it’s convenient to regard estimates as a range of outcomes rather than a specific value. In his book Software Estimation, Steve McConnel, a well-known industry author, presented a diagram called “Cone of Uncertainty.” This diagram features how the range of possible software cost/size estimates shrinks as a project progresses through its lifecycle.

The idea is simple. At the very beginning, the cone is wide, indicating a high level of uncertainty. At this stage, many factors can affect the final outcome. Implementation possibilities, technological limitations, and changes in client requirements create significant “noise” around the project. Over time, as requirements are refined and tasks clarified, the cone begins to narrow. Initial uncertainty is replaced by clearer expectations and a better understanding of the final product. As the project approaches completion, the level of uncertainty becomes minimal, and teams can confidently estimate costs and timelines.

Let’s review an example. Suppose we have a project with just a single line as a requirement. Let’s say “Implement a Payment Gateway solution.” In the beginning, the vast number of the requirements are not clear (e.g., what this gateway will be used for, which payment methods it will support, what interfaces are the most important for the end user). We can identify this stage as “Initial Project Concept.”

Statistically, according to the cone of uncertainty, an estimate for this stage will have a range of outcomes anywhere from 0.25x to 4.0x. In practice, this means that if the project is given an estimate of 100 days, based on historical data, the possible outcomes can be anywhere from 25 days (being the most positive outcome) to 400 days (being the most negative outcome). With time, as product teams perform work that clarifies specifications and defines clear UI design, this estimate becomes clearer, too. Once the most basic questions about functionality are answered and the initial design sketch for UI is finished, the estimate can be further narrowed down to the slot in the cone that corresponds to the range of 0.8x to 1.25x. In the example of 100 man-days for the baseline, it will mean 80 to 125 days for potential outcomes.

Calculate a Risk-Adjusted Estimate by Using Standard Deviation

While it may be very representative to use an estimate range for presenting estimates, it is still often much more convenient to use a single number based on the given range and so-called risk appetite. Risk appetite is the amount of risk an organization can take to achieve their objectives. In this case, project goals. It is smart in general to select a reasonable expectation rather than bet on high risk; however, in some situations, such as when the project team is quite experienced, one may pick a higher risk.

It is convenient to calculate a risk-adjusted estimate by using standard deviation formulas.

Note: Given formulas are based on prior broad research on IT projects average performance in the industry. They can be helpful in general cases, but can be tweaked based on historical organizational and teams’ performances. These formulas are the simplest ones.

Use these formulas this way:

1. Take historical value as a baseline

2. Calculate standard deviation by using low range number as a best case estimate and low range number as best case

3. Calculate risk-adjusted outcome estimate based on risk appetite correlated with % level of confidence

Example

Let’s assume that our project “Implement a Payment Gateway Solution“ is in the Requirements stage and that the team has provided the following baseline estimates (in days) for the project tasks.

Our goal is to evaluate an outcome estimate based on provided baseline estimates and the confidence level of 80%.

Let’s apply the formulas we defined earlier.

Based on the stage of the project, which is Requirements, we can use the 0.67x for best case multiplier and 1.5x for the worst case multiplier according to the Cone of Uncertainty. Let’s calculate all necessary values for the equation.

Let’s calculate the standard deviation based on that data:

StandardDeviation = (150 - 67) / 6 = 13.83

Based on the confidence level we should select the following formula from the table to calculate the outcome estimate:

80%: Baseline + (0.84 x StandardDeviation)

Let’s evaluate that calculation for our case

OutcomeEstimate = 100 + (0.84 x 13.83) = 111 days

We got 111 days as an outcome estimate with 80% confidence level. Using that estimate will decrease our risks when executing a software development project and will ensure minimum stress on teams and clients with being on track on delivery expectations.

All-In-One Solution for Honest Roadmaps

If you need a complete all-in-one solution to build reliable, evidence-based roadmaps check out the method developed by our team of experts: https://honestroadmaps.com.

The software development industry is fast and dynamic. Frameworks, such as Scrum or Kanban, are extremely popular. And what’s inside of those frameworks? Sprints, story-points and velocity. Most estimation models that exist today focus on short-term capacity arrangements. But what about the long-term planning?

Financial Department: An Elephant in the Room

When I talk to developers, I often hear: Short cycles are enough, releases should be tiny, or no need to plan far ahead. When I then talk to product managers, they agree completely. But, meanwhile, they still ask for a delivery date. Or arrange for quarter or annual planning to scope work for the months ahead.

There is no contradiction.

Development, indeed, is best in short cycles, whereas business results will be evaluated in quarters or years. And delivery dates are important. This is just how a stakeholder mindset works, and thus the financial budget cycles follow.

Realities of Long-Term Estimation: “Let’s Do It, but Pretend like We are Not Doing It”

Because of the mainstream idea that long-term planning is not important or even “harmful,” but also because it’s still needed, many people prefer to do it in a stealth mode. Here are some tactics that I’ve seen:

• Never share any roadmaps but keep all plans and commitments in one’s head

• Create estimates but never share any assumptions that stand behind them

• Schedule a big “scrum” event that would arrange plans for the next three months

• Communicate delivery dates to clients or stakeholders based on a “gut feeling”

This is all so that everyone can say that the bullet was dodged and no rigid Waterfall was used. We can successfully claim we’re truly Agile!

Guesstimates at Work

When the process is weak, the results are weak, too. Many companies struggle with not delivering projects on time, employees burning out trying to chase unrealistic goals, and stakeholders expressing concerns over missed commitments [1]. It’s a natural result of a non-disciplined, “imitated” process of long-term roadmap planning.

The problem is: Many “gut feeling” estimates are biased [2]. They express an opinion of a person who can be too optimistic. If they forget the assumptions that stand behind the estimate, it becomes useless. If it’s in someone’s head, no one else can reach it, like in the case when the person got sick or left the company. Unrecorded or poorly evaluated estimates quickly become unusable or confusing.

What Should We Do to Make Estimates Real?

Fixing the process is very simple. We should introduce a structured and disciplined process of long-term planning on a top of Agile development cycles [3]. The process should be Agile too, call it Agile Roadmapping, with risk management, proper recording, continuous reviews, alignment and adjustments along the execution journey. We should log all work that we do for all initiatives and features, so that we can use it as a historical reference for future planning. We should account for expertise, nature of work (AI or not), and record all uncertainty and assumptions for our estimates, along with the scope that those estimates represent. Record this information to the place that everyone can reach and edit.

Summary

We can’t make software development absolutely chaos free and deterministic. But we can make it much more comfortable and predictable. Pretending that long-term planning doesn’t exist will not help the situation but make it less transparent and practical. On the contrary, what benefits most is a discipline in our selection of planning methods, estimation techniques, and practices of recording and logging data. This is the best path to transform organizations for better outcomes.

All-In-One Solution for Honest Roadmaps

If you need a complete all-in-one solution to build reliable roadmaps check out the method developed by our team of experts: https://honestroadmaps.com.

Let’s Take a Look at Our Truck

Here we need to unload a track with various items. The truck contains 100 boxes of furniture. This is from our house, and so they are all very valuable and expensive for us and should be carried with care. We also have workers that will be unloading the truck. All of them are very capable and carry about the same number of items per hour. Simple job indeed!

Let’s Look at Our Software Development Project

Software projects are a different fruit. In fact, they are more similar to the job of building a house. In construction, you need to create an architectural sketch, then put in the foundation, build walls, establish water pipelines, install electricity, put on a roof, and lastly paint everything. Each process may require teams with a unique expertise. Likewise, in software development, projects require backend and frontend development, building services and databases, perform quality assurance, and DevOps duties. Every team has unique capabilities and skills to perform the job.

Our crews are ready, let’s start!

Round 1: Baseline

Let’s start with two people for unloading a truck and seven people for developing software. Two people on a truck can usually do the job two times faster, spending 0.5 hours together instead of a full 1 hour. Whereas having seven people on the software project requires them to extend the timeline seven times because they only can do their job after the previous dependent job has been finished. For example, a QA engineer can’t start their job if the backend and the frontend engineers haven’t finished development. They will spend 7 days in total. Bummer!

Round 2: Double the Personnel

Let’s double the number of people for both crews. We can see that in the truck example, it clearly results in a faster timeline. Let’s look at the software project. The timeline still improves as different teams that have more people can do the job much faster. Nice!

Round 3: Double the Personnel One More Time

Let’s double the number of people one more time. For a truck, having eight people on a job clearly results in a much faster timeline. Let’s look at the software development project. Here we can see that although we have doubled the number of people, the timeline may not change so dramatically.

The reason for this is for a simple software project, two people can be more than enough to do software architecture, while for QA engineering or business analysis, it can be more beneficial to have more people. So, the new people will be mostly idle for most of the jobs. At the same time, adding them to the work will require communication and coordination to explain the context for their activities and provide updates about the work that the other team members have already completed. Thus, the effort and cost increase even higher! So does that mean that adding more people to software development projects beyond a certain threshold wouldn’t be practical?

What Statistics and Research Says

For software development, there is research on how far you can optimize a software project without major risks to delivery. There is even a term for it called “The Impossible Zone.” The term essentially defines the compression limit of 25%. Beyond the limit, the project will almost certainly fail. That means if you have a project for 100 estimated days, you can only compress to 75 days maximum by adding people or paralleling jobs.

Other research shows that adding more people to a single software development team can affect performance. When adding team members beyond pizza size of 5, the communication between them will require more effort while the calendar days output will not improve or may even degrade. In that situation of adding more people to a single team of five, you may be even paying more for poorer outcomes.

Summary

All of that shows one thing. It can be tempting to simply hire more people because it is a visible action taken to resolve the issue, but this does not alleviate the systemic problems in planning that are at the root of numerous delivery failures we see nowadays in software projects. When planning for software development, one needs to learn project specifics and team expertise, understand how jobs can be paralleled and optimized and where they cannot. Don’t try to engage multiple women to deliver one baby!

All-In-One Solution for Honest Roadmaps

If you need a complete all-in-one solution to build reliable roadmaps check out the method developed by our team of experts: https://honestroadmaps.com.