Home/Method

How we work

The hard part is not build

It is building the right thing, delivering it in working order, and making sure it still serves you in three years. Here is how we go about it — and what we commit to holding.

The starting point

What makes an IT project fail

We have taken over enough abandoned projects to recognise the same causes. None of them is technical.

01

The need was never written down

Everyone carries their own version in their head. The disagreements surface at acceptance testing, once the budget is spent.

02

Users find out at the end

Consulted once at kick-off, never seen again. On switchover day, they reopen their old spreadsheets.

03

The project produces nothing until the end

Eighteen months with no usable deliverable. At the first budget tremor, there is nothing to salvage.

04

The supplier holds the keys

No documentation, no administrator access, no code. Changing partner means starting over.

Our method does not try to be elegant: it is built point by point against those four causes. That is why it spends so much time at the start, and why it turns down projects with no intermediate deliverable.

The sequence

Five phases, five outputs

Every phase ends with a deliverable you can take away and use, even if the project stops there. It is the only serious guarantee against a project that bogs down.

  1. Diagnosis 2 to 4 weeks

    We look at what exists before proposing anything: interviews with users, technical inventory, timing of the tasks that cost most. We put figures on the problems before the solutions.

    • Diagnostic report
    • Costed list of pain points
  2. Scoping 2 to 3 weeks

    The need is written, settled and signed. Scope, out of scope, acceptance criteria, budget and schedule. This document is the reference for the whole project: anything not in it becomes a change order, not an argument.

    • Scoping document
    • Mock-ups
    • Firm quotation
  3. Build in 2-week increments

    We deliver a testable increment every two weeks, on an environment you can click through. You watch the project advance and you correct course early, while it still costs little.

    • Testable deliveries
    • Increment report
  4. Switchover 1 to 3 weeks

    Data migration, training at the workstation, a period of parallel running, then switchover with a rollback available. We stay present for the first weeks, not merely reachable.

    • Data migration
    • Training
    • Rollback procedure
  5. Operations annual contract

    Monitoring, fixes, enhancements and a monthly report. And above all: continuous skills transfer to your teams, so your dependence shrinks instead of growing.

    • Service agreement
    • Monthly report
    • Up-to-date documentation
One peculiarity

We spend heavily at the start

A third of the budget goes before the first line of code. That is not a consulting habit: it is arithmetic.

Why

A scoping error caught at acceptance testing costs between ten and a hundred times what it would have cost at scoping. The arithmetic is old and has never been disproved. Yet the custom is still to start fast to reassure, and rebuild afterwards.

We prefer the uncomfortable moment in week three when it turns out that two departments were expecting different things. It is uncomfortable, but it is still free.

What that guarantees you

  • A firm quotation after scoping, not a range that drifts
  • A written scope, so change orders are discussed rather than endured
  • Acceptance testing whose criteria were known before we started
  • The option to stop after scoping, keeping all the work produced
What is written in the contract

Six commitments, not six promises

Each one appears in our contracts. None is a statement of intent.

The code is yours

Sources, database and documentation handed over at every delivery. No reversibility to negotiate on the day you leave.

Deadlines are measured

Our turnaround commitments are published every month, including the months we miss them, with the reason.

No vendor commission

We take nothing from the software we recommend. Our selection grid is shared, weightings included.

Skills transfer

Every operations contract includes hours of training for your teams. The aim: that you need us less often.

A firm quotation after scoping

The price quoted at the end of scoping does not move, unless you ask in writing for a change of scope.

Your data stays yours

No client data is ever reused, neither to train a model nor for a demonstration. Export is available at any time.

How we bill

Three models, chosen according to risk

The billing model is not a commercial preference: it depends on what is known at the moment of committing.

Amounts are set after the diagnosis. No public price list: a figure quoted without seeing the context commits no one.
Model When we propose it What you know in advance Who carries the risk
Fixed priceFirm price per deliverable The scope is written and stable: after a scoping phase, or for an audit with defined boundaries. The total amount and the delivery date, from signature onwards. We do.Any overrun in effort is ours to absorb.
Capped time and materialsDaily rate, agreed cap The need is shifting, or exploration is part of the work: an AI prototype, taking over a poorly documented system. The daily rate, the monthly cap, and a stop point every fortnight. Shared.The cap protects you, the review keeps us in check.
SubscriptionMonthly or annual Operations, managed services, and SANKOFA licences. The recurring amount, the response commitments, the notice period. We do.Covered incidents are never re-billed.

What we refuse: a fixed price on an unscoped need. It always ends the same way — either we cut quality to hold the price, or we pile up change orders. Either way, you lose.

Reciprocity

What we expect from you

A successful project is never the supplier's doing alone. Here is what we need from your side — better said before signing.

Four conditions

  • An identified decision-maker, able to settle a question in under a week. Without one, every open question becomes a delay.
  • Users who are available a few hours a month. They are the ones who know how the work actually gets done.
  • Access to your real data, however imperfect. A clean test set hides exactly the problems that need finding.
  • The right to say no to you when a request degrades the whole — and to explain why.

The projects we turn down

  • Those where the decision is taken elsewhere, with no one to settle questions
  • Those whose deadline is already unworkable when the request arrives
  • Those meant to justify a decision already made rather than inform it
First step

It all starts with an hour of conversation

Free, without obligation, and enough to know whether we are the right partner for you — or to tell you we are not.