Why do digital projects drag on?

Why do software projects tend to drag on? Is the software sector business plagued with a chronic crisis of confidence? 

Building software is an expedition, especially in large product development projects: the jungle you need to hack a path through may be more dense than initially thought, meaning you’ll arrive at the destination later than expected.

In addition, the functionality of the systems may undergo major changes throughout the project – something that wouldn’t happen, for example, when constructing a bridge or a house.

“Humans are optimistic creatures by nature, which means that offers often tend to involve some highly optimistic scheduling, even though schedules cannot be assessed reliably, especially in large projects," says Rakettitiede’s CEO Juha Huttunen.

A software project is often a process of gradual realisation, which informs the contributors about the things that need to be developed and their direction as the project unfolds. The needs may change along the way, which simultaneously also changes the milestones and schedules. 

Quality before quantity 

Some of the problems can be solved by Agile development methods, but they never go away completely. However, the number of iteration rounds can be reduced by employing particularly competent developers.

It should be borne in mind that neither the size of the team nor the apparent speed of the developer guarantees productivity. At worst, they’ll only produce copious amounts of run-of-the-mill code and a lot of technical debt. 

If you don’t know how to hold your horses, you’re in for a rough ride. In software projects, time pressure often leads to hasty temporary fixes, although rewriting some part of the code might offer a smarter solution. 

The work becomes quicker once the codebase is neat and tidy. On the flipside, bad code slows down the development process and increases security risks, drives away one developer after another and, thus, raises costs.

Under-sell and over-deliver

Open communication and trust are great tools for getting through the rough patches. Trust is never a given, but it’s what makes or breaks the project. 

“I believe that the buyer and others involved in building the software must be supported by at least one technical expert whose opinion can be trusted 100 percent. This person must possess the ability to be honest – they need to have the courage to see things as they are and to say if something’s not technically possible,” Juha says.

And this is exactly what we want to offer our clients: honesty. 

“We don’t sell anything whose high-quality delivery we can’t guarantee, and we never one-up an offer if that means making unrealistic promises we can’t keep. This is something we inform the client about as well. We consider this a question of values. Holding to this principle inevitably leads to losing some projects and leaving money on the table. Nevertheless, we’ll continue to tell our clients if there’s something we can’t do. Luckily, that’s not very often. ‘Under-sell and over-deliver’ is a good rule, even if it sometimes means losing a deal,” Juha adds.

Read more:

Client story: An app designed to restore your confidence in taxis