ICTs for Government Transparency

Techniques

Avoiding eTransparency Failure: Ideas About Design

This page offers ideas about how to address one factor identified as important to the success or failure of e-transparency projects. Follow this link for more information about such factors (and some related case examples).

Idea 1: Prototype And/Or Pilot Your Project

Taking project requirements, disappearing off to a darkened room for several months, and then implementing the entire e-transparency project is not a great recipe for success. Instead, an iterative and incremental approach should be used. First, this involves prototyping - the use of a working model of the final system, which users can see, comment on, and have revised before the final version is produced. This has been shown to increase the rate of e-transparency project success by making the design match real user needs, and by making users more realistic in their expectations of the system.

Second, this can involve piloting - typically implementing the e-transparency system at a single site; observing, learning and reviising the system; and only then rolling it out to other sites. Again, this has been a proven way to increase the chance of project success.

Another way of phrasing this last point is to say that you should be incremental - going step-by-step - with your e-transparency project, and avoid the hazardous "big bang" approach.

(From: Richard Heeks, Mr M.D.R.R. Senanayake & Mr A.M.S.K. Chandrasena)

Idea 2: Stakeholder Involvement Is A Must

The main internal stakeholders for an e-transparency project - the senior officials and the operational staff - MUST be involved in project design in some way. Without that, you can almost guarantee failure. For example, the Cameroon government initiated the SIGIPES project: introducing e-transparency into the process of human resource management within government. The first attempt at the project - which took a top-down approach - was a failure. The second attempt ensured that general staff, including administrators and other lower-/middle-level system users, were involved with the project. Their ideas were incorporated into the design, and the process of involvement also helped develop their commitment.

The main external stakeholders for an e-transparency project - donors/funders, and citizens or businesses who are intended beneficiaries - should also be involved.

Involvement in design can take many forms, and you can see a ladder from low to high levels of involvement:

(From: Olivier Kenhago & Richard Heeks)

Idea 3: KISS - Keep It Simple, Stupid

The more complex your e-transparency design, the greater the likelihood of failure. Keep your system design simple will make it more likely to succeed.

(From: Olivier Kenhago)

Idea 4: Design For Local Realities - Both Hard And Soft

Designs for e-transparency are most likely to fail where they mismatch local realities. A good design will be sensitive to local realities: not just the 'hard' realities like the state of current technology or the quality of local data, but also the 'soft' realities such as local culture and motivations.

(From: Sebastian Ailioaie & Sorin Kertesz)

Idea 5: Use International Standards Where Possible

Sometimes - in order to ensure a sufficient match to local realities - it pays to develop your own design for e-transparency projects and system components. In other cases, though, re-use of existing international standards (at least for part of the e-transparency system) can save time and build credibility for the project. Examples could be the use of international standards for procurement, or the use of international accounting standards for financial e-transparency applications.

(From: Vickram Crishna, Udit Chaudhuri, Tapan Mehta, Mr M.D.R.R. Senanayake & Mr A.M.S.K. Chandrasena)

Idea 6: Design In Feedback For Users

Some e-transparency systems are like black holes - they swallow up citizen complaints or registrations, then provide no response. A good e-transparency application will have design features that provide feedback and status reports to users, thus encouraging them to have faith in the system and to keep using it.

(From: Erwin A. Alampay)

 

Page Author: Richard Heeks. Last updated on 19 October, 2008.
Please contact richard.heeks@manchester.ac.uk with comments and suggestions.