In the Case Studies section:
Design-Reality Gap Case Study No.4
A Single Personnel Information System for a Southern African Government
Case Study Author
Anonymous
Organisation
The Office of the Civil Service (OCS) has central responsibility for employment of all public servants. It was the central coordinator for the application, but all individual ministries and departments would also participate in data entry and use.
Application Description
The application was an integrated personnel information system - consisting of a basic data entry/storage component and a management information system component - that would handle details of all public servants.
Application Drivers
Traditionally, personnel records for public servants were held in three places - OCS, the employee's parent ministry, and their operational department. This led to duplications, fragmentation and inconsistencies in records. Data was inaccurate and thus unreliable as a basis for decision-making. Data-gathering was subject to delays or worse when files were lost. The existing system was usable, but computerisation and simultaneous integration/rationalisation of personnel records was seen as a route to eradicating all these problems, by creating a single system that would provide accurate information to all in a timely and cost-efficient manner. All of this coincided with an external political environment that wanted to see more use of IT within the country, particularly within government, and by a positive (arguably unrealistically-positive) view by some senior officials of IT as an agent for change.
Stakeholders
The three main stakeholders were OCS, the government's National IT Unit (NITU: which provided technical advice), and the IT firm which won the supply tender for the personnel information system. All government ministries - especially those ministry staff involved in personnel matters - were also stakeholders as, in a fairly direct sense, were all government employees since their details were to be recorded on the system.
Design-Reality Gap Analysis
Design-reality gap analysis compares the assumptions/requirements within the application design with the reality pertaining just before that design was implemented along seven 'ITPOSMO' dimensions:
- Information : the design did not seek to radically change the type of basic personnel information being used. However, it did assume a very different set of information storage locations and information flows by moving to a single system from the pre-existing multiple-storage system. It also assumed the presence of complete and accurate personnel data. In reality, the existing data was neither 100% complete nor 100% accurate. This created a medium/large design-reality gap on this dimension. Gap score: 7.
- Technology : the design assumed the use of a broad range of new software and hardware, including a series of networked PCs spread across the whole of the government and the use of human resource software. The initial reality was an entirely manual personnel information systems, with some PCs in use for word processing. The project's design assumption of a robust nation-wide telecommunications infrastructure largely matched national realities. This meant a medium/large design-reality gap on this dimension. Gap score: 7.
- Processes : the design incorporated a new set of security procedures, which barred clerical staff (those who did the data entry work) from amending personnel records of managers and senior officials. In the pre-computer reality, clerks were allowed to amend all records except those of senior officials that were explicitly identified as confidential. Related to security, the design assumed the acceptability of electronic signatures, which would allow forms and other formal documentation to be passed between ministries and departments. In reality, electronic signatures were not legally acceptable. The design also assumed a change in location of many processes, even though many of the basics of personnel record-keeping would remain as they were in pre-existing reality (except for their partial automation). Overall, this created a medium/large design-reality gap on this dimensions. Gap score: 7.
- Objectives and values : the design assumed that the objectives of the project (automation, integration and rationalisation of personnel processes) were shared by all stakeholders. In initial reality, some of these objectives were shared by some senior officials, mainly in OCS and NITU. Many senior officials in mainstream ministries, however, did not share those objectives, and their real values (of hoarding information) clashed with the design assumption that sharing personnel data around government was a good thing. Overall, there was a medium/large design-reality gap on this dimension. Gap score: 7.
- Staffing and skills : the design assumed the presence of a broad range of staff competencies. These particularly included a sizeable NITU team large enough to be posted in every ministry and department (so that they could rapidly address user problems and queries). In reality, the team did exist but was nowhere near the dozens required by the design. The design required a broad spread of personnel-related IT skills that were not present before implementation. The design also assumed that those real IT competencies would be raised by a one size fits all five-day training workshop. This took no account of the reality of a very varied base of existing competencies and a very varied set of training needs. Overall, there was a large design-reality gap on this dimension. Gap score: 8.5.
- Management systems and structures : the design assumed changes in the personnel management system of government, with system responsibilities for data entry being devolved to individual ministries/departments. Formal structures were not intended to change, but the design did assume some changes in the balance of power within informal structures. This meant a medium design-reality gap on this dimension. Gap score: 5.
- Other resources : the design requirement was for budgetary expenditure of several million dollars-worth of direct costs, plus further indirect costs due to disruptions through training. The government had, in reality, set aside resources to cover the direct costs. The design did appear to require more time than some ministry staff felt they had to offer. This meant an overall medium/small design-reality gap on this dimension. Gap score: 4.
- Overall : there was an overall large/medium design-reality gap in this case. Total gap score: 45.5.
Design-Reality Gap Changes During Implementation
During implementation, the new technology was introduced. In some ways, this helped narrow the design-reality gap on that dimension. In other ways, though, the gap increased because PCs were typically allocated in individual ministries on the basis of status rather than relation to the information system - they were put in the offices of senior staff rather than in places accessible by operational staff involved with the personnel information system. So most records management staff who were to undertake data input/update had no PCs; while more senior staff who had the PCs had no personnel data role. Overall, only limited progress was made in closing the gap between technology design and technology reality; bringing it down to around 6.
In a similar manner, the five-day training workshops helped deliver some skills to some staff but many staff put onto the workshops lacked the basic IT skills that were a workshop pre-requisite and/or found the training not relevant to the specifics of their personnel work. They gained little or nothing from their training. In all, the design-reality gap could be estimated to fall to about 6, taking the overall gap total to around 42.
Evaluation: Failure or Success?
Introduction of the integrated personnel information system has been largely unsuccessful, as might well be expected with a medium-large/42-score design-reality gap.
The system was implemented, but hardly used. More than three years after the system was finally introduced, personnel data was only being updated by OCS staff. After some initial attempts, staff in the ministries and departments reverted back to their manual personnel records. The new system did not impact their personnel decision making.
Learning: Identifying Causes of the Largely Unsuccessful Outcome
The dimensional gaps are arranged in descending order in the following table, which focuses on the situation during implementation:
Dimension |
Rating |
Information |
7 |
Processes |
7 |
Objectives & Values |
7 |
Technology |
6 |
Staffing & Skills |
6 |
Management Systems & Structures |
5 |
Other Resources |
4 |
The relatively 'mechanical' issues of technology and skills did play a role in this failure; in particular exacerbated by the inability of the implementation process to lessen those gaps, as one might typically expect during implementation.
However, the key cause of failure is the cluster of gaps - on the information, processes, and objectives and values dimensions - that relate to the attempt to change so much of what the ministries were doing, when most senior staff in those ministries were unsympathetic to such changes.
Recommendations: Reducing Design-Reality Gaps
To reduce the risk of failure, e-government projects must reduce problematic design-reality gaps. This means either making the design more like current reality and/or making reality more like the design. Hindsight recommendations for improvements on this project fall into two main camps:
i. Generic gap closure recommendations
These are approaches to e-government projects that can help generally to reduce gaps on a number of dimensions:
- Scope limitation : the initial project should have been much more limited in its scope and ambition. By trying to computerise and integrate and rationalise systems at the same time, it created too big a design-reality gap, meaning it tried to change too much at once, leading to a high risk of failure. The project should, instead, have initially aimed just to introduce computers and networks to the government personnel function, but to leave current working practices largely untouched. It could have done this in one of two ways. Most obviously, by automating some of the current personnel practices, but leaving those practices as close as possible to the original form - i.e. retaining the same information, the same processes, the same management systems and structures, the same personnel - as much as possible. Alternatively, by focusing on roll-out of basic network applications - particularly email - to a broad range of personnel-related locations and staff. This would not change any of the main work of the government's personnel function, just automate some communication and data-gathering practices. In either case, this would mean a significantly smaller overall design-reality gap, and a much higher probability of success.
- Participation : the personnel IS project was designed by the IT sub-contractor with some inputs from senior civil servants and from the NITU. There was little or no involvement from those at lower levels who would actually be required to operate the new system and who understood how the existing system worked. It would potentially have been better if those lower-level stakeholders had been involved in the process. In that way, a richer sense of reality would likely have been incorporated into the project's design (e.g. in relation to access to senior staff records, and in relation to the design of training workshops) resulting in a smaller overall design-reality gap. The idea of allowing lower-level staff to participate in important projects is itself rather out-of-synch with current government realities, making it harder to achieve as a technique. However, the failure to involve those staff led to a very clear result - with their bosses' blessing, they 'voted with their feet' and chose to continue working with the system they found easier and more effective to use: the old manual system.
- Hybrids : hybrids are staff who understand government from both a working practices and information systems perspective. It would have helped this project if specific individuals had been trained as hybrids. They would especially have helped bridge the gap between the e-government application designers (who understood IT but not the working practices of the personnel function) and the application users (who understood their working practices but did not understand IT). This could have addressed both the scope and participation issues just identified, and closed a number of design-reality gaps.
ii. Specific gap closure recommendations
These are actions taken on e-government projects that can help specifically to reduce gaps on a particular dimension:
- Staffing and skills : if the design and delivery of training activities had been devolved to individual ministries and departments, there is a greater likelihood that the design would have been included a more effective way to develop the needed skills; more effective than the centralised one size fits all approach that was adopted. This would have produced a greater reduction in the gap on this dimension during implementation.
Action Recommendations
All of the above represent retrospective recommendations: ways in which the project could have been better implemented if it had recognised design-reality gaps earlier. What they suggest for the current project is that it tries to make alternative use of the IT base that has been installed. First, it should look to spread very simple applications, like email, as suggested in the scope comments. Then, via key 'hybridised' individuals in each ministry, it should take a more bottom-up approach led by suggestions from within the ministries about how to gradually computerise more of the personnel function. Having a single, integrated system may remain an ultimate goal but, being a design so different from existing reality, that goal will only be reached many years in the future.
Case Details
Author Data Sources/Role : Application User/Participant Role
Outcome : Largely Unsuccessful. Reform : eAdministration (managing process performance).
Sector : General Services (Public Administration).
Region : Southern Africa. Start Date : 1997. Submission Date : January 2003