In the Techniques section:
Techniques
Identifying eGov Failure Causes: Simple Factor Rating
"Why did my e-government project fail?"
This page offers one technique for answering this question by identifying causes of failure. Follow this link for other techniques.
Analysis has shown that there is a general set of success and failure factors that affect e-government projects. The identification technique presented here asks you to rate the presence/absence of these factors. Follow this link for a detailed explanation of these factors (and some related case examples).
Identifying the Factors Underlying Failure
Identification consists of questions relating to a series of factors, with attached rating numbers.
Notes:
- Work through the factor questions one by one, reflecting on the situation that existed during the implementation of the e-government project.
- You give a rating number for your answer. The rating for each answer can be anywhere on a scale from zero to ten: the higher the number, the less likely it is that this factor was an important cause of failure. Examples are only given for zero, five and ten, but all numbers in the range are possible.
- It may be necessary to conduct further data gathering (interviews, document analysis, observations, questionnaires, etc.) in order to adequately answer the questions.
- The term 'public agency' is used to mean the department, Ministry, parastatal, or other public sector organisation in which the e-government project is being undertaken.
- There is a worked example at the end of the page.
1. Drivers
Factor Question 1a . How strong was the drive for change from outside the public agency (e.g. from central government, or from an aid donor, or from citizens, etc.)?
Answer Rating : from 0 for 'non-existent' through 5 for 'moderate' to 10 for 'intense'.
Factor Question 1b . How strong was the drive for achievement of e-government goals from key agency officials?
Answer Rating : from 0 for 'non-existent' through 5 for 'moderate' to 10 for 'intense'.
2. Strategy
Factor Question 2 . Was there a clear, long-term strategy for e-government that saw IT as a means to achieving broader reform objectives?
Answer Rating : from 0 for 'no strategy at all' through 5 for 'partial strategy' and/or 'only partly clear' and/or 'somewhat unstable' and/or 'saw IT more as an end than a means' to 10 for 'strategy that met all the stated criteria'.
3. Management
Factor Question 3a . How good was project management for the project?
Your assessment should cover at least the following six sub-points as examples of good practice: the presence of clear project responsibilities; consideration of risk; good monitoring and control; good organisation of resources (including staff); good management of partnerships (with private suppliers and with other public agencies); and effective procurement.
Answer Rating : from 0 for 'very poor' through 5 for 'moderate' to 10 for 'very good'.
Factor Question 3b . How good was change management for the project?
Your assessment should cover at least the following four sub-points as examples of good practice: strong leadership from a project champion; support of senior officials and other powerful stakeholders; use of incentives to create commitment and ownership among stakeholders (including operational staff); and strong stakeholder involvement that built support.
Answer Rating : from 0 for 'very poor' through 5 for 'moderate' to 10 for 'very good'.
Factor Question 3c . How much were key players just focusing on personal self-interest and playing politics?
Signs of this that could form a checklist include infighting; resistance where loss of power was feared; "me too" copying of e-government solutions for image purposes; obsession with electoral impacts and short-term kudos; and corruption.
Answer Rating : from 0 for 'very much' through 5 for 'somewhat' to 10 for 'very little'.
4. Design
Factor Question 4 . How effective and realistic was the design of the e-government project?
Your assessment should cover at least the following four sub-points as examples of good practice: an incremental/piloting approach; quick and feasible objectives; strong stakeholder involvement ensuring design met real needs; and an understanding in the design of the 'human factor', including local culture and values.
Answer Rating : from 0 for 'very ineffective and unrealistic' through 5 for 'moderately effective and realistic' to 10 for 'very effective and realistic'.
5. Competencies
Factor Question 5 . Were the required competencies present?
Assessment of competencies should at least approximate to a three-dimensional matrix that covers: a) the different categories of competency (skills, knowledge and attitudes); b) the different stakeholder groups (system developers, system managers, organisational managers, system operators, system users, etc.); and c) the different areas of competency (strategic, change/project management, information systems development and management, hands-on, interpersonal, 'intelligent customer' (contracts, suppliers, procurement), etc.).
Answer Rating : from 0 for 'completely absent' through 5 for 'some presence' to 10 for 'all present'.
6. Technology
Factor Question 6 . Was the technological infrastructure adequate?
Assessment would cover the presence and resilience of data systems, software, hardware, and telecommunications. Where appropriate, this can include assessing whether systems (data, software, hardware) supposed to 'talk to each other' were actually compatible.
Answer Rating : from 0 for 'wholly inadequate' through 5 for 'moderate' to 10 for 'completely adequate'.
7. Other
Factor Question 7 . Were there other factors likely to cause an e-government project to fail?
These might relate to money or timescales as well as other issues.
Answer Rating : from 0 for 'yes' through 5 for 'perhaps' to 10 for 'no'.
Presenting, Analysing and Using the Results
The rating scores for each factor are ranked in numerical order. These can be presented either as a table or diagram. Examples of both are given in the worked example below.
Those factors which receive the lowest answer rating are most likely to represent the causes of failure in the e-government project. (Note: it is useful at this point to change the wording of the factor to its negative aspect, e.g. 'change management' to 'poor change management', or 'Politics/self-interest' to 'Dominance of politics/self-interest'.)
Factors with scores of more than 5 are unlikely to be causes of failure, unless all other factors have even higher scores. Rating is a subjective process, but a rough guide to likelihood of a particular factor being a cause of failure is shown in the table below.
Factor Score |
Likelihood of Factor Being Contributor to Failure |
|---|---|
0.0 - 2.0 |
Very likely |
2.1 - 4.0 |
Likely |
4.1 - 6.0 |
Possible |
6.1 - 8.0 |
Unlikely |
8.1 - 10.0 |
Very unlikely |
Rather than simply accepting the scores and rankings, it makes sense to first discuss the order and scores that have emerged, to see whether they reflect the perceptions of key stakeholders. For example, the ranked list of factors - with likely failure causes clearly identified - can be circulated for further comments to those stakeholders, or can be used as the basis for 'lessons learned' workshop.
Knowledge about the likely causes of failure can then be disseminated to others who would find it useful; and subsequently applied. Application of this knowledge will broadly mean:
- Using the knowledge to try to revive the existing e-government project, and turn it from failure to success. This will mean paying special attention to the identified causal factors to change them from constraints into enablers/drivers. For example, imagine Factor 1b - internal drive for e-government - emerged with the lowest score as the strongest individual cause of failure. What should the current e-government project team do? They should plan how to create a drive for achievement of e-government goals from key agency officials. This would not mean empty exhortations about e-government. Instead, it will mean developing an understanding of the individual motivations of key officials, and planning around those motivations. Plans might include awareness-raising about e-government, visits to e-government sites, benchmarking comparisons with other agencies, enlistment of even more senior government figures, introduction of e-government-related incentives, design of e-government programmes around the specific priorities of key officials, etc.
- Using the knowledge in future e-government projects to reduce their risk of failure. This will mean paying special attention to the identified causal factors in future projects to ensure they become enablers/drivers and not constraints. For example, imagine Factor 3b - change management - emerged with the lowest score as the strongest individual cause of failure. What should future e-government project teams do? They should focus on developing and supporting strong change management competencies and processes. This would mean ensuring plans to put in place as many of the identified sub-points as possible: strong leadership from a project champion; support of senior officials and other powerful stakeholders; use of incentives to create commitment and ownership among stakeholders (including operational staff); and strong stakeholder involvement that builds support.
The chief hazard in the latter case is the assumption that what causes one project to fail will also be the main cause of failure in a later project. Other techniques - such as design-reality gap analysis - do not make this assumption.
Variations on the Basic Technique
The basic technique makes a questionable assumption - that all factors are equally important; for example, that if Factors 3a and 6 both get a score of 2, then the absence of both good project management and sound technological infrastructure were equally important causes of failure. A more complex variation - already noted above - uses the raw scores as the basis for further reflection and discussion, leading to a revised ranking list of factors.
A more complex version again would - at the start of the process - review the list of factors provided. Factors seen as irrelevant to the project failure would be removed. Other factors, not on the list, would be added. Then scoring and ranking would proceed as above.
Pros and Cons of this Technique
This technique is simple and quick to understand and put into practice. On the downside, at least in its simple form, it assumes that "one size fits all" e-government projects, which we know is not really true. The questions, being relatively few in number, sometimes try to cover quite a range of different issues in a single question. The approach also takes no account of possible interaction between factors as a cause of failure.
Worked Example
A new Web-based procurement system was implemented last year by the Ministry of Transportation in Gedactia. Introduction of the system was promoted and partly-funded by an external donor, which put in place many of the formal skills and technology required, but the project had relatively little internal support.
Evaluation shows that the e-procurement system is little used. It has significantly undershot on its objectives, which set clear goals for the value of electronically-made purchases to be achieved within one year, and for the savings to be made through e-procurement.
Why did this e-government project partially fail? An answer is given below.
Questions, Answers & Ratings
Factor Question 1a : How strong was the drive for change from outside the public agency (e.g. from central government, or from an aid donor, or from citizens)?
Answer : The donor wa pretty keen on seeing significant changes in the way the Ministry operated.
Rating : 8
Factor Question 1b : How strong was the drive for achievement of e-government goals from key agency officials?
Answer : Officials were relatively happy with the status quo, and have been generally fearful of change, particularly change involving IT.
Rating : 2
Factor Question 2 : Was there a clear, long-term strategy for e-government that saw IT as a means to achieving broader reform objectives?
Answer : It is questionable whether there really has been any commitment within government to stated reform objectives, and officials are only just now starting to identify policies and strategies for IT.
Rating : 2
Factor Question 3a : How good was project management for the project?
Answer : The donor insisted on bringing foreign consultants in to help manage the e-procurement project. They brought with them a strong set of rational, textbook skills in project management and experience of projects in industrialised countries. On the downside, they had little awareness of the specific issues facing the Gedactian public sector.
Rating : 7
Factor Question 3b : How good was change management for the project?
Answer : There was little or no internal support or championing of the project, and little internal ownership. The consultants made some half-hearted attempts to get stakeholders involved, but they seemed to see the donor as their main client.
Rating : 2.5
Factor Question 3c : How much were key players just focusing on personal self-interest and playing politics?
Answer : There was a fair amount of this going on; even, arguably, within the consulting firm which seemed to care more about its reports and its appearance than about a successful system. Many internal staff have been resistant to the project, partly for personal reasons, but also because they do not feel e-procurement is an appropriate priority for the Ministry.
Rating : 2
Factor Question 4 : How effective and realistic was the design of the e-government project?
Answer : The consultants created a very professional-looking design that incorporated an incremental/step-by-step approach, and provided some limited quick wins. However, it has felt more like an 'off-the-shelf' solution than one matched to local needs and conditions.
Rating : 5
Factor Question 5 : Were the required competencies present?
Answer : On the technical side, things were good - the consultants knew what they are doing, and they provided hands-on training for local staff. On the other hand, many of the human and change-related skills and knowledge were lacking, especially within the Ministry.
Rating : 5
Factor Question 6 : Was the technological infrastructure adequate?
Answer : The consulting firm was able to introduce a sound technological infrastructure for the project. There have been some compatibility issues, particularly the lack of IT access among smaller suppliers.
Rating : 7
Factor Question 7 . Were there other factors likely to cause the e-government project to fail?
Answer : Not that can be identified at present. Sufficient funds have been provided by the donor for the first two years of the project, though a question hangs over the ongoing financial sustainability of the project.
Rating : 7.5
Results
The factors are sorted into numerical order, and can be presented as a table and/or diagram. As noted above, the wording of the factor should be changed to indicate the constraint aspect of the factor, as illustrated in the diagram.
Factor |
Rating Score |
Likelihood as Cause of Failure |
|---|---|---|
Internal political desire |
2 |
Very likely |
Overall vision/strategy |
2 |
Very likely |
Politics/self-interest |
2 |
Very likely |
Change management |
2.5 |
Likely |
Competencies |
5 |
Possible |
Design |
5 |
Possible |
Project management |
7 |
Unlikely |
Technological infrastructure |
7 |
Unlikely |
Other |
7.5 |
Unlikely |
External pressure |
8 |
Unlikely |
Conclusions and Action
Three factors - lack of internal political desire, lack of overall vision/strategy, and dominance of politics/self-interest - have been identified as the most likely causes of this e-government failure. These factors can now form the focus either for remedial action on the existing project and/or for risk reduction strategies in future projects.