Techniques

Avoiding eGov Failure: Design-Reality Gap Techniques

"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).

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.

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.