Success and Failure in eGovernment Projects

Design-Reality Gap Case Study No.5

An Integrated Information System for Defence Force Management in the Middle East

Case Study Author



The Republican Defence Force (RDF), under control of the Department of Defence (DoD), consists of the nation's army, air force and navy.

Application Description

The application was the planned introduction of an integrated information system (IIS) that would cover all branches of the Republican Defence Force. This would not only computerise but also integrate a variety of management information systems, including human resource IS, budget IS, accounting IS, and procurement/payment IS.

Application Drivers

Until the mid-1990s, management of the RDF was a hierarchical activity that relied mainly on manual information systems. As the RDF grew during the 1990s, this approach became increasingly inefficient and ineffective. A decision was therefore made to upgrade the management information systems, with a view to improving management processes, and improving the image of the RDF. This also coincided with a more general move to try to improve the functioning of the whole apparatus of government, and with a more general spread of IT, which some senior and middle-rank officers mis-perceived as an overnight solution to a variety of managerial and administrative problems.


The main stakeholders are those in senior positions (Secretary for Defence and other DoD senior officials; Head of the RDF, Heads of the individual Defence Services, and other senior officers); key advisers or close colleagues of those senior officials/officers; middle-ranking officers who will be involved in the IIS introduction process, including the head of the IT Unit, and others who will be using the outputs of the system; and ordinary service men and women, who will be recorded on the system and may also be operators or users. Local IT firms also had some stake. They can be represented on the following matrix of power and interest. The most important stakeholders will be those combining highest power and highest interest (senior officers) and there is a continuum down to the least important who have lowest power and lowest interest (ordinary service personnel).




Secretary for Defence / Other senior DoD officials

Head of RDF / Heads of Defence Services / Other senior officers

Level of Power


Head of IT Unit

Advisers / Close colleagues of senior officials/officers




Majority of service men / women


Middle-ranking officers

Local IT firms





Level of Interest


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:

Design-Reality Gap Changes During Implementation

It emerged that the system implemented was a product initially designed for the private sector. Although the RDF design removed inappropriate private sector components, in practice those components were not actually removed by the initial contractor. In other words, the IIS was never customised to specific RDF processes and systems (nor, implicitly, to its objectives and values). The design-reality gap on these dimensions therefore actually increased after initial implementation. The initial contractor was then removed, and a new one introduced, which did attempt some of the designed customisations, bringing the design-reality gap back down to initial levels.

The staffing and skills gap was narrowed somewhat by IT training provided to service personnel. However, this left the gap in other competencies untouched. That gap was affected by the change in contractors - reducing as a more competent contractor was introduced, but growing again when some key project personnel left to work in the private sector. Overall, the gap reduced to a score of c.7.5.

The technology gap narrowed as new IT was brought in (thus changing the reality of the RDF to make it more like the design and bringing the score at the time of case analysis to around 5.5), but other dimensions did not alter because the IIS failed to make an impact on the reality of organisational functioning.

Finally, after a few years, and despite the obvious problems with the system, the design was expanded to incorporate two additional computerised modules, thus creating some modest increase in most design-reality gaps.

In all, after some years of implementation, the overall design-reality gap has not significantly reduced from the initial score.

Evaluation: Failure or Success?

Introduction of the integrated information system has been largely unsuccessful, bordering on a total failure, as might well be expected with a large-medium/51-score design-reality gap.

The system was implemented, but most modules have never worked satisfactorily and never been used, or were just run in parallel with existing practices but not made part of those practices. At the time of analysis - some six years after project initiation - of the five initially envisaged modules, only one is in operational use. In cost-benefit terms, the project has been little short of disastrous, with hundreds of meetings, training sessions, and other uses of staff time plus the direct financial costs all being invested with very little to show on the benefit side of the balance sheet.

Learning: Identifying Causes of Near-Total Failure

The dimensional gaps are arranged in descending order in the following table, which focuses on the pre-implementation situation:





Staffing & Skills




Management Systems & Structures




Objectives & Values


Other Resources


With such high gap ratings for so many dimensions, it can be argued that all except 'other resources' were a contributory cause of the largely unsuccessful outcome. As noted above, the greatly-lengthened timescale for the project and the gradual introduction of IT means that 'technology' in practice should not be seen as a prime cause of the failure. The remaining dimensions can be grouped into three related areas as causes:

Any one of these can be problematic - together they created a strong likelihood of 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 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:

ii. Specific gap closure recommendations

These are actions taken on e-government projects that can help specifically to reduce gaps on a particular dimension:

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. Some of these are not of much use to the existing project, since they essentially argue that this was the wrong project, and that RDF should have started with a completely different e-government application. Some, however - incrementalism, better communication, training - could be used to try to rescue IIS.

Case Details

Author Data Sources/Role : Application User/Participant Role
Outcome : Largely Unsuccessful. Reform : eAdministration (managing process performance).
Sector : Security Services (Defence).
Region : Middle East. Start Date : 1996. Submission Date : January 2003

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