eGovernment for Development

Techniques

Avoiding eHealth Failure: Design-Reality Gap Techniques

1. Assess Gaps
2. Determine Action
3. Generic Action
4. Specific Action
5. Example

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

This page offers one approach to answering this question.

A gap exists for all e-health projects between the design assumptions/requirements and the reality of the client health organisation.  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-health 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 assess design-reality 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:

1. Changing the design of the e-health project to make it more like reality, and/or
2. 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 eHealth Failure

i. Legitimising and mapping current reality .  To succeed in e-health - and to properly identify design-reality gaps - you have to understand current reality.  Yet this may be difficult to achieve.  eHealth 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 .  Public healthcare organisations too readily try to install ready-made digital solutions that have been designed for private health providers.  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.

To combat such problems, managers of public e-health projects must be competent enough and confident enough to demand designs that match their organisation'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-health 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-health systems accordingly.

iii. Client-vendor relationship management .  The squeeze on public sector skills and cash means that public e-health 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-health 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 public healthcare organisations, 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-health 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 public e-health projects (see figure below).

v. 'Hybrids' and 'tribrids' .  Design-reality gaps often arise in e-health because of a 'two tribes' mentality that afflicts many healthcare organisations.  IT designers understand technology but not the realities of healthcare delivery.  Public officials and health workers understand the realities of healthcare 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 healthcare and the role of information in healthcare.

vi. Scope limitation: KISS and automation .  eHealth 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 healthcare operations.

vii. Reality-supporting not rationality-imposing applications .  There is a continuum of e-health 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 healthcare 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 healthcare organisational situations.  eHealth 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 eHealth Failure

i. Information dimension .

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

ii. Technology dimension .

• · Investigate ways in which healthcare reforms could be delivered without ICTs.
• · Investigate ways in which healthcare 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 healthcare processes within the e-health 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-health application) to participate in the analysis and/or design of the e-health application.
• · Base e-health 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-health 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-health application design.

vii. Other Resources dimension :

• · Seek additional financing from donor or central government agencies.
• · Get private firms to develop, own and operate the e-health application.
• · Charge business or wealthier users of the e- health system.
• · Scale-down ambitions of the e- health project.
• · Extend timescales of the e- health 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 Example

Recommended generic and specific gap closure techniques are provided for the following real-world case of e-health: Computerising a Central Asian Epidemiology Service.