The Way We Work on Integration Projects

What we do first

1. Understand the process as performed, from the person performing it
2. Establish the current cost, with real numbers
3. Look at thirty real examples, including the awkward ones
4. Test access to the destination system before quoting anything

Only then do we estimate. An estimate before those four is a guess.

Four things we insist on

• An evaluation set, because otherwise nobody can say whether it works
• A review path for uncertain output, because it will be uncertain sometimes
• Your ownership of code, credentials and data, without exception
• A named owner in your business for quality after launch

These are not preferences. A project without them produces something that demonstrates well and degrades quietly, and we would rather not build that.

What we will not do

1. Promise an accuracy figure before seeing your data
2. Build something whose volume cannot repay it
3. Hold your credentials or code as leverage
4. Automate a decision that should carry a person's name

How we communicate

A weekly note: what moved, what did not, what we need from you and whether the date has changed. Short, honest and on the same day each week.

If something is going wrong, you hear it that week rather than at the deadline. That is the whole of our project management philosophy.

What you are left with

• A system that measurably does what was agreed
• The code, in your repository
• The credentials, in your accounts
• A runbook, an evaluation harness and a trained owner
• The ability to take it elsewhere if you want to

That last point matters. We would rather be kept because the work is good than because leaving is difficult.

Frequently asked questions