Your pilot works. Why can it still not go live?

Your team has shown that the new system can complete a transaction. The test is over, but nobody can give you a clear route into daily use. Staff still copy data into the systems they rely on. Another round of testing won't settle who runs the service afterwards.

The test leaves work outside its scope

A pilot is a limited test that answers a specific question. It can prove that a transaction works while leaving the surrounding work untouched. That is useful if everyone knows what the result means.

The gap appears when a successful test is treated as a complete service. Booking a payment or updating another record may still depend on manual work. The test team can carry those tasks once. Daily use needs them to belong to a funded service.

The other gap is ownership after the project ends. Someone must deal with errors and keep the service running. If that responsibility remains with the test team, the handover has yet to be designed.

A pilot can also end well without becoming a live service. If it answered the agreed question, closing it may be the right decision. What leaves you stuck is a test with no clear decision at the end.

Design the next transaction around your real teams

RWA Link starts with the work needed after the demonstration. We design and implement the system your institution will own and run. We have no platform of our own to extend into your project. We can compare keeping the pilot with replacing parts that don't fit daily use.

First, we describe what the next transaction must involve. The people who will run the service need to be part of that discussion. We include the work before and after the step already shown in the test.

Next, we trace where information passes to your existing systems. We identify which record each team acts on and who checks that records agree. A completed transfer is only useful when the people downstream can use it.

Then we agree who owns normal work and who handles exceptions. A failed payment needs an owner as much as a completed one. The design must show what staff do when a connection fails or an instruction is wrong.

Finally, we compare the routes into operation and their costs. Scoping is the paid work that sets out what to build and how. It produces a design plan and a costed comparison before the build is agreed. Implementation follows the chosen route, with handover to your team included in the agreed scope.

Your budget buys a route into use

You can see which parts of the pilot are worth keeping. You can also see what is missing and who must take it on. That gives your colleagues a basis for deciding whether to proceed or stop.

The comparison includes the work needed around the software. Connections to your books and the staff effort to run them belong in the decision. Otherwise, a low build price can leave those costs with another team.

Your next request for funding can describe the service you intend to operate. It can name the work required to get there. You no longer have to rely on the success of the demonstration to explain the whole project.

Turn the test result into a decision

Read how we work to see the route from workshop to agreed build. When you are ready, use that page to arrange the free first workshop. Bring the step your pilot proved and the work your staff still do by hand.