How to complete an IT project that cannot fail

The IT system which supports the UK'sFaster Paymentssystem was created, in 18 months, by a team of "obsessional planners" facing a non-negotiable deadline and no room for compromise.

APACS and UK banks decided to create a service which could clear payments in a day at the end of 2006. It went live as planned in May 2008.

Faster Payments was the first new UK payment system to be introduced in 20 years. It offers shorter times to clear payments than the three days needed for the Bacs payment system. Within six months of its launch, Faster Payments had processed about 60 million transactions worth £24.9bn.

Any system that handles money and payments relies totally on the trust of users if it is to be accepted, says Nick Masterson-Jones, director of information technology at Vocalink.

"The key challenges in this programme were driving to a hard end date while ensuring that there were no compromises, at all, on quality," he says.

Vocalink used standard Prince 2 methodology for the project management. But Masterson-Jones says this project differed from other IT projects in the way the emphasis was on quality, time and cost. "A payments system needs to be engineered to a very high level of quality because any issues could destroy confidence," he says.

The system is designed with no single point of failure so the service continues when there are problems. A lot of effort went into thinking through the consequences of a failure of every component.

The technology system, which runs Faster Payments, is in two parts: a front office that links to banks to capture all payment details, and a back office that records, stores and settles payments.

 The front office uses an application from eFunds which Vocalink has customised. This sits on HP non-stop servers. There are two sets of servers which can both handle the complete load alone if required. These two stacks also communicate so they both know the status of the other.

Information sent to the front office from the banks' systems is captured and sent to the back office. The back office system then calculates how much the banks owe each other. It runs three times a day and sends the information to the Bank of England.

Keeping to schedule

At its peak, 150 people worked on the project, made up of a mixture of permanent and contract staff. The firm brought some of its offshore developers onshore for the project.

"With a fixed programme schedule, we needed the maximum level of interaction between designers and coders," says Masterson-Jones.

A team of engineers from Perot Systems in India worked alongside UK staff. "It worked well and cut down the length of time it took to resolve issues," says Masterson-Jones.

The system is built to last using modular design so upgrades can be done without disrupting the service. "We avoid the 'Big-Bang' approach to replacement by keeping the system constantly up to date."

When you are used to running IT projects where mistakes are not an option, being methodical and, in the words of Masterson-Jones, even obsessive are essential qualities.