.svg)
There are few questions as difficult as: what should this IT project cost?
Not because we have too little experience. Not even because we're building something that has never been done before. The real challenge lies in something else: unclear requirements and the fundamental tension between selling a service as if it were a product.
After working on all sides of the table—agencies, clients, and tech companies—I dare say that most projects follow the same pattern even before a single line of code has been written or one setting has been changed.
The service-product paradox
In short: you are not buying a ready-made product. You buy time.
Time in which standard components are integrated, configured and adapted to your situation. By definition, this is a service, even if we call it a “solution”.
And as requirements change—due to new insights, technical limitations, platform updates, or shifting priorities—the time required also changes.
That's where the paradox comes in.
Management wants a fixed price and schedule in advance. To be able to provide that, the product owner needs a fully detailed scope. This requires stakeholders not only to name their wishes, but also to think through all their consequences. If that doesn't happen, assumptions arise. Standard solutions are chosen. And as soon as it is delivered, reality appears to be more unruly: expectations do not match and adjustments are necessary.
In almost every project, we see the same thing happening:
- Complexity is underestimated
- Effort and costs are minimized by all parties
- No one has a complete picture of the end situation at the start
In addition, software development is still a profession, not a commodity.
Good solutions require experience, judgement and refinement. New tools accelerate work sharing, but don't eliminate uncertainty.
So we choose MVPs
The usual response is: we build a minimal viable product and rely on standard functionality as much as possible. That definitely has value. But we've also seen how high-potential projects are thus reduced to solutions that work but make hardly any impact.
For standard parts—shopping carts, product overviews, CRM flows—this often works great. But once value lies in distinction, integration, or operational efficiency, it becomes risky.
If customer service does not have an up-to-date order overview, or product information does not show why a product is unique, then no go live will pay for itself.
The 80/20 approach
If we can estimate, why do projects still run out in time and budget?
Because we approach everything in the same way. What works in practice is a split.
The 80%: standardizing and budgeting
The routine components—checkout flows, common integrations, basic automation—are easy to predict. These can and should rely on proven solutions. Here, speed is important and fixed estimates are realistic.
The 20%: collaborate and iterate
The other 20% is where real value comes into being. These are the company-specific components: how processes really run, where there is friction, where a distinction is made.
This knowledge is often implicit and context-dependent. She does not fully allow herself to be caught in an RFP or two intake interviews. She asks for mutual understanding.
That means actively involving stakeholders, exposing processes fairly, and making space for exploration—through workshops, prototypes, and iterations. Especially in the parts with the most impact, this approach prevents expensive misunderstandings later.
And no, that doesn't have to take months. Well-facilitated sessions, service blueprints and rapid prototypes can be set up in days, provided that the right people sit down together and focus on the real problems.
What this means in practice
Projects remain manageable if a few principles are taken seriously.
Preparation is crucial. Gather real requirements, ensure access to relevant documentation, and reserve time with stakeholders. This determines the quality of everything that follows.
Time is a factor. Haste seldom produces quality. A complete e-commerce transformation—from idea to go-live—can quickly take a year. Not because there is constant construction, but because good cooperation requires continuity.
And above all, be pragmatic. When something goes wrong—and it always happens—it's not about sticking to the original plan, but about getting the best result within the available time and budget. Flexibility prevails over rigidity.
The core
IT projects don't fail because people are ignorant. They fail when we pretend to buy a product when we're actually collaborating.
Successful projects are partnerships, with shared responsibility for impact, choices and budget. Uncertainty won't disappear, but you can deal with it honestly and consciously: standardize where possible, collaborate where it counts and stay agile.
If we approach projects like this, the demand for
“what should this cost?” unto
“how do we deliver real value together?”
And that's what makes the difference.
