There is a conversation that happens far too often in technology projects.

The client has a problem. The vendor has a solution.

And somewhere between the initial brief and the final invoice, the focus quietly shifts from solving the problem… to managing the contract.

I have spent twenty years on the other side of that conversation. And I made a deliberate decision to approach technology delivery differently.

The Scope Trap

Most technology projects are governed by scope documents. Pages of:

  • requirements
  • exclusions
  • change request procedures
  • carefully worded clauses about what is and isn't included

On paper, this looks like good project management. In practice, it often creates a damaging dynamic:

  • the vendor optimises to protect the scope
  • the client spends energy negotiating it

The product eventually gets delivered. But an important question often remains unanswered: does it actually work for the people using it every day?

Technically complete and genuinely usable are not always the same thing.

A Different Starting Point

When I take on a project — whether it is an LMS implementation, an AI-powered platform, or a bespoke digital product — I try to start from a different question.

Not:

What did we agree to build?

But:

What does this organisation genuinely need in order for this to work?

Those two questions sound similar. They are not. The first produces a deliverable. The second produces a solution.

The difference usually appears in the details. It is:

  • the notification workflow nobody specified but everyone needed
  • the reporting view that makes audits straightforward rather than painful
  • the onboarding experience that drives adoption instead of resistance
  • the small usability decisions that determine whether a platform becomes valuable or frustrating

None of these things are particularly glamorous. All of them matter enormously.

What Clients Actually Pay For

Here is something I believe very strongly:

Clients should feel they received more value than they expected.

Not because projects should be underpriced. But because the real measure of success in technology is not:

  • the number of features delivered
  • the number of tickets closed
  • or whether every line item matched the original specification

The real measure is whether the organisation is genuinely better off afterwards. Whether:

  • the platform gets adopted
  • the workflow improves
  • the experience feels intuitive
  • the original problem is actually solved

When clients feel they received more than they paid for, it is usually because somebody cared enough to think beyond the brief. To notice the thing that was never explicitly requested… but was clearly needed. That is not charity. That is what good technology delivery looks like.

The Long Game

There is also a practical reality to this approach. Clients who feel genuinely supported tend to:

  • come back
  • recommend you
  • become long-term partners rather than short-term transactions

Some of the professional relationships I value most today have lasted more than a decade. Not because of contracts. Because of trust. Trust that:

  • I will say what needs to be said
  • build what genuinely needs to exist
  • and continue standing behind the work after delivery

In a market where many vendors optimise for margin and minimise for responsibility, that approach tends to stand out more than any marketing message ever could.

A Simple Principle

If I had to reduce twenty years of technology delivery into a single principle, it would probably be this:

Build it so it works. Not so it's done.

The distinction sounds subtle. For organisations relying on these systems every day — for learning, compliance, operations, and growth — it makes all the difference.