Success and Failure in eGovernment Projects

Design-Reality Gap Case Study No.1

Automating Public Sector Bank Transactions in South Asia

Case Study Authors

Asad Ghalib and Richard Heeks


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.


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:

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:

Learning: Identifying Causes of Partial Failure

The dimensional gaps are arranged in descending order in the following table:





Objectives & Values




Staffing & Skills


Other Resources




Management Systems & Structures


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:

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

Last updated on 19 October, 2008.
Please contact with comments and suggestions.