a route map for ict components in world bank projectsdocuments.worldbank.org/.../pdf/31886v1.pdf ·...

TASK MANAGERS’ ICT TOOLKIT

A Route Map for ICT Components

In World Bank Projects

Pub

lic D

iscl

osur

e A

utho

rized

Pub

lic D

iscl

osur

e A

utho

rized

Pub

lic D

iscl

osur

e A

utho

rized

Pub

lic D

iscl

osur

e A

utho

rized

Pub

lic D

iscl

osur

e A

utho

rized

Pub

lic D

iscl

osur

e A

utho

rized

Pub

lic D

iscl

osur

e A

utho

rized

Pub

lic D

iscl

osur

e A

utho

rized

Administrator

31886 v. 1

© The International Bank for Reconstruction and Development

The World Bank

1818 H Street, NW

Washington, DC 20433

All rights reserved.

The findings, interpretations, and conclusions expressed here are those of the author(s) and do not necessarily reflect the views of the Board of Executive Directors of the World Bank or the governments they represent.

Rights and Permissions

The material in this work is copyrighted. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or inclusion in any information storage and retrieval system, without the prior written permission of the World Bank. The World Bank encourages dissemination of its work and will normally grant permission promptly. For permission to photocopy or reprint, please send a request with complete information to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, USA, telephone 978-750-8400, fax 978-750-4470, www.copyright.com.

All other queries on rights and licenses, including subsidiary rights, should be addressed to the Office of the Publisher, World Bank, 1818 H Street NW, Washington, DC 20433, USA, fax 202-522-2422,

e-mail [email protected].

Acknowledgements

This publication was identified as a requirement in the Information and Communications Technologies World Bank Group Strategy Paper (ISBN 0-8213-5105-2), and was financed from the Global Information and Communication Technologies Department (GICT) budget. It has been prepared with enthusiastic support and contributions from many persons throughout the World Bank Group. The core team comprised Samia Melhem, Juan Navas-Sabater, and Robert Schware. Valuable contributions and comments were received from World Bank Group colleagues including Ghassan Alkhoja, Carlos Braga, Arleen Cannata Seed, Pierre Guislain, Nagy Hanna, Ali Hashim, Sridhar Iyer, Erik Johnson, Dariush Kianpour, Fritz Königshofer, Mohamed Muhsin, Krishna Pidatala, Bobak Rezaian, David Satola, Charlie Schueller, Ramesh Siva, Hugh Sloan, Eduardo Talero, and Eloy Vidal. We are grateful for the consulting services of Crown Agents for Oversea Governments and Administrations, in particular Ron McGill and Peter Norkunas, and the editing services of Shampa Banerjee.

A route map

1

A route map

Information system projects appear to have an alarmingly high failure rate, even in developed countries — half of large implementations fail, half suffer disputes.

elcome to the task managers Information and Communication Technologies (ICT) toolkit, designed to give guidance on ICT

components in World Bank operations.

The opening italicized comment may appear negative. But it helps to illustrate why this toolkit has been produced. Informatics projects carry certain risks. The World Bank’s projects are especially vulnerable to these risks.

It is estimated that more than 80 percent of World Bank projects have an informatics component. Many of these components meet essential development needs. It is vital therefore, that they are planned and implemented to bring lasting benefit.

This is a vast subject with any amount of guidance available. The difficulty lies in what to exclude. This toolkit is a simple guide, focusing on World Bank operations. It brings together in one place the experience contained within the World Bank, and provides tips, checklists, and reference material. Importantly, it prompts readers toward further assistance.

The toolkit is made up of two parts:

Part 1, A route map is aimed at raising awareness. It attempts to give direction by helping to categorize ICT components by complexity, and “walks through” the issues at preparation, implementation, and supervision.

Part 2, Good practice goes into greater level of detail, providing a summary of the various disciplines relevant to the conceptualization, planning, delivery, and sustainability of ICT based products.

Structure of part 1

1 Introduction......................................................................................................................3 2 Awareness of ICT............................................................................................................6 3 Categorization of ICT components ........................................................................... 14 4 Preparing and supervising an ICT component......................................................... 24 5 Where to seek further guidance .................................................................................. 39

Figures Figure 1 24

W

Ch

ap

ter 1

A route map

2

Tables Table 1 Contradictory advice 28 Table 2 Factors affecting implementation and supervision 37 Table 3 Supervision pointers 37

Boxes Box 1 Illustration of reengineering business processes 7 Box 2 ICT in sectors 9 Box 3 Illustration: absorptive capacity 30 Box 4 Illustration: absorptive capacity (2) 31 Box 5 Illustration: diagnosis of readiness for automation 32 Box 6 Illustration: impact of facilities management decisions 34 Box 7 Checklist of documentation 36

Glossary 40

A route map Introduction

3

1. Introduction

Who is it for The principal audience is the World Bank Group task manager. The task manager instigates an ICT component or accepts the component for funding under a loan. The task manager takes the first critical planning steps that will set the course of the component. This toolkit will assist the task manager in discussions with borrowers and increase the ability to dialogue with experts. Some task managers may have little background in ICT and need to be better informed. However, the toolkit should be relevant to all task managers, regardless of their computer literacy and experience of ICT components.

The audience is also the task team, including the procurement advisers who will play an important role at various milestones in the procurement lifecycle. ICT procurement can be exceptionally complex and they should know when to seek expert advice and recognize the expertise required..

A secondary audience includes the project implementation units, and borrowers and beneficiaries. The toolkit provides guidelines for good practice so that they may better prepare for and monitor ICT components. It also helps expert implementers to provide orientation and nomenclature, and an aide mémoire for the formulation of project plans, expanding the focus beyond mere technology.

What is it for ICT is pervasive in World Bank operations. This is true not only in number and value, but also in terms of criticality. As a crucial change agent and enabler, ICT drives development and can be essential for modernization. The World Bank recognizes the need to build ICT competences, and to make adjustments in project design and strategic approaches to ICT lending. Over the years the World Bank has built strong competences in several sectors.

Even so there is a perception, one that is hard to quantify without adequate monitoring and evaluation, that World Bank ICT components are, for a variety of reasons, suboptimal in their performance. The toolkit, identified as a requirement in the World Bank Group ICT Sector Strategy Paper,1 was conceived to remedy this situation.

In particular the toolkit is aimed at achieving:

Awareness

There are three areas of awareness.

• First, awareness of what ICT can do for development, how it can enhance, enable, and act as a catalyst for change. The World Bank’s e-government web site illustrates high profile information technology (IT) enabled projects.

• Second, awareness of good practice, the importance of planning, and bringing the right expertise to bear at the right time

• Third, awareness of the limitations of ICT and the associated risks and pitfalls.

Quality

Good practice, or “the right way to do anything”, enhances the reputation of projects, those responsible, and the World Bank. In the process it improves the quality of involvement in the project, helps to make the ICT component more dynamic, and increases overall efficiency and functionality.

1 Information and Communication Technologies, A World Bank Group Strategy, The World Bank, Washington, DC, April 2002.

A route map Introduction

4

Risks and vulnerability

There are many examples around the world of failed ICT projects. Projects using ICT are more prone to failure. Why this might be is discussed later. Consequently there is a perception that projects with ICT are less likely to meet their objectives and achieve the desired outcome, and more likely to have cancelled, or worse, wasted disbursement.

The World Bank and task managers in particular are vulnerable to these risks.

Scope This toolkit attempts to summarize, at an arbitrary level of detail, pertinent and explicit knowledge. It is not intended to be used by an inexperienced person to execute an ICT component without expert assistance. Instead it is meant to be a practical guide addressing a limited area of work —- the role of task managers in preparing for and supervising the implementation of ICT as part of a development objective.

There is deliberately no emphasis on technological terms and new technology. The toolkit is independent of any particular methodology. When a specific approach is used to present a topic, this should be viewed as indicative and not constraining.

The content of the toolkit is not defined in an academically rigorous manner. No evidence is presented to support assertions, but a number of examples and case studies are included to illustrate particular points.

How to use the toolkit How it is organized

The toolkit is organized in two parts. To make it easy to navigate there are: A list of contents at the beginning of each part A glossary of terms and definitions

Each chapter has opening and concluding paragraphs describing the purpose and structure of the chapter and where to seek further guidance.

Part 1 is an overview or route map. It covers awareness of the use of ICT, how to categorize an ICT component, and “walks through” a component lifecycle giving brief comments and tips, and pointing to more detailed guidance in part 2 and elsewhere. In both parts 1 and 2 there is reference to the use of appropriate expertise for further guidance.

Part 2 goes into greater detail, providing a summary of the various disciplines relevant to the conceptualization, planning, delivery, and sustainability of ICT components. The chapters are further divided into: Techniques and topics pertinent to the delivery of an ICT component Steps in the process of delivery of an ICT component

When to read it

It is hoped that part 1 may be read from cover to cover. It should also be kept conveniently for reference when considering an ICT component, especially at the early stages of identification, design, and preparation. The more detailed part 2 will help identify products and activities expected at a particular stage during preparation or execution of an ICT component; it will also help to understand these products and activities, and assess them to ensure they are reasonable and complete.

A route map

5

Awareness of ICT

There is an element of intangibility attached to ICT. There is no single way in which ICT may be delivered and no exact knowledge available of how it will work. Precise and explicit specifications are required, but such requirements are often dynamic, affected by changing business objectives, organizational politics, and rapid technological change over the project lifecycle. The greater the discretion exercised, the more difficult the range of decisions. There is great scope for ambiguity. Problems during implementation or with system performance often have nothing to do with the quality of the hardware or with programming errors. Usually the fault lies with the specifications provided.

What this chapter is about

This chapter is about awareness of what ICT is and what it can do. In defining ICT the chapter also discusses the characteristics of ICT that may lead to problems in planning and implementation. Later chapters (and part 2 of this toolkit) provide good practice to remove or mitigate these risks. Examples are given of the generic and sector specific uses of ICT applications. There is some discussion of e-issues as well.

Structure of this chapter

What is an ICT component? 6

Is an ICT component different? 6

Uses of ICT 8

ICT in sectors 8

Strategies 10

E-issues 11

The future 12

Ch

ap

ter 2

A route map Awareness

6

2. Awareness of ICT

What is an ICT component? Definitions

Several terms, such as information technology (IT), ICT, information systems (IS), or informatics are often used interchangeably. This toolkit for the most part uses ICT, but other terms are applied where the context makes them more appropriate: IT is the use of technology such as computing and software in support of information processing. In

this guide the term is used to refer to technical aspects (like hardware, the platform or technical architecture) or for simpler components involving only the procurement of goods. The emphasis in this guide is on IT systems or, more precisely, computer aided business systems, which include applications and their supporting infrastructure components.

ICT stands for hardware, software, networks, and media. In the context of this toolkit “communication” is more about connectivity and the exchange of information rather than the communication infrastructure over which the information may be transmitted.

IS is any procedure or process, with or without IT, which allows an organization to acquire, store, process, and disseminate information that supports its business needs, or a discrete business area within an organization.

ICT components in projects should support the fundamental business needs, activities, processes, and information required to meet the business objectives of the organization or business area. Fuller definitions are given in the glossary at the end of part 1.

Is an ICT component different? It is often claimed by IT professionals that IT projects are different and require special skills and extra care in planning and management. But is this so? Ignoring for the moment those examples that involve a simple supply of goods, IS is more analogous to a construction, or a “supply and install” engineering project. But is it more or uniquely complex? It is certainly true that IS projects appear to have an alarmingly high failure rate, even in developed countries: 50 percent of large implementations fail 50 percent suffer disputes 80 percent require contract amendments.

Why is this so? This section explores some features and characteristics, unique or otherwise. The issues are grouped, but do not necessarily split neatly, under four main headings:

Technical

ICT is difficult to define; it is hard to be precise about what is to be delivered and know how it will work. Although it demands exact specifications, the requirements are often so dynamic, affected as they are changing business objectives, organizational politics, and rapid technological change, that flexibility and an ability for quick adjustments must also be built into the process. However, if more discretion is allowed, more options are available, making the range of decisions large and unwieldy. Consequently, there is great scope for ambiguity. To add to the confusion, problems during implementation or with system performance are often independent of the quality of equipment supplied or programming errors. What is more commonly at fault is the specification of the requirement.

A system includes a diverse range of hard and soft technologies, which must work interdependently. The value is derived from the whole system, not the parts. Building works, cabling, and improvements to electrical supply must therefore be coordinated.


7

A broad range of skills is required to implement ICT. Have the business plans of the organization been translated to an IS strategy? Do management and users have an understanding of their own requirement or how to articulate it? It is rare to find an expert in business needs who is also an IT expert able to use the tools that will communicate the requirements. The systems analyst who will help with the specifications may not necessarily have sufficient knowledge to define the technical architecture. The cutting of the computer code is best left to the programming specialist. Yet another set of expertise will be required for installation. Someone somehow must pull all this together, and this is where the project managers come in with their particular expertise.

Institutional

A system implementation affects an organization profoundly. It cannot be treated purely as a technical issue because it affects human activity. It often requires reengineering (see box 1) of business processes and the development of a range of complementary procedures. Its implications may go beyond the organization.

Box 1 Illustration of reengineering business processes

There are change management issues, issues of inertia, fear of change, and problems with absorptive capacity. The changes may require new sets of skills and knowledge in the organization’s staff.

ICT, unlike most capital assets, takes a long period of time to generate economic returns because of the steep learning curve imposed on the organization. Technological change therefore has institutional implications that go beyond technology.

Management

Of course the well-known principles of management apply, but an ICT component does have differences if only because project management invariably crosses organizational boundaries, and IS has its risks as well as opportunities for change. Just as there are common features, there are also differences between projects that make every project unique. It is the differences and the fact that the projects are endeavoring to produce something that did not exist before, which introduce risks and create the need for greater care in project management.

There are many definitions of a project (see part 2, chapter 1). For this guide a project is a process whereby a defined, unique, IS (or self-contained part) is produced to defined quality, within a finite timescale, and using allocated resources. As with all projects, the aim is to deliver to those that need it, at the agreed time, and within budget. But what makes ICT different is exactly in the word “defined”. An ICT project or component has to be defined clearly and unambiguously. Remember, project failures are mostly caused by incorrect or inadequate specification of the requirement.

Sophisticated project management methodologies have been developed specially for ICT or IS with recommended management structure and participants. Project management plays a vital role in bringing together all the parts to ensure there is no need for expensive redesign of the system, or expensive reworking of items is complete, and the risks are managed and controlled, so that opportunities and benefits can be fully realized.

Procurement

ICT procurement has particular complexities and large IS are among the most challenging. Most encompass both supply of products and provision of services, although in different mixes: from straightforward supply and maintenance of technology products, to complex development, integration, and operation of mission-critical systems. Several procurements may be necessary, or different

Mere “automation” may involve library records taken on to a database and a catalogue printed from there. Better still may be reengineering the whole process so that the catalogue is online and searchable, removing the need for physical catalogues entirely.


8

components may be bundled in a single procurement exercise, as with a turnkey procurement. Issues of proprietary goods and conflicts of interest take on special significance in this context. Standard bidding documents (SBD) have been developed for World Bank projects. While these facilitate procurement, they need to be used with flexibility and tailored to the requirements of a specific project.

Uses of ICT The term ICT covers many things. The following list, although neither exhaustive nor definitive (see part 2, chapter 9 for expanded comment), gives some idea of what it might cover: Personal systems, that is small systems and tools used by an individual Office systems, that is interconnected (through networks, files services, or mail services) or

disconnected systems Data capture systems, or some scheme by which data external to a computer are brought into it Imaging systems by which a human readable document is scanned to create a digital image Image character recognition (ICR) systems that are an extension to the imaging systems Management information systems (MIS) that analyze aggregates, counts, comparisons, tabular data,

and other summaries to provide information, for example, of organizational performance Transaction processing systems, or online systems involving operators on terminal equipment

interacting with transaction processing and database servers to provide some service to clients, for example, entry of motor vehicle registration details and issue of certificates

Geographical information systems (GIS), or systems that combine digitization of spatial images with statistical data and static descriptions

Workflow systems, or transaction processing using tools that extend and facilitate the design by encoding an organization’s process flow, for example, encoding the process of an insurance claim from the mail room through the review process, premium confirmation process, to the payment process

e-business systems, or subsystems using the Internet to enable global anywhere, anytime interaction Enterprise information systems (EIS) that collate and summarize data and present information

pertinent to the decision processes of executives Decision support systems, or tools that help decision makers to draw upon data and models to solve

semistructured and unstructured problems Expert systems, or an interactive system built with a tool set using an inference engine that applies

specialized symbolic reasoning to a database of encoded knowledge, to perform at a level of competence higher than that of nonexpert humans, for example, the Banker credit evaluator, the Dipmeter oil location advisor, the Mycin medical diagnostician.

ICT in sectors How ICT can be best incorporated in sectors probably should be left to sector specialists, who can leverage the World Bank’s and their own knowledge of the catalytic role of ICT worldwide.

Many applications, such as those for financial accounting, budgeting, project management, human resource management, payroll, knowledge management, MIS, and so on are cross-sectoral, but there are technical applications specially relevant to each sector (see box 2).


9

Box 2 ICT in sectors

Agriculture Hungary — agriculture / commodity trading — data cast Economic Policy Education Indonesia — SINAS university link for online access — data network China — computational problem solving — computer farm / network Yemen — teacher / student shared resources — data network Turkey — computer literacy / IT for pedagogical purposes — school PC networks

Electric Power and Other Energy Yemen: power station monitoring / control — telecontrol Environment Brazil: microcatchment soil analysis — GIS Nepal: river basin resource management — GIS Central African Republic: national forest inventory — GIS Finance Hungary: commercial bank GIRO — system interconnection network Chile: interbank operations — interbank network Ethiopia: home loan processing — transaction processing Mexico: microlending processing — transaction processing Health, Nutrition and Population China: environmental health maps — GIS Philippines: environmental health and epidemiological patterns — GIS Jordan: Heartbeat telemedicine China: housing, health, morbidity study — GIS Public Sector Management Tax modernization (Morocco, Philippines, Hungary, Jamaica, Argentina, Brazil) Customs modernization (Philippines, Armenia) Korea: municipal budget and finance — enhanced compliance processing and MIS Morocco: national debt management — MIS Brazil: budget and expenditure control — data collection and MIS India: Andhra Pradesh land and property registration Brazil: multiple agency service kiosks e-procurement (Chile, Philippines) Transportation China: traffic analysis and planning — GIS China: road inventory, traffic density maps, workshops — GIS India: interstate check post automation — self-identified registration, weighing Urban Development China: land use planning and management — GIS Angola: virtual cadastre — GIS Water Supply and Sanitation Pakistan: inventory of water and sanitation networks — GIS India: water authority branch office network — integrated voice and data network Brazil: sanitation monitoring and control — telecontrol


10

Strategies Organizational IT-IS strategies

IS exists to service the business needs of an organization. An IS-IT strategy for an organization seeks to align information services, IS and IT, and investment in these with the current and future direction of the business, for enhancing the effectiveness and efficiency of the organization and supporting its “corporate” objectives, policies, and procedures.

All ICT, IS, IT projects should be formulated according to an IS-IT strategy. The IS-IT plan responds to the basic purposes, objectives, policies, and strategy for the organization identifying, prioritizing, and advocating complementary requirements for information, communication, and data processing. The plan is a management document that can provide a consistent business basis for investment in ICT.

The strategy provides a statement of direction laid out by the executive. The direction entails: Analysis of organizational strategies, plans, policies, and procedures that seeks to identify information

requirements Assessment of information assets to identify opportunities for new products and services Assessment of existing services, service levels, systems, infrastructure, and organization for IS and IT,

and the effectiveness in meeting the requirements and opportunities Determination of affordable services and service levels appropriate to the organization Revision of the management system that measures the effectiveness of the strategy, service delivery,

and execution of projects Revision of existing projects and identification of new projects seeking to sustain services and service

levels Revision of the organization to provide services at required service levels Investment framework Framework within which unidentified future proposals can be assessed Technical, commercial, and user guidance to service providers, and personnel in ongoing projects and

new projects.

The benefits sought from the strategy include: Improved delivery of relevant products and services to the clients of the organization Delivery of new products and services enabled through IS and IT Reduction in the cost of business Improvement in the reliability of product delivery Ongoing modernization and revitalization of the organization for competitiveness Informed selection, control, and coordination of investments Control and coordination of services and systems Clarity of ideals, purpose, and limitations in the provision of IS-IT services.

For the World Bank the benefits may also include: Identification of projects that substantiate modernization activities Identification of projects that can be a vehicle for organizational change and development Validation of a sound basis for project proposals A baseline for measuring effectiveness of initiatives.

Refer also to part 2, chapter 9 for further guidance.


11

National strategies

The development of national IS-IT strategies is still in its infancy. Only a few countries have produced and implemented such strategies, and achieved varying degrees of success. A small number have a formally documented and published strategy, and most strategies only cover the public sector.

National strategies differ in their scope and content. In some cases, they cover only the provision of a technical infrastructure (for example telecommunications provision), while others concentrate on the provision of a national IS-IT system where all government ministries are to be linked together electronically.

In all cases the major problem has not been the ability of technology to provide solutions, but the rate at which policymakers (both political and administrative) are able to adapt their thinking on the future shape of government. The United States “reinventing government” initiative of the mid-1990s is one example of a more visionary approach, which challenges the traditional ideas of how government should be organized, what types of services it should provide, and how it should provide them.

In the United Kingdom, the central government has adopted a “business-driven” (rather than “IT-led”) approach to the harnessing of IS-IT for the benefit of society. That approach was developed in the late 1980s and its framework is used for the development of departmental business strategies as well as IS-IT strategies.

Key areas for examination include: Information needs of citizens Coordination of effort between central government departments and ministries Government service centers (one-stop shops) Public sector reform and reengineering government business and transactions Improving service through the innovative use of IS Increasing awareness and understanding of senior civil servants and policymakers Integration of future strategy with other government initiatives, such as a citizen’s service charter and

outsourcing and privatization policies Links between central and local government Administrative arrangements for development and management of the strategy.

Products should not be named in a national strategy without at least a framework pricing and services agreement with the manufacturer.

E-issues The information age, the knowledge economy, the digital divide: what do these phrases mean? The World Bank Group ICT Sector Strategy paper gives some answers. All of them are inextricably linked to e-issues.2 Certainly the Internet and electronic business provide many new and valuable opportunities by offering productivity, efficiency, service, convenience, and transparency. On no subject are there more buzz, uncertainty, and hype. However, the fact remains, only 20 percent of the world’s population has ever made a phone call, and 7 percent ever been on the Internet. This is a surprising statistic that puts e-issues in perspective. There have been many failures of e-initiatives in the developed world partly for reasons of poor execution (flawed systems) and partly because customers or citizens are not ready or able to interface in this way. If the true potential of e-initiatives is to be realized, there needs to be greater appreciation of its limitations.

Underlying e-business there are some hardheaded precepts, approaches and methodologies that are fundamental to IT. E-business cannot be implemented in isolation. Not only should there be an

2 For this toolkit, largely, “e” is taken to mean Internet connectivity or access rather than any form of electronic business.


12

information infrastructure, it should also be built on sound core systems, and not be viewed as a substitute for what was there before.

Instead of corresponding through the mail, using a telephone or visiting a counter, clients of an organization may access the Internet. Thus e-business can be seen as merely a new interface between an organization and its clients. The machinery of the organization’s internal processes still needs to be in place. Do water billing systems or social security systems consist only of data entry for new application forms? Does a tax office merely accept returns? How does the rest of the system work? The traditional, bread-and-butter systems need to be there and are likely to consume 95 percent of the investment. What is more, mailroom attendants, telephone operators, and counter clerks still need to be there, especially in the public sector where equity of access is an imperative.

E-business also requires security and legality. Government policies and complex legislation, legal precedence and commercial agreements are required to underpin the Internet transactions.

E-business needs continuous maintenance. E-government and improved governance (improving access, timeliness, accountability, and transparency), will only work if the sites are kept updated. There are ample sites that have been constructed but have no systematic update.

Also be aware of the regional, cultural, and sectoral differences when working on e-solutions (for further information refer to www1.worldbank.org/publicsector/egov/)

The future This toolkit has no intention of second-guessing the future of ICT. The content would date too rapidly, and neither the large technology, telecommunications, and media companies, nor the stock market analysts are absolutely sure of what lies ahead.

In any event World Bank projects should not be at the helm of technology, attempting to achieve what has not been done elsewhere, even in the developed world (but see Box 6). While experimentation may be occasionally appropriate, World Bank projects generally support development objectives, and therefore need to use technology that can be accessed and sustained by the recipient country and its citizens.

Nevertheless, there are trends in technology, world economy, and human society that allow us to make certain conjectures: The rapid pace of technological advance will continue Virtual speed and storage space will continue to increase. Hardware costs will fall. Robustness will increase, and the need for controlled environments and special maintenance

provisions will reduce. User empowerment will continue through direct access to systems and increased information. The convergence of IT and communication and media technologies will accelerate, with yet uncertain

implications for business and leisure industries. Connectivity will accelerate with large caches of readily accessible data from intelligent database

accessed by high-speed networks capable of communicating voice, data, and image with no perceptible delay.

Tools for creativity, discovery, training and business management will become commonplace. Systems will be less about economy and saving on staff, and more about supporting the business and

effectiveness.

These developments will have profound implications for the World Bank’s customers, although there will remain cultural and sociological reasons why the impact will vary from country to country: Organizational impact — more flexible less hierarchical: people will be given more responsibility and

expected to be goal oriented


13

Management impact — distributed decisionmaking: corporate knowledge will reside in systems and not necessarily in people, who may come and go.

While hardware costs may reduce, service costs will not. Advances do not always equate to simplification. Complexities will continue, as human activity systems will not change. System life will reduce. Whereas previously a planned life of ten years was reasonable, even five years seems a long event horizon today. Demand for skilled staff will increase. Outsourcing and facilities management is less of a solution in the developing world where the private sector also lacks capacity and the developed world is competing for scarce resource with the developing. This poses both a threat and an opportunity.

In any event the importance of ICT to development is uncertain or unproven. How much is the ubiquitous computer in the developed world a contributor to progress and development and how much a manifestation of consumerism? It does appear that the impact on productivity has been overstated. But what is the impact on growth without inflation, where the Internet appears to be a driver of global pricing?

Growing technical awareness among users is a positive factor, but there is a risk that this may translate to poor quality systems and organizations finding out the hard way that, when it comes to system development, there is no substitute for quality, professionalism, and standards. It is an important task of the World Bank to bring this advice to its clients.

A route map

14

Categorization of ICT components

The taxonomy of IS is somewhat blurred. The essence is a methodical application of some scheme that manipulates data for some purpose that is perceived to be worthwhile.


This chapter prompts, points, and asks questions. It asks: what type of ICT component do you have? How complex is it? What resources will be needed? It is hoped that this chapter will be useful immediately after an ICT component has been identified, to shape the early conceptualization and planning of the project or component. The idea is to provoke thought, and guide the task manager toward experts within and outside the World Bank for advice and help with planning.

Structure of this chapter

Follow the arrows and find your own answers.

Ch

ap

ter 3

A route map

23

Preparing and supervising an ICT component

The ICT component lifecycle nestles within the larger project lifecycle… it should fit with the strategic dimension of the project but it is distinct. It requires a different level of planning, possibly using different terminology. In effect the project must plan for planning around the ICT component… project design must allow for this.


Following some introductory comments this chapter traces the component lifecycle. It follows closely the lifecycle for all projects within the World Bank. This is familiar, soundly based, and there is a range of relevant toolkits already in place.

Of necessity the chapter can only cover one type of component and it opts to consider a more complex component for an IS. An ICT component that is about hardware, for example would possibly have a truncated planning phase and the guidance in the previous chapter may be sufficient. However, the topics here may still help to shape a hardware component.

Structure of this chapter Project and component lifecycles 24 Environment for success 24 Preparation 27 Problem analysis 28 Stakeholder analysis 29 Institutional appraisal 29 Objective analysis 32 Logical framework 32 Other planning tools 33 Other topics 33 Procurement planning 34 Cost estimation 35 Checklist of documentation 35 Supervision 36 Completion 38

Ch

ap

ter 4

A route map Preparation and supervision

24

ISStrategy

Evaluation

BusinessCase

SystemSpecification

BusinessAnalysis

Implementat ion

Deve lopment Insta l la t ion Operat ionClosure

CountryAssistanceStrategy Identifi

-cation AppraisalPreparationImplementat ion

Superv is ionCompletion

Loan/Project Lifecycle

ICT Component Lifecycle

Procurement

P ro ject Management

Diagnostic

Institu-tional

Appraisal

Stake-holder

Analysis

ProblemAnalysis

Design

3. Preparing and supervising an ICT component

Project and component lifecycles What is the project for? What problem is being addressed? What goal and objectives are being set? What is the outcome that is wanted? These are questions with which task managers are familiar. But for a project with an ICT component there will be a set of parallel planning and design questions (with a set of related but different answers). The IT component lifecycle nestles within the larger project lifecycle as illustrated in figure 1. The component should fit with the strategic dimension of the project but it is distinct. It requires a different level of planning, possibly using different terminology.

In effect the project must plan for planning around the ICT component. This chapter deals with the task manager’s role and principal interest: the project as defined by the project appraisal document (PAD); but remember; the project also encompasses the ICT component lifecycle. Project design must allow for this.

Figure 1 The “nested” ICT component lifecycle (IS component)

There could be many variations to figure 1. For a simple hardware requirement, once the specifications are written, only the procurement remains (although installation services and maintenance should be included). For multiple components, World Bank funds may only provide partial cover. It also depends on the starting point: the World Bank may agree to include a component in a project where the beneficiary has already done a lot of preparatory work. And further “nests” could be added for implementation: procurement process, delivery process, deployment process, each having it own process of planning, analysis, specification, delivery, deployment, and closure.

Environment for success This section provides in tabular form a series of short good practice pointers for the development of an IS. It summarizes some of the planning described elsewhere in this toolkit. For the sake of presentation the topics are divided into three: Understand (the problem), Design (the solution[s]) and Implement. To


25

be successful, the issues must all be considered at the planning stage. A measure of a successful IS is one that the organization can use, maintain, and develop as business needs change, without continuing external support. Sustainability needs to be planned.

Understand the problem Develop a shared understanding of the problem Use sound problem analysis techniques.

Remember, there are often multiple perceptions. Identify and involve stakeholders. Obtain consensus before proceeding with solutions.

Undertake a sound institutional appraisal Identify formal and informal structures. Assess constraints imposed by organization structure. Assess risks imposed by poor pay and conditions. Understand how information is used and decisions taken. Assess scope and climate for change. Identify external pressures for change.

Ensure organization is fully involved Identify champions. Have named persons involved in design and implementation. Involve those responsible for business activities. Consider absorptive capacity at all levels. Obtain agreement to all interim and final outputs.

Define problem and change clearly and quantitatively

Identify inefficient core business activities. Assess current performance. Examine reasons for inefficiencies. Identify internal and external constraints.

Examine statutory requirements, policies, and constraints

Assess soundness of legislative framework. Ensure compliance with international requirements. Consider impact of externally imposed timetable for legislative change.

Design solutions

Base solution on business objectives and priorities

Ensure objectives are clear and promulgated. Ensure business plans are documented and realistic. Ensure component integrates with operational activities and other development plans.

Use sound business systems analysis and design methods

Determine improvements to core business activities. Design plans for realizing improvements. Produce detailed business plan including cost-benefit analysis.


26

Identify information needs for decisionmaking Consider requirements for strategic, tactical, and operational use. Assess ability to make decisions using information. Consider costs of information provision. Avoid unnecessary information. Consider training in information management.

Consider data quality, availability, cost, and ownership issues

Identify data sources, quality, cost and usability. Obtain data as a by-product of operational functions. Avoid unnecessary data collection. Consider data definitions, consistency, and interchange standards. Consider data transfer, bottlenecks and backlogs.

Ensure solutions are affordable Ensure beneficiary can afford support and maintenance. Ensure beneficiary can pay for future enhancements. Ensure beneficiary can afford in-house technical experts.

Design hierarchy of components to deliver program of change

Identify components of change program. Identify linkages and dependencies.

Implement solutions

Link phases to design, development, and implementation approach

Determine how outputs are to be delivered. Assess scale and size of business change. Consider options for piloting change. Consider procurement strategy. Draft project appraisal document, defining scope, and measurable criteria.

Establish project, risk, and change management processes

Establish sound project management organization. Apply sound project management techniques. Consider impact of change. Identify and manage risks.

Ensure appropriate use of external resource Determine multidisciplinary team. Ensure flexibility of inputs. Remember, requirements change as project progresses. Integrate with project organization. Ensure appropriate advice, facilitation and transfer of knowledge.


27

Use appropriate IT

Provide solutions that can be sustained. Avoid novel or bespoke solutions. Consider obsolescence if implementation phased. Encourage use of standards through strategies and policies. Seek maintenance from local suppliers. Ensure appropriates services.

Develop recipient capacity Identify core competencies. Build in training throughout. Measure and monitor organization development. Build into outputs of logical framework[s].

Ensure appropriate procurement strategy and methods

Procure based on business requirements. Consider basis of supply; total solution or use of different consultant, supplier, and contractor roles. Avoid fragmentation if organizational capacity weak. Consider five-year costs. Use sound evaluation methods.

Consolidate change before project closure Remember consolidation can take time and should be planned. Ensure benefits realized. Measure performance.

Ensure arrangements for development, support, and maintenance

Organization can solve business activity and work practice problems. Organization has minimum system administration capacity. Effective and efficient maintenance and support contracts. Organization can manage supplier contracts and system upgrades.

Preparation Identification

How to identify an ICT component is covered in the previous chapter, which describes the initial steps to categorize the component, and depending on the answers the reader is then guided to this chapter and elsewhere in the toolkit for more information.

This chapter assumes that a higher risk, more complex component has been identified. The preparation and planning will probably require more than can be achieved under a normal project preparation budget. Any detailed analysis and design for the component would be more than can be achieved by a task manager alone.

Consider therefore, the use of external assistance to be funded from grants or met from the loan. Plan ahead for the input of these resources and ensure the means by which the right skills — business, system, and commercial as well as technical — can be brought to bear. A common complaint is that advisers are too technical. Consider too involving technical auditors. Examples of the range of expertise are given in


28

part 2, chapter 6 and good practice in selecting consultants described in part 2, chapter 8. Make sure you have clear objectives and terms of reference in order to facilitate supervision.

Ideally, sufficient design input should occur before quantification of the project or component budget. However, in most cases the detailed planning and design inputs for an ICT component will occur after the loan is approved. Consequently in following the description of the planning process described in this chapter, it must be remembered that some of the hierarchical structure of plans (with levels for project, project component, and component phase), will be prepared before and some after the loan is signed. The point at which this occurs will vary from project to project.

Successful introduction of ICT, for example the implementation of an IS, can involve fundamental change affecting most or all of an organization. Changes need to be predicted, planned, and managed, and require the commitment of senior managers as well as staff acceptance. Be aware of resistance to change. Some, if not all, stakeholders will see change as a threat. Considerable effort may be required to overcome resistance. See part 2, chapter 5 for guidance on planning for and managing change.

Before proceeding too far with preparation, look to see what is already there. There will be scenarios where some effective investment is already taking place. If that is the case give it support. Many country factors will influence the approach. Make the project relevant and grounded in reality and practicality.

Finally, before going into detail, be aware of the pace of change: in five years any system is likely to be obsolete. Design horizons should be kept short, one to two years (although with long term objectives), to avoid outdated solutions. Even without technological change smaller steps in implementation make sense.

Any number of tips and pointers can be included here, some of which may seem contradictory. One set is included below to illustrate that the right decisions must be based on a judgment of the circumstance.

Table 1 Contradictory advice

Do not fund indiscriminately; deliver a sustainable system, with the seeds of success built in.

Early distribution of PCs along with appropriate training can lead to experiment, early learning, and intellectual investment.

Avoid a credit card mentality; resist pressure for early procurement.

It is valid to disburse to maintain momentum and enthusiasm

Resist pressure to downgrade development objectives to simple equipment upgrade or office automation.

Consider the catalytic impact of supporting a network facility or simple electronic mail on organizational development.

Do not procure the platform before the solution. Early procurement of hardware can have cost and specification disadvantages.

Do not disburse for the sake of it.

Problem analysis An ICT component may be prompted by: A business area not achieving its performance targets New statutory requirements to be met, such as the introduction of a new tax Existing systems, whether computerized or manual, no longer able to cope with the volume A need to adjust to changes in other business areas or organizations.

Whatever the problem or development need being addressed, the ultimate solution must be linked to the business need of the organization. It will not be useful or successful unless it contributes to the organization’s aims and objectives. However, the problem must be analyzed beyond the ICT component.


29

On its own an ICT component would be unlikely to provide worthwhile benefits. The investment must be driven through as part of an integrated program to improve performance.

Stakeholder analysis Before proceeding too far with problem analysis task managers will want to make use of the stakeholder analysis toolkit. It is worth considering who might be stakeholders for an ICT component. Possible interests are listed within part 2, chapter 2 of this toolkit. Consultation should include other government agencies and departments, and particularly the target organization, where there should be a strong sense of ownership. It may not be possible to identify all stakeholders from the outset. As with much planning, the list should be reviewed periodically to ensure it is complete and accurate.

Emerging from this analysis it is important to identify a sponsor (also see part 2, chapter 1). To secure stakeholder commitment and acceptance, particularly that of the user, there should be agreed mechanisms for bringing them into the development. Participation can be secured by: Formal project management and organization arrangements directly involving stakeholders Building of confidence and improving skills by developing capacity through all stages of the project Providing appropriate external inputs to facilitate change and complement available human resources.

These would need to be factored into the project design.

Institutional appraisal A fuller diagnosis of the problem, necessary to informed planning, will be provided by an institutional appraisal. Using the institutional appraisal toolkit and checking the organization structure, management systems and practices and human resource issues, will give insight into the organization and test the climate for change. Some of the key understandings will be: How the organization actually works The formal and informal organization structure Performance of core business activities Work practices and existing IS Business rules supporting core activities Quality and timeliness of information flows How information is used for decisionmaking Unwritten rules and codes of behavior Communication patterns, particularly informal ones Constraints that preclude effective performance of business activities Restraining forces, external and internal particularly attitudes of people Driving forces for change, external and internal.

This analysis will ensure that the true nature of the problem is understood, that it is the right problem and is clearly defined and quantified. It is important to establish an “owner” or champion who will take responsibility, provide leadership, and has the authority and commitment to see it through. The “owner” will be a vital point of contact, but at this stage will not necessarily be the direct line manager of the business area, have accountability for the proposed project, or become the project manager (see discussion on the champion part 2, chapter 1 and project manager part 2, chapter 1). Further, the analysis should: Make clear what will happen if nothing is done. Obtain information on any planned changes that may affect the problem. Identify measures of success in dealing with the problem.


30

The appraisal will need to confirm the legal status of the organization, its ability to enter into contracts, and its capacity for procurement and for managing contractors.

The analysis should also assess the absorptive capacity (see box 3 and 4), sustainability of the intended investment, and resistance to change. The plan should take account of the findings in terms of scale, duration, phasing, and measures to address weaknesses and capacity issues.

Box 3 Illustration: Absorptive capacity

This case study illustrates that an IS and IT supplier can deliver much faster than even the mostambitious beneficiary can absorb. A comprehensive automation project was instigated for direct tax functions in a southern African inlandrevenue department. A comprehensive automation system was required. The original specification wasspecious but a contract was constructed in two parts: analysis-specification-costing and then delivery. The system consisted of processing to support the core business functions including registration,collections, returns, compliance, and audit. The supplier delivered within budget and scheduleparameters in 1998. Both purchaser and supplier considered the project successful. The purchaser is progressive and dynamic. However, by the end of 2001, three years intoimplementation, only the registration and collection functions have been fully utilized. Progress in theother functional areas is stalled. Returns processing is only very abbreviated: the returns are far too complex, the organization cannotdecide on simplification, and cannot justifiably obtain the data entry resources (human resources) forreturn processing, so only summary data is entered for accounting purposes. Compliance processing consists of internal listings in support of manual letters: the organization hasjudged that its clients would react badly to computer generated demand notices. Audit is not used: the audit function requires return data and hence cannot be used.


31

Box 4 Illustration: Absorptive Capacity (2)

Remember that a broad institutional appraisal may not provide detailed understanding of performance in complex business areas. An illustration of this is given in box 5.

This case study illustrates that an IS and IT supplier can deliver much faster than even the mostambitious purchaser can absorb. A comprehensive automation project was instigated for the direct and indirect tax functions andgeneral administration of inland revenue in a Far East country. This was a large Bank IS project,recognized to be ambitious and carefully prepared from an IT perspective. A strategic IS plan wasdeveloped. A well-constructed procurement specification, treading a fine line betweenrequirements and design, led to a turnkey supply: hardware, system software, datacommunications, and application software, together with training, expert consulting, facilitiesmanagement, support and maintenance. A lot of effort was concentrated on supplier supervision(perhaps learning a little from another large Southeast Asian project a few years in advance). The supplier delivered within budget and schedule parameters in 1998. Both purchaser andsupplier considered the build phase very successful. (Note 1) However, the system has not been rolled out to the hundreds of offices as intended. The supplierhas well and truly fulfilled its obligations to supply goods and services to the extent possible,forgoing some services through failure on the part of the purchaser to fulfill some dependencies.There are two main reasons: (1) passive resistance of ill-informed, underinvolved users in a far-flung almost feudal organization where central power was overemphasized, combined with (2)insufficient organizational capacity to undertake concomitant capital improvements. Capacity for the capital works was too enthusiastically overstated and too readily accepted. This isdifficult to correct. The lesson to learn is to visit and revisit the commitments of all parties inregular and direct monitoring. A parallel but feeble organizational development effort was made through technical cooperationfrom another bilateral donor. Insufficient attention was applied to this by the project and by theorganization. Insufficient resources were available. There was no understanding and commitmentto the social implications of the new IS. It was regarded as IT rather than a computer-assistedbusiness system. It was sufficiently complex as an IT project to obscure the social dimension. Note 1: The case also illustrates two other lessons: (1) the complexity of large IS projects, and (2) the paradox of comprehensive design. Management complexity rises exponentially with the number of internal resources and external parties. In this example, the internal resources of the supplier were handled satisfactorily. However, the number and impact of disparate factors in the environment external to the project were not fully appreciated. Much of that environment was within the purchaser’s own organization. Lesson: recognize management complexity and budget accordingly or at the risk of creating information islands, break the project into discrete steps. Comprehensive design takes time. The program was comprehensive with a long lead-time through phases of analysis, specification, build, and delivery. There are two consequences. (1) Focus, momentum, interest, and tolerance diminish with time. (2) Tie long lead-time to the dynamics of the IT industry and the result is inevitable obsolescence. In the early 1990s, when the project gained momentum, bespoke development for tax systems was the only option, character-based interfaces were normal, proprietary systems were still common, and OSI standards were news. By implementation in the mid-1990s everything was GUI and POSIX, Windows was ubiquitous, and Intranets were breaking news. The project products may be criticized as old even if somewhat unfairly (obsolescence in IT is a relative condition) and even though actually shining new. Lesson: design is relatively (but not perfectly) robust. Invest effort to design but make delivery in smaller steps. Accept that delivery may be on disparate technological platforms and that there will be an ongoing cycle of renewal.


32

Box 5 Illustration: Diagnosis of readiness for automation

Objective analysis In converting the hierarchy of problems into objectives, the analysis should ensure that that there is no confusion between project objectives and ICT component objectives. Indeed a reverse analysis should gauge whether the achievement of the ICT component would be enough in itself to meet the project objectives. Gaps should be filled by further project components. This analysis should include the discussion of alternative solutions, before completing the planning process.

If the organization is not ready for change, or it is determined that more diagnostic work is necessary before a major investment, it may be possible to implement some interim or preparatory, short-term measures. These can bring benefit and, through implementation, provide further diagnostic insight. They may include: Providing help with strategic and business planning Introducing simple PC technology to, for example, improve record keeping and provide management

information Introducing performance measures for selected business activities and assessing the opportunities for

improved performance Streamlining work flows, simplifying forms, and so on Establishing clear decisionmaking criteria within business processes Conducting human resource assessment and training needs analysis.

Logical framework The plan for the ICT component should have its specific objective, outputs, activities, and performance measures, and determining these is best fulfilled by preparing a separate sublog frame for the IT component, using the log frame toolkit. This should fit with the project log frame and help to ensure a strategic fit of the component with the goal of the project.

This case study illustrates the importance, through institutional appraisal or business analysis, of assessing the readiness for automation of an organization or business area. A comprehensive automation project was instigated for the direct tax functions in an African revenue authority. Consultants were appointed. An early output was a diagnostic study of the operation of the department. This identified that by any standards the department was performing poorly and that by certain key measures was performing badly. It was concluded that the department was not ready for automation and that it should be postponed. An alternative program was put in place. This was effectively a different project with the objectives to: Clean the taxpayer records Streamline the work flow in the main processes Create decision criteria where these were lacking Build capacity in the performance of tax inspectors Strengthen key functions, such as debt management and investigative activity.

During the same period the corporate IT department was strengthened and capacity built within the tax department to enable them to be fully involved in the definition of their future IS requirement. A new project for automation then met with particular success.


33

Assumptions and Risks

It is a good time to consider risks when using the sublog frame as a real design tool. The “plan down” and “think up” process, particularly when determining important assumptions, allows for certain risks to be removed or mitigated in project design, leaving only those risks and assumptions outside the control of the project. Further guidance on risk management is given in part 2 chapter 4. A sample ICT component sublog frame is included at annex B of part 2 chapter 1.

Indicators

If the project implementation unit is to implement the project, use the log frame for monitoring purposes, and comply with the World Bank’s procedures (including procurement procedures), the planning process should consider the project implementation unit’s capacity to perform. Measures to strengthen the unit should be incorporated. This should include a project implementation unit staff member with ICT experience and possibly a dedicated staff member on ICT procurement during peak times. Sufficient training for the unit should be built in as necessary.

Other planning tools Activity–output plan shows the relationship between activities and time. Usually expressed as a Gantt

chart, it is frequently preceded by the use of network analysis techniques, which identify dependencies (and critical path) between activities and outputs.

Resources plan shows the resources required to complete the activities in the time identified. A tabular summary showing on the same time-scale as the technical plan should show: Human resources required from the organization and external expertise (type, skills, and numbers)

for both management and technical activities Equipment and other resources required either through purchase or from the organization Cost of these resources.

Procurement plan is devised from the other planning outputs and should be based on the procurement strategy suggested by the planning analysis (see part 2, chapters 8 and 10).

Quality plan, see part 2, chapter 3.

Other topics Other topics that need to be considered include: Business plans and IT and IS strategy (part 2, chapter 9) Risk management: both project risk and asset risk, that is sustainability and beyond, including support

and maintenance and disaster recovery (see part 2, chapter 4) Organizational capacity Organizational change Assistance: engaging of assistance at any stage (internal to the World Bank and external), terms of

reference (TOR), selection, contracts Beneficiary arrangements: how they should be organized, equipped, accommodated, staffed, educated

or trained, and how project management is to be exercised Civil works Cabling and wiring for LAN and WAN Support and maintenance System administration Private sector capacity


34

Outsourcing, application service providers (ASP) and facilities management (FM): see box 6 Dealing with subcontractors Legal and regulatory Scheduling: timeframes should not be too ambitious. The supplier or contractor is likely to be able to

move faster than the beneficiary institution can fulfill contractual obligations and absorb the change. Schedules should also take into account the business cycle of the beneficiary. For example a financial management package should not be scheduled to go “live” at the end of a financial year. Think too of the World Bank procurement and “no objection” timeframes.

Box 6 Illustration: Impact of facilities management decisions

Procurement planning As soon as possible, consider the way procurement is to be organized. It is difficult to separate the planning associated with the design of the system from that associated with procurement; both are important and interrelated elements. A systems strategy that does not take into account the procurement process from the beginning is likely to run into difficulties later on. Procurement planning should create a structured decision chain that complements the systematic management of the rest of the component.

Procurement planning therefore should start at the beginning of the project. Decisions on the nature of the system will have direct implications for procurement: for the type of expertise required, the scale of the purchases, the choice of SBD and types of contract, and the relationships between the parties involved. As examples, decisions on the following will have an impact on procurement arrangements: Complexity of the system Scale of the system Package or bespoke software Use of prototyping, replicating

This case study illustrates the link between the business imperatives of a system (in terms of robustness and system availability), the technical platform, and support and maintenance services. It also illustrates the value of the two-stage bid process A project was instigated for the automation of company registration as part of an investment in its status as an offshore financial center for a Caribbean island. The concept was electronic company registration, enabled by changes to legislation. The bid documents sought solutions giving remote registration combined with security against unauthorized access. Included, as an option, was a request for bidders to offer FM, recognizing a) the high availability necessitated by the requirement to offer service to clients in different time zones; b) the lack of system administration staff within the registry and c) the lack of support and maintenance capacity on the island. In the event only one bidder offered FM services. The cost proved unaffordable and undermined the business case. Alternative support and maintenance services were defined, including resident support during the first year of operation. The bidder that included FM services requested permission to rework the offer to provide a more robust hardware platform and software solution, and include greater hardware redundancy and database mirroring. This reworked bid was the winning bid. The two-stage procurement approach allowed the initial bids to inform the requirement and for these changes to be made to meet the need as informed by the first set of proposals. The resulting innovative, Internet based solution has proved very successful.


35

User and technical support and maintenance services required Any sole source needs

Having considered the implications from the outset and established a procurement strategy, the decisions should be revisited at the various stages mapped out in the plan. At each stage additional information will be available to inform decisions. Project and procurement time scales are always longer than anticipated.

Further guidance on procurement planning and execution is given in part 2 chapter 8.

Cost estimation Other than the standard project costing model a costing model spreadsheet for ICT components is also available. Seek advice in its use.

Even with the most diligent use of a costing model, however, there is a paradox here: sufficient data for reasonably accurate costing mean the products have been designed! In practice loan amounts are often formulated ahead of sufficient knowledge of the products and the methods of delivery. Can a package be customized? Must there be costly and risky bespoke development?

It is also dangerous to accept unquestioningly cost information from “similar” ICT components in other countries. Given three country comparisons for an IS, there can be a tenfold difference in costs depending on ambition, scope, scale, complexity, number of sites, geographical spread, and so on. If the loan amount proves to be stable it may not imply perspicacious estimation. Instead it is likely that the delivery has been cut to the budget!

There are also many projects that do not end with actual implementation. These typically result in studies, plans, specifications, and so on. Cognizance of the overall budget is combined with some heuristic to set an effort and cost estimate. Parkinson’s law will apply during delivery: effort will equal the available budget. This in no way confirms that the estimate is sufficient or that the output is complete, but merely “this is what we could manage with the available budget”. This may not be such a bad thing (analysis and specification could proceed ad nauseam), provided it is recognized as such.

More uncertain are the indirect costs following implementation. Some consideration of indirect costs should nevertheless be attempted. Forewarned is forearmed!

The difficulty with cost estimation is another reason for using grant or loan funds for the preparatory phase of a medium to high complexity IS. Further guidance on cost estimation and the business case is given in part 2, chapters 9 and 1.

In the event that the planning process described in this chapter is not possible and therefore the cost estimate is little more than a guesstimate, some flexibility should be built in particularly in line item estimates within PADs.

Checklist of documentation Box 7 gives a checklist of documentation related to the ICT component that a task manager may expect to see over the course of a project:


36

Box 7 Checklist of documentation

Supervision Formally supervision will be conducted using the Guidelines to Staff on Project Supervision and reported in accordance with the Project Status Report (PSR) format. However, many failures in IT projects are due to poor compliance with otherwise good guidelines and practices. Assuming good project design, the aim will be to ensure the project stays in line with good practice.

It is obvious that the supervision should relate to the plan. However, this should be based on more than the PAD and PSR. Particularly if the task manager has begun involvement at the supervision stage (rather than during preparation), progress should be related to the IS strategy plan, the business case, and the specification. The component log frame should be used for review periodically. Regardless of whether it is going right or wrong, look for deviations from these preparation documents and record the trail.

Relevant to those involved in the project management will be an exception plan. This is prepared when a phase has deviated from the plan, either in terms of cost or elapsed time, or by exceeding agreed tolerances. It shows the actions proposed to rectify the deviation and their consequences. Keep this exception plan under review.

There are no blueprints to implementation and therefore, to supervision. The process and content will depend on a number of factors (see table 2).

Corporate strategy, IS-IT strategy (including portfolio of existing and projected services and assets,project options, selected projects, and financing plans)

Stakeholder analysis, institutional appraisal, business analyses Benefits statement, benefits management plan Cost estimate, business case Sublogical framework Loan documents, beneficiary commitment statements Bidding documents for consultants, contracts for consultants Bidding documents for goods and services, contracts for goods and services, bid evaluation reports HR plans Project plans Project progress reports Business system analysis, requirements specifications, system design, technical infrastructure

design, option papers on the designs Implementation plans Engineering documentation, usage documentation, operation documentation, complementary

procedures Recurrent budget


37

Table 2 Factors affecting implementation and supervision

How the implementation is to be phased Number of modules to be implemented Whether there is to be a pilot and roll-out Procurement methods and issues Interfaces required with other systems Software availability System acceptance strategy and cut-over plan

to the new system State of readiness of physical infrastructure

Scale and complexity of change Internal and external constraints Policy and legislation changes affecting the

business area Scale and complexity of procedures and user

manuals that need to be developed Whether new forms have to be designed The training strategy

Irrespective of these complications there are some key pointers grouped under four main headings that will assist with supervision:

Table 3 Supervision pointers

Business needs Have business objectives altered? Has the business environment changed?

Publicity and communications Ensure effective communications including regular newsletters to those affected by change (external and internal).

Performance and quality Monitor external expertise and review performance during key events. Develop organizational capacity continuously; measure and report on progress at regular intervals. Make a business manager responsible for tracking and realizing key outputs. See that interim and final outputs are signed off to predetermined quality criteria.

Project management Use logical framework as a dynamic project management tool (with cascading frameworks for components). Manage changes to inputs, activities, and outputs through formal and effective change control procedures. Ensure project team has right skills and numbers; if necessary change membership. Involve stakeholders through clearly defined project organization. Ensure progress reports (except independent quality assurance reports) are from the project manager and not the external expert. Have regular and frequent project team meetings. Integrate World Bank task manager monitoring and review visits with team and project board meetings. Involve IT contractors and suppliers at appropriate review points. Ensure that risks are reviewed and managed by the project team and their status reported at all board meetings. Ensure that exceptions are reviewed and managed by the project team and their status reported at all board meetings. Base project board and team meetings on structured agenda with minutes that can be used to assess the quality of project management. Set up formal and consistent procedures for managing project documentation. Have agreed procedures for coping with problems.

Resist pressure to downgrade development objectives to simple equipment upgrade or office automation, but allow scaling up or down depending on progress. If at all possible, predefine the triggers for change of scale. Suspend swiftly if political conditions are not favorable. Provide mechanisms to terminate


38

nonperforming projects and switch funding to more promising ones. Remember, cancelled disbursement does not equal failure.

There is a real difficulty in supervising highly qualified consultants and reviewing complex outputs or products. Two or three weeks of supervision during execution will not suffice. Consider the use of and budget for independent quality assurance or technical audit consultants and agree to their terms of reference in advance. This should cover all aspects: technical, political, managerial, institutional and financial.

ICT components often fall behind plan and the contractor will request changes to delivery and payment milestones to facilitate cash flow. With overambitious plans straining the beneficiary’s ability to carry out the obligations, the contractor’s position may be viewed with sympathy; but care should be taken to relate payment to progress without losing sight of the fact that pieces of a system will be of no use to the beneficiary until a working system has been accepted.

The task manager must be aware of the World Bank’s limitations in milestone reviews. These are not a health or “fit-for-purpose” check, only a no-objection (notwithstanding any added value arising from the review process). There is risk to the borrower and World Bank reputation in doing more than confirming that the procurement may proceed.

Part 2, chapter 12 gives further guidance on a range of possible problems that may be met before going operational with the system.

Completion After implementation a consolidation phase is usually needed to stabilize the system and assess whether planned changes are in place in preparation for the closure of the project. It needs both time and resources to ensure completion of all operations that will make the systems and the changes sustainable. Additional work may be required to: Integrate business activities with the new IS Modernize work practices.

To achieve this, systematic reviews of business activities and work practices need to be undertaken, followed by a period of further changes backed up by training. This might also be a time to introduce revised performance-based job descriptions and to stabilize aspects of user roles and related organization structures. The review team should consider: Achievement against the log-frame Costs and benefits against forecast Effectiveness of revised business activities, rules and work practices Capacity developed and sustainability of the business change Ways of maximizing benefits and minimizing cost and risk.

Unless there is access to documentation, factual information, and adequate baseline measures, this type of review will encounter problems. In planning therefore the review should be anticipated as an integral part of the change program.

Review at completion

The implementation completion report should evaluate transparently any problems with the project, identifying those directly associated with the ICT component as well as those related to meeting broad project objectives. Only in this way will lessons of good practice be learned.

A route map

39

Where to seek further guidance

The text of part 1 is cross-referenced to the companion part 2 throughout. This provides more detailed guidance on selected topics as follows: Chapter 1: Project management Chapter 2: Stakeholder analysis and human factors Chapter 3: Quality management Chapter 4: Risk management Chapter 5: Change management Chapter 6: External expertise, skills, and capacity Chapter 7: Intellectual property rights and licensing Chapter 8: Procurement planning and project models Chapter 9: IS and IT strategy Chapter 10: Business analyses for a proposed ICT Chapter 11: IS engineering Chapter 12: Making the computer aided business system operational.

Technical specifications The procurement web site provides generic specifications for PCs, servers, LANS, and so on. The Global Information and Communication Technologies department and the Information Solutions Group are able to advise on technical specifications. Ask for help formally to ensure you get the right resource allocated. Advice on the accuracy, completeness, openness, and consistency with loan objectives would require the resource to be provided with all the background information and may include a site visit.

Procurement and SBD The procurement web site provides samples of the latest SBD and the rationale for changes and additions to these documents. There is also a series of IT procurement guidance notes on such topics as: Contracting for IT maintenance and technical support services Complex systems engineering and integration: contractor continuation options Specification of brand names in IT procurements Selecting an SBD for IT procurement Pricing of foreign goods in IT procurement contracts Evaluation of nonprice factors in IT procurement.

A route map Glossary

40

Glossary Acceptance test: final evaluation of an IS by the user, prior to live operation, to ensure that the IS meets all specified requirements. Application software: a commercially available set of one or more computer programs that contain predefined data and functionality and are designed to provide a complete business application, for example word processor or database. The software may or may not offer the facility for customization to meet specific requirements. Architecture: a high level view of system design, the frame that holds the more detailed parts of the design. Benefit: enhanced efficiency, economy, and effectiveness of future business operations to be delivered by an IS, that is, an improvement in the way in which a business area meets its objectives, brought about by the implementation of business change. Benefits management: the identification of potential benefits, their planning and tracking, the assignment of responsibilities and authorities, and their actual realization. Benefits realization plan: the controlling mechanism that governs the identification and structuring, optimization, realizing and tracking, and reviewing and maximizing of potential benefits. Bespoke: system designed or modified to meet the specific requirements of a client. Bespoke development: the task of designing, producing and testing bespoke software. Business: an organization, its structure, and activities. Business activity: a discrete, identifiable task that encompasses the transformation of one or more inputs into one or more outputs, expressed as what is accomplished, not how. Business aims: the purposes for which an organization or business area exists. Business analysis: the determination of a business’s purpose, its business needs, and how those business needs can best be satisfied. Business area: a discrete part of an organization that is managed as a single cohesive business, or a related set of businesses that exhibit common business needs. Business benefit: see Benefit. Business case: the overall justification for the business strategy or IS strategy proposals defining the financial and other benefits they are expected to deliver, and the cost, timescale, and other constraints within which they will be required to operate and against which their performance will be evaluated. The basis of comparison is the effect of proceeding according to current plans. Business change: a change in the way business is conducted, brought about by either internal factors (such as change of business direction) or by external influences (such as business takeover or merger, statutory requirements changes) in order that business aims may be achieved. Business needs: the fundamental activities, processes, and information required in order to meet the statutory obligations and business objectives of the organization. Business objective: a specific, planned achievement for furthering an aim. It may be specified as a planned output or level of performance (that is, efficiency, economy, or some attribute of physical output). Achievement may be distant and influenced by factors beyond the manager’s control. Objectives should be specified as measurable milestones that mark progress toward achieving the organization’s long-term business goals. Business planning: the process of developing a business strategy and its associated plans. Business process: a set of logically related tasks or activities, linked by flows of information andr materials, by which an organization achieves its business objectives. Business requirement: a description of a required feature of proposed changes that may relate to business activities, work practices, or IS. Business rule: an explicit rule (part of operational guidance) on what activities are to be performed, how


41

they are to be performed, and when. In certain cases this may be manifested as a constraint on how, why, or when an activity is carried out. Business strategy: the organization’s long-term plan for achieving its aims. The strategy should define the organization’s future business direction, needs, and objectives, and the resources required to meet them. In organizations composed of many business units, separate strategies may be developed for each unit, and brought together into a corporate strategy. Capacity: quantity and quality of resources — financial, human, and institutional — available to fulfill a task or set of tasks. Capacity development: the process of enhancing the quality of an institution’s capacity (such as training, workshops). Centralized system: one or more physical computer units located at a single site to provide processing capacity for all users of the system wherever located, for example, mainframe serving dumb terminals. Champion for change: a recipient organization staff member who supports a particular change and who will act as an effective advocate of that change within the organization. Change management: the implementation of business change. Coding standards: standards governing the quality of software development. These may exist at company, industry, government, or international level. Communications architecture: the hardware and software components of an IS which are necessary to permit two or more computers to communicate with each other. Communications hardware: equipment to facilitate transfers of information between computers, for example a modem or network card. Communications software: a program dedicated to facilitating communications, such as software to control a piece of communications equipment or a protocol to facilitate data transfer between computers. Competency: the ability to perform a particular task to a required standard. Consultant: an individual, company, or government agency providing external expertise. Core competency: the ability to perform those functions that are “mission-critical” to the survival of the organization. Culture: the manner in which members of an organization interact with each other, the organization and the outside world Data: a generic term for information which is, or is about to be, stored by an IS and which may then be transformed by, and output from, that IS. Data architecture: a logical model of the data to be held on a computer system, such as file and record formats. Data backup: the process or the result of copying data held on a computer system for security purposes. The result is normally stored on a separate medium and at another location. Database: a collection of logically structured data supporting the operations of the organization. Data management: the control and maintenance of data structures. Data models: a logical representation of the information and its interrelationships stored within an IS. Data protection: measures established to prohibit the misuse of data by unauthorized persons. Data standards: standards relating to frequently used data types, for example, a data item which is to contain a last name should have a standard length and should only allow for alphabetic and punctuation characters. Such standards are enforced to avoid unnecessary variation across applications and between systems. Data structures: a logical representation of a set of data and its relationships or the physical organization of data within an IS, such as a database. Data take-on: collection and collation of new data into an IS or transformation of existing data into a new format. May be performed in either batch or interactive mode. Data transfer: movement of data within an IS or from one IS to another.


42

Database Management System (DBMS): a system that organizes the storage of data and controls access to that data in such a way as to facilitate retrieval for many different applications. Dependency: where a static or dynamic object or process is reliant on another such factor. Design deliverables: the resultant documentation, models, or prototypes that are generated during the design stage of an IS. Development: see Software development Development audit: the verification of the correct implementation of a design or specification by means of an independent review of procedures and outputs generated during development. Disbenefit: an unfavorable outcome of business change, either avoidable (such as the result of bad design or implementation) or unavoidable (such as an inherent part of the change process). Distributed system: a number of physical computer units linked together, either at one site or across multiple sites, to offer localized processing capacity for all users of the system, such as PC networking. Environment: the circumstances under which the business operates — cultural, economic, political. Escalation procedures: a structured method of increasing priority in order to resolve a problem. Facilities management (FM): the outsourcing of services — for example IT, catering — which are not part of the core business activities and which the business does not need to provide from internal resources. Full study: a study undertaken to determine the precise requirements prior to the acquisition of a system. Functional requirements: a collection of features of an IS deemed necessary by the organization to complete specified business functions. Informatics: the science and art of information management applied to information needs and use. Information and communication technologies (ICT): hardware, software, networks, and media. The stress on the word communication is deliberate, but in the context of this toolkit communication is more about connectivity and the exchange of information rather than the telecommunication infrastructure over which the information may be transmitted; Information system (IS): any procedure or process, with or without IT, which provides a way of acquiring, storing, processing, and disseminating information that supports the business needs of an organization or discrete business area within an organization. The emphasis in this guide is on IT systems or, more precisely, computer aided business systems, which include applications and their supporting infrastructure components. Information technology (IT): is the use of technology, such as computing and software, in support of information processing. In this guide the term is used more to refer to the technical aspects (like hardware, the platform, or technical architecture) or more simple components involving only the procurement of goods. Institutional capacity: human resources and systems, existing within or available to the institution to enable it to perform its business functions and adapt to change. Intellectual property rights (IPR): ownership of methodologies, techniques, and tools by companies or individuals who are entitled by copyright and trademarks legislation to control and charge for the use thereof. Intelligent customer: the capacity of an organization to manage external resources so as to ensure that those resources provide the services required cost effectively. Logical framework: a framework identifying the goals and purposes of a project or program, its outputs, the inputs and activities needed to achieve them, and the means of verifying their achievement. Made to measure: see Bespoke. Management information: information required by management to assess the effectiveness and efficiency of a business area. Management of risk: an overall process by which risks are analyzed and managed. Migration: the transition from an existing IS environment to a new one. Network architecture: hardware and software IT components used as part of a distributed system.


43

Off the shelf: predetermined IT components available in the market (converse of bespoke). Office services: the infrastructure required for an office to function — accommodation, furniture, equipment, ancillary services such as messengers and cleaners. Open systems: IS that utilizes recognized industry standard IT components to allow the transfer of software and data between them. Output and performance measures: measures of the extent to which outputs and performance are achieving predetermined objectives. Outputs: deliverables generated either during the acquisition of, or as the end product from an IS, such as design documentation or printed output reports generated by the computer system. Outsourcing: see Facilities management. Ownership: acceptance by the user that the system belongs to them and is to be used by them for the benefit of the organization (that is, as distinct from regarding it as something foisted on the organization by outsiders and to be marginalized and ignored). Package software: see Off the shelf. Prototyping: use of a substantial experimental system to clarify requirements, or test a design before full-scale development and deployment. Sample bidding document (SBD): World Bank sample bidding documents. Several have been developed for ICT requirements. Soft systems methodology (SSM): a methodology for defining the purpose of a business area — an essential prerequisite to defining its IS requirements. Useful in areas where there is not complete agreement on ends and means, it provides an organized way of tackling messy problems. Software: a set of one or more computer programs that contain predefined data and functionality. Such software may or may not be tailored to meet specific requirements and can be developed internally or externally. Software development: the creation of the software components of an IS, normally to a formally agreed specification. Software development tools: terminology usually associated with software development, to assist with the generation of IS. Software engineering: the establishment and use of sound engineering principles to economically obtain software that is reliable and works efficiently on real machines (Fritz Bauer, “Software Engineering: a report on a conference sponsored by the NATO Science Committee,” 1969). Although a very early definition, it states the main principles. Software package: see Application software. Stakeholder: a person or entity inside or outside the organization who may be affected either favorably or adversely by the changes proposed. Stakeholder analysis: the determination of the views of stakeholders regarding proposed solutions, leading to a common understanding of problems and an acceptance of solutions. Standard software: see Off the shelf. Support: background services for users, such as maintenance, repairs, advice, and help desk. System analysis: the determination of the processes, tasks, activities, and information required by an organization to achieve its objectives. System architecture: the foundation specification upon which the software elements of an IS are built. System design: the development of a logical system that meets the requirements of the systems analysis. System development standards: see Coding standards. Third party software: software bought from a second party but in which a third party has intellectual property rights. Tools: see Software development tools. Turnkey contract: a contract for the supply of an IS, where the contractor has full responsibility for


44

supplying, delivering, and installing all the hardware and software; for providing training and systems documentation; and for maintaining the complete system. UNIX: powerful multiuser operating system developed in the 1970s, originally for scientific and engineering applications, but since extended into business functions. Because of its processing requirements this operating system is usually run on high specification computers. User acceptance test: see Acceptance test. User role: business and computer user activities, which determine the design of an IS. User support: see Support. Workflow model: a manual or automated model used to calculate the processing and storage requirements of an IS, based upon the levels of business activity. Work practice: the low-level business activities of an organization. Work practice analysis: the documentation of an organization’s existing low-level business activities to assist with the design of an IS. Work practice design: amendment of existing work practices to accommodate changes to, or a new IS. Work practice model: either a basic model showing the actual activities carried out in the business or business area, who carries them out and where; or a model of alternative activities and roles to demonstrate possible improvements in work practices. Workshop: a formal meeting, managed by a facilitator, whose objective is to resolve issues by debate, with all sides stating their views and eventually coming to an agreement.

a route map for ict components in world bank projectsdocuments.worldbank.org/.../pdf/31886v1.pdf ·...

Documents