Anyone who manages or is responsible for IT projects is familiar with the questions: How long will it take? How much will it cost? But there is often a big gap between estimates and reality. In this article, we reveal why this is the case, what clients and implementation teams often overlook, and how both sides can achieve better results together.
The classic at the project kick-off
A department requests a new software function. The IT department or an external service provider is supposed to implement it. Even before the “what exactly” has been clarified, the question arises: “How long will it take?” Or: “How much will it cost?”
This question is perfectly legitimate—because without planning, there can be no budgets, no roadmaps, no quotes. But it regularly leads to frustration on both sides:
- for the client, because implementation takes longer or costs more than expected.
- for the implementation team, because a rough estimate suddenly becomes a firm promise.
What is going wrong here? And how can this classic scenario be better managed?
Client vs. implementer: two perspectives, one misunderstanding
Two roles come together in IT projects: the clients (e.g., departments, product management, internal project management, or external customers) want to know how much effort an idea will require. The implementers (e.g., development teams or service providers) are expected to provide a reliable answer—ideally quickly, clearly, and with certainty.
The problem: effort cannot be negotiated. Only the service or the price for it. And many estimates are based on vague requirements or unclear expectations.
A common source of frustration: if this figure is then used as a fixed value in the project, even though the scope has changed, this creates uncertainty, pressure, and ultimately, recriminations.
There is often a big gap between estimates and reality. (Source: Adobe Stock – Pormezz)
Why effort estimates are so often wrong
Even with the best intentions and a wealth of experience, cost estimates are often inaccurate—not because teams are unprofessional, but because IT projects involve a multitude of uncertainties. The most common causes at a glance:
- Requirements are rarely stable: The more precisely a requirement is formulated, the more accurately it can be estimated—but the more likely it is to change later on. The result: The estimate quickly becomes obsolete.
- People systematically estimate incorrectly: An analysis of over 160 real development tickets shows that small tasks are regularly underestimated, while large ones are overestimated. The reason: uncertainties, blockers, or queries rarely occur and are difficult to assess. The larger the task, the more uncertainties are factored in.
- Estimates are requested too early: Often, an initial figure is required before it is even clear what is actually being built. If communication is not clear at this stage, there is a risk that rough estimates will be taken as firm commitments.
- There is no learning effect: Many companies document estimates, but do not evaluate them systematically. Without feedback, the quality of estimates remains low.
What helps: Better practice in estimation and communication
To analyze the accuracy of estimates, we examined and evaluated over 160 real development tickets from customer projects in 2024 – with exciting results: As our chart impressively shows, small tasks are systematically underestimated, while large ones are often overestimated. And this is independent of the developers’ level of experience. The reason? Uncertainties tend to be assessed proportionally – but queries and clarifications are not necessarily dealt with more quickly for small issues than for larger ones.
These practical findings show that even though cost estimates can never be perfect, the framework conditions can be significantly improved with a clear approach, appropriate methods, and open communication between clients and implementation teams. Five proven approaches from practice:
- Estimate relatively rather than absolutely: Compare new requirements with familiar tasks from the past. This results in a more realistic classification—e.g., using story points or categories.
- Use Fibonacci rather than fantasy numbers: Use proven scales such as 1–2–3–5–8–13 instead of exact values such as “11 person days.” This allows uncertainties to be represented more naturally.
- Have the second-best person estimate: Don’t let the top expert estimate – let someone with experience but a realistic assessment do it. This keeps the focus on typical hurdles.
- Accept estimation deviations—but document them: No project runs exactly as planned. It is important to learn from this: How big was the deviation? Why? What could have been foreseen?
- Communication instead of confrontation: If estimates do not match expectations, it is often due to a misunderstanding—not incompetence. Clarification is more effective than pressure. Discuss scope, risks, and alternatives early on.
Estimating is not a guessing game—it is a process that can be learned
Cost estimates will never be 100% accurate. But with the right approach, honest communication, and systematic evaluation, risks can be minimized and project goals better achieved.
flowciety supports IT managers, product owners, and project managers in creating a better foundation for planning and estimation—with technical depth, methodological experience, and an eye for the big picture.
Get our Whitepaper on IT Architecture (in German) now—for better planning, stable systems, and sustainable project management.
Source header image: Adobe Stock – Nuttapong punna
We are IT partners
Our motto: Establish IT in everyday business as a solution, not as a source of problems.