eGovernment for Development

Training

Training Workshop Content

Part 1: Introduction

[c.10 mins]

1. Read out workshop aim, objectives and structure. [ TRAINER ]

Other Possible Activities:

• If trainees may be unsure what e-government is, read out e-government definition: see eGovernment Definition page (note broad definition). Then get the group to discuss or debate definition of e-government. [ TRAINER & GROUP ]
• If trainees may be unsure what e-government covers, get trainees to read through the coverage of e-government: see eGovernment Definition page . Then get them to give examples of e-government projects, and see if these relate to the categories given on the Web page. If not, what conclusions does the group draw? [ TRAINEES & GROUP ]

Part 2: Why Worry About eGovernment Failure?

1. Explain that e-government failure may be a problem. This part of the workshop looks at the scale and nature of that problem in more detail. [ TRAINER ]

Part 2a: What is e-government success and failure?

[c.35 mins]

1. Get trainees to read through the section on 'Defining eGovernment Success and Failure', and the associated examples on the Success/Failure Definition page . [ TRAINEES ]
2. In pairs, small groups or plenary, get trainees to give examples from their own experience of e-government projects that were 'successes', 'partial failures' and 'total failures'. Get trainees to justify their success/failure categorisation. [ GROUP ]

Other Possible Activities:

• If trainees need additional confidence in handling success/failure categories, identify a short e-government case study that does not overtly contain a success/failure categorisation (for example, you could choose one of the 'Other Recent Cases' or 'Other Cases' from the Case List page ). Get trainees to use the categorisation guidelines on the Success/Failure Definition page in order to categorise the case study in success/failure terms. [ GROUP ]
• If trainer or trainees are unhappy with the listed categories, discuss or debate the success/failure categories; e.g. Are they appropriate to the trainees' own situation? Are they useful to the trainees or not? Are there better categories that could be used? [ GROUP ]

Part 2b: How common is e-government failure?

[c.35 mins]

1. Get trainees to read just the 'Overall Results' and 'Conclusions' sections of the Success/Failure Rates page . [ TRAINEES ]
2. In small groups or plenary, discuss these findings. Do these success/failure rates match trainees' own experience? If not, why not? What are the implications of these failure rates? [ GROUP ]

Other Possible Activities:

• If trainee-specific data on success/failure rates would be useful, conduct a secret ballot before trainees read the Success/Failure Rates page. Get each trainee, in private, to write down the percentage of e-government projects that - in their experience - fall into each of the success, partial failure and total failure categories. Collect in and average the results. Compare the results to those presented on the Success/Failure Rates page . Discuss similarities and differences. What does the group conclude? [ GROUP ]

Part 2c: What is the impact of e-government failure?

[c.60 mins]

1. In small groups or plenary session, get trainees to identify what they see as the impacts - both good and bad - of e-government project failure. [ GROUP ]
2. Now compare the list of impacts to those presented on the Impacts of Failure page . Discuss similarities and differences between the Web list and the group-developed list. What does the group conclude? [ GROUP ]

Other Possible Activities:

• Alternatively, if trainees would benefit from more initial guidance about impacts, start by getting trainees to read the 'Potential Costs' and 'Potential Benefits' sections of the Impacts of Failure page . Then, get them to give examples for each cost and each benefit category from their own experience. What does the group conclude (e.g. about how often we look for, and extract, the benefits from e-government failure)? [ TRAINEES & GROUP ]
• If trainees have limited experience, get them to read through some of the cases of failure found on the Categorised Cases page . They can use these cases to help them identify the impacts of failure. Then they can undertake activity ii. above. [ TRAINEES & GROUP ]

Part 3: What Causes eGovernment Projects To Succeed Or Fail?

1. Review the workshop findings to date (these are likely to be: that e-government failure is quite common; and that e-government failure causes problems). The next step, then, is to find out why some e-government projects fail (and others succeed). [ TRAINER ]
2. Explain that there is no agreement about why e-government projects succeed or fail: different people give different explanations. Here, the group will look at two possible explanations for success/failure. But these explanations might not be relevant to everyone's situation. Rather than treat them as 'the truth', better to see them as starting points for thinking and planning. [ TRAINER ]

Part 3a: Simple factor explanation for project success/failure

[c.70 mins]

1. Get trainees to read through the Factor Model page. [ TRAINEES ]
2. In pairs or small groups, get trainees to provide examples from their own experience so that they make up their own factor list. These examples can be: ones that match the critical success factors listed; ones that match the critical failure factors listed; other factors that do not appear on the Web page. [ GROUP ]
3. Discuss the match or mismatch between the list of factors on the Web page and the list of factors developed by the trainees. What does the group conclude about factors present in one list but absent in the other? What does the group conclude overall about the factor model: is this a model that is relevant and useful in its current form, or one that needs to be modified to make it relevant and useful (if so, how), or is it simply not relevant or useful in any form (if the latter, then later factor model activities can be ignored)? [ GROUP ]

Other Possible Activities:

• Alternatively, if you wish to give trainees a more open space for reflection, reverse the order of activities above. Start by getting trainees in small groups to reflect on, and list, the factors they feel bring success or failure to an e-government project. Then get them to compare their list to the one on the Factor Model page . Then facilitate a group discussion and conclusions about the match or mismatch between the factor lists. [ GROUP ]
• If trainees have limited experience, they can spend more time reading and/or discussing the linked case study examples found on the Factor Model page . [ TRAINEES/GROUP ]
• If trainees have limited experience and/or you wish trainees to build their own list of success/failure factors from case material, then replace activities i. and ii. above by allocating each trainee group three or four of the 'eGov4Dev cases' (found on the Case List page ). The groups should read their cases, focusing particularly on the 'Enablers' and 'Constraints' sections. Each group's task is to synthesise the enablers into a list of - at most - five top critical success factors for e-government, and to synthesise the constraints into a list of - at most - five top critical failure factors for e-government. The group lists can then be brought together to form a single plenary list via group report-back.
• If trainees need additional confidence in handling success/failure factors, identify a short e-government case study (for example, you could choose one of the 'Other Recent Cases' or 'Other Cases' from the Case List page ). Then get trainees in small groups to identify which critical success factors and/or which critical failure factors were present in the chosen case. [ GROUP ]

Part 3b: Design-reality gap explanation for project success/failure

[c.70 mins]

1. Get trainees to read through the Design-Reality Gap Model page . [ TRAINEES ]
2. In pairs or small groups, get trainees to provide examples of design-reality gaps from their own experience. For experience of successful projects, do they find that there are mainly small gaps between design and reality? For experience of unsuccessful projects, do they find that are mainly large gaps between design and reality? Are there other dimensions that are missing from the ITPOSMO checklist? [ GROUP ]
3. Discuss the match or mismatch between the ideas of the model, and the experience of the trainees. What does the group conclude about design-reality gaps: is this an idea that is relevant and useful in its current form, or one that needs to be modified to make it relevant and useful (if so, how), or is it simply not relevant or useful in any form (if the latter, then later design-reality gap activities can be ignored)? [ GROUP ]

Other Possible Activities:

• If trainees have limited experience, they can spend more time reading and/or discussing the linked case study examples found on the Design-Reality Gap Model page . [ TRAINEES/GROUP ]
• If trainees need additional confidence in handling design-reality gaps, identify a short e-government case study (for example, you could choose one of the 'eGov4Dev Cases' or 'Other Recent Cases' or 'Other Cases' from the Case List page ). Then get trainees in small groups to identify the dimensions and size of design-reality gaps in the chosen case (note, unless the case is particularly detailed, trainees may be unable to identify all seven ITPOSMO dimensions). Discuss whether the overall size of gap relates to the reported outcome (success or failure) of the case. [ GROUP ]

Part 4: What To Do About eGovernment Failure: Implemented Projects

1. Explain that most e-government projects are failures, and that trainees need to take account of this in their e-government work. With that in mind, the workshop now moves on to look at some practical techniques trainees can use if involved with projects that have already been implemented. [ TRAINER ]

Part 4a. Was My eGovernment Project A Success Or A Failure?

[c.85 mins]

1. Get trainees to read through all five steps on the Project Assessment page . If necessary, discuss the steps in more detail. [ TRAINEES ]
2. Get trainees to work in pairs or small groups. Each pair/group should identify one implemented e-government project. Get them to undertake each of the five steps in turn. This often works best if one person (who has most experience of the chosen project) acts as the client, and the other group member(s) act as consultant(s) to that client. Those in the consulting role actually undertake the steps. Those in the client role answer the consultants' questions, and provide other active input as required. Each group should report back its assessment of the project - success, failure or something in-between. [ GROUP ]
3. In small groups and/or plenary, get trainees to reflect on the assessment process. Did the five steps work? How would they do the assessment differently next time? [ GROUP ]

Other Possible Activities:

• If trainees lack sufficient depth of project knowledge and/or the trainer wishes to have all trainees focus on the same case, the trainer can develop their own case study, ensuring that sufficient data is provided to cover all five of the assessment steps. Some of the cases provided on the Cases page , could be used as the basis for such a case study. Trainees then complete activities i.-iii. as above. [ GROUP ]

Part 4b. Why Did My eGovernment Project Fail: Factor Model

[c.110 mins]

1. Get trainees to review the Failure Evaluation page . Then get trainees to read through the Factor Model Cause Identification page . [ TRAINEES ]
2. Get trainees to work in pairs or small groups on a real-world e-government failure case. Ideally, they should use a single real-world case with which all the group is familiar (e.g. one on which they are all currently employed). Alternatively, a text-based case must be prepared by the trainer: one of the Web site cases (found on the Cases page ) could be used as the basis for this. The trainees' task is to ask the ten factor questions in relation to the case, and give an answer rating for each factor. Either a table or diagram should be used to present the findings, like those used in the worked example on the Web page. On that basis, the group should identify what it feels are the most likely causes of failure in this case. [ GROUP ]
3. Get the groups to reflect on the approach they have just used, and then discuss questions such as: Was this a relevant and useful approach to understanding causes of failure? What were its strong and weak points? How would we do it differently next time? [ GROUP ]

Other Possible Activities:

• If trainees need greater focus on taking action to combat failure then, once they have identified the main causes of project failure, get the trainee groups to develop an action plan for addressing those causes, either on the selected case or on future e-government projects. [ GROUP ]

Part 4c. Why Did My eGovernment Project Fail: Design-Reality Gaps

[c.110 mins]

1. If they have not already done so, get trainees to review the Failure Evaluation page. Then get trainees to read through the Design-Reality Gap Cause Identification page, including at least one of the related case examples. [ TRAINEES ]
2. Get trainees to work in pairs or small groups on a real-world e-government failure case. Ideally, they should use a single real-world case with which all the group is familiar (e.g. one on which they are all currently employed). Alternatively, a text-based case must be prepared by the trainer: one of the Web site cases (found on the Cases page) could be used as the basis for this. The trainees' task is - taking each of the ITPOSMO dimensions in turn - to identify organisational reality just prior to implementation; to identify the design assumptions/requirements; and then to give a 0-10 rating for the design-reality gap on that dimension. A table should be used to present the findings. On that basis, the group should identify what it feels are the most likely causes of failure in this case. [ GROUP ]
3. Get the groups to reflect on the approach they have just used, and then discuss questions such as: Was this a relevant and useful approach to understanding causes of failure? What were its strong and weak points? How would we do it differently next time? [ GROUP ]

Other Possible Activities:

• If trainees need greater focus on taking action to combat failure then, once they have identified the main causes of project failure (i.e. the main design-reality gaps), get the trainee groups to develop an action plan for addressing those causes, either on the selected case or on future e-government projects. [ GROUP ]
• If trainees need to think more about adapting design-reality techniques to their particular situation, get the groups to discuss in turn each of the 'Variations' listed on the Design-Reality Gap Cause Identification page . The groups should draw up an action plan for modifying the design-reality gap technique in practice. [ GROUP ]
• If trainees need to select one particular approach to identification of failure causes then, if they have undertaken both Part 4b and Part 4c, get them to discuss the relative merits and demerits of each approach, and to select one for future use. They can provide justification for their selection in a plenary report-back. [ GROUP ]

Other Possible Activities:

If trainees need to understand and/or adopt a learning approach to e-government failure, then add an additional part:

Part 4d. How Can I Learn From My eGovernment Project's Failure?

• Get trainees to read through the four stages of learning from e-government failure on the Impacts of Failure page . [ TRAINEES ]
• Get the trainees, in small groups, to draw up an action plan explaining in more detail the structures and processes they would put in place in order to learn from e-government failure in future. Given time, present and discuss these action plans. [ GROUP ]
• Get trainees to read through the analysis of why learning from failure is so rare, on the Impacts of Failure page . Get the groups to amend their action plans to show how they would try to avoid some of the identified problems. Discuss these amendments in plenary session. [ TRAINEES & GROUP ]

Part 5: What To Do About eGovernment Failure: Planned/In-Progress Projects

1. Reminder that most e-government projects are failures, and that trainees need to take account of this in their e-government work. With that in mind, the workshop now moves on to look at some practical techniques trainees can use if involved with projects that are planned or that are in the middle of being implemented. [ TRAINER ]
2. Explain to the trainees that there are no panaceas to guard against e-government failure. If there were, then failure would have been banished long ago. Instead, there are just some ideas that some people may find feasible and effective (but some people may not). [ TRAINER ]

Part 5a. Assessing and Reducing Risks of eGovernment Failure: Design-Reality Gaps

[c.110 mins (i-ii) + 100 mins (iii-v)]

1. Get trainees to review the Risk Assessment page . Then get trainees to read through the Design-Reality Gap Risk Assessment page , including at least one of the related case examples. [ TRAINEES ]
2. Get trainees to work in pairs or small groups on a real-world e-government project that is planned or being implemented. Ideally, they should use a single real-world case with which all the group is familiar (e.g. one on which they are all currently employed). Alternatively, a text-based case must be prepared by the trainer: one of the Web site cases (such as those listed as "too early to evaluate" on the Cases page ) could be used as the basis for this. The trainees' task is - taking each of the ITPOSMO dimensions in turn - to identify organisational reality at present; to identify the design assumptions/requirements; and then to give a 0-10 rating for the design-reality gap on that dimension. A table or diagram, like those used in the worked example on the Web page, should be used to present the individual dimension gaps. The gaps for all the individual dimensions should be totalled, and compared to the results table on the Design-Reality Gap Risk Assessment page . On this basis, the group should draw conclusions about the likelihood of success or failure, and about the main sources of risk to the project. [ GROUP ]
3. Get trainees to read through the Design-Reality Gap Closure page , including at least one of the related case examples. [ TRAINEES ]
4. Assuming that the earlier group activity identified some potential sources of risk, get trainees to continue working in their existing groups on the same case. Based on their earlier identification of main sources (dimensions) of risk, the group should now make an action plan that directly addresses those dimensions through design-reality gap reduction. The plan should identify key generic and specific actions to take in order to reduce project risk and increase the likelihood of success. The group must show that any suggested actions are both desirable and feasible. [ GROUP ]
5. Get the groups to reflect on the approach they have just used, and then discuss questions such as: Was this a relevant and useful approach to assess and then reduce the risks of failure? What were its strong and weak points? How would we do it differently next time? [ GROUP ]

Other Possible Activities:

• If trainees need to think more about adapting design-reality techniques to their particular situation, get the groups to discuss in turn each of the 'Variations' listed on the Design-Reality Gap Risk Assessment page . The groups should draw up an action plan for modifying the design-reality gap technique in practice. [ GROUP ]
• If trainees need more practice with gap closure techniques, get trainee groups to read through one of the design-reality cases listed on the Cases page . Assess any gap closure recommendations that are made. Does the group agree with these? Are they both desirable and feasible? Are there other gap closure actions that could be taken?

Part 5b. Assessing and Reducing Risks of eGovernment Failure: Factor Model

[c.90 mins (i-ii) + 90 mins (iii-v)]

1. If they have not already done so, get trainees to review the Risk Assessment page. Then get trainees to read through the Factor Risk Assessment page, including the worked example. [ TRAINEES ]
2. Get trainees to work in pairs or small groups on a real-world e-government project that is planned or being implemented. Ideally, they should use a single real-world case with which all the group is familiar (e.g. one on which they are all currently employed). Alternatively, a text-based case must be prepared by the trainer: one of the Web site cases (such as those listed as "too early to evaluate" on the Cases page) could be used as the basis for this. The trainees' task is to ask the ten factor questions in relation to the case, and give an answer rating for each factor. A table or diagram, like those used in the worked example on the Web page, should be used to present the individual factor ratings. The rating scores for all the individual questions should be totalled, and compared to the results table on the Factor Risk Assessment page . On this basis, the group should draw conclusions about the likelihood of success or failure, and about the main sources of risk to the project. [ GROUP ]
3. Get trainees to read through the Factor Action Ideas page. They should also read all the individual factor ideas pages that relate to those factors identified as main sources of risk to the project. [ TRAINEES ]
4. Assuming that the earlier group activity identified some potential sources of risk, get trainees to continue working in their existing groups on the same case. Based on their earlier identification of main sources (factors) of risk, the group should now make an action plan that directly addresses those factors. The plan should identify key ideas and actions to take in order to reduce project risk and increase the likelihood of success. The group must show that any suggested actions are both desirable and feasible. [ GROUP ]
5. Get the groups to reflect on the approach they have just used, and then discuss questions such as: Was this a relevant and useful approach to assess and then reduce the risks of failure? What were its strong and weak points? How would we do it differently next time? [ GROUP ]

Other Possible Activities:

• If trainees need to think more about adapting factor risk assessment techniques to their particular situation, get the groups to discuss in turn each of the 'Variations' listed on the Factor Risk Assessment page . The groups should draw up an action plan for modifying the factor risk assessment technique in practice. [ GROUP ]
• If trainees need more practice drawing out action points from real-world cases, divide the trainees into small groups. Allocate three or four of the 'eGov4Dev cases' (found on the Case List page ) to each group. The group should focus mainly on the 'Recommendations' section of each case. Their task is to synthesise all the recommendations into a list of - at most - five top recommendations for e-government project success. If possible, they can identify which of the eight success/failure factors (found on the Factor Action Ideas page ) each one of their recommendations relates to. [ GROUP ]
• If trainees need to select one particular approach to assess and reduce risks of e-government project failure then, if they have undertaken both Part 5a and Part 5b, get them to discuss the relative merits and demerits of each approach, and to select one for future use. They can provide justification for their selection in a plenary report-back. [ GROUP ]
• If trainees need a wider selection of risk assessment techniques, get trainee groups to investigate the other Risk Assessment Models. Each group should present and justify which risk assessment technique (including design-reality gap and factor analysis) it sees as most effective, and should draw up an action plan for implementation of the technique. [ GROUP ]

Part 6: Action Plans

[c.25 mins]

1. Get trainees to write down three key learning points from this workshop (i.e. the three most important things they feel they have learned from the workshop) and three key action points (i.e. three actions they wish to take on their return to the workplace as a result of undertaking this training). [ GROUP ]
2. Summarise some of the overall issues that have emerged from the workshop, and identify any "next steps". [ TRAINER ]

Other Possible Activities:

• If trainees need to get feedback on their personal action points, get trainees to share and discuss learning and action points with one other person and/or get trainees to share and discuss learning and action points in a plenary report-back. [ GROUP ]
• If generic or group action points need to be identified, get trainees to discuss further training or other generic action needs arising from the training workshop. [ GROUP ]
• If this training workshop needs to be evaluated, get trainees to fill in (and possibly discuss) an evaluation form. A simple evaluation form asks just four questions: "What was good about this workshop, that we should retain if we repeat the workshop?"; "What was not so good about this workshop, that we should change if we repeat the workshop?"; "What was missing from this workshop, that we should add if we repeat the workshop?"; "Any other comments?". [ GROUP ]