For a first release, count the moving parts

In every project, I suggest how to build the MVP to minimise time to money for the customer, and to deploy the service as fast as possible and as cheaply as possible.

The more components you have, the more risks you have, and the more effort you have to put into that. The less friction between components, the better.

Find the moving parts before you estimate

We usually do an exact estimate after preliminary work. We interview your employees, we interview you, to understand the capabilities of the organisations we need to integrate with. It's like consultancy work. We do it from the start, and after that you receive an artefact you can use with us or without us. It gives you the details for a sharper, concrete estimate. Without such discovery work, the estimate will be very, very preliminary.

Usually I suggest that such a discovery is no longer than two months, because if you make it longer, it will not happen. We will minimise budgets and timing there, and we will understand all the gaps. Maybe not all the gaps, but we will understand the risks involved. After that, it will be easier to prioritise: on business benefits, but also on the bottlenecks and risks we found.

When a provider is not ready

There could be several scenarios. From our experience, sometimes we switch to another functionality, because we have already done phase zero, the discovery, and we know what to do. We have to keep the team running because it's effective, and after that you will not spend time getting back to this speed.

The second scenario: we build stubs, an emulation of what we expect from the company. For example, you have chosen a provider, but haven't signed yet. They didn't give us anything, like a sandbox or something. But they can give us a specification, and we will build an emulation of that system according to the specification, and we will test with that. Of course, that's a bit of overwork from our side: additional effort, but not double, because you have to implement the specification in any case. We just build an additional answering part, which emulates fake answers.

You will see how it looks and how it works in the service, and when they are ready, we will open the integration. Of course, there will be some adjustments after that. That's real life. But we will not lose time there.

Building the target architecture in parts

The architecture is complex, but it has to be agreed together with the client, and for the long term. It has to be looked at right away and chosen as a direction. It will be complex in the end, but we don't have to build it as a big bang from day one.

For example, with my team, in one bank we moved off the internet bank that sat in the core banking system, an internet bank for small businesses. It came with the core system as a package. It was clunky and badly built, from the century before last. Everyone cried over its design and usability, and kept using it. Big corporate clients keep putting up with that, because the people who make the decisions don't have that problem. The pain never comes out. For SMEs it doesn't work like that. So the decision there was to move it in parts.

For a while, part of the internet bank already worked on the new rails, through an orchestrator and a normal interface, and part of it went by redirect to the old one. We thought clients would complain loudly: what is this rubbish? On the contrary, they praised it a lot and asked when the new features would finally appear on the new interface. Little by little they migrated, until the old interface was switched off completely. It means we work and improve right now, instead of paralysing the bank's work for a year.

Another way, or another provider

Usually I suggest minimising the risks, for us and for the customer. When that is not possible and the customer doesn't want to go with my approach, usually we find something suitable. But we have also had experience of starting with time and materials from scratch, and of working at a fixed price for the whole project, or with every stage of the project at a fixed price. It depends on the maturity and the readiness of the customer.

I tell a customer to find another solution or another provider only in cases where we are not 100% sure that we will deliver the best result, because of a lack of competence, or a lack of something else. We don't take on projects that we can't deliver at the right level of quality. And if we take one on, we do it properly.

Before you sign off the plan

List every system that release one connects to and your team does not control. For each one, ask:

• is it ready, or do you only have a specification;
• can it be emulated from that specification and tested against;
• can it wait for release two.

Then count what is left.