1. Why should the public sector want to innovate?
H.W
Why should the public sector want to innovate?

2. analysis of what is currently happening, and
7.1 THE SYSTEM LIFECYCLE E-Government System Lifecycle and Project Assessment
Innumerable methods for systems development have been created, with a variance here or there, but all of them correspond more or less to four core stages:
analysis of what is currently happening, and
of whether and why a new e-government
system is needed;

3. Design of the new e-government system’s
components;
construction of the new e-government
system;
Implementation of the new e-government
system.

4. Any e-government systems project seeks to create a new situation that is different from the current one. The greater the difference between the new and current situations, the greater the degree of change that is required.
The core of the systems development method described here will consist of three activities:
Mapping out the realities of the current situation
Designing a proposal for the new situation
Assessing the difference between the two
Reacting to that difference.

5. The design–reality differences could be
assessed on each and every one of the elements listed in the onion-ring model of systems, these dimensions are:
Information
Technology
Processes
Objectives and values
Staffing and skills
Management systems and structures
Other resources: money and time

6. The outline can be described as a set of five stages:
Project assessment: Identifying possible e-government projects; outlining basic project parameters; and assessing whether or not to proceed with the project
Analysis of current reality: d
escription and analysis of the seven dimensions as they exist within the current situation of the organization.
Design of the proposed new situation: Setting objectives for the proposed new e-government system, and then describing in general terms how the seven dimensions should be different for the new system to meet these
objectives.
System construction: Acquiring any new technology; undertaking detailed design of the new system; then building it, testing it and documenting it.
Implementation and beyond: Training users to use the new system; converting data to new formats; introducing the new system; monitoring and evaluating its performance and context; then undertaking any necessary system maintenance.
Read Textbook ) from page 159)

8. Gathering Information on the Project
who, what, why – approach
Stakeholder Analysis: Who is Involved?
‘Who has the power/ability to make the project and system fail in some way?’
Project manager/team: Those who will analyze, design and build the e-government system.
Supplier(s): Those who will supply the technology and other resources required by the e-government system.
Operators: Those who will be carrying out the activities/processes that make the e-government system work.
Clients: Primary clients are on the immediate receiving end of what the e-government system does or outputs. Sometimes these will be outside government (e.g. citizens or businesses).

9. Champion(s): The person (or group) who drives the project on and seeks to justify its implementation. • Sponsor(s): The person (or group) who pays for the expense and effort required to develop the new e-government system. • Owner: The manager of the organization or department that will own and use the system, who is ultimately responsible for the system. • Other stakeholders: Who have a significant influence on the project or on whom the project will have a significant influence. Problem Statement: What is the Problem? It is likely that most e-government systems are currently driven by a perceived problem rather than a perceived opportunity. It may, therefore, be useful to create a problem statement: a single sentence that tries to encapsulate who or what the problem relates to, and what exactly is wrong, without trying to define a solution.

10. Project Rationale: Why?
This is a simple definition, possibly in a single sentence, of the main objective for the new e-government system sought by the most powerful stakeholders. In most situations it would relate to alleviating the previously
identified problem (or making use of the identified opportunity).
Constraint Analysis: What Constraints?
Driver analysis – particularly of political and personal drivers – helps you understand what pushes an e-government project
forwards. Constraint analysis helps you understand the roadblocks that hold an e-government project back.
Constraints will vary from situation to situation. You can use the ITPOSMO checklist to identify these

11. Using Design–Reality/ITPOSMO model to the process of e-government implementation.
Design Vs. Reality

13. Technology: What technical infrastructure (telecommunications, computer systems, etc.) is/is not available that the project
may require?
• Objectives and values: Based on the stakeholder analysis and the subsequent set of questions, what support is?
• Staffing and skills: How many/how few people could work on this project? What skills are available/not available that are likely to be relevant to this project?
• Other resources: How much/how little money is available for this project? How much/how little time is available for this project? Is there a deadline?
• Other dimensions: What other constraints exist that will affect this project (government guidelines; quality of existing data; flexibility of current
procedures; and so on)?

14. Entity Relation
1:1
1:M
M: N

16. Design of the New eGovernment System
successful approach to e-government design must therefore be a hybrid approach: one that encompasses both hard and soft elements; in other words, all of the ITPOSMO dimensions

17. This chapter will cover six main dimensions of change within five overall design headings ( page 192)
Objectives
• Information
• Technology
• Processes;
• Human systems (staffing, skills and management).
Note : Estimations of required time and money

18. 1. Setting objective
Most projects will require a set of objectives to work to. Taking account of the framework of constraints and future changes, these can be based on the previous problem statement, project rationale statement, problem analysis and/or personal objective setting. E-government objectives are made SMART Keeping objectives simple and flexible may also increase the chances that those objectives are met.
2. NFORMATION DESIGN
How will information outputs meet system objectives?
What information will they require to be output from the system?
Users record details of the questions they need answering
Structured interviews: Questioning users on critical success factors for a particular government system, on overall information priorities and needs, on main issues of concern and problems, and getting users to review existing outputs from a
data quality (CARTA: completeness, accuracy, relevance, timeliness, appropriateness of presentation) point of view.
Prototyping to see what information content users want

19. 3. TECHNOLOGY DESIGN
In designing the IT component of an e-government system, software is typically the first focus because it is software that actually does the work. If hardware is designed first, there is a danger that it will not be able
to run the necessary software.
Software
Type of Application, Method of Software Development : ( ex: Custom application) and Operating System
Hardware
Computer Size and Specialist Hardware
4. PROCESS DESIGN
This involves thinking through alternative ways in which organizational processes can meet stated objectives, and selecting one set of alternatives.
5. HUMAN SYSTEMS DESIGN
Process design phase focused on what is to be done.
This phase focuses on how it is to be done, and by whom