By Andy McCue, 12 February 2004 11:15
NEWS
The £400m PFI Criminal Records Bureau (CRB) for vetting staff who work with children and vulnerable adults was so "appallingly planned" that it went live despite concerns the system was not ready, resulting in a backlog of delays in vital background checks and a system that is still not fully functional, according to a report by the National Audit Office.
The CRB - a private finance project between the UK Passport and Records Agency and Capita - went live nine months late in March 2002 but government procurement watchdog the Office of Government Commerce only gave it the green light because the pressure to launch meant it was at the point of "no turning back".
The project will not now break even until a year later than planned, in 2005/2006, leaving the taxpayer to foot a deficit of £68.2m.
The NAO report, Criminal Records Bureau: Delivering Safer Recruitment?, reveals a litany of critical errors and failures during the initial stages of planning. These include an unrealistic timetable for implementation, and problems dealing with vetting checks after the CRB went live due to the unforeseen demand for paper applications. The system and processes had been designed based on projections that 80 per cent would come via the telephone and internet.
Capita's bid was the lowest but even at this stage concerns were raised by one of the three bidders about the realism of the timetable, the report said.
The government and Capita then only realised in the summer, when it was originally due to launch, that users wanted to apply mainly using paper applications.
"Data entry screens had not, however, been designed for keying in of data from paper forms and the Optical Character Recognition Systems designed for telephone applications had insufficient capacity to deal with the volume of paper applications."
Launch was delayed until March 2002 but concerns were still raised by the OGC, which was not in existence during the early stages of the CRB, that the system was not ready to go live. But, the report said, it accepted there was too much pressure on the government for the CRB to be delayed any longer.
"The Bureau was under pressure to go live, not least because the police had stopped accepting applications directly, as planned, in preparation for the start of the Bureau's service," the report said.
Although the backlog has now been cleared and the government says Capita is meeting service level agreements, the report said the CRB is still not fully functional.
"The Bureau's problems have impacted adversely on the intended level of service for customers which is not yet as extensive as the Government had planned."
One area where vulnerable people are being put at risk is the lack of checks on existing health care and social care workers. This only began - over six months late - in October 2003, while the CRB cannot currently access data held by Customs & Excise and the British Transport Police, as well as overseas crime databases.
The report reveals Capita has paid or is paying £3.69m in fines for not meeting service levels while the government has paid an additional £8.4m for changes in contract requirements.
Edward Leigh MP, chairman of the Public Accounts Committee, said in a statement that there is a "grim familiarity" about another high profile government IT failure that was "appallingly planned andÂ… badly implemented".
"Wishful thinking seemed to lie behind the key assumption, unsupported by any solid market research, that up to 85 per cent of applications for access to criminal records would be made by telephone or online," he said. "The Bureau and its partner, Capita, entirely failed to translate policy objectives into workable operational plans. When the going got rough they both started blaming each other. And, while the service has now improved, it is not the one we were promised."
He said gaps in record checks should be "remedied without delay" and called for research into how effective the CRB is in helping protect children and other vulnerable people from potential abusers or whether it is in fact "having any effect at all".
Comments
There are 5 comments. Join the discussion
1. David Johnston
The paperwork involved in a PFI requires a specialist familiarity to process. This PFI expertise is not possessed by the technical software solutions companies, who really can deliver solutions much more quickly and use much more advanced technology. Organisations with PFI expertise are usually large and employ the less skilled IT expertise, who develop using the older technologies - the solutions delivered have therefore shorter lives. I question the wisdom of PFI initiatives and the Return On Investment of PFI.
2. anonymous
As an ex-Sales Manager, previously working for a major IT systems vendor to the public sector, I can tell you categorically, it’s not about ability to do the job, it’s about winning the procurement and often at any cost. The cost of bidding for PFI projects is very high and there are no prizes for coming second. Vendors will do anything to win, from thoroughly over stretching their capabilities to telling downright lies. One organisation I know actually threatened one of their client’s with "future difficulties" to ensure a good reference visit. They went on to win a substantial government contract. In this environment, employing buyers and clever management consultants is demonstrably not enough. What the Government needs in every procurement team is the advice from a poacher turned gamekeeper, they will know how to get to the truth about vendors capabilities and consequently dramatically cut taxpayer's risk.
3. anonymous
How can you optically recognise telephone applications? - they are auditory surely not optical
4. Adam Carden
One of the paragraphs in this article states:
"Data entry screens had not, however, been designed for keying in of data from paper forms and the Optical Character Recognition Systems designed for telephone applications had insufficient capacity to deal with the volume of paper applications."
-> What complete rubbish, obviously the OCR system is designed to scan the forms (paper forms) and OCR surely has to relevance to telephone applications unless staff are handwriting the data, or are entering it into a word processor then printing it? What is this madness.
You can see where this leads however
1) Staff no training, trying to mix old with new. Should be entering all data directly into system (forms for telephone apps should be pretty much the same as paper apps, the information you want it the same right?)
2) Lowest bidder -> Capita -> Indian Programming House (most likely vb6)
3) Based on the article this looks like a data entry and storage/cross referencing apps. Probably backed by a standard database/data warehouse.
Can someone tell me how an application like this could possibly cost 462 million pounds or over 700 million dollars?
Why where there only 4 bidders? Companies that are experts in ripping goverments off?
Why not choose from the thousands of certified software houses in the UK? most of which could do the project, to spec in less time and for a great deal less money.
Civil servants (not all of you) should not be managing the bidding, and specification of these systems. Why not put a couple of proper experts on the team eh?
5. Andrew Clark
For many a long year, access to government contracts has been restricted to large companies. The spurious rationale behind this policy is that small companies are too risky to take on for even the most modest of projects because they are deemed likely to go out of business, leaving the government high and dry.
(So much for software escrow?)
On the contrary, a government contract for a small company is an assured lifeline.
It ensures the long-term future of the company.
That, together with the lower overheads of operating a small company, ought to make specialist providers a viable alternative to the major companies for more government projects.
The notion of the "large project", beyond the scope of any but the major corporations seems to be based on the projected number of users and supporting infrastructure rather than the complexity of the application.
Most so-called "large projects" are not particularly complex in terms of functionality. They just have a lot of users.
So, why not separate the application development from the rollout?
With current technology, an application can easily be developed on a small scale, and rolled out on a massive scale.
The question for any designer is ?is this a single-user or a multi-user system??. If it isn?t a single-user system it doesn?t matter a damn if it?s two users or two million.
The critical difference is that where there is more than one user, transaction control becomes important. Otherwise, the functionality of the application remains exactly the same for two or two million users, only the supporting infrastructure changes.[
Finally, any set of "methodologies" that cannot cope with the fact that, in real life, the world will move on during all phases of a project are just plain unrealistic.
There is no Holy Grail in system design and development.
There are no hard and fast rules, only principles that need to be recognised as best practice and even these need to be ?modified? where appropriate for any given project. It is not just down to old versus new technologies. What matters more is the use of appropriate tools for the job in hand.