That's why a blog series about how we look at the profession at Blis Digital. As an ode to all developers who are busy making valuable things for their users every day. To the people who come up with solutions 'from scratch' to complicated problems that no one in the world has ever tackled before and for which there are therefore no examples available.
This is part 2: why some software projects exceed their budget by a factor of 10 - and how we prevent that.
Software is not a home
People sometimes compare software projects to building a house. They then explain that if a frame has to go into an opening that is too small, it will be expensive to modify. The conclusion: first think carefully, elaborate and specify. I am annoyed by such simplistic comparisons. Because software development involves much more than just technical implementation. The impact of mistakes or wrong choices is exponentially greater than during a renovation.
In 18 years of Blis, we have already seen many stalled software projects where the realization costs were more than 10 times higher. Imagine that building your new home costs 4 million instead of the 400,000 euros you borrowed from the bank. Then there is more to it than just a few poorly measured frames... Indeed, the causes of a failed software project often lie deeper than just technical challenges.
5 reasons why projects are derailed
1. Unclear goals
The failure of a software project usually starts early: with unclear goals. If the intended value of the product is not sharp enough, the foundation is wrong from the start. Teams then work on features without a clear purpose, leading to continuous changes in direction during construction.
2. Team composition
The composition and management of the team also play a crucial role. We often see specialists who don't know each other, don't work together, and team compositions that change regularly during the project. As a result, start-up costs and miscommunication are piling up. This is reinforced if the product owner understands the business but has no experience with complex software projects, or vice versa.
3. Integration issues
Another classic pitfall is underestimating integrations. Teams make too easy assumptions about links to external systems. In practice, these are almost always more complex and time-consuming than expected. This becomes even more painful when difficult tasks are pushed forward, when they should have been tackled first to identify and tackle risks early.
4. Hour invoice
Then there is the phenomenon of steering by hours instead of output. Teams are judged by attendance rather than results. This masks inefficiencies and delays adjustments. It also leads to the dangerous “point-of-no-return” thinking (also known as the sunk cost fallacy): “There is already so much money in it, we have to keep going”. Whereas, at all times, you should take a critical look at the business case for the remaining work.
5. Old technology
Finally, we see projects that take so long that the chosen technology is obsolete before launch. Extra time goes into getting rid of these technical debt during development - a costly and frustrating exercise.
The Blis approach
At Blis Digital, we take a different approach. We start with a careful match between project team and project. This goes beyond just matching technical skills. We look at the balance between senior and junior developers, relevant work experience, and how used the team is to working together. We also include knowledge of the sector and business context.
Before we start major development processes, we first create a proof of concept. This provides insight into technical feasibility, performance and integration options. It also helps to test user acceptance of core functionality early.
Risk management is part of our entire process. We identify risks early, take concrete measures, and monitor continuously. Open communication about risks and impact prevents surprises later in the process. In this blog, you can read more about how we organize the development of digital products efficiently and how we exclude risks.
A strong product owner is, as I said in my previous article, crucial for success. That's why we invest in training and coaching for new product owners. They receive support in making choices, stakeholder management and prioritizing activities.
And yet, there are always unforeseen circumstances and things you didn't know you didn't know (the infamous unknown unknowns). If they overtake you, it's important to be creative enough to think outside the box and adjust the plan. Such surprises often include opportunities. You can grab it if you organize your team and project in such a way that you can make quick adjustments.
Moreover, in our development, we do not focus on hours but on results. That means: clear definitions of 'done', measurable acceptance criteria and regular demos of working software. We do not report on time spent, but on business value delivered. Continuous evaluation keeps us on our toes in this regard. We analyse team effectiveness and development speed, adjust processes where necessary, and share learnings within the team. This creates a culture of improvement and knowledge sharing.
Craftsmanship as a foundation
Software development is a complex profession. It requires a combination of technical expertise, project management and business insight. Thanks to our years of experience, we know where the pitfalls lie and how to avoid them.
In the next part of this series, I'll dive deeper into how we build our teams and keep their expertise up to date. After all, it's the people who make the difference between a successful project and a costly failure.
.jpg)
