We carry the delivery risk so you don't have to
Dates, scope, cost. One agreement covers all three, and the project-internal risk sits with us.
01 / The promise
Complete responsibility, one agreement
In a turn-key project, we take on complete responsibility for the adherence to delivery dates, the scope, and the cost of the entire subject of delivery to the customer.
Our customers thus are not affected by any risks inside the project, and the result of the project is covered by one agreement.
02 / The engagement
Assessment, BPR, and a progressive plan
Based on what we have learned across engagements, preceding the project with an Assessment and BPR phase, then drawing up a progressive plan as a stream of processes and capabilities, is the approach that wins.
- 01
Assessment
Before the scope is signed, the Assessment phase puts numbers on the current-state systems, the integration surface, and the constraints the delivery has to respect. It is what makes a turn-key project safe to commit to.
- 02
BPR
Business Process Re-engineering reframes the workflows the new system is meant to support, so the build targets the process the business actually wants, not the one the existing tools happen to enforce.
- 03
Progressive plan
The plan stages the work as a stream of processes and capabilities rather than a single waterfall, so business value lands in increments and each stage is informed by what the previous one taught us.
03 / The method
Waterfall, meshed with Agile principles
How do we successfully deliver the project? It is a Waterfall methodology meshed with Agile principles in order to maximise the involvement with the business. The result is an “Agile Like” approach that runs iterations between the phases of the project, instead of treating each phase as a one-way handoff.
04 / Why this works
Prototypes validate before you build
Here are the main reasons we adopt this approach.
- 01
Requirements consolidation
A prototype turns each requirement into an artifact the team can point at, so the scope conversation moves from “what should this do?” to “is this the thing?”
- 02
Hands-on user testing
Users open the prototype and try to do their work with it, instead of evaluating a document. The behaviour they show is the requirement, more honestly than a written specification can capture it.
- 03
Requirements validation
Sign-off lands against software that already exists in some form, not against an assumption that the built version will look like the spec the room agreed on.
- 04
Errors and omissions surface early
Gaps in coverage and edge cases the specification missed appear during the prototype phase, before the build has committed code to them.
- 05
Complex interaction patterns
For non-trivial UI and interaction concepts, a prototype is the only honest way to compare options. A user interface is its own argument, and documents do not make it.
Scoping a project where risk has to land somewhere?
Tell us the shape of the delivery: the scope, the timeline, the constraints. We come back with an approach for the Assessment and BPR phases that sets the rest of the project up to be predictable.
