0
ARCHITECTING EGOVERNANCE SPACE Prof. K. Subramanian Professor & Director Advanced Center for Informatics & Innovative Lear...
PRINCIPLES OF  GOOD GOVERNANCE <ul><li>Leadership </li></ul><ul><li>Selflessness </li></ul><ul><li>Integrity </li></ul><ul...
E-GOVERNMENT IS EVOLUTIONARY  NAMING IS EVOLUTIONARY,  E-GOVERNANCE IS YET TO TAKE OFF <ul><li>fficient Government …   Eff...
FOUR MANTRAS OF GOOD DIGITAL GOVERNANCE <ul><li>From Vision   Mission   Implementation-->Impact study->Improvisation- Le...
UNDERLYING FOUNDATIONS OF ARCHITECTING EGOV SPACE <ul><li>Undertake a Structured eGovernment Strategy Exercise </li></ul><...
FOUR DIMENSIONS OF EGOV <ul><li>The information dimension  : the system design assumed that its creation of formal strateg...
FIVER TIER ARCHITECTURE FOR EGOV SPACE <ul><li>Data Architecture :  </li></ul><ul><ul><li>an overall plan for the data ite...
COMPETENCES REQUIRED FOR EGOV PROJECTS PLANNING <ul><li>Skills,  </li></ul><ul><li>Knowledge  </li></ul><ul><li>Attitudes....
NEEDED COMPETENCIES <ul><ul><li>Systems Development Competencies  </li></ul></ul><ul><ul><li>Project/Change Management Com...
Emerging Technologies -Competitive Environments &  Integration Catering through ICE Technologies 1.  IT 2. BT 3. CT 4. ET ...
TECHNOLOGY SELECTION FOR EGOV PROJECTS <ul><li>Should not be the Leading Edge(Bleeding edge as it is vendor driven) </li><...
TECHNIQUES & REQUIREMENT ENGINEERING/ARCHITECTING THE EGOV SOLUTION SPACE <ul><li>An Overall Vision/Strategy for eGovernme...
GOOD GOVERNANCE STRENGTHENING INTEGRATION OF MULTI-STAKEHOLDERS <ul><li>Operational Integration </li></ul><ul><li>Professi...
IDEA 1: UNDERTAKE A STRUCTURED EGOVERNMENT STRATEGY EXERCISE
IDEA 2: ENSURE YOUR EGOV STRATEGY HAS A SOUND UNDERLYING ARCHITECTURE  <ul><li>Data architecture: an overall plan for the ...
IDEA 3: CREATE A SINGLE HIGH-LEVEL STRATEGIC BODY  <ul><li>This body - of senior staff and other powerful stakeholders - c...
IDEA 4: DON'T LET STRATEGY BECOME DETACHED FROM LOCAL REALITIES  <ul><li>In an overall sense, e-government strategy asks t...
IDEA 5: SET CLEAR &quot;GO/NO GO&quot; CRITERIA  <ul><li>Thinking in a high-level, strategic manner, work out a set of cri...
IDEA 6: MAKE YOUR EGOVERNMENT VISION CLEAR, COLLECTIVE, CHALLENGING AND CUSTOMISED  <ul><li>A good e-government strategy w...
IDEA 7: THE OBJECTIVES OF EGOVERNMENT STRATEGY SHOULD BE BETTER GOVERNMENT  <ul><li>In one or two states in India, for exa...
IDEA 8: DO SOMETHING  <ul><li>Don't become so wrapped up in visions and strategies that you never actually do anything.  A...
AVOIDING EGOV FAILURE:  IDEAS ABOUT PROJECT MANAGEMENT  <ul><li>Idea 1: Use Project Management Software  </li></ul><ul><li...
AVOIDING EGOV FAILURE:  IDEAS ABOUT PROJECT MANAGEMENT  <ul><li>Idea 2: Move From Democrat To Autocrat  </li></ul><ul><li>...
AVOIDING EGOV FAILURE:  IDEAS ABOUT PROJECT MANAGEMENT  <ul><li>Idea 3: Set Clear &quot;Go/No Go&quot; Criteria For The eG...
AVOIDING EGOV FAILURE:  IDEAS ABOUT PROJECT MANAGEMENT  <ul><li>Idea 5: It's Never Too Late To Stop  </li></ul><ul><li>Sto...
AVOIDING EGOV FAILURE: IDEAS ABOUT CHANGE MANAGEMENT  <ul><li>Idea 1: Your Project Must Ask And Answer The &quot;What's In...
IDEA 2: STAKEHOLDER INVOLVEMENT IS A MUST  <ul><li>The Cameroon government initiated the SIGIPES project: introducing e-go...
IDEA 3: PROJECTS NEED LEADERS AS WELL AS MANAGERS  <ul><li>Leadership and management are not the same thing:  </li></ul><u...
THE FACTOR MODEL <ul><li>The Factor Model identifies a set of ten key factors:  </li></ul><ul><ul><li>external pressure,  ...
DESIGN-REALITY GAP MODEL <ul><li>identifies a gap that exists for all e-government projects between the design assumptions...
IDEA 1: ATTUNE THE PROJECT TO POLITICAL CYCLES  <ul><li>Everyone complains that e-government projects suffer from politica...
IDEA 2: DON'T IGNORE SELF-INTEREST  <ul><li>Everyone involved in the e-government project will be motivated to a greater o...
IDEA 3: EGOVERNMENT IS A CHESS GAME  <ul><li>Picture the e-government project as a chess game. Ask yourself - what piece a...
AVOIDING EGOV FAILURE: IDEAS ABOUT DESIGN  IDEA 1: PROTOTYPE AND / OR PILOT YOUR PROJECT  <ul><li>Taking project requireme...
AVOIDING EGOV FAILURE: IDEAS ABOUT DESIGN  IDEA 2: STAKEHOLDER INVOLVEMENT IS A MUST  <ul><li>The Cameroon government init...
AVOIDING EGOV FAILURE: IDEAS ABOUT COMPETENCIES  IDEA 1: ADDRESS THE WHOLE RANGE OF NEEDED COMPETENCIES <ul><li>Competenci...
AVOIDING EGOV FAILURE: IDEAS ABOUT COMPETENCIES IDEA 2: IDENTIFY AND DEVELOP THE NEEDED COMPETENCIES  <ul><li>4 Components...
AVOIDING EGOV FAILURE: IDEAS ABOUT DESIGN  <ul><li>Idea 1: Prototype And/Or Pilot Your Project  </li></ul><ul><li>Taking p...
AVOIDING EGOV FAILURE:  IDEAS ABOUT TECHNOLOGICAL INFRASTRUCTURE  <ul><li>Idea 1: Avoid The &quot;Bleeding Edge&quot;  </l...
AVOIDING EGOV FAILURE:  IDEAS ABOUT TECHNOLOGICAL INFRASTRUCTURE  <ul><li>Idea 2: Who Will Fix The Technology When It Goes...
AVOIDING EGOV FAILURE:  IDEAS ABOUT TECHNOLOGICAL INFRASTRUCTURE  <ul><li>Idea 3: Technology Facts, Not Dreams  </li></ul>...
AVOIDING EGOV FAILURE:  IDEAS ABOUT EXTERNAL & INTERNAL DRIVERS  <ul><li>Idea 1: Balance External And Internal Drivers  </...
AVOIDING EGOV FAILURE:  IDEAS ABOUT EXTERNAL & INTERNAL DRIVERS  <ul><li>Idea 2: Meet A Senior Official's Agenda  </li></u...
03/10/08 Suny BUFF Lecture 27th Nov 2007 Assurance in the PPP Environment
ENABLING TO RAPIDLY MOVE UP THE  E-GOVERNANCE EVOLUTION STAIRCASE Strategy/Policy People Process Technology 3. Transaction...
06/29/06 NPC Sikkim  May 2006
Thank you <ul><li>FOR FURTHER INFORMATION PLEASE CONTACT :- </li></ul><ul><li>E-MAIL:  [email_address] </li></ul><ul><li>[...
Upcoming SlideShare
Loading in...5
×

Architecting E Governance Space Npc Lecture Feb 2009

648

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
648
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Transcript of "Architecting E Governance Space Npc Lecture Feb 2009"

    1. 1. ARCHITECTING EGOVERNANCE SPACE Prof. K. Subramanian Professor & Director Advanced Center for Informatics & Innovative Learning, IGNOU Consulting IT Adviser to CAG of India EX. DDG(NIC), Ministry of Comm. & IT
    2. 2. PRINCIPLES OF GOOD GOVERNANCE <ul><li>Leadership </li></ul><ul><li>Selflessness </li></ul><ul><li>Integrity </li></ul><ul><li>Objectivity </li></ul><ul><li>Accountability </li></ul><ul><li>Openness </li></ul><ul><li>Honesty </li></ul><ul><li>Humane Governance </li></ul><ul><li>Should be Creative </li></ul><ul><li>Uses Knowledge for National Wealth and Health creation </li></ul><ul><li>Understands the economics of Knowledge </li></ul><ul><li>High Morality </li></ul>
    3. 3. E-GOVERNMENT IS EVOLUTIONARY NAMING IS EVOLUTIONARY, E-GOVERNANCE IS YET TO TAKE OFF <ul><li>fficient Government … Effective Government … Open Government … Joined-up Government.. Connected Government </li></ul>e-Government is evolutionary, Naming is evolutionary, e-Governance is yet to Take off
    4. 4. FOUR MANTRAS OF GOOD DIGITAL GOVERNANCE <ul><li>From Vision  Mission  Implementation-->Impact study->Improvisation- Leadership & Alignment </li></ul><ul><li>Projects  Formulate, Architect, Design & Construct, Comprehensive Multi-tier Review, Monitoring & Feedback control </li></ul><ul><li>Collaborate, Communicate, Cooperate, Co-work & co-exist </li></ul><ul><li>Logical Process Integration (ERP) superimposed with BI makes the Enterprise a creative and Innovative  A mature accountable, transparent and Open Government </li></ul>06/09/09
    5. 5. UNDERLYING FOUNDATIONS OF ARCHITECTING EGOV SPACE <ul><li>Undertake a Structured eGovernment Strategy Exercise </li></ul><ul><li>Ensure Your eGov Strategy has a Sound Underlying Architecture </li></ul><ul><li>Create a Single High-Level Strategic Body (create synergy and convergence of vision & mission in inter & intra departments of govt. for Development) </li></ul><ul><li>Don't Let Strategy Become Detached From Local Realities(participation of constituents in the system design requirements) </li></ul><ul><li>Advocate & Implement Project Governance & Management Principles. </li></ul><ul><li>Make Your eGovernment Vision Clear, Collective, Challenging and Customised </li></ul><ul><li>The Objectives of eGovernment Strategy Should be Better SMART( simple, moral, accountable, responsive and transparent) Government </li></ul><ul><li>Vision-Mission-Implementation-Feedback & Correction- Sustenance with One Nation(INDIA ONE) & One Government </li></ul><ul><li>For the People-By the People- Of the People </li></ul>
    6. 6. FOUR DIMENSIONS OF EGOV <ul><li>The information dimension : the system design assumed that its creation of formal strategic information would be of value to Ministry functioning.  In reality, informal information and gut feelings were what decision makers valued and used. </li></ul><ul><li>The process dimension : the system design assumed that a rational model of structured decision-making held sway within the Ministry.  This mismatched the dominant reality of personalised, even politicised, unstructured decision-making. </li></ul><ul><li>The objectives and values dimension : the system was designed within, and reflecting, a scientific environment which had a 'role culture' that valued rules and logic.  In reality, it was to be used in a political environment which had a 'power culture' that valued self-interest and hidden agendas. </li></ul><ul><li>The management systems and structures dimension : the system was designed for an organisation that had both structures and systems to support strategic decision making.  In reality, such structures and systems did not exist within the Ministry. </li></ul>
    7. 7. FIVER TIER ARCHITECTURE FOR EGOV SPACE <ul><li>Data Architecture : </li></ul><ul><ul><li>an overall plan for the data items (and their relationships) necessary to deliver e-government. </li></ul></ul><ul><li>Process Architecture : </li></ul><ul><ul><li>a plan of the key activities that e-government will support and undertake . </li></ul></ul><ul><li>Technology Architecture : </li></ul><ul><ul><li>how computers will be sized and connected for e-government, and an outline of the software to be used . </li></ul></ul><ul><li>Data Management Architecture : </li></ul><ul><ul><li>how data input, processing, storage and output functions will be divided across the information technology architecture . </li></ul></ul><ul><li>Management Architecture : </li></ul><ul><ul><li>the policies, standards, human resource systems, management structures, financial systems, etc. necessary to support e-government. </li></ul></ul><ul><li>To create a building, you need a sound underlying architecture for that building, based on an architect's plan.  The same is true for e-government.   </li></ul>
    8. 8. COMPETENCES REQUIRED FOR EGOV PROJECTS PLANNING <ul><li>Skills, </li></ul><ul><li>Knowledge </li></ul><ul><li>Attitudes. </li></ul><ul><li>All three of these must be in Planning the </li></ul><ul><li>e-government project . </li></ul>
    9. 9. NEEDED COMPETENCIES <ul><ul><li>Systems Development Competencies </li></ul></ul><ul><ul><li>Project/Change Management Competencies </li></ul></ul><ul><ul><li>Intelligent Customer Competencies </li></ul></ul><ul><ul><li>Operational Competencies . </li></ul></ul>
    10. 10. Emerging Technologies -Competitive Environments & Integration Catering through ICE Technologies 1. IT 2. BT 3. CT 4. ET 5. NT 6. ST 1. Operational Integration 2. Professional Integration (HR) 3. Emotional/Cultural Integration ICE is the sole integrator & IT/Cyber Governance is Important <ul><li>Selection of Technologies </li></ul><ul><li>Affordable </li></ul><ul><li>Acceptable </li></ul><ul><li>Sustainable </li></ul><ul><li>Reliable </li></ul>
    11. 11. TECHNOLOGY SELECTION FOR EGOV PROJECTS <ul><li>Should not be the Leading Edge(Bleeding edge as it is vendor driven) </li></ul><ul><li>Should not be Outdated( e dumping, difficult to maintain and sustain) </li></ul><ul><li>Based on the connectivity levels and technological standards available right now. </li></ul><ul><li>Work with & connect directly to all end users </li></ul><ul><li>rather than intermediaries. </li></ul><ul><li>1. Prototype And / Or Pilot Your Project Making the design match real user needs, and by making users more realistic in their expectations of the system. </li></ul><ul><li>2. Stakeholder Involvement Is A Must general staff, including administrators and other lower-/middle-level system users, were involved with the project. Their ideas were incorporated into the design, ensuring that the design did meet the real - rather than imagined - needs of these key stakeholders. </li></ul>
    12. 12. TECHNIQUES & REQUIREMENT ENGINEERING/ARCHITECTING THE EGOV SOLUTION SPACE <ul><li>An Overall Vision/Strategy for eGovernment </li></ul><ul><li>Project Management for eGovernment </li></ul><ul><li>Change Management for eGovernment </li></ul><ul><li>Politics/Self-Interest in eGovernment </li></ul><ul><li>Design of eGovernment Applications </li></ul><ul><li>Competencies (Skills, etc.) for eGovernment </li></ul><ul><li>Technological Infrastructure for eGovernment </li></ul><ul><li>External and Internal Drive for eGovernment </li></ul>eGovernment projects need managers, but they also need leaders as well
    13. 13. GOOD GOVERNANCE STRENGTHENING INTEGRATION OF MULTI-STAKEHOLDERS <ul><li>Operational Integration </li></ul><ul><li>Professional Integration (HR) ‏ </li></ul><ul><li>Emotional/Cultural Integration </li></ul><ul><li>ICT & Government Business & Services Integration </li></ul><ul><li>Multi Technology co- existence and seamless integration </li></ul><ul><li>Information Assurance </li></ul><ul><li>Quality, Currency, Customization/Personalization </li></ul>06/09/09
    14. 14. IDEA 1: UNDERTAKE A STRUCTURED EGOVERNMENT STRATEGY EXERCISE
    15. 15. IDEA 2: ENSURE YOUR EGOV STRATEGY HAS A SOUND UNDERLYING ARCHITECTURE <ul><li>Data architecture: an overall plan for the data items (and their relationships) necessary to deliver e-government. </li></ul><ul><li>Process architecture: a plan of the key activities that e-government will support and undertake. </li></ul><ul><li>Technology architecture: how computers will be sized and connected for e-government, and an outline of the software to be used. </li></ul><ul><li>Data management architecture: how data input, processing, storage and output functions will be divided across the information technology architecture. </li></ul><ul><li>·Management architecture: the policies, standards, human resource systems, management structures, financial systems, etc. necessary to support e-government. </li></ul>
    16. 16. IDEA 3: CREATE A SINGLE HIGH-LEVEL STRATEGIC BODY <ul><li>This body - of senior staff and other powerful stakeholders - can take responsibility for functions such as scoping and commissioning an e-government strategy; prioritising particular e-government projects; ensuring necessary resources are in place to deliver projects; and monitoring progress in e-government. </li></ul><ul><li>Where such a body is set up with a view across the whole of government, it can also have a coordination function - ensuring some degree of inter-operability between independently-developed e-government applications, assisting reusability of solutions to avoid 'reinventing the wheel', and generally facilitating learning across e-government projects </li></ul>
    17. 17. IDEA 4: DON'T LET STRATEGY BECOME DETACHED FROM LOCAL REALITIES <ul><li>In an overall sense, e-government strategy asks three questions: </li></ul><ul><ul><li>&quot;Where are we now?&quot; (Here) </li></ul></ul><ul><ul><li>&quot;Where do we want to get to?&quot; (There) </li></ul></ul><ul><ul><li>&quot;How do we get from here to there?&quot; </li></ul></ul><ul><li>The danger is that asking such questions ignores local realities, creating a hypothetical vision of &quot;There&quot; that can never be achieved.  Government is only one player: rather than thinking it can design its environment, it should instead design TO its environment.  This means infusing question 1 with a sense of where clients (e.g. local citizens, local businesses, local communities, local NGOs, local agencies) currently are: their current rates of ICT access and use; their current needs; their current priorities.  It means infusing question 2 with a true sense of where those clients are headed: forecast trends in ICTs, needs, priorities, etc.  By doing this, you create a realistic rather than idealistic e-government strategy . </li></ul><ul><li>Where e-government strategy does not take the local environment into account, problems will arise.  e-government strategy designs must take good account of existing realities </li></ul><ul><ul><li>An ambitious strategy for e-government in Central Africa failed to take account of local realities: funding limitations, infrastructural constraints, mismatch with objectives of key players, problems of theft of equipment.  The result was a failed strategy.  </li></ul></ul><ul><ul><li>In some Indian states, too, e-government strategy has been a top-down, techno-centric exercise that neglects the social, economic and cultural realities of intended client groups.  Such strategies are self-defeating disasters . </li></ul></ul>
    18. 18. IDEA 5: SET CLEAR &quot;GO/NO GO&quot; CRITERIA <ul><li>Thinking in a high-level, strategic manner, work out a set of criteria for decision-making about e-government projects.  </li></ul><ul><li>What criteria will you use to decide whether or not an e-government project should be supported and funded?  </li></ul><ul><li>What criteria will you use to decide that a project - once funded - will be abandoned? </li></ul>
    19. 19. IDEA 6: MAKE YOUR EGOVERNMENT VISION CLEAR, COLLECTIVE, CHALLENGING AND CUSTOMISED <ul><li>A good e-government strategy will have the following features.  It will be clear: ordinary citizens will understand what it seeks to achieve.  It will be collective: shared by the key stakeholders involved (and probably developed collectively in order to meet that criterion).  It will be challenging: not so optimistic as to be unrealistic, not so pessimistic as to be uninspiring: one watchword is </li></ul><ul><li>&quot;Think Big, Start Small, Scale Fast&quot;.  </li></ul><ul><li>It will be customised: matched to specific local conditions. </li></ul>
    20. 20. IDEA 7: THE OBJECTIVES OF EGOVERNMENT STRATEGY SHOULD BE BETTER GOVERNMENT <ul><li>In one or two states in India, for example, e-government is seen as the servant of broader good governance objectives.  Put another way, e-government is seen as a means, not as an end in itself.  The end specified in some cases is SMART government: government that is simple, moral, accountable, responsive and transparent. </li></ul>
    21. 21. IDEA 8: DO SOMETHING <ul><li>Don't become so wrapped up in visions and strategies that you never actually do anything.  And don't let strategy-making be an excuse for inaction.  Small, useful e-government projects can proceed alongside strategy, and can create knowledge that feeds into strategy-making. </li></ul>
    22. 22. AVOIDING EGOV FAILURE: IDEAS ABOUT PROJECT MANAGEMENT <ul><li>Idea 1: Use Project Management Software </li></ul><ul><li>Familiarise yourself with one of the common project management software packages. Even if you don't use this perfectly, it will 'set the tone' for the project. It will make project management seem tangible. It will help nudge project decision-making a little away from the subjective/personal, and a little towards the objective. It will provide diagrammatic guidance for project decisions. </li></ul>
    23. 23. AVOIDING EGOV FAILURE: IDEAS ABOUT PROJECT MANAGEMENT <ul><li>Idea 2: Move From Democrat To Autocrat </li></ul><ul><li>Plan the e-government project and the application design in a democratic and participative manner - taking account of all stakeholder views and seeking to achieve consensus. In moving from this design phase to the implementation phase, change from democrat to autocrat. Implementation requires listening and communication, but it can become mired in delays if everyone's view must be taken into account, and consensus always reached. Sometimes, it needs strong and authoritative leadership to push the implementation to completion. </li></ul>
    24. 24. AVOIDING EGOV FAILURE: IDEAS ABOUT PROJECT MANAGEMENT <ul><li>Idea 3: Set Clear &quot;Go/No Go&quot; Criteria For The eGov Project </li></ul><ul><li>Have some guidelines for the most major decisions about the project - the decisions about whether to continue or not continue with the project. At the start, determine what criteria you will use at various decision points within the project to decide whether to proceed with the project, and whether to abandon it. </li></ul><ul><li>Idea 4: Project Management Is Not The Same As Other Management </li></ul><ul><li>Just because Jo Bloggs can run your IT service, it does not mean that she can run your e-government project. Project managers manage projects, they don't run departments or services or systems - in fact, if a manager is good at running a department or service, s/he may well not be a good project manager (and vice versa) </li></ul>
    25. 25. AVOIDING EGOV FAILURE: IDEAS ABOUT PROJECT MANAGEMENT <ul><li>Idea 5: It's Never Too Late To Stop </li></ul><ul><li>Stopping an e-government project is incredibly difficult - they rapidly gather political, financial, technical and emotional momentum. However, stopping a project - even at a late stage - is often a better decision for the organisation (at least in rational terms). It may be cheaper and better to abandon the project than to &quot;throw good money after bad&quot;. This will particularly be true IF you can use the abandoned project as a source of knowledge-building, helping you to create a better project next time round. However, this is a big &quot;if“. </li></ul>
    26. 26. AVOIDING EGOV FAILURE: IDEAS ABOUT CHANGE MANAGEMENT <ul><li>Idea 1: Your Project Must Ask And Answer The &quot;What's In It For Me?&quot; Question For All Key Stakeholders </li></ul><ul><li>Key stakeholders - funders, managers, operators, users, clients, etc - must support (passively or, ideally, actively) the e-government project. For any human to support a project, that project must align with at least some of their personal goals and values. Put more simply, the e-government project must provide each stakeholder with at least some positive answer to the question we all ask of any project: &quot;What's in it for me?&quot;. The process of change management must ensure that this question is asked for all key stakeholders, and the answer incorporated into the project design or implementation process. </li></ul><ul><li>In Gujarat state in India, efforts were being made to roll out a wide area network. The project management process asked the &quot;What's in it for me?&quot; question on behalf of key stakeholders. The answer was: &quot;Free access to email&quot;, &quot;Free access to the Web and Internet&quot;, and &quot;Free access to long-distance, inter-agency telephony&quot;. These answers were incorporated into project design, leading to high levels of project acceptance and use: far higher than could have been achieved through training or through empty exhortations to use the network </li></ul>
    27. 27. IDEA 2: STAKEHOLDER INVOLVEMENT IS A MUST <ul><li>The Cameroon government initiated the SIGIPES project: introducing e-government 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. </li></ul>
    28. 28. IDEA 3: PROJECTS NEED LEADERS AS WELL AS MANAGERS <ul><li>Leadership and management are not the same thing: </li></ul><ul><li>&quot;The difference between leadership and management”  </li></ul><ul><ul><li>'Imagine there's a sudden power failure on the Metro - The system halts and all the lights go out. In the central control room someone is marshalling resources, implementing the standby facilities, rescheduling the trains, calling the emergency services . That's management . </li></ul></ul><ul><ul><li>Someone else is walking along the darkened platform with a torch bringing a trainload of people to safety . That's leadership.'&quot; </li></ul></ul><ul><li>eGovernment projects need managers, but they also need leaders as well. </li></ul>
    29. 29. THE FACTOR MODEL <ul><li>The Factor Model identifies a set of ten key factors: </li></ul><ul><ul><li>external pressure, </li></ul></ul><ul><ul><li>internal political desire, </li></ul></ul><ul><ul><li>overall vision/strategy, </li></ul></ul><ul><ul><li>project management, </li></ul></ul><ul><ul><li>change management, </li></ul></ul><ul><ul><li>politics/self-interest, </li></ul></ul><ul><ul><li>design, </li></ul></ul><ul><ul><li>competencies, </li></ul></ul><ul><ul><li>technological infrastructure, </li></ul></ul><ul><ul><li>Presence or absence of these factors will determine success or failure </li></ul></ul>
    30. 30. DESIGN-REALITY GAP MODEL <ul><li>identifies a gap that exists for all e-government projects between the design assumptions/requirements and the reality of the client public agency.  The larger this gap between design and reality, the greater the risk that the project will fail.  The smaller the gap, the greater the chance of success. </li></ul>
    31. 31. IDEA 1: ATTUNE THE PROJECT TO POLITICAL CYCLES <ul><li>Everyone complains that e-government projects suffer from political cycles - the four years between elections, or the two-year tenure of Ministers in particular posts, or the annual funding round. But these cycles are a fact of life that must be recognised and built into the project design. They mean - whatever the ultimate ambitions of the project - that it must show some fairly quick deliverables. </li></ul><ul><li>&quot;Think Big, Start Small, Scale Fast&quot; was specifically matches the political realities of e-government. There are also advantages of this approach - they make unworkable leviathan projects less likely, and they encourage an incremental approach that has been shown to be more successful than &quot;Big Bang&quot; methods. --(From: Richard Heeks) </li></ul>
    32. 32. IDEA 2: DON'T IGNORE SELF-INTEREST <ul><li>Everyone involved in the e-government project will be motivated to a greater or lesser extent by self-interest. Recognising this - either explicitly or implicitly - will be a key to project success. One implication is to ensure that the project meets some element of self-interest for all main stakeholders. See the &quot;What's in it for me?&quot; idea on Change Management . --From: Richard Heeks & RK Dave) </li></ul>
    33. 33. IDEA 3: EGOVERNMENT IS A CHESS GAME <ul><li>Picture the e-government project as a chess game. Ask yourself - what piece am I? Are you the all-powerful queen, a middle-ranking bishop, or just a lowly pawn? If you are one of the lesser pieces in the game, you will face problems unless you can find a powerful ally: the equivalent of a rook or queen in chess. If you have trouble from middle-ranking stakeholders, ask yourself if there's a more powerful player that you can bring in - a senior official, a politician, an external agency, a donor organisation, etc. –Richard Heeks </li></ul>
    34. 34. AVOIDING EGOV FAILURE: IDEAS ABOUT DESIGN IDEA 1: PROTOTYPE AND / OR PILOT YOUR PROJECT <ul><li>Taking project requirements, disappearing off to a darkened room for several months, and then implementing the entire e-government 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-government project success by making the design match real user needs, and by making users more realistic in their expectations of the system. </li></ul><ul><li>Second, this can involve piloting - typically implementing the e-government system at a single site; observing, learning and revising 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. (From: Richard Heeks) </li></ul>
    35. 35. AVOIDING EGOV FAILURE: IDEAS ABOUT DESIGN IDEA 2: STAKEHOLDER INVOLVEMENT IS A MUST <ul><li>The Cameroon government initiated the SIGIPES project: introducing e-government 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, ensuring that the design did meet the real - rather than imagined - needs of these key stakeholders. </li></ul><ul><li>(From: Olivier Kenhago) </li></ul>
    36. 36. AVOIDING EGOV FAILURE: IDEAS ABOUT COMPETENCIES IDEA 1: ADDRESS THE WHOLE RANGE OF NEEDED COMPETENCIES <ul><li>Competencies required for an e-government project cover three things - skills, knowledge and attitudes. All three of these must be addressed in planning the e-government project. Development of skills and knowledge can be undertaken through relatively straightforward training. Training to change attitudes is much harder but ultimately probably more important. Examples of attitude training could include: case study analyses of information systems failure and/or best practice; role-play exercises to highlight the gap between users and IT staff; group-forming activities for key stakeholders; and demonstrations of functioning information systems to highlight system benefits </li></ul>
    37. 37. AVOIDING EGOV FAILURE: IDEAS ABOUT COMPETENCIES IDEA 2: IDENTIFY AND DEVELOP THE NEEDED COMPETENCIES <ul><li>4 Components: </li></ul><ul><ul><li>Systems Development Competencies </li></ul></ul><ul><ul><ul><li>eGovernment projects in developing countries have frequently - and often to their cost - had to rely on the import of external ICT personnel in order to develop new information systems. The indigenous information systems development capacity for e-governance must be strengthened, both within user organisations in the government and NGO sectors, and within private sector vendor organisations. </li></ul></ul></ul><ul><ul><li>Project/Change Management Competencies </li></ul></ul><ul><ul><ul><li>The public sector particularly has been poor at managing e-government projects and at managing change. That capacity needs to be strengthened. As well as techniques for managing the non-human resources, e-government project managers particularly need help with managing the human components of projects and change. They especially need a greater capacity to manage the issue of motivation; to be able to make use of external drivers, of internal rewards and punishments, of their own negotiation and influencing skills in order to help answer the &quot;what's in it for me?&quot; question for all key e-government project stakeholders. </li></ul></ul></ul><ul><ul><li>Intelligent Customer Competencies </li></ul></ul><ul><ul><ul><li>Public sector organisations especially have been poor ICT customers, unable to raise the finance for projects, unable to specify their needs, unable to manage the procurement process, and unable to manage vendors. All of these capacities need to be addressed to change a client-vendor relationship that, to date, has been too combative, too corrupt or too vendor-driven. Whilst not a panacea, the corruption within procurement may be partly addressed by broader anti-graft, transparency and accountability initiatives. </li></ul></ul></ul><ul><ul><li>Operational Competencies </li></ul></ul><ul><ul><ul><li>Finally, the ability of the public sector and other governance-related organisations to operate and maintain e-government systems must also be strengthened. For almost all developing countries this will still initially include (but not be limited to) a need to build basic computer literacy skills within user communities. </li></ul></ul></ul>
    38. 38. AVOIDING EGOV FAILURE: IDEAS ABOUT DESIGN <ul><li>Idea 1: Prototype And/Or Pilot Your Project </li></ul><ul><li>Taking project requirements, disappearing off to a darkened room for several months, and then implementing the entire e-government 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-government project success by making the design match real user needs, and by making users more realistic in their expectations of the system. </li></ul><ul><li>Second, this can involve piloting - typically implementing the e-government system at a single site; observing, learning and revising 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. </li></ul><ul><li>(From: Richard Heeks) </li></ul><ul><li>Idea 2: Stakeholder Involvement Is A Must </li></ul><ul><li>The Cameroon government initiated the SIGIPES project: introducing e-government 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, ensuring that the design did meet the real - rather than imagined - needs of these key stakeholders. </li></ul><ul><li>(From: Olivier Kenhago) </li></ul>
    39. 39. AVOIDING EGOV FAILURE: IDEAS ABOUT TECHNOLOGICAL INFRASTRUCTURE <ul><li>Idea 1: Avoid The &quot;Bleeding Edge&quot; </li></ul><ul><ul><li>The type of technology to be incorporated into the e-government project should come from a particular window. It should not be so leading-edge (called &quot;bleeding edge&quot; by those who suffer the problems of using such technology) that it has not been tried and tested by others. On the other hand, it should not be so outdated that is lacks some key features that you require to achieved the stated e-government objectives. Instead, the technology should be selected from the window that lies between the leading-edge and the outdated. </li></ul></ul>
    40. 40. AVOIDING EGOV FAILURE: IDEAS ABOUT TECHNOLOGICAL INFRASTRUCTURE <ul><li>Idea 2: Who Will Fix The Technology When It Goes Wrong In Six Months' Time? </li></ul><ul><ul><li>Hope for the best, but prepare for the worst. If there are problems with the e-government technology - the software, the hardware, the telecommunications, and the physical infrastructure (electricity, air conditioning, fire control, etc) - following installation, then you must ask yourself who is going to fix the technology. If the answer is not someone local and reliable, you should perhaps reconsider your technology choices. </li></ul></ul>
    41. 41. AVOIDING EGOV FAILURE: IDEAS ABOUT TECHNOLOGICAL INFRASTRUCTURE <ul><li>Idea 3: Technology Facts, Not Dreams </li></ul><ul><ul><li>When reaching out to citizens, businesses, other agencies, etc. with e-government, ensure that the project is based on the factual reality of the connectivity levels and technological standards available right now. Don't base the project on some imported dreams of what things might look like if your country changed into Finland overnight. In many cases, this will mean working through intermediaries rather than hoping to connect directly to all end users. </li></ul></ul>
    42. 42. AVOIDING EGOV FAILURE: IDEAS ABOUT EXTERNAL & INTERNAL DRIVERS <ul><li>Idea 1: Balance External And Internal Drivers </li></ul><ul><ul><li>Without external encouragement, e-government projects may never be contemplated or started. Without internal ownership, e-government projects may never be developed. Without external facilitation, e-government projects may never be successfully implemented. eGovernment proposals must grapple with the difficult business of balancing and integrating these three forces. </li></ul></ul><ul><ul><li>eGovernment projects risk being too external: many initiatives in developing countries are donor- or vendor-led. The latter is particularly problematic given often conflicting objectives between vendors and governance, and the poor quality of some vendors. Care must be taken that both initiatives and institutions relating to e-government do not become vendor-dominated. </li></ul></ul><ul><ul><li>But e-government projects also risk being too internal: for some ruling elites in developing countries, 'it seems that governance is seen as a tool for serving personal, then ethnic, then social affiliation and last the national interest. All state machinery, institutions and mechanisms are viewed and used in this light.' eGovernment projects can be just the same: if senior public officials do come to see e-government as being in their interests and are able to take control of those initiatives, they may steer projects away from broader goals. </li></ul></ul><ul><ul><li>It is very difficult, but a balance must be struck between external and internal drivers. One lesson from a Zambian e-government initiative was that an independent project team was required 'so that government cannot intimidate team members and that donor countries cannot hijack the project for their own benefit.' </li></ul></ul><ul><li>  </li></ul>
    43. 43. AVOIDING EGOV FAILURE: IDEAS ABOUT EXTERNAL & INTERNAL DRIVERS <ul><li>Idea 2: Meet A Senior Official's Agenda </li></ul><ul><ul><li>eGovernment projects must have an internal driving force if they are to succeed. To work with this fact, you must therefore understand the agendas and interests of relevant senior officials. This may go as far as explicitly designing e-government projects to ensure that they meet at least one senior official's own agenda. This may create the necessary drive and championing for the project. </li></ul></ul>
    44. 44. 03/10/08 Suny BUFF Lecture 27th Nov 2007 Assurance in the PPP Environment
    45. 45. ENABLING TO RAPIDLY MOVE UP THE E-GOVERNANCE EVOLUTION STAIRCASE Strategy/Policy People Process Technology 3. Transaction Competition Confidentiality/privacy Fee for transaction E-authentication Self-services Skill set changes Portfolio mgmt. Sourcing Inc. business staff BPR Relationship mgmt. Online interfaces Channel mgmt. Legacy sys. links Security Information access 24x7 infrastructure Sourcing Funding stream allocations Agency identity “ Big Browser” Job structures Relocation/telecommuting Organization Performance accountability Multiple-programs skills Privacy reduces Integrated services Change value chain New processes/services Change relationships (G2G, G2B, G2C, G2E) ‏ New applications New data structures Time 2. Interaction Searchable Database Public response/ email Content mgmt. Increased support staff Governance Knowledge mgmt. E-mail best prac. Content mgmt. Metadata Data synch. Search engine E-mail 1. Presence Publish Existing Streamline processes Web site Markup Trigger 4. Transformation Cost/ Complexity Define policy and outsource execution Retain monitoring and control Outsource service delivery staff Outsource process execution staff Outsource customer facing processes Outsource backend processes Applications Infrastructure Value 5. Outsourcing Constituent Evolve PPP model
    46. 46. 06/29/06 NPC Sikkim May 2006
    47. 47. Thank you <ul><li>FOR FURTHER INFORMATION PLEASE CONTACT :- </li></ul><ul><li>E-MAIL: [email_address] </li></ul><ul><li>[email_address] </li></ul><ul><li>[email_address] </li></ul><ul><li>91-11-23219857 </li></ul><ul><li>Fax:91-11-23217004 </li></ul><ul><li>Office of the CAG, </li></ul><ul><li>10, B.Z. Marg, </li></ul><ul><li>New Delhi-110002 </li></ul>Let all of us work together to make our country a Developed And Good Governed Nation
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×