In the Case Studies section:
Design-Reality Gap Case Study No.1
Automating Public Sector Bank Transactions in South Asia
Case Study Authors
Asad Ghalib and Richard Heeks
Organisation
The bank is government-owned at the state level and set up within the last twenty years. It has more than 200 branches and more than 2,000 employees.
Application Description
The application was the introduction of computers into all branches of the bank - first main branches, then other branches - in order to provide automated support for the main branch transactions (accepting cash and issuing a receipt; issuing cash payments; paying utility bills), and to produce management reports for regional and head offices.
Application Drivers
Previous, manual processing of bank transactions and production of financial reports was slow and inaccurate. Computerisation was seen as a relevant reaction to these problems, driven on by competition from other banks and by a National State Bank directive emphasising the need for branch computerisation. Internally, automation was seen as a necessary component of structural decentralisation within the bank, and as a way to provide a more modern and stimulating work environment that might address the bank's high level of staff turnover, particularly among recent graduate employees.
Stakeholders
The main stakeholders involved with this application were bank senior executives, officers and clerical staff plus the bank's customers. Lesser stakeholders were the government owners, the National State Bank, and other banks and financial institutions.
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 assumed that accurate data was available within the bank about factors such as numbers of daily transactions, types of transactions, daily cash requirements. In reality, such data was generally available prior to automation but was not accurate. This created a medium design-reality gap on this dimension. Gap score: 5.
- Technology : the design assumed the use of a broad range of software and hardware. The initial reality was no computers at all in branches since all operations had been manual. This created a large design-reality gap on this dimension. Gap score: 8.5.
- Processes : the design assumed automation of the pre-existing bank processes with some amendments made to take account of IT but with many of the core elements of transactions and reporting left as they were. This created a small/medium design-reality gap on this dimension. Gap score: 3.
- Objectives and values : the design assumed that the objectives of the project (automation of processes, better reporting) were shared by all stakeholders. In reality, prior to automation, most branch managers and officers supported these objectives, as did the bank chairman. However, many clerical staff felt secure and confident with the pre-existing system, and feared the new one because they felt it was too complex or because they feared they might lose their jobs. Many senior managers opposed the change, partly because the values of internal politics made them oppose any initiatives of the bank chairman. Overall, there was a medium/large design-reality gap on this dimension. Gap score: 7.
- Staffing and skills : the design assumed the presence of sufficient numbers of skilled, knowledgeable staff. In reality, some staff were available prior to implementation, but too few (just six to undertake system set up, testing, training, troubleshooting, and help desk functions for the entire bank plus three to help with hardware and wiring). The computer division general manager had no technology experience; the division's manager had technical skills but was new and thus unfamiliar with bank operations. Other staff lacked the skills needed to operate the system but the design assumed that these skills could fairly readily be developed through training. (In fact, skill levels of bank officers were raised relatively easily to the level required by the application design. The same was not possible with clerical staff who appeared resistant or disinterested in the system, with frustration that grew as they made errors during training. Their skills could not readily be brought up to the designed level.) Overall, there was a medium design-reality gap on this dimension. Gap score: 5.
- Management systems and structures : the design proposed no real changes to pre-existing bank structures and relatively few changes to management systems. There was thus only a small design-reality gap on this dimension. Gap score: 1.5.
- Other resources : the design requirement was for budgetary expenditure of some US$170,000 to be spent on a three-year installation period. In reality, this budget drew heavily on the bank's financial resources. The designed timescale was also rather unrealistic given available resources - it assumed an average of four days per branch to accomplish wiring all staff desks and counters, installing and testing the hardware and software, and training the staff to full operational capacity (in practice, two weeks was found to be necessary). This meant an overall medium design-reality gap on this dimension. Gap score: 5.
- Overall : there was an overall medium design-reality gap in this case. Total gap score: 35.
Evaluation: Failure or Success?
Bank automation was a partial failure, as might well be expected with a medium/35-score design-reality gap.
On the plus side, computers have been introduced into bank branches and they are providing automated support for some key transactions between the bank and its customers in those branches. On the minus side:
- Three years past the deadline for automation of all branches, only just over half the branches have been computerised.
- There have been severe cost overruns, partly due to the need to recruit extra staff to cope with both basic implementation and ongoing problems, partly due to increased payments made to all staff involved with the project.
- The application generates 70-100 pages of reports per branch per day. Some, such as the trial balance and cashbook reports, are used for reconciliation checks with individual ledger balances. Others are never used, but simply stacked in a storeroom.
- There have been system usage problems with errors in the posting of entries, causing staff frustration and leading to additional training and re-training of staff. The usage problems and staff resistance to the system have fed off each other. These have been only partly assuaged by late-in-the-day decisions to pay 'disturbance allowances' to all staff involved with computerisation, and to change the job titles of cashiers and clerks to 'cash officers' and 'cash managers'.
Learning: Identifying Causes of Partial Failure
The dimensional gaps are arranged in descending order in the following table:
Dimension |
Rating |
Technology |
8.5 |
Objectives & Values |
7 |
Information |
5 |
Staffing & Skills |
5 |
Other Resources |
5 |
Processes |
3 |
Management Systems & Structures |
1.5 |
This suggests that the main causes of partial failure for this project were firstly the differences between design and reality for technology, and secondarily the differences for objectives and values. Issues around information, staffing and skills, and time and money (other resources) may have played some lesser role in the partial failure.
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 include:
- Other resources/Technology : the designed timescale should have been altered to make it closer to the real time requirements. The failure to do this led to many arguments, meetings, quick shortcuts that were later regretted, etc. Had this been done, the degree of technology change in any given time period would have been significantly reduced.
- Objectives and values : the objectives and values of many bank staff were out of synch with those implicit within the design as required for effective functioning of the system. Various techniques should have been used to bring staff objectives/values into synch in order to avoid the resistance experienced. Examples include involvement of staff representatives in the design process; preparatory workshops that discussed the value, importance and likely impact of the automated systems; broader training that focused not just on technical skills but also on the wider role and use of the application; and early payment of computing allowances to those staff involved.
- Staffing and skills : more skilled implementation staff should have been hired to make the reality of available staff more like the true design requirement. Through experience it emerged that a team of 30, not nine, was the true requirement.
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. However, very similar recommendations could still be used on the project in order to try to move it away from partial failure towards success.
Case Details
Author Data Sources/Role : Application User/Participant Role
Outcome : Partial Success/Partial Failure. Reform : eAdministration (cutting process costs).
Sector : Economic Services (Finance).
Region : South Asia. Start Date : 1995. Submission Date : January 2003