Advice was once given to school examinees by a jovial
examiner: "Do not on any account attempt to write on both sides of
the paper at once."
The equivalent in blindingly obvious advice for central government
departments on how to prepare for and manage IT projects would be:
ask the end-users at an early stage how they think they are likely
to access and use a system, and act on what they say; do not go
live with a system unless you are convinced it is fit for purpose;
do not ignore the warnings of key stakeholders before going live;
and do not set too little time to do too much. Finally, if all else
fails, have a well-rehearsed fall-back plan in case the system does
not meet expectations.
Obvious though these maxims are, every one of them was ignored,
circumvented, flouted or simply not fully appreciated when the
Criminal Records Bureau, run by the Passport and Records Agency,
prepared for and implemented systems that caused serious
operational problems when they went live.
The idea of the systems was to widen access to criminal records, so
that employers could check a job applicant's background if the work
entailed contact with children or vulnerable adults. But a report
by public spending watchdog the National Audit Office found that
the backlog of applications for checks was so great at one point
that some staff were employed before it was known whether they had
a criminal history, and as a result had to be closely supervised.
The audit office report - impressive in the thoroughness of its
research and the detail of its findings - found that the design of
the system seemed to be based more on assumption than listening to
key stakeholders and end-users. There was an assumption, for
example, that between 70% and 85% of customers would apply for
checks to be made by phone rather than paper. So the systems
installed by supplier Capita - and the business processes - were
designed around the use of a call centre. In fact, 80% of
applications were in paper form - but data entry screens had not
been designed for the keying in from paper forms. There was
consultation with end-users, but initially it was inadequate and
fed false assumptions.
It also emerged that three months before the system was due to go
live, there was no solid plan for a model office and pilot. The
go-live date was rescheduled and, before go-live, a Gateway review
of the project was undertaken by the Office of Government Commerce.
It raised a series of concerns but, incredibly, the reviewers
accepted that there was "now no turning back" and recognised that
on balance the operational launch would go ahead "given the
confusion and bad publicity that would result from delay".Ê
We do not believe that a fear of bad publicity should have been a
material factor in the decision of Gateway reviewers to endorse the
department's decision to go live.
The publication of the NAO report is timely, as it reinforces
recommendations made by Computer Weekly this week to the Work and
Pensions subcommittee, which is investigating IT best practice.
In an effort to improve the rate of success of central government
IT projects, we have recommended two things in particular: that
best practice is enshrined in legislation, as has already happened
in the US with the Clinger-Cohen Act. We also want independent
Gateway reviews on the progress of major projects to be published.
In the case of the Criminal Records Bureau, publication of the
Gateway report would have alerted all interested parties to the
potential for serious operational difficulties and perhaps altered
the outcome.
We expect both of these ideas to meet considerable opposition in
officialdom. Heads of central departments can be expected to resist
instinctively any outside pressure to make them more accountable.
But there is clearly a pressing need both for radical steps to
tighten controls over departments and for assessors and reviewers
of projects to make decisions that will stand the test of scrutiny
by Parliament and the media - or the NAO will be writing similar
reports ad infinitum.