Project Objective
 Background
 Key Achievements
 Methodology
 Assessment and Lessons Learnt
 Conclusions

Project Objective
The objective of this Project was to process the 2001 Census Forms and deliver clean, consistent and complete data for input into the in-house edit, imputation and output systems.

Background
Traditionally, Census forms have always been processed in-house, but following the 1997 Census Test it was decided that better value for money could be obtained from contracting-out the main scanning and capture services for the 2001 Census.

An Open Options Procurement Project was undertaken in 1998 by the Census Offices for England and Wales (ONS), Scotland (GROS) and Northern Ireland (NISRA), jointly known as 'the Authority', with the aim of acquiring processing services for the 1999 Rehearsal and the 2001 Census. In December 1998 the Processing Contract was awarded to Lockheed Martin (LM). The latest technology was used to process 27 million Census forms, with forms scanned at high speed, and responses coded electronically, using automated and computer assisted methods.

The key benefits to outsourcing the processing operation were to:

• streamline the capture and coding process with a view to reducing staff costs and number of processes and accommodation required;
• improve quality in terms of accuracy and consistency of the captured and coded data;
• improve the speed of processing data over 1991 so that outputs could be delivered to a reliable timetable; and
• enable a trade-off between reduced costs and coding all responses - only 10 per cent of responses to Industry, Occupation and Workplace Address questions had been coded in previous censuses.

During the procurement of processing services, three potential suppliers were short-listed. Their Best and Final Offers were considered against a Public Sector Comparator (PSC), which is an assessment of the cost to the Authority to process the census in-house, taking into account contingency and the value of the risk being transferred. The contract was awarded to LM who submitted the proposal which best met the Census Offices' requirements in terms of solution and price.

The Processing Contract was drawn up to achieve value for money and to transfer to LM major risks associated with the design, development and implementation of processing services for the 2001 Census. The Contract was based on an 'outputs' approach with the requirements being stated in terms of 'what' was required and not 'how' things should be done, i.e. descriptive rather than prescriptive. However, it is worth noting that the solution which LM successfully tendered (their 'how') was captured in the contract as well, so that they could not change the solution accepted by the Authority without the Authority's consent.

The overall aim of the Processing Project was to provide an efficient and effective processing operation that delivered a set of clean, consistent and complete data for input to the Edit and Imputation systems. The data had to meet the stated quality standards and be available according to a timetable negotiated with the Contractor, taking into account overall cost and quality considerations.

The scope of the project was to manage all the development and operational services provided by LM covering the Census Offices' processing requirements, from the receipt of forms from the field operation, through scanning, capture and coding, to the delivery of data and images to the Census Offices. Additionally, the Project would manage the printing of all forms that were to be completed by the public and scanned by LM, and agree and implement the interfaces between the Contractor and the Authority.

The Project set up the procedures and systems required to satisfy contractual responsibilities, and ensured the services provided were in accordance with the contracted delivery schedule, quality standards and payment profile.

A Rehearsal of the systems designed by LM and the operations planned by their sub-contractor ICL (now Fujitsu), were conducted at ONS (Titchfield) in 1999.

Live processing activities for the 2001 Census took place at Widnes, Cheshire, at a processing site selected by LM and ICL, and approved by the Authority.

The staff, numbering over 1000, were recruited locally and trained by ICL. LM maintained a presence on the site throughout as they were responsible for the processing systems. ONS, together with colleagues from the other 2 Census Offices, also set up and maintained a team on site to resolve queries, and 'oversee' the management of the operation.

The 2001 Census processing system, designed by LM, used Optical Mark Recognition (OMR) and Optical Character Recognition (OCR) to 'lift' the data from the census forms. The OCR software employed recognised both upper and lower case letters and was tuned to the UK style of handwriting. If characters were not recognised automatically, with a pre-determined degree of confidence, the image was presented to an operator for interpretation and keying.

In addition to the automatic recognition of the data, LM developed an automatic coding system, used for responses that required translation from a textual response into a numerical format.

Those responses not coded automatically by the system were presented to manual coders who used computer-assisted technology to apply the appropriate codes.

The system was very sophisticated, enabling LM to modify and tune the application, thereby continually improving the throughput and accuracy.

The assessments and lessons learnt section of this report reflect those things that went well and which should be carried forward, as well as recommendations for change.

Key Achievements

There are three key indicators by which to measure the success of the Processing project - Quality, Cost and Timeliness.

All Quality Standards were met or exceeded. These standards formed part of the contract and were measured continuously throughout processing. The overall results for each of these standards are:

More detail on Quality Standards will be included in the Quality Report due for publication later in 2003.

The final total costs compared favourably with the original estimates.

Within the 11 month period between July 2001 and May 2002, 24.1 million forms were processed for England and Wales and the cost to ONS for the services provided by LM was £54 million.

External consultancy for the Processing Project, covering advice and assistance on Procurement, Contract Management, Legal and Technical matters cost a little under £2 million. A further £1 million was expended on internal administration. Other in-house processing activities, such as the set up and management of the Authority presence at the processing site, which lay outside the contract but which the Authority undertook in order to ensure a successful interface with the contractor, cost a further £2 million. Together, these costs for the management of the contract and the processing interface represent 9.2 per cent of the overall costs.

The overall cost to the Authority of £59.5 million compares very favourably with the ONS element of the Public Sector Comparator of £61 million.

There were some timetabling issues which ultimately led to a slippage of 5 weeks in the final data delivery milestone, but this is still an excellent achievement in the context of a 4 year programme.

Overall, this compares extremely favourably with equivalent Government Information Technology projects. It provides a successful model on which future similar initiatives can be based.

The Authority's relationship with the Contractor was managed in a very professional manner and was the cornerstone of the Project's success.

Methodology
A major difference in processing the 2001 Census, compared with previous censuses, was the contracting-out of the main capture and coding services. The project's success was therefore heavily reliant on the timely delivery of quality services from LM and procedures were established to manage both the contract and the project to achieve a successful outcome, within budget.

The Capture and Coding systems were automated which enabled 100 per cent coding of Occupation and Industry responses compared to 10 per cent in 1991.

Initially, the Authority's role was to provide the Contractor with the essential information needed for them to develop a service to meet the requirements. This then developed into one of overseeing the Contractor's management of the live operation.

LM sub-contracted the scannable forms printing to Polestar and operational elements of the contract, including warehousing activities, to Fujitsu (formerly ICL).

Contract Scope and Interfaces
The negotiated services route or 'open options' procurement had the advantage of inviting potential Service Providers to present additional and innovative options which would be negotiable and relevant to the delivery of Census requirements. The premise on which the processing contract was let was to transfer the risk inherent in processing a census to a service provider, at a fixed price plus a negotiated cost for changes. The actual scope of the contract covered:

• printing scannable forms;
• the capture, coding and delivery of clean data;
• warehousing activities;
• the production of microfilm from the Census Forms for long-term archiving;
• interfaces with the Authority on matters such as quality and the resolution of queries generated during processing; and
• the destruction of Census Forms.

Potentially, the contract could also have covered:

• the systems and services implemented by the Authority that interfaced directly with those from LM, for example, the Query Resolution system, built to transfer difficult queries to the Authority for resolution and return; and
• the systems and services implemented by the Authority that did not interface directly with those from LM such as the Edit and Imputation processes that took place 'downstream'.

However, these aspects were not finally included after undertaking a cost benefit analysis.

Requirements
The high level requirements, which were based on versions of the 1997 Test Specifications, became the Statement of Requirements which formed the basis of the original invitation to tender and served us well over the course of the contract. During initial negotiations with the three potential suppliers they were discussed at length and were further honed by this process. This fitted well with the recommended approach of an outputs based procurement, with the requirements being stated in terms of 'what' was required and not 'how' things should be done. However, without constraining the bidders' creativity prior to contract award, the winning bidder's solution was captured in the contract, so that the Authority retained control over subsequent development of the chosen system and services.

Timetable
A timetable was put in place to provide clear reference points, for both the Contractor and the Authority, to assist with contract management and to monitor interfaces with other census activities.

Management of the Contract
Following award of the Contract, two committees were formed. The Contract Steering Committee (CSC) included representatives from the Contractor's team and was responsible for providing strategic direction to the Project. The Contracts Management Board (CMB) was internal to the Authority and to its advisors, and was responsible for the management and monitoring of all Contracts. Regular, less formal meetings complemented those of the CSC and the CMB. The contract administration team acted as the official conduit between Authority and Contractor.

Testing
A testing plan was set up as part of the contract, where the Contractor and the Authority undertook distinct and specific activities. As the project progressed, there were clear benefits identified in combining these teams but leaving the overall obligation with the Contractor to ensure all systems and services functioned correctly.

Service Levels and Liquidated Damages
The contract required LM to provide the Authority with services of a predetermined quality to ensure the delivery of accurate and timely data. If the predetermined quality standards i.e. Service Levels, were not met, Service Default Points (SDPs), were allocated by the Authority. The accrual of SDPs entitled the Authority to have the contractor take corrective action, if necessary.

Liquidated Damages (LDs), which are payments which compensate against failure to meet contractual milestones, were specified in the contract. Each LD was set at a cost per day for a pre-specified period. If either SDPs or LDs ever reached certain pre-set levels, the Authority would have been entitled, had it so wished, to terminate the contract and have the Contractor transfer it to a third party or bring it back in-house.

Data Quality Management
Quality Managers were appointed by the Contractor and the Authority, and jointly set up a Data Quality Management implementation plan. Service levels were the instrument used to ensure the data and services were delivered to the right quality.

Change Control and Issue Management
A contract of the size and complexity of the Processing Services will inevitably need changes made to it over the course of its life. Formal procedures for managing the changes were set up and were fundamental to ensuring that changes were costed according to the pricing structure in the contract. It was also important throughout the project to distinguish between changes to requirements - which were chargeable by the Contractor - and measures to rectify failures to achieve requirements - which were not chargeable.

Potential and emerging problems were recorded as Issues and were managed jointly by the Authority and the Contractor, through to an acceptable conclusion. Several Issues Databases were set up within the Processing Project to record and manage issues as they arose.

Risk Management
A Risk Consultant was recruited, from an external consultancy firm, to identify and assess risks to the project and to maintain a Risk Register. The Authority managed the identified risks through the CMB and CSC, securing changes to the contract and rectification measures to enforce the contract (as appropriate) from the Contractor.

External and Internal Expertise
As well as Legal Representatives, a pool of external consultants were employed, who had a wide experience of a variety of aspects of lengthy contracts, and practical experience of technical solutions. The Authority trained these consultants to ensure they had a good understanding of ONS/Census business.

An external employment agency was used for recruiting staff to represent the Authority at the Processing Site.

Security and Confidentiality
An Independent Security Review was set up, aimed at providing assurance that both the Authority and the Contractor had adequate existing and planned practices and standards for the security of 2001 Census data and to meet the principles set out in the 2001 Census White Paper.

Assessment and Lessons Learnt
Contract scope and Interfaces
Where there are complex interface issues between separate contracts, there can be problems. For example, at the interface with the logistics contract, the responsibility for employing a driver to move trailers from the secure holding area into the warehouse was unclear. To avoid this it may be beneficial to award all related and interdependent contracts to one supplier/prime contractor. This needs, however, to be balanced with a risk that in awarding the total contract to one supplier they may not be specialists or best placed in every area within the contract. To overcome this consequence, additional experts can be employed to advise. For example, concerns about the print aspects for 2001 Census Forms were mitigated by buying-in the services of an expert in forms design and printing for scanners/Optical Character Recognition (OCR), to support the Authority. Overall, the decision to place the onus for printing scannable forms with the Contractor responsible for processing turned out to be sound and avoided a potentially difficult interface between two contracts.

But wherever the cut-off is placed, the Contractor needs to understand subsequent processes to ensure as seamless an interface as possible.

On balance, the Authority has concluded that a single contract could well have improved overall effectiveness. There is scope for combining processing, transportation, all printing, storage and perhaps payroll and call centre activities into one contract, dependant on a detailed assessment at the time.

Arguably, the inclusion of Downstream Processing, that is, those activities which follow the production of the data, such as the Edit, Imputation and One Number Census (ONC) processes, would have avoided an interface but overriding factors mitigated against this:

• the checking mechanisms naturally in place within the Downstream activities, such as the Loading processes, which included checks for valid codes and overall consistency of the data, provided a clear-cut mechanism for ensuring the quality of the data provided by the contractor; and
• the Contractor carried out a feasibility study for undertaking the Downstream processes and their estimate of cost was prohibitive.

The chosen cut-off did, however, provide a workable solution.

Interfaces between the Authority and the Contractor and internally between Projects need to be jointly defined and managed to ensure that the needs of all are met.

Formal meetings at working level should be set up for the various Census Projects including Data Collection, Geography, Census Coverage Survey (CCS) and Processing. Meetings and consultation should take place during development and throughout the lifespan of each project and should be arranged and pro-actively managed by the Programme Support Office (PSO). It is critical that this is maintained and stepped-up in the year before Census, when requirements are being defined and issues within Projects need to be considered in their widest context.

There were no issues with printed forms for scanning and recognition processes, due in part to the involvement of Processing team members and input from a Print Consultant who understood processing requirements. In any future census, the Print contract should again be closely allied to the Processing contract and the Processing team should again be involved.

Consideration should be given to re-modelling the tasks and activities within the Census Projects. The Data Collection Logistics and Processing activities are so closely allied that they could be considered as part of the same contract. Other models will also need to be considered if changes such as on-line form filling are introduced.

Both Processing and Data Collection representatives should be present throughout the delivery and check-in of Census Forms. Both areas of expertise are essential to a successful check-in.

It should be recognised early on that a contract of this magnitude will inevitably have changes made to it over the course of its life. Any future contract should include a ring-fenced contingency amount on which the project would have first call. Allowance should also be made for a significant level of external contract support.

The contract was awarded as a fixed price contract placing the onus on the Contractor to cost accurately at bid time. Formal changes to the requirements were charged in accordance with the contract. All other unexpected costs were borne by the contractor.

Requirements
Draft detailed requirements were supplied during negotiations, but these were not refined until after Award of Contract. As a consequence:

• time was wasted as we agreed the format of the specification and the lines and methods of quality assuring the specification documents;
• work that had already been done on the specification had to be re-jigged to fit with this format;
• the amount of development work came as a surprise to LM;
• Authority and LM resources were not marshalled and ready to take on the work; and
• the Rehearsal was delayed.

Requirements must be reviewed and, if possible, simplified. For 2001, the detailed coding and processing requirements were not totally clear and complete at bid time which meant that LM experienced some difficulties in pricing their proposal. Ideally, a detailed requirement specification should be in place prior to award of contract and examples of the detailed processing rules should be developed well in advance of award. If timing does not allow this, a contract mechanism needs to be built in to cope with an evolving requirement.

Many benefits could be obtained by bringing in the Contractor at an earlier stage in the Census Programme, for example, prior to any large scale test. This would allow greater time for an iterative specification and development approach which would reduce the risk of requirements not being implemented correctly and would almost remove any ambiguity over what is a clarification and what is a change. However, the likelihood of a Contractor bidding for a fixed price contract on this basis is very small.

The contractors proposal, which covered how they intended to implement the requirements, was captured in the contract. This was important because while their freedom to be innovative in their bid was not constrained by the Authority, they were not at liberty to deliver a different solution from the one that the Authority chose as the best solution. Had LM been contractually free to do so, the Authority would have had no redress if they had delivered a solution totally at odds with the one chosen, and control over the development of the system and services would have been lost.

The Contract must allow for clarifications to be raised by Contractor and Authority staff as a means of formally communicating unclear requirements, and a similar method adopted, as used in 2001, for updating and sending revised documents to the Contractor.

A contract awarded jointly by 3 countries requires a lead Authority approach, such as in 2001, whereby ONS led all the elements, with representatives from each Country as key members of the Contractor/Authority combined planning teams. All three Offices, but NISRA and GROS in particular, benefited from economies of scale. In such a contract for common services it is neither reasonable nor practical for each Country to manage their own contract. There is however, a point at which the degree of difference in the individual requirements of the 3 countries becomes so large as to make it impractical for a common approach to be sustained. The view is that we came very close to that point in this contract.

Whilst accepting that the Census is a devolved activity every effort should be made to keep questions and Geography data the same for ONS, GROS and NISRA with the objective of keeping all coding/processing rules consistent.

The Contractual and Operational implications of the differing requirements of the three countries should be carefully considered. The principal of 'no unnecessary differences' should be adopted again. For each deviation from a common standard there is a direct cost, as quoted by the supplier, and an indirect cost in terms of management, development, testing and implementation that must be justified. Although, in theory, a common contract with common requirements was let, in practice there were differences in the requirements of the three countries. If practical, rules or drivers should be devised which result in penalties for the introduction of diversity in direct relation to the additional content and complexity introduced. The management of the differences in 2001 was a challenge, but was successfully met.

Census forms and data must be continually tracked through all systems and this process is called Forms Control. The requirements must be specified and included in the bid. Forms Control must be seen as a process that spans all activities from the collection or posting of a form all the way through until the data is constructed for output. Clearly, for capture and coding, forms control is fundamental to a complete and accurate capture process and must be in place at the point of entry when a form is introduced to the processing system (warehouse).

Consideration should be given to being prescriptive in the specification of requirements in areas of high impact, such as quality and forms control. The Authority should specify how they wish the Contractor to meet these requirements to ensure sound principles, developed over time by the Authority, can be built into the systems and services by the Contractor.

It is essential that we convey to the Contractor the fundamental importance of our delivery requirement. They must be aware of the requirement to deliver complete geographical areas and fully understand the implications of this for their processing systems.

Timetable
The lack of time between Award of Contract and the Rehearsal, and the consequent delays, had a serious impact on the time available for the development and testing of systems for 2001 and ultimately led to the following recommendations:

The 2001 Census Processing Contract timetable was too compressed. Future procurements must consider awarding the contract earlier. More time is needed between Award of Contract and Rehearsal.

It should also be recognised that governmental processes, such as the legislative programme, can be slow and may impact severely on the timetable. Awarding the contract earlier would enable the Contractor to gain a better understanding of our emerging requirements and to build a solution by stages, rather than a 'big bang' as was the case for the 1999 Rehearsal.

Timetabling requires better co-ordination between Census Projects to meet the dependencies and mitigate the risks to all the linked activities i.e. Data Collection; Processing; Downstream Activities; Geography; Outputs.

The Contractor experienced problems meeting the agreed delivery schedule. The delay in completing Rehearsal processing had an adverse effect on the timing of the development of all 2001 systems and procedures. Rehearsal delays impacted on 2001 development, which in turn meant that systems were not fully tested. Lack of testing led to unforeseen problems in processing the forms. As a result, delivery delays required major rectification steps by LM and adversely affected ONS financial management.

To recover from delays, the Contractor had to deliver data at 3 times the expected volume. The delivery of data at this unexpected volume had a serious effect on the team responsible for receiving and checking the data and images and on other Census projects, e.g. Downstream Processing and the One Number Census team. Good communication of delays to both senior management and to other projects is essential. Contingency arrangements for unexpected workflow or deliveries of data must be in place.

Management of the Contract
The dedicated, within project, contract team was essential for the smooth running of the contract. This team drew on the census wide PSO for certain activities, notably management of Requests for Change.

Tailor-made Contract Management training for all relevant staff, regardless of grade, is a key tool in ensuring the proper procedures are observed and communications are managed in a professional manner. Contract Management training for 2001 was made available only to middle management and above.

Throughout the specification, development and implementation phases of the project, the Contractor should be required to report against an agreed mid-level plan and track and report on issues. Authority involvement in the production of a Detailed Implementation Plan, used by the Contractor for day to day monitoring, was considered to be a useful approach for keeping the Authority aware of progress.

Measuring progress against key elements of the service is essential. To do this, detailed production metrics must be available throughout operations, to use as a measure of the progress being made. The recruitment of an independent auditor to analyse plans and challenge progress also provides an important lever in discussions with the Contractor, if the project begins to fail to deliver against timetable or service levels.

It is important to involve Departmental Finance representatives, from the publication of the advertisement to the conclusion of the contract. More particularly they should be present at Contracts Management Board (CMB) meetings in order to ensure their understanding of the issues if bids for extra money are necessary.

Meaningful predetermined quality standards i.e. Service Levels, should be set and closely monitored, to allow the Authority the opportunity to re-evaluate their relevance if the Contractor's failure to meet them threatens. The purpose of Service Level Agreements (SLAs) and the method of calculating Service Default Points (SDPs), if the Contractor failed to meet the SLAs, needs to be reviewed. If too many SDPs had accrued, the contract could have been terminated. A pragmatic approach is needed in determining how to use SDPs to put pressure on the Contractor to take corrective action in the event that performance falls below SLAs.

Realistically, if we had terminated the contract during the operational phase (2001/2002), there was no alternative for processing the census on schedule. Considerable thought must be given to how to practically implement an alternative which would still result in the Census being delivered on time, in the event of termination of a contract for non-compliance.

Clear, specific and formal channels of communication between the Authority and the Contractor are essential.

Staff at all levels and in both organisations should meet their counterparts and follow the procedures for communication.

As happened in 2001, the Authority needs to take a pragmatic and sensible approach to working through issues with the Contractor, whilst being mindful of contractual commitments - this enables a successful working partnership to develop on both parts, based on mutual trust and understanding of key drivers.

Whilst explaining or clarifying a point, within the Contract, Authority representatives might unwittingly introduce costly contract change. To guard against this, a method needs to be in place to log all communications to minimise misunderstandings which could, in turn, increase the likelihood of risk transference back to the Authority.

Future contracts which link payments to delivery must balance reward to the Contractor with protection for the Authority. A possible solution to this would be to split milestone payments into 'Data Delivery' and 'Data Acceptance'.

Testing
The 2001 Census Capture and Coding Service was far more integrated and automated than the equivalent 1991 version, which relied heavily on manual input. However, although the 2001 Census approach brought many efficiencies, it was considerably more complicated to specify, develop and test than in the past. The following recommendations have been made:

The contract must cater for managing the need to test changes between Rehearsal and 2001 (timetable, approach, system impact, costs).

When testing that the Contractor's system meets the Authority's requirements, the Authority and Contractor need a clear understanding of the objectives of each test and to share a common understanding of what constitutes an acceptable result - acceptance criteria should be agreed up front and met before moving on to the next phase.

A large scale 'live' test should be run using the final version of the form and using a larger test base e.g. 1 million forms. It should be the final test before 'live' operations. Prior to that there should be as many dry runs as possible using the forms collected from a Field Rehearsal.

The final testing phase should include all Operational Services as well as Operational Systems/Interface with Field Operations and Interfaces between Authority and Contractor and Contractor and Sub-contractor. The contract should make it clear that the Authority expects to see evidence of full operational capability well in advance of 'live' operations. The number of test forms should be sufficient to simulate full operational processing volumes.

This is even more important as systems become more automated and complex and span more field and processing activities and may need to consider combining data captured from a variety of sources.

Service Levels and Liquidated Damages
Basing the contract on Service Levels was an extremely effective way of obtaining data and services of the correct standard. Setting Service Levels is difficult and as much care as possible must be taken at Award of Contract to identify key Service Levels and to avoid those which, if not met, would have minimal impact, as this serves only to divert the Contractor's attention.

Quality issues can be successfully resolved provided that the relationship between the Authority and its Contractor is sufficiently robust to enable this to happen. Service levels can be jointly developed early in the life of the contract, within flexible and costed parameters.

There were no Service Levels against output for small areas, such as groups of several Postcodes, which allowed problems in the data to legitimately slip through. These had to be corrected by the Authority in the later stages of processing. For the future, service levels against such small areas must be in place.

Liquidated Damages (LDs) should be used to incentivise, not only to start on time but also to complete on time. LDs were accrued as debts and could lead to termination of the contract.

Data Quality Management
If the Contractor is responsible for identifying systematic error, they must show that they can analyse data in real time.

The Authority should receive a large block of coded data within one week of the start of the operation. This would allow a thorough check of the coded data and enable glaring errors and omissions to be identified and corrected before the bulk of the data is processed.

Ownership of and the process for updating indexes during operational running should be clearly established up front and tested prior to live running.

The Contractor should have a dedicated Quality Manager who will not be diverted on to other work.

Quality checks should all be in one place and managed centrally. This could be either the responsibility of the Authority after the data has been received or that of the Contractor, at the processing site, before delivery. To achieve this, data experts with specification, operational and coding skills in addition to statistical/research officer skills are needed.

100 per cent accuracy is only achievable at immense cost and this need should be considered very carefully. The Authority needs to balance what is achievable against the risk and cost.

Change Control and Issue Management
The Contract should include more detailed provision for defining the costs of change. In particular it should be clearer about categorising changes occurring between Rehearsal and the Census and establishing which categories were catered for within the original price and which would be charged for.

The purpose of the Rehearsal needs to be clear to all parties. The Authority required full and accurate processing so that the approach could be confirmed. LM increasingly regarded it as a trial of their own systems - a learning experience. These ideas were in conflict.

As happened in 2001, all potential changes need to be prioritised and actively managed to ensure that they are essential and to ensure that only agreed changes are implemented.

During the 4-year lifetime of the project, 107 changes were made, 52 sponsored by the Authority and 55 by the Contractor. Optional services such as the destruction of the census forms and the archiving of the images were included in the contract and pre-costed from the outset.

The Authority was very rigorous in enforcing the distinction between a change to requirements - for which the Contractor is entitled to charge additionally, and a rectification measure to meet existing requirements - for which the Contractor is not entitled to charge additionally. This approach was vital in ensuring that the project costs were kept within planned limits.

A fully electronic Change Control system should be developed to streamline the procedures and consideration should be given to enabling access by the Contractor.

Although the Processing Project Issue databases were effective for recording issues, they were used for administration purposes, rather than as an effective mechanism for managing issues and taking decisions. A centrally managed Census-wide Issues Database should be set up as soon as the first Project begins work. The database should be pro-actively managed by someone with a business understanding across all Projects, so that appropriate circulation of the respective issue can take place and resolution secured.

Risk Management
The major input into assessing the risks to the Project was from an external Risk Consultant. The transference of skills in this area of expertise would have made Risk Management more cost effective.

Risk should be managed centrally by the Programme Support Office, with the close involvement of a representative from the business area who fully understands the impact of each risk on their own Project.

Training in Risk Management should be provided to all potential risk owners, either as a specific course or as part of an overall project Management course.

The recording and management of risks should include the potential solution, should a risk become reality.

External and Internal Expertise
An understanding of census issues/requirements takes time, so key external expertise needs to be enlisted early and retained until the end of the contract, as happened for the 2001 Census. Similarly, continuity of the members of the processing team ensured that invaluable census expertise was always available.

Within the overall framework of a service contract the Authority should, if possible, devise a mechanism of utilising expertise in areas where Authority knowledge far outweighs that of the Contractor, without transferring risk back to the Authority.

The use of a Recruitment Agency to recruit staff for the Authority team at the Processing Site and provide additional resources if necessary, worked well. This approach should be used next time.

If, in a future census there is a remote processing site with an Authority presence, the Authority Manager would benefit from having joined the Project before the Rehearsal so as to experience Census first hand.

All Senior Managers within the project team should have formal Project and Contract Management training.

Authority personnel with working knowledge of each of the component systems are essential. There needs to be sufficient numbers of staff to provide contingency against people leaving and also to spread the load.

Security and Confidentiality
Specify staff security clearance requirements well before recruitment starts. Such processes should be included in the project plans as a milestone date.

Where a government requirement exists, such as for risk analysis for systems processing protectively marked data, this should be made a contractual requirement from the outset.

Procedures relating to back up and recovery should be tightened up for any future contracts of this kind. Appropriate procedures need to be in place and the Contractor must demonstrate that they will be implemented correctly.

Conclusions
There is no doubt that the Processing Project has been a resounding success, due to two key features: the carefully drawn up contract with its in-built safeguards; and the unstinting commitment and capability of staff working within the Project, both Contractor and Authority.

The selection of the preferred Contractor has also proven to be a sound choice, given their continued commitment to meet their contractual obligations. Where alternative procedures have been recommended this merely reflects the lessons learned during the lifetime of the project which took an innovative approach to a traditional process.

The external expertise brought in to assist in managing the Processing Contract has added undoubted value to the Project. Also, the importance of sound legal and tactical procurement advice throughout the Contract cannot be overstated. It is generally acknowledged that those who have been working on the Project, many of whom had never had the opportunity to work in a commercial environment before, have benefited from the experience of working alongside contractors with a range of expertise.

Independent analysis has confirmed that the accuracy of the data has met or exceeded the service levels laid out in the contract.

Continuity of the processing team members provided one of the most important benefits to the Project. The expertise available for training new staff and providing business assistance to external experts was invaluable.

top

This page last revised: 26 February 2003