eGovernment for Development

In the Techniques section:

Risk Assessment

Assessing Your Project

Techniques

Avoiding eGov Failure: Design-Reality Gap Techniques

Assess Gaps
Determine Action
Generic Action
Specific Action
Examples

"How can I make my e-government project more likely to succeed and/or less likely to fail?"

A gap exists for all e-government projects between the design assumptions/requirements and the reality of the client public agency. The larger this gap between design and reality, the greater the risk that the project will fail. If you can reduce the gaps between design and reality, you can reduce the risk of e-government failure. This page looks at various ways of reducing those design-reality gaps. Follow this link for further explanation about design-reality gaps (and some related case examples).

Step 1. Assess Design-Reality Gaps

The first step in reducing the chances of failure is to assess two things. First, the individual design-reality gaps on each of seven 'ITPOSMO' dimensions: information, technology, processes, objectives & values, staffing & skills, management systems and structures, and other resources. Second, the total design-reality gap (obtained from adding the seven individual gaps).

Follow this link for guidance on how to do risk assessment based on the design-reality gap model.

Step 2. Determine Action

If you have a significant overall design-reality gap, you should take action since you may be heading for failure. If you have a significant design-reality gap on a particular dimension, you should take action since this may cause you problems. Assessing whether a gap is 'significant' is a matter for discussion, debate and judgement. However, an overall gap of more than about 20, and an individual dimension gap of more than about 5 could give cause for concern.

"Taking action" means either:

Changing the design of the e-government project to make it more like reality, and/or
Changing current reality to make it more like the assumptions/requirements within project design.

Selected techniques will, of course, depend on which dimension(s) the gap occurs. Take the example of a financial gap along the 'other resources' dimension. This gap could be reduced by scaling-down the project remit and thereby reducing cost (design change). Or it could be reduced through public-public or public-private collaboration that increases the supply of available finance (reality change).

A sample of gap reduction techniques is presented in more detail below. Some techniques are generic : they relate to one or more ITPOSMO dimensions. Other techniques are specific : they relate to one specific dimension.

In selecting a technique for a particular project, practitioners should ensure that the technique is not only desirable but also feasible. There is no point considering techniques that could reduce risks in theory, but not be implemented in practice.

Step 3a. Generic Gap Reduction Techniques to Reduce the Risk of eGov Failure

i. Legitimising and mapping current reality . To succeed in e-government - and to properly identify design-reality gaps - you have to understand current reality. Yet this may be difficult to achieve. eGovernment leaders can help by 'legitimising reality': by encouraging stakeholders to express the difference between prescriptive models of what they should be doing, and real depictions of what they are actually doing.

Techniques for exposing and mapping organisational realities play a role here. Self- and third party observation helps expose realities. Use of soft systems tools such as 'rich pictures' helps map realities. Prototyping helps both, particularly helping users to understand their real information needs.

ii. Customisation to match realities . In the 1970s and 1980s, government was rebuked for reinventing the wheel by custom-building each IT solution from scratch. In the 2000s, the pendulum has swung too far the other way. Government agencies too readily try to install ready-made digital solutions that have been designed for private sector firms.

The problem is that private sector and public sector remain fundamentally different. Solutions designed for the former do not necessarily match the realities of the latter, and can create a classic situation of square pegs and round holes; and of large design-reality gaps.

To combat such problems, managers of e-government projects must be competent enough and confident enough to demand designs that match government's unique reality. The keywords for such projects must be 'customised' not 'off-the-shelf'; 'adapt' not just 'adopt'.

In many cases, this will require national and/or sectoral and/or in-house e-government development capacities to be strengthened. This will also affect selection of software vendors and developers. One key criterion will be their demonstrable willingness and ability to understand client contextual realities and to customise e-government systems accordingly.

iii. Client-vendor relationship management . The squeeze on public sector skills and cash means that e-government projects are increasingly outsourced to the private sector. This can exacerbate the traditional gulf between developers and clients, by stirring in an additional clash of culture and values. Gaps between vendor design and client reality readily emerge.

To reduce these design-reality gaps, much more attention needs to be paid to active management of the client-vendor relationship. Successful e-government projects are adopting innovative approaches to build mutual understanding and shared objectives. Gap reduction techniques include vendor shadowing of key client staff, joint team-building events, joint profit sharing and open book accounting.

For government, this heightened focus on supplier relationship management means the development of new skills and roles, including relationship building, contract facilitation, contract monitoring and vendor development. It also means a renewed emphasis on other roles that must remain in-house such as strategic management, business analysis and change management.

iv. Step-by-step: modularity and incrementalism . The bigger and bolder the e-government project, the greater the risk of failure. Developers must reconfigure such projects to limit the extent of change (i.e. of design-reality gap) at any given time.

Stretching project time horizons is one technique. There is also a growing consensus behind modularity (supporting one business function at a time) and incrementalism (providing stepped levels of support for business functions) within digital government projects (see figure below).

v. 'Hybrids' and 'tribrids' . Design-reality gaps often arise in e-government because of a 'two tribes' mentality that afflicts most governments. IT designers understand technology but not the realities of government. Public officials and politicians understand the realities of government but not the technology. To close these gaps, projects need to develop and use 'hybrid' professionals, who understand both perspectives. We might even call them 'tribrids' (see figure below), because they combine three aspects: understanding the technology and the business of government and the role of information in government.

vi. Scope limitation: KISS and automation . eGovernment projects sometimes fail because they try to change too many things at once. One way to address such over-large design-reality gaps is to cut down the scope and ambition of the project design; sticking with the valuable design motto 'KISS': Keep it Small and Simple . One way to incorporate KISS is by trying to freeze all except the technology dimension. How? By simple automation of existing activities. The intention is to retain the same information, same processes, same management systems and structures, etc., but merely change them from manual to computerised operations. In other words, you attempt to create no design-reality gap (no change) on most ITPOSMO dimensions. Although criticised in hindsight as being insufficiently bold, simple automation can be a very good - and successful - way to institutionalise new technology in a particular aspect of public sector operations.

vii. Reality-supporting not rationality-imposing applications . There is a continuum of e-government applications, as shown in the diagram below. At one extreme, there are 'rationality-imposing applications', such as decision support systems. These include in their design a whole series of assumptions about the presence of rational information, processes, objectives and values, management structures, etc. These rationalities must either be present in the organisation as a pre-condition for successful implementation of this application, or they must be imposed. In many government organisations, the introduction of such applications will not succeed because of the large gap between the application's required rationalities and current organisational realities.

At the other extreme, there are 'reality-supporting applications' such as word processing or email. By comparison with rationality-imposing applications, reality-supporting applications require fewer rational pre-conditions or impositions. They can therefore work successfully in a wider variety of government organisational situations. eGovernment projects will therefore be more likely to succeed if they focus on 'reality-supporting' rather than 'rationality-imposing' applications.

Step 3b. Dimension-Specific Gap Reduction Techniques to Reduce the Risk of eGov Failure

i. Information dimension .

Undertake a professional requirements analysis in order to draw out true information needs of stakeholders.
Use prototyping - getting users to use a test version of the e-gov application - in order to help them explain what information they really need.

ii. Technology dimension .

Investigate ways in which government reforms could be delivered without ICTs.
Investigate ways in which government reforms could be delivered using the existing ICT infrastructure.
Avoid leading-edge technologies in your design.
Investigate opportunities for use of donated or recycled equipment.

iii. Process dimension .

Keep doing things the same way, only with the addition of some new technology (see generic point above about automation).
Avoid business process reengineering; instead, at most, look at optimisation or minor modification of existing processes within the e-gov application design.
Consider a two-stage approach: in the first stage, processes are optimised without any change to ICTs; in the second and later stage, new ICTs are brought in.

iv. Objectives and Values dimension .

Use rewards to alter stakeholder objectives and values (e.g. messages of management support, better pay, better working conditions, career advancement, etc.).
Use punishments to alter stakeholder objectives and values (e.g. threats, reprimands, transfers, worsened pay and conditions, etc.).
Communicate with stakeholders about the system: sell the true benefits and address the true negative aspects.
Get key stakeholders (those regarded as key opinion formers or those vociferous in their resistance to the e-gov application) to participate in the analysis and/or design of the e-gov application.
Base e-gov application design on a consensus view of all main stakeholders.
Use prototyping: this helps incorporate stakeholder objectives in the design, and also helps to make actual stakeholder objectives more realistic.
If feasible in skill, time and motivational terms, get users to help develop and build the e-government application.

v. Staffing and Skills dimension .

Outsource contracts in order to improve the current reality of available competencies (though may increase other gaps).
Train staff to improve current reality of competencies.
Improve recruitment and retention techniques to reduce competency (staff) turnover.
Make use of external consultants (though may increase other gaps).
Hire new staff to expand the volume of current competencies.

vi. Management Systems and Structures dimension .

Make an explicit commitment to retain the existing management systems and structures within e-gov application design.

vii. Other Resources dimension :

Prioritise e-government applications that maximise revenue generation for government (e.g. those dealing with tax, fees, fines, etc).
Seek additional financing from donor or central government agencies.
Take out loans from private sector institutions.
Get private firms to develop, own and operate the e-government application.
Charge business or wealthier users of the e-government system.
Scale-down ambitions of the e-government project.
Extend timescales of the e-government project.
Negotiate central/shared agency IT agreements to reduce hardware and software costs.
Use 'one for all' contracts that are reusable.
Use project management techniques to reduce waste and delays.
Outsource contracts in order to reduce time (and possibly costs) gaps.
Make use of open source software (though cost savings are often less than anticipated).

Real-World Examples

Recommended generic and specific gap closure techniques are provided for a number of real-world cases of e-government (from the primary topci section of this website):

Recommended specific gap closure (risk mitigation) techniques are provided for a number of real-world e-government proposals (from the primary topci section of this website):