Back to blog

Project Management

How we ensure quality in digital projects from day one to delivery

Ole-Martin Thorvaldsen
Ole-Martin Thorvaldsen·27 August 2026·7 min read
How we ensure quality in digital projects from day one to delivery

Ole-Martin has a habit some clients find a bit annoying at first: he always asks «why» one more time right when someone thinks they're done answering. It's not to be difficult. It's because quality in digital projects is rarely about doing one big thing right. It's about doing twenty small things right, consistently, across the whole life of the project.

He likes telling the story of a project early in his career where the team delivered exactly what the spec said. On time, within budget. And the client still wasn't happy, because the spec had captured the wrong problem. That's when he understood quality begins long before anyone writes code.

Day zero: understanding the problem before the solution

The most common quality mistake happens before a project even has a name. A team that jumps straight to a solution without challenging the problem statement often builds something technically solid that solves the wrong thing. Quality starts with asking «what do we actually believe will happen once this is done», and being honest if the answer is vague.

Along the way: small deviations allowed to pile up

No project fails because of one big disaster. It fails because many small, acceptable deviations are allowed to pile up: a test skipped because time was short, a comment in a code review that was never addressed, an assumption that was never confirmed with the client. Each one is small. Together they become the delivery that doesn't hold up.

Ole-Martin's fix isn't perfectionism. It's discipline in making deviations visible right away, so they can be a conscious choice rather than something discovered too late.

Delivery: when the real work starts

Many teams celebrate when something goes live. That's understandable, but a bit early. The real test of quality is what happens in the first weeks after launch: does the solution actually handle traffic, error messages, and real users, not just the scenarios that were tested beforehand.

Quality isn't a department that tests things at the end. It's an attitude that has to be present from the very first meeting.

Three questions Ole-Martin asks on every project

What happens if this goes wrong? Who notices first if quality slips here? And: if we had to defend this decision to the client six months from now, would we feel confident?

Get in touch with Ole-Martin if you want to know what quality work looks like from day one to launch on your next project.