TASK MANAGERS’ ICT TOOLKITGood Practice for Planning, Delivering,and Sustaining ICT Products© 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 thegovernments 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 withcomplete 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 202522-2422,
e-mail: pubrights@worldbank.org
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 fromthe Global Information and Communication Technologies (GICT) Department budget. It has
been prepared with enthusiastic support and contributions from many persons throughout theWorld Bank Group. The core team comprised Robert Schware, Samia Melhem and Juan NavasSabater. Valuable contributions and comments were received from World Bank Group
colleagues including (in alphabetical order): Ghassan Alkhoja, Carlos Braga, 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,
Arleen Cannata Seed, Ramesh Siva, Hugh Sloan, Eduardo Talero and Eloy Vidal. We are gratefulfor the consulting services of Crown Agents for Oversea Governments and Administrations, inparticular Ron McGill and Peter Norkunas, and the editing services of Shampa Banerjee.

Good practiceGood practiceInformation system projects appear to have an alarmingly high failure rate, even indeveloped countries — half of large implementations fail, half suffer disputes.

W

elcome to part 2 of the task managers Information and Communication Technologies(ICT) toolkit, designed to give guidance on ICT components in World Bank operations.

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 tocategorize ICT components in terms of complexity and “walks through” the different stages ofpreparation, implementation, and supervision.
Part 2, Good practice goes into greater detail. It is intended that this second part would:•

For task managers and task teams provide a summary of the various disciplines relevantto the conceptualization, planning, delivery, and sustainability of ICT-based products•

For project implementation units provide guidelines that will help them better prepare forand monitor ICT components•

For borrowers and beneficiaries provide a primer on good practice•For expert implementers provide orientation and nomenclature, and an aide-mémoire forthe formulation of project plans, expanding the focus beyond mere technology.

The information contained here pertains to “complex” ICT components which may require
tailored information systems (IS), have a wide impact, have several subcomponents, have asignificant management dimension, have relatively high financial worth, or are key to the successof the loan.
This section of the toolkit is not intended to allow an inexperienced person to use theinformation and execute an ICT component without any expert assistance. However, anybody
may benefit from an enhanced ability to dialogue effectively, especially with experts.
The toolkit is independent of any particular technology, including technologies for project
management, system engineering, and so on. There are instances when a specific approach isused to present a topic. At all times this should be viewed as indicative and not constraining.
This is a vast subject with any amount of guidance available. The difficulty lies in what to exclude.
The guiding principle has been not to glorify, mystify, fantasize, overemphasize, or overestimate
ICT and its place in development. This toolkit attempts to be a simple, practical treatment,
focusing on World Bank operations. It brings together in one place the experience contained
within the World Bank, providing tips, checklists, and reference material. Importantly, it prompts
readers toward further assistance.

Good practice

Structure of part 2This part has two further divisions: techniques and topics pertinent to the delivery of an ICTcomponent (chapters 1 to 8), and steps in the process of delivery of an ICT component(chapters 9 to 12).
1.

Project management ............................................................................................................................52.

Stakeholder analysis and human factors .........................................................................................30

3.

Quality management..........................................................................................................................34

4.

Risk management ...............................................................................................................................43

5.

Change management..........................................................................................................................62

6.

External expertise, skills, and capacity ............................................................................................66

7.

Intellectual property rights and licensing........................................................................................75

8.

Procurement planning and project models ....................................................................................85

9.

IS and IT strategy...............................................................................................................................98

10. Business analyses for a proposed ICT ......................................................................................... 115
11. IS engineering .................................................................................................................................. 125
12. Making the computer aided business system operational ......................................................... 145

FiguresFigure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure 10
Figure 11
Figure 12

A typical project planning process
Illustration of relationships between project management and IS implementation
stages
Product — Client — Attribute — Quality concept
Generalized model of change management (control processes)
Examples of possible commercial structures for ICT components
Examples of possible commercial structures for ICT components (page 2 of 3)
Examples of possible commercial structures for ICT components (3 of 3)
Linkages between corporate strategy/plans and IS/IT strategy/plans
Processes during early stages of product life
Definition phase — techniques to bring increasing focus
General model for the workflow for product definition and relationship to build
phase
Building blocks for e-services

15
17
34
39
94
95
96
104
125
127
129
139

2

Good practiceTablesTable 1
Table 2
Table 3
Table 4
Table 5
Table 6
Table 7
Table 8
Table 9
Table 10
Table 11
Table 12
Table 13
Table 14

Log frame matrix structure
An example for an ICT project: Tax Administration Modernization
Stakeholders with interest in business change
A matrix of assets versus threats and vulnerabilities
Protective measures to consider for an ICT environment
Format for analysis of threats
Parameters for complexity
Hierarchy of skills required by an
Risks from inadequate contractual provision for IPR
Policy dimensions for national ICT strategies
Examples of high level benefits from an
Requirements specification contents
System design options contents
System design statement contents

26
26
31
43
45
49
50
69
79
109
122
141
142
143

3

Good practice

Project management
Chapter 1

All indications are that organizations using a project approach experience better
control, better client relationships, shorter implementation times, lower costs, higher
quality, greater reliability, sharper orientation toward results, and betterinterdisciplinary coordination. As a rule of thumb: projects should invest 10 to 15
percent of the effort in management activities.
What this chapter is about

This chapter provides an overview of the discipline of project management, with particularreference to ICT projects. The bulk of the content pertains to medium to high complexity
IS, rather than simpler projects (for example, narrowly implementing hardware).
Although the World Bank uses “project” to mean the work program supported by a loan,
for the purposes of this chapter, “project management” is specifically the management of
the implementation of an ICT component within a World Bank project.
Ideally the formal project management role should be filled by the beneficiary organization.
There are a number of scenarios, however, where the role may be filled wholly or partiallyby external resource. This chapter assumes an external resource. It also assumes thereby an
ICT component where the important definition and design work is done after the loan has
been signed.
Structure of this chapter

Introduction
A definition of “a project”
Characteristics of projects
ICT projects in the developing context
Environment for successPreparing a project
Running and controlling a project
Winding down
What to expect from the project manager
Where to seek further guidance
Annex A: Role of the steering committee
Annex B: The sublog frame

5
5
5
6
8
12
19
21
21
24
25
26

4

Good practice1.

Techniques and topics

Project management

Project management

Introduction

Projects have occurred throughout history — take for example the Great Wall, or the Pyramids! However, modern project
management is said to have begun with the Manhattan Project. The techniques and disciplines were honed in large andcomplex research and development and in massive constructions, before project management came to stand for “getting
things done” — a now ubiquitous application in most tricky or novel circumstances; and unfamiliarity with andapprehension of technology and technologists, a high degree of implementation discretion, and the intrinsic social
dimensions make ICT particularly novel and tricky.
Although management theory would apply to project management, there is a profound difference between them. The
underlying assumptions in management theory are profit, growth, and survival of the organization being managed. While a
project might, fairly, have a profit objective, long-term growth and survival would never be the goal. Projects are
distinguished by their fixed objectives, fixed resources, and limited time frame. A successful project will terminate. Its aim
is to terminate — upon delivery of its intended products. In general, if it terminates early, then so much the better!
Perhaps stemming from this defining characteristic, projects differ from enduring organizations in other ways. There areusually firmer and clearer, and hence simpler, objectives, described in terms of the products required to be delivered. There
are more tightly defined budgets, constraints on resources, and delivery schedules. There is more frequent monitoring,
feedback, and control, and quicker response to deviation from expected quality, schedule, and budget.
There are consequences. Projects are less nurturing of their human resource — management theory might apply but thereis less time to apply it, so it is applied less diligently. In any case, the project would have no direct reason to nurture beyond
narrow self-interest — the delivery of the project’s products. Projects can be abrasive — stemming from the need for ahighly task-orientated project team. Projects inspire jealousy from the incumbent organization. A project might be seen as
the intruder — a statement or an admission that the incumbent was incapable of achieving some desired outcome.
A definition of “a project”

A project is a temporary organization of managed resources and processes, which seeks to deliver a predefined set of
products to a defined quality, using defined resources and finances, and within a defined and finite time scale.
Characteristics of projects

A project is a unique, one-time activity, divided into subtasks that together are sufficiently complex to require careful
coordination and control. A project may itself be part of a carefully coordinated program.
A project is an intervention that interacts with and alters the standard, ongoing operations. Management by exception isstandard (and there are usually many exceptions) and conflict is the norm — conflict for priority, for resources, forinteraction, for solution-generation, adoption, and so on.
One person — the project manager — will be responsible for the detailed planning, coordination, and ultimate outcome ofthe project. The responsibilities are often interdisciplinary, interfunctional, and more akin to general management than line
management.
A project will deliver products — goods or services, but more likely goods with attendant services. For IS and information
technology (IT) projects the products would consist of all or some subset of revised business organization processes andresources, technologies, and attendant services for their implementation.

5

Good practiceTechniques and topics

Project management

It is important to recognize that IS are social systems. The ramification of new or changed IS on an organization can besignificant and reach beyond technology. While deployment of ICT requires a rational engineering approach, it must berecognized that concomitant social engineering is required. This is often far from rational.
ICT projects in the developing context

While the following comments may not apply in all World Bank client countries, they may well apply in the least developed
ones.
The role and limits of ICT are not well understood
The developing world is beset by problems of great magnitude. There is a desire to improve the human condition in
depressed and sometimes appalling conditions. A quick fix will always have appeal. The purpose of ICT in this context isoften confused. It is confused because the technology is revered and the use of it is seen as an end to itself. This is very
deceptive.
ICT on its own does not provide water, food, housing, health care, or education. Nevertheless, it is alluring because it
enables high levels of activity at a low capital cost. The activity is apparent but is confused with productivity. It may notactually contribute very much to the underlying objectives.
Technology is a tool that, if properly directed and understood, may be able to help in some small way in providing better
services that improve the human condition. But ICT will not permit an underdeveloped society to leapfrog the conditionsof its material environment. There are no silver bullets.
Management theory — values disjunction
Good practices of the developed business world do not always easily translate into the developing context. Cultural
attitudes are not necessarily shared: profit orientation is not everywhere entrenched; there is no general acceptance of atolerable apportionment of wealth; also not present are approximately shared values of the criticality of time, schedules,
efficiency and effectiveness. The only constant is change.
Public institutions can be like clubs where a form of democracy rules rather than a place dominated by leadership,
productive output, tight time targets, and financial performance goals. “They pretend to pay us and we pretend to work”: itis far more common for information to be withheld than shared.
Time may be seen as less important: “tomorrow”, “mañana”, “later”, “soon to come”, usually do not have a shared meaning
when a project manager with developed world attitudes interacts with a developing country client. The project manager
may log the new piece of data into a Gantt chart and be disappointed and frustrated when the predicted event does notoccur. The Gantt chart may be treated as a curious mural rather than a management tool!
The organizational dynamics of developing world public institutions may be unfamiliar to an external project manager. Ifthey are of sufficient stature these institutions may be very attractive career prospects — not necessarily for the purest
reasons. Some institutions have long waiting periods for new recruits — but so lucrative and well regarded, and highly
sought are the new positions that the wait is worth it. However, salary and promotion may not always be dominant
motivations. Whereas it is often considered a privilege to work in a high-tech IT section, in many societies this may beconsidered a place to be sent to for some failing, well away from the public interface. The people within may not bedisciplined to high productivity consistent with rational, public institutional objectives. There are few effective penalties forpoor performance, and no effective procedures for dealing with pervasive malpractice.
Project management may be considered a particularly sharp, mean, and directed subset of management. The dedication to“getting the job done”, the sharper focus on tight schedules and budgets may not be understood in the same way.
Consequently, there may be greater propensity for conflict in a project environment, especially where external members ofa project team are driven by fixed and hard-negotiated budgets that place a premium on lowest price over quality.

6

Good practiceTechniques and topics

Project management

The bottom line is that there is a displacement of values that propels firmly held developed world management maxims
toward quaint theory rather than practice. Yet, paradoxically, in this arena it is precisely these values that are desperately
required in order to achieve the material improvement that is desired.
Other perspectives in the developing context
Change is not yet a constant. Many public institutions remain in a time warp. Change is resisted determinedly evenif passively. The change being sought may well be argued to be rational from the perspective of the public goalsof the organization. However, there will be challenging patterns of entrenched behavior.
There is an underlying developed world assumption when planning and executing ICT projects: that in general,people skills are a commodity that is readily available. Market factors may drive prices but supply is more or lessguaranteed. In the developing context this may not hold good. Regardless of price, skills shortage may be acute,especially during the long haul of operation. This may mean that a project using imported skills may be successful
during the delivery phase, only to falter when the operation is turned over to the operator. Skills pertaining to thetechnology of management are perhaps more at risk than those of IT-specialization.
Donors provide a soft line of finance. While loans may be a little “harder” than grants, there is nevertheless asentiment that “it is not our hard-earned money”. From this arises commitment that is less robust and moremercurial.
ICT, management technology, technology in the broad sense, may provide many solutions. However, if the
problem is simply not recognized, the solution may be disregarded or at best undervalued.
There seems to be a greater disparity between wage structures and the budgets managed by individuals. There
are relatively large fixed costs pertaining to the introduction of ICT. There are essentially worldwide
benchmark prices that are not greatly affected by local cost factors. Local cost factors are not significant to
ICT for two main reasons:
There is widespread evidence that ICT is risky. To mitigate risk, novelty is avoided through customized offthe-shelf solutions. Almost invariably, whether for hardware, systems software, or application software, thismeans the purchase of a solution from an international provider. Local costs are then limited to labor for
installation, support, and maintenance.
Local skills are highly mobile: they move toward developed world markets. To retain skills, a default paritypricing scheme exists. So, even local service costs for credible skills are not available at great discounts.
Employees of public institutions are then placed in positions where they control significant budgets but onmeager wages. Aberrant behavior is classic.
New information systems effect change to human activity systems. A particular note in the World Bank context:
implementation cannot be treated as a purely technical or administrative matter handled through the bureaucracyof a procurement procedure.
Design and implementation horizons should be kept short. While doing so, the “big picture”, the longer-term
objectives, should be kept in view to mitigate the creation of disjointed information system “islands”. The bridging
between such islands never seems to be simple. Shorter implementation steps, of say one year, ideally each with aproduct tangible and beneficial for end users, provide several benefits, including avoidance of out-of-date
solutions. Beware the pace of change within IT — by the end of the fifth year of the loan, perhaps only thesecond full year of implementation, the system is likely to be criticized as obsolete. An alternative approachpromoted by technology suppliers may be the use of a “technology intercept strategy”. However this is very risky
and not appropriate in the development context. Shorter steps also provide some protection in the politicaldimension. There is more likelihood of consistency of direction and continuity of key people. For example in amore extreme case, during a tax project in Hungary, there were five chief executive officers during the life of theloan. Longer, all-encompassing projects may also be unmanageable. For components within World Bank projects,
the right time to influence and structure the implementation steps is during the project appraisal document (PAD)
preparation. Even if the steps are not fully identified, the objective of implementation by stages should be set andlater monitored.
Task managers are supported by a monitoring and evaluation toolkit. There may be contradictory imperatives.
From the perspective of the successful implementation of the component, emphasis needs to reside within the7

Good practiceTechniques and topics

Project management

development objectives rather than in any disbursement imperative. Cancelled disbursement should not be equatedautomatically with failure.
Outcomes are not accurately reported. Nobody wants to be associated with failure, so unless it is so prodigiousthat it cannot be concealed, few postimplementation evaluations report failure. This is a common disease but isacute in public institutions where profit and loss are not so sharply felt, and more acute in the developing context
where good governance is not transparent, and the “service” aspect of civil service is neglected.
Environment for success

The preceding section seems to suggest: “why bother”. However, there is consensus that ICT has a crucial role and that
there are tangible benefits (see also chapter 10, annex A — Managing benefits):
Reduced service times
More uniform service delivery
Increased revenue
Increased transparency
Reduced corruption (both reduced opportunity and greater risk of discovery and consequent penalties)
ICT can make a difference. Available, accurate, and timely information reduces uncertainty of development: how many
taxpayers, how many farmers, how much water, how many breakdowns, how many students or teachers, how muchabsenteeism, what volume of imports? It is not uncommon for projects to be launched where the basic business statistics
are not reliable.
There are successes. Experience indicates organizations using a project approach experience better control, better client
relationships, shorter implementation times, lower costs, higher quality, higher reliability, sharper orientation toward results
and better interdisciplinary coordination. As a rule of thumb: projects should invest 10 to 15 percent of the effort inmanagement activities.
To create the right environment for success, develop shared objectives, agree on products, and verify commitment. These
recommendations may seem trite, but they are valid and sometimes overlooked. A healthy project and successful
completion are much more likely when good preparation is made well before the project commences:
Too many projects are cast adrift without adequate clarity in a lazy hope that execution is merely a procurement or
technological issue. Somehow these issues are supposed to resolve themselves. This gives rise more than anything
to conflict between the parties, time overrun at the very least, or more likely abject failure. Be well prepared andgive the project a good chance of succeeding!
Both the borrower and the beneficiary must be part of the process. The key stakeholders, decision-makers, andchief patrons of the project should be identified and consulted prior to and upon project commencement.
When confronted by a request from within the borrower for loan support for an ICT component, the task
manager should encourage the beneficiary to describe the component and be as succinct, clear, and comprehensive
as possible. The description should contain
The vision for the project
A detailed description of anticipated products and the conduct of the projectIts benefit statements
Its business caseIts goals, purposes, outputs, and activities (essentially its log frame)
Its tie-in to any wider loan objective.
This submission should be kept to a few pages and a respondent from the beneficiary identified for any follow-up
information. If there are technology issues beyond the competence of the task team, advise that experts will
review the submission. It would be improper to debate or confirm a request without adequate knowledge.

8

Good practiceTechniques and topics

Project management

It is necessary to determine whether the project has a hidden agenda. For example, a modernization project toupgrade hardware and software for an existing system may not have any commitment to success other than forpolitical or personal gain.
It is also common to have strong supporters as well as strong antagonists within the beneficiary organization. For
example, a manager may be annoyed by the impending intrusion of an ICT project; a long standing administrator
may prefer that procedures remain the same as before, because that eliminates the need to learn something new, acustoms collector may want information about inland warehouses to stay inexact. The antagonists need to beappeased or otherwise engaged, or at least identified and discussed with the borrower.
For conflict mitigation, the borrower and beneficiary need to be in accord with the World Bank. It is healthy tohave an open exchange of views. Avoid circumstances where the borrower seeks to impose change on thebeneficiary through ICT. This alone would fail. At the very least ICT would need to be accompanied by changes inthe executive cadre, and through them in the culture of the beneficiary.
Within the beneficiary organization the actual users, especially those directly affected, need also to be placated. It isbetter still if they are committed, although, it might be a little naïve to require this. Remember: IS are social
systems, new systems disturb old social structures, and change has many enemies and few allies.
The shared statement of objectives and products needs to be documented. Debate should be encouraged toestablish a healthy partnership. There should be no rush to enter a full-scale project until this is established.
Politics will come into play.
Seek to maintain continuity of staff. This applies both in the World Bank and the beneficiary. As projects are
typically leanly staffed, most of the staff is crucial for a project. Changes to project personnel can lead to
disruption through:Changes in direction
Changes in culture
Loss of project knowledge
Simple loss of labor.
To mitigate change, seek commitments over the required period.
When modernization commences, organizations, especially in the developing context, find themselves adrift on asea of uncertainty and impending change. Objectives and products of the project often modify over its life. An
environment of healthy dialogue should be encouraged so that the project is kept in alignment with theorganization or, where the priorities and requirements change sufficiently, abandoned. Abandonment in such cases
is not a failure! It represents mature and professional decision-making.
Objectives might be of the nature of one or more of the following: business, loan, regulation, commerce, finance,
people, society, and technology. They need to be kept measurable, achievable, and realistic.
There may be contradictory objectives that need to be balanced by the project. For example, expanded, supported
public access to the Internet may disturb existing Internet service providers (ISP).
Note that shared objectives and the elaboration of agreed products and commitment should settled before any
loan is signed and reconfirmed before any procurement has commenced and or any contract entered. The project
should seek again at inception to reconfirm and adjust for inevitable drift that would be exacerbated by any long
delay.
Support the project champion, maintain support offered by the project sponsor, appoint the right project manager, develop
a healthy relationship with the client, and explain to the client what the project will do.
A serious project needs a serious, respected, energetic champion. The champion needs to identify himself. Someschools hold that champions can be nurtured. That may hold true in the context of an IT department within theperpetual organization. In the context of an ICT component within a World Bank loan, the project, that is thecomponent, is usually already launched. The champion needs to be there already.
Many projects may be simple: purely the introduction of some noninvasive, unambitious technology, such as
personal computers for word processing or an intranet to be used more for casual chatter than hard business. The
main requirement is reduced down to assigning singular responsibility for completion in an uncontroversial
environment. However, a meaningful IS project of significant ambition is an agent introducing social change

9Good practiceTechniques and topics

Project management

within the organization. There will be resistance. A project may have financial muscle but it remains vulnerable tosimple sabotage such as through passivity, avoidance, and obstruction. The role of the champion is to foster anenvironment agreeable to the changes, winning the social battle for hearts and minds.
The champion will be an insider, possessing a power base within the organization. A project may start with asupply of patience and credibility credits, but these gradually expire as time goes by. The champion needs to keepfaith with executive and users when enthusiasm wanes.
Every project requires a sponsor who provides the resources and formal framework for the execution of the
project. The sponsor may also champion the project. There are some advantages when the sponsor is thechampion. Sometimes the sponsor and champion may be different individuals and while providing opportunity for
conflict, this can also strengthen the message of the champion. Either way continued support of the sponsor isneeded in order to maintain supply of the necessary resources and to pave the way through formal lines ofauthority. The sponsor needs to be identified and kept informed.
A project will have a project manager. The project manager has the mandate and responsibility to deliver theagreed products at agreed quality with technical excellence and within time, cost, and resource constraints. The
project manager needs to have the right stuff — a blend of appropriate experience in general management skills
across finance, engineering, logistics, procurement, commerce, negotiation, planning, resource allocation,
disturbance handling, control, change management, and quality. The project manager will be figurehead, leader,and primary liaison person, and experience in the business of the client will be useful. The project manager
requires energy and determination, a belief in the project management disciplines, and an ability to motivate aproject team toward the project goals and maintain momentum.
The relationship between the project manager and the project champion must be symbiotic. Occasionally the
project champion is the project manager. Again there are advantages and disadvantages to such a situation: theproject champion may get bogged down in detail, and distanced from the real business of change, or the project
manager may be ill equipped to simultaneously handle engineering and politics. As there are usually different skills
required, a technical project manager often supports the project champion. As an outsider, the project manager
may also make an effective, conveniently dispensable change agent.
Be prepared with appropriate skills in adequate numbers internally, adequate understanding externally, and requisite
resources. Some pointers to constructive preparation are described below.
As noted above, a healthy project needs a good deal of preparation prior to commencement. According to Sun
Tzu: “Planning completely creates victory. Planning incompletely causes failures.”
Condition the beneficiary to understand the meaning project management. This can be a long process. The
training and guidance materials for project management should be provided to the beneficiary. There will beconflict and difficulties, but this should help to reduce surprises.
Ensure the beneficiary is a participant to the preparation. The formal project manager should be appointed fromthe client organization. This is often an executive role. Most of the description herein pertains to technical project
management.
There is a management truism: failure to plan equates to planning to fail. In order to be prepared to execute theproject, the project manager, the project team and the beneficiary, at the very least, need to know where they are,where they want to be and how they are going to get there.
For an ICT project there should already be an IS and IT strategy. Refer to chapter 9 on strategic planning. The
plan while constraining assists the project to focus on the objectives and not drift beyond its mandate, expending
resources to address open-ended, often arbitrary or value-based decisions.
The plan is multifaceted and steers the project to its conclusion, accommodating the technical and administrative
steps toward delivery. The true project manager would also be prescient of the likely risks, but not necessarily
invoking corrections, since the risk may be a low probability occurrence or the correction a high-cost action (seechapter 4 on risk management).
To complement the plan during execution there will be a control system. A facet of the plan will be description of
the procedures by which progress will be monitored, deviations corrected, and change in plan assessed andaccommodated in a revised plan.

10

Good practiceTechniques and topics

Project management

The plan should include the termination of the project.
Plans should be well researched, realistic, and thoughtfully constructed. It is usually possible to plan the near term(say one year) with some certainty. The longer term can only be indicated based on the input of earlier phases andthe likelihood of shocks and surprises. Plan for the full project but plan in detail only so far forward as isreasonable — execute in stages. Beyond the defined prepare indicative plans. An indicative plan is still very useful— it represents best knowledge and assessment at the time of preparation and provides a basis for interpreting
new data. The plan may prove to be incorrect. In fact, an accurate plan for any project of consequence can only be
written after the project is completed.
The final act of preparation is organization: ensuring that necessary resources — human, material, and financial —are obtained and structured to deliver the project products. Do not commence the project without guarantee of atleast adequate resources, with contingency. (However, be aware that superfluity of resources would be a fatal
distraction.)
Resources need to be organized. The project organization will evolve as the project progresses through its stages.
An external project board or steering committee is vital. In principle it should exist prior to commencement. The
steering committee provides the forum for confirming that the project remains aligned with the beneficiary’s
business, user, and technological objectives, and should be constructed accordingly: with representatives of thebusiness, user, and technology authorities within the organization together with authoritative representation fromorganizational elements with essential key inputs. The tasks of the project board would include confirming
progress, addressing obstacles, correcting performance, reaffirming resources, and coordinating with parallel
activities. It provides a stage for the project champion and the project manager to inform and motivate the wider
audience. Refer to annex A for a synopsis of the role of the steering committee.
The understanding of external parties is likely to be ephemeral and mercurial, perhaps vexatious. This may beoffset by periodic broadcast of project news, but is best addressed by delivering tangible benefits; therefore, where
possible plan to deliver viable and useful products early.
Execute with discipline, using resources and delivering products according to plan, maintain a healthy relationship with theclient, and keep the client informed.
The environment for success during the execution is when activity is in accord with the plan, with the agreed
resources — human, material, and financial — engaged effectively in the right quantity and at the right time.
Delivery of the required products should be the consequence.
Informed technicians diligently applying technology known to them is by far preferable to and less risky than
excellent technology in inexperienced hands.
News on progress should be broadcast from time to time. While the project is a self-managed vessel, externalreporting and occasional audit are useful disciplines.
Expect change and accommodate it. Change is likely, especially over long time horizons, such as changes inmanagement, elections, or environmental shocks. Change will provide opportunity of conflict between the client
and the project. Politics will be a constant feature. An understanding of the client’s politics would be
advantageous. Efforts need to be made by the project manager to establish and maintain a healthy relationship sothat conflicts can be resolved (see chapter 5 on change management).
Replan as often as necessary, however there is a fine line. Make sure this is conscious replanning of the same
project. A project should not be considered an omnibus vehicle for handling unspecified events. In particular:
beware of project drift. A successful project is particularly prone to drift.
Success should be nurtured by stability in requirements. Proceed in short stages that deliver useful products.

11

Good practiceTechniques and topics

Project management

Preparing a project

During the preparation phase the project team should be small. It may consist of the authoritative project manager and atechnical project manager, supplemented as required by a business analyst or a methods specialist, depending upon thebreadth of experience of the technical project manager and the scale of the undertaking.
The larger project team, such as might be expected for software development or customization, should not be in place atthis time. While the diligent project manager (whether a supplier’s or a client’s representative for internal developments)
would prepare for subsequent phase resources to mitigate delays, the end of preparation is a final moment of decision.
Research the project
The first step for the project manager is to research the origins of and intentions for the project, by:Studying the contract (for an external supplier) or other orders commissioning the project
Studying available materials such as corporate plans, business plans, IS and IT plans, World Bank project appraisals,
supervision reports, loan documents, and so on
Having informal discussions with key persons initially identified in the client organization.
Education and orientation
The next step in the preparation should be educational. The project should be conducted using a recognized formal
method, customized for pragmatic application to the specific project. The project manager should:
Identify the mainstream project management method to be engaged.
Document the customized methods for the project to the extent possible at this stage. Subsequent customization
should be the topic of information notices distributed to interested or affected parties.
Provide at least one set of literature pertaining to the standard project management method together with thecustomization notice, preferably in hard copy and soft copy.
Conduct an orientation seminar that outlines and explains the key processes, artifacts, and nomenclature of themethod, procedures of particular relevance to the client, an overview of all procedures to be used, and stages ofthe project, with emphasis on what follows immediately.
Log frame
The log frame for the loan succinctly describes the mandate for the ICT component and is an obvious starting point. Log
frames are suitable project management instruments for planning, and monitoring, and eventual evaluation. It provides asynopsis of the project and the means by which overall progress will be judged. This avoids distortion that can arise from
activity based reporting where the objectives are often too distant and obscured by activity presumed to be useful.
Often the ICT component is complex and tied to a development objective. The ICT component might be part of amodernization effort seeking to restructure and introduce a new culture to an institution. Sublog frames, tied to the loan’s
log frame, are useful for planning and monitoring the steps toward the softer, more elusive objectives. In nine out of ten
projects the technology component will be straightforward — implementation and adoption by the intended user is theharder part. In determining the efficacy of the ICT component during supervision and completion the sublog frames canbe very useful.
The sublog frame is instrumental in maintaining the client’s and the project manager’s focus on the big picture. The WorldBank’s project planning toolkit contains a section on use of log frames as a project planning and monitoring tool. See alsoannex A to this chapter on the log frame structure and for a sample ICT component sublog frame.
Business case
The business case should have been prepared long before project commencement as part of the conceptualization process.
The business case consists of a quantification of benefits that are expected and the direct costs of implementation and

12Good practiceTechniques and topics

Project management

operation. Benefits may also include aspects difficult to quantify such as improved work environment, projection ofefficiency, or improved morale. Benefits are often expressed optimistically. A risk-based approach to benefit reduction
should be employed. (Beware: if the project is successful at implementation, the benefits may be expected to follow and theexecutive measured accordingly!)
The business case also establishes that the project is desirable from a “corporate” perspective, enhancing the image in amanner consistent with the executive’s intentions, and that the expenditure is not at the cost of higher priority or more
rewarding opportunities. Direct costs are often difficult to assess with accuracy, especially in early versions of the businesscase. Sufficient detail of the products and the methods of delivery are rarely known in advance. Even then there aresufficient examples of change notices being used to expand project budgets!
There is also a paradox here. For a subset of projects, sufficient data for reasonably accurate costing means the products
have been designed. However, that design can only be created from a limited perspective (often a single individual),
whereas there is a world full of innovative suppliers who should not be unduly constrained.
Loan amounts are often formulated ahead of sufficient knowledge of the products and especially the methods of delivery.
Can a package be customized? Must there be costly or risky bespoke development? If the loan amount proves to be stable,
it probably reflects that the delivery has been cut to the budget!
There are many projects that do not end with actual implementation. These typically result in studies, plans, specifications,and so on. In setting effort estimates, cognizance of the overall budget is combined some heuristic assumption 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, merely that it is “what we could manage on theavailable budget”. This is not such a bad thing (analysis and specification could proceed ad nauseam) provided it isrecognized as such.
More uncertain are the indirect costs associated with expected and unexpected events during and following
implementation. Some consideration of indirect costs should nevertheless be attempted. Forewarned is forearmed!
IS and IT rarely deliver benefits directly. Benefits accrue through the use of IS and IT. The benefits are not realized by
accident. It is preferable to identify them in advance and manage their realization deliberately (see chapter 10, annex A).
Refer to chapter 10 for guidance notes regarding the business case.
Project plans
For actual and detailed preparation of the project a project plan will be required. This should not be confused with a Gantt
chart that is merely one element of the project plan.
There are many, sometimes proprietary, approaches to project planning. The various methods use different nomenclatureand emphasize different elements, but there is a common thread. The process that is described in the following paragraphs
is intended to be a generic, product-orientated approach.
Original project parameters: objectives, headline products, timescales, resource, and cost summaries should be restated.
The project plan will be based on the project objectives, requirements, and the named and derived products andcomponents. The derived components result from the engineering discipline that is applied. For example, a transaction
processing system for water billing consisting of identified functions might be the user’s named requirement. Derived
objectives, the extent and value of which might not be immediately obvious to the client, might include: business models,functional hierarchies, requirements specifications, system architecture specifications, database specifications, engineering
specifications, test plans, integration plans, source code, object code, and a plethora of other objects.
The headline products are disintegrated into derived products and components, and those iteratively disintegrated, toprovide a product breakdown structure.

13

Good practiceTechniques and topics

Project management

Headline products need to have real clients who genuinely want or need or would eventually need the products. The clients
will determine the attributes of the headline products. It is the delivery of the headline products accepted by testing inaccordance with the agreed attributes that will constitute a successful conclusion to the project.
The product breakdown structure will contain both headline products and derived components. All elements eventually
will be specified in terms of attributes, often based on engineering standards. The attributes will be used eventually toconfirm the successful delivery of the component. The derived components are often for internal consumption where theclient may have neither the interest nor competence to inspect them. Sometimes the derived component, such as arequirement specification or a training course, is sufficiently important to the overall delivery, especially for confirmationthat the project is on the right track. The client will be enjoined to confirm quality in terms of accuracy and completeness.
The product breakdown structure is significant since it states what the project will deliver. The project may be conceived
primarily as a change agent with technical objectives incidental to it. Nevertheless the project’s formal persona must be todeliver products. However, the product breakdown structure does not assist with day-to-day management. It is the activityof the project team that is actually managed. Delivery of the products is an indicator of effective management. The productbreakdown structure is converted into a work breakdown structure — that is the activities and tasks required to deliver thecomponents and the products.
The derivation of the product breakdown structure and work breakdown structure requires knowledge and experience ofthe business of the project, the nature of its products, and the engineering methods to be used. This part of the process is
not merely administrative.
There will be dependencies between tasks and activities. Sequencing and staging will emerge. For example, specifications
are prepared before software is written. Technical architectures are prepared before technical specifications andprocurement specifications can be finalized. Bid lot strategy is agreed upon and bid routes selected before procurement
commences, and so on. Often there are many precedents to a single task. The tasks and activities can be organized into an
activity network or a critical path network. This is often represented as a Gantt chart.
Often the Gantt chart will also consolidate significant events that are beyond the project mandate but significant to theachievement of the project products. For example: refurbishment of premises may be under some civil works contract but
vital to implementation of the ICT component.
Effort estimates are required for all tasks. Effort estimation is a discipline in its own right not elaborated here. An
experiential database of applicable benchmarks is at the heart of estimation. Hint: tasks should generally be theresponsibility of a single person and should not generally exceed an elapsed time of one week. This facilitates progress
tracking. Effort estimates must be balanced with resource availability and schedule requirements. Negotiation may berequired. The end result is the baseline Gantt chart.

14

Good practiceTechniques and topics

Project management

Figure 1 A typical project planning process
CLIENT(user / business / technicalperspectives)
negotiates

negotiates

deriveobjectives
requirements
headline products
named requirements

derived components
Product Breakdown Structuretasks
effort estimatestask dependencies
precedents

informf
inengineering discipline
standards
quality management
methodmorresource constraints

interpretted intointerpretted
intoWork Breakdown Structure

rm
fo
in

derivessetselaborated
into

Log frame for the loan
sub-log-frames for the ICTcomponent

activity network
milestone / checkpoint events
gantt chart

15

Good practiceTechniques and topics

Project management

Each stage should be defined in terms of management responsibility, products and components to be delivered, schedule,
resources, organization, tasks, and dependencies. For each task: there should be a definition of the component to bedelivered, delivery method, and quality control method. In effect each stage should have a stage plan.
It is important to recognize that stages provide decision points and usually end at a project milestone. Milestones may also
be used as project manager’s device to emphasize any significant event to the client. There is often friction in the decision
making process. The opportunity for review and acceptance inevitably takes longer than theoretically required. This can bea result of the unavailability of key persons, politics, malice, or merely jitters. It is wise to make allowances for stage-change
delays of the order of one month at significant points. It is not unheard of, however, to have six or more months pass forreasons that are never quite clear. The key difficulty here is how to determine the balance between standing down ordeferring mobilization of the subsequent stage team, the budget impact of doing so, and the consequential aggravation of
the client. To continue is at risk of disagreement and the need to rework anything that may have been prepared. The
beneficiaries (and the World Bank) are often reluctant to acknowledge these realities.
In projects financed by the World Bank there is also a need to accommodate “no objection” processes at events
determined in the loan agreement and as documented in guidelines such as “Procurement under IBRD Loans and IDA
Credits”. It is also crucial to keep the schedule constrained to provide some chance of stability. Long projects suffer staff
changes and consequent discontinuity, changes in the business environment and its priorities, diminution of interest, ennui
and loss of tolerance, loss of ownership, momentum, direction, and control. Long and large projects are likely to be too big
to manage without a huge management overhead and corresponding budget.
When confronted by a long or large project, every effort should be made to have distinct subprojects each with genuinely
useful products that will be used.
Resources organization needs to be planned. There will be an organization chart, staffing schedule, resource schedule, roledescriptions, and leadership and reporting method. The internal organization should reflect the productive elements,
quality management element, support elements, and the management element. Financial resources should likewise beclarified.
The project’s external organization should be confirmed and documented. At the least there will be a project board or
steering committee to which the project reports. The project board should reflect user, business, and technical perspectives
with representatives selected accordingly. Typically for a significant project financed by the World Bank, the task manager
will receive quarterly reports. The project will benefit from periodic independent audit of its progress, reporting, andmethods. Such audits should be anticipated and accommodated in the plan. Also in the external environment, stakeholders
should be identified and assessed (refer to chapter 2 for guidance notes stakeholder analysis).
Dependencies on the client should be documented to make clear the role that the client is expected to play and the relianceof the project on those inputs.
A commitments register should be prepared to document a list of dependencies on parties external to the project, usuallyalso independent of the client. Commitments should be evidenced by confirmation by those parties. Examples may be a
supplier engaged under separate contract with the beneficiary, installing technical infrastructure or standby power
generation, or the printing of user guides in support of an information system that is the responsibility of the project.
In addition to the specific tasks, the project will have methods that underpin the tasks or are implied but listed as specifictasks or are otherwise pertinent to the impending execution. These should be declared in the project plan and include:
Engineering and production methods — the main purpose is to clarify (so that the client has some insight into
the methods that the project will engage) and confirm (so that the client has confidence in the project).

16

Good practiceTechniques and topics

Project management

Figure 2 Illustration of relationships between project management and IS implementation stages
when built, verified and validated byrequests / nominates
one or more

ClientProduct
Attributedescribes each

Product
determines
Breakdown
Structure Product
Flow
Diagramdescribed andrefined by

Productin combination
definesparceled into awhen built, confirmed
by inspection of

Project Initiation
Documentation

Methods for
Strategy,
Tech. Infrastructure,
Procurement,
Implementation,
Training, etc...
SystemDevelopment
MethodStrategic
Plans

Budgetingbasis ofin combinationinfluences

Staffing,
Structures,
Resourcing
Admin,
Procedures

includesincludesPlanning
Methodcomprisedefines

ProjectPlandefinesOrganising
MethodLeading
Methodexplicitly authorises, limits,
directs, controls,
and measures the success ofare each a
type ofdirecting /coordinating
may alter

Project
Execution

as a standard plan,for the applicable part of the project,
identifies the need and sequence forControlling
MethodincludesBroad System
DesignTechnical Infrastructure
SpecificationStage

comprised ofeach

for applicable product types
provides the standard
plan for

Requirements
Definition System Design
Selection

distinctly
for each ofStage
builds andbaselines

influences

Project Plan
Task

performed
in asets scope andcontext for each

Broader
Strategic andTactical Plans

Work
Breakdown
Structureare each part ofand directed, controlled,etc. in line withincludesProject
ChangeMethodReporting
Correcting /Responding

Detailed System Design
Specification, Executable
Object etc.
Installation /Implementation
etc.

Quality management for the project — planning for quality will entail:Overall organization: roles, quality management products, and policies and approaches to be engaged
Planning the methods to be used for quality control (to confirm that delivered components conform topredefined requirements or attributes)
Planning the methods to be used for quality assurance (to confirm that the management arrangements are inplace, that the quality control process is followed and these are effective.) Refer to chapter 3 for further
guidance on quality management.
Acceptance procedures — acceptance is a particular case of quality control where the client is asked to verify (itis functionally correct) and validate (it is traceable to a client requirement) the delivery. Often acceptance is tied to
payment events and is thus of interest to the supplier and purchaser.
Reporting methods: internal and external — the plan should document the means by which the project teammembers regularly report resource spend, progress in the performance of tasks, raise alerts, and document issues
relating to project products. Accordingly, the method by which the reports are handled needs to be documented.
The project manager will usually report at quarterly or monthly intervals, depending upon duration and status of
the project, to the project board or steering committee and the task manager. Typical elements of the report arelisted in the paragraphs below.
Issue reporting procedure — the method by which a client (or the project team, or any other recognized party)
raises an issue should be documented. Issues may relate to any aspect of the project and its products and17

Good practiceTechniques and topics

Project management

components. Often the project team, having the keenest interest, will administer a scheme for registering, tracking,assessing, resolving, and responding to issues. The assessment might
Recognize a fault or deviation
Determine that a misunderstanding has arisen, orThat there is a change in requirement (and hence subject to change control procedures as outlined below).
Resolution would be performed accordingly with the issue-raiser kept informed. Typically repair of a fault
would not lead to a change of cost — the responsibility and risk being borne by the project. Issue statistics are
an important indicator of the effectiveness of project management, the engineering method, and quality
management.
Change control procedures — for a project of significant duration (say more than a year) change is almost
inevitable. The beneficiary’s requirements change, domestic politics intercede, priorities change, new ideas arise,and so on. New information may come to light, invalidating some estimates. In all such cases changes to theproject plan (and any underlying contract) should be conducted in a controlled manner. The procedures for thisshould be outlined in the project plan. Typically this will involve raising a request for change, an assessment of thevalidity of the change, the nature of the change, and effort and cost estimates. Where changes are consequent in
an underlying contract, the change procedures in the general or special condition of contract would be invoked.
Change statistics can provide an important indicator of the quality of the entry conditions for the project and therobustness of the products. A large number of changes in a component may indicate that the component needs
replacement rather than modification.
Configuration management procedures — ICT products are usually an interoperation of many components
each subject to revision. The project must maintain a record of its products and its components — the so-called
configuration items. There should be a database that records configuration items, versions of configuration items
and the disposition of configuration items. There should be controls over changes to any configuration item withauthorized check-in and check-out procedures. Recording would typically begin at a selected point in the delivery
process. For hardware or system software this might be when receipt is acknowledged at the destination. For
application software code, this might be when a programmer offers the configuration item following unit testing,or for a whole system when the relevant and specified combination of configuration items is delivered with arelease note to the testing or acceptance test team. Specified formal documents (plans, specifications, procurement
documents, contracts, reports, and so on) are configuration items and should likewise be placed underconfiguration control. Configuration management is a vital procedure that must carry over or be converted to theclient’s operational environment. For sustainability the client must always have an accurate record of its assets,
their revision levels and their disposition.
Risk management methods — risk here relates to threats to the successful completion of the project rather
than the topic of risk theory as applied to assets. Refer elsewhere in this toolkit for further description of bothproject-related risk and asset-related risk (chapter 4). For information to all parties, it is wise to document all
genuine vulnerabilities and threats that the project faces together with estimates of the probability and size of
realized risk if possible. The objectives of a project are almost inevitably at risk. The method by which andperiodicity with which the risk analysis will be reconstructed should be documented in the project plan. An initialrisk assessment should be included within the plan.
Allowance for contingency — it is wise to include contingencies in time, budget, and resources. The planning
process by its nature only identifies that which it can identify. Skill and experience mitigate but do not eliminate thesurprise element. A contingency allowance provides a buffer against the unexpected without the need to workthrough the full gamut of project and budget review processes.
Benefits — there is need for a restatement of benefits summary from the business case and mechanism formonitoring the success in terms of benefits. In many projects, benefits management would reside outside theproject with the client. It can be expected that a contracted supplier will resist inclusion of benefits management
for fear that this may be confused with an obligation to deliver benefits. Nevertheless this circumstance should beclarified.

18

Good practiceTechniques and topics

Project management

World Bank context
The process is supposed to be assisted by a documented corporate strategy and IS and IT strategy. The reality is that theseare often nonexistent, or at least not articulated. It is better to defer the project until these strategies are enunciated.
Alternatively, the project may itself negotiate the resources to undertake abbreviated activities to first prepare snap shots ofthe corporate and IS and IT strategic plans. Refer to chapter 9 for guidance.
There is often a long lead between project definition (per request for proposal and invitation for bids) and actualcommencement. The transparency imperative of the bidding procedures also impedes the dialogue between purchaser andsupplier and hence constrains understanding. Upon commencement, it is recommended that an inception report beprepared to clarify objectives and requirements and, understandings of the proposal, as well as to assess changes over time.
The inception report can be the project plan. If the planning cycle requires a level of input beyond, say, two person-months
or two elapsed months, the inception report may be an outline of the eventual project plan.
Running and controlling a project

During the execution phase the project team will grow and shrink according to the stages and the plans.
If sufficient effort, knowledge, and experience are brought to bear during the preparation, execution can be dull, inparticular for the project team members. The project manager will organize and reorganize according to the plan direct
work to be undertaken according to the defined methods, be informed of progress of tasks according to the documented
internal reporting methods, and report progress externally via the advertised means.
The reality, however, is not quite so mundane. Estimates can be wrong, tools fail, misunderstandings arise, people leave,
become sick, or perform below par, dependencies may be unreliable, commitments are broken, clients can be whimsical or
restless, priorities change, stakeholders may become vexatious, finances become less certain, or the environment produces
unspecified shocks.
The overriding role for the project manager during the execution phase, supported by the project champion and the projectboard, is to keep the project on track.
Risk awareness and response
A key task for the project manager during the execution is to be vigilant of risks that beset, and arrange for preventativeand corrective responses to perceived and realized risk. The tools for this are the previous risk assessment (starting with theinitial assessment in the project plan), the imprecise art of environmental monitoring, and a revised risk assessment madepublic to the steering committee. More often than not the project will be unable to deal with the risks itself. It will rely
upon shelter afforded by the steering committee. Each risk should be described in terms of
The threat or vulnerability
Probability and quantification
Prevention, avoidance, response actions.
Other project management tasks
During the execution phase other project management tasks include:
Organizing and reorganizing —as the project progresses through its stages, according to plan and in response
tot the unexpected.
Drift — leading and directing the team to maintain its focus on developing the products within its mandates. It is
important to detect and eliminate project drift, one of the great project diseases: the slippery slope of doing somelittle thing extra. These little things are often not subject to assessment and snowball out of proportion. A little
programming productivity tool may end up as a pet thesis that deletes an otherwise productive resource. Perhaps
the worse that could happen is that there is successful delivery of these little things — that only attracts morerequests.

19

Good practiceTechniques and topics

Project management

Resolving conflict — the project itself is a social system. As team size grows there is an inevitability of internal
conflict concerning approach, direction, and priorities. The project manager must balance participation, creativity,and empowerment with a degree of harmony. The project itself is also likely to be at conflict with elements of theclient organization. It is new and temporary and probably the least resilient unit. With the assistance of the project
champion and the steering committee, the project will need to manage cohabitation with the client’s organizationand get around obstacles to get its job done.
Keeping people informed — it is important to remind stakeholders of the project’s existence and reason for its
existence, to broadcast achievements, and to assuage impatience. When a project is initiated to deliver someproduct, there is usually an immediate need but in reality a lag in delivery. Patience does not last.
Lifting lids — occasionally things go badly. It is the duty of the project manager to present the facts, mitigating
unnecessary expenditure.
Managing stage change — at stage transition points, the project will undergo changes in staffing, teamstructures, leadership, and procedures as the nature of the products changes, such as from initiation to analysis,
analysis to design, design to procurement or to build, and build to implementation. Different skill sets may berequired. There will be judgment calls about whether to continue or pause when client decision-making is slow.
Measuring and monitoring — a significant proportion of project management time during execution will
involve measuring, monitoring, assessing, and reporting progress. Progress should be compared first to the projectplan and the Gantt chart. On product delivery, progress should be compared to the plan. Products andcomponents should be assessed according to planned and actual delivery dates. For significant volumes of
products, rate charts may show a curve of planned delivery rate over time to actual delivery rate over time. Each
product or component should have one of only three possible states: not yet due, due and completed, due but notcompleted. For slippage, explanation should be provided and an impact assessment made. Resolution actions
should be described if appropriate.
The baseline Gantt chart should be updated to illustrate progress. Any task should have only three possible start
states: not due to start, started, due but not started; and three possible completion states: not due, due andcompleted, due and not completed. The deceptive “eighty percent or almost completed” syndrome should beresisted. Early start information might be useful if dependencies or other parties are involved. Known upcoming
failure to meet schedule should be highlighted. Resource expenditure should be tracked. Any discrepancy between
resources expected to be engaged versus resources actually engaged should be illustrated and clarified. Financial
progress should also be tracked. Once again rate charts are useful for such illustration.
At milestones, comparison should also be made to the sublog frame. An important note: disbursement progress is
not a good measure for project progress. It should be secondary and not allowed to become a distraction to aneffective direction for the project.
Responding to threats of deviation — the purpose of vigilant monitoring of the environment and project
performance is to respond with preventative or corrective action. The project manager is responsible for creating
and soliciting appropriate responses and acting accordingly.
Responding to change — a particular source of deviation is changes in requirements or in priorities. There is aconsequential need for impact assessment to determine the extent of the change, any indirect effects pursuant toaccepting or rejecting the change, approaches to effecting the change. Special treatment may be required because
there may be cost implications that require a separate course of administration. Negotiation skills may be required.
Replanning — from time to time, it may become necessary to replan the project. From the World Bank’s
perspective the time to do this is during the mid-term review. For the project manager there may be a scheduled
event such as when information planned to become available actually becomes available (for example, whencustomization specifications are complete, detailed planning of the delivery can be completed, or following a site
survey, capital works can be planned). Necessity to replan may follow significant change — new or revised
requirements may arise, effort and schedule estimates may prove spurious, commitments may not be honored,
dependencies fail, and so on. Typically different phases require different planning techniques.

20

Good practiceTechniques and topics

Project management

Winding down

The successful project will eventually terminate. Typically the client will assume responsibility for the operation of thesystems that are delivered and implemented. In many cases this can be the most challenging part of the project. The
supplier may provide ongoing support and maintenance, even to the extent of providing operational support. The client,however, cannot any longer avoid full responsibility for the effective use of the newly acquired systems. There is aphenomenon that may be exacerbated within the developing context. In a large and complex project, the client’s
representatives can become accustomed to relying upon a supplier who has become a trusted partner and who seems tohave all the answers.
A final acceptance instrument such as a final acceptance certificate or a final invoice will often signify termination. Thisconfirms that the client recognizes that all products of satisfactory quality have been delivered according to the agreementwith the project team.
It is common to have a postimplementation review, constituting a final audit of the project and providing some feedback
to the client, World Bank, project manager, and the supplier. The feedback is designed to be useful for the preparation of
future projects and should summarize positive and negative lessons learnt from the project.
The World Bank will normally prepare its own summary in the form of the implementation completion report (ICR), basedon any available project implementation review (PIR) and its own supervision.
What to expect from the project manager

During preparation and planning
1. Inception report (either separately or included with the project plan), consisting of key understandings regarding:
Clarified or revised objectives
Clarified or revised products
Milestones and milestone dates
Project–client relationships
Resource availability
Dependencies on the client and other parties
Sources of information and reference (such as key personalities, strategic plans, existing specifications, and so on.)Summary of any changes or clarifications since the request for proposals (RFP) or invitation for bids (IFB) andproposal
An acceptance note from the client or purchaser signifying agreement with the inception report
2. Project sublog frame — where there are significant complex and soft goals and purposes, or where there are
relationships to other activities that have them. The sublog frame will consist of a matrix of (refer to annex B):
Rows: goals, purposes, outputs, and activities
Columns: narrative summary, measurable indicators, means of verification, and important assumptions
3. A project plan consisting of
Restatement of project objectives
Identification of the project’s client(s), usually constituents of the purchaser’s environment
Definition of the complete set of products to be delivered, including the product’s client and where known theclient’s specification of product attributes
Key milestones and dates

21

Good practiceTechniques and topics

Project management

External organization showing the directive mechanism of the project board or steering committee, key
interactions with external parties, and demonstrable commitment from those parties
Internal organization for the project, including organization chart, staffing schedule, resource schedule, role andjob descriptions, leadership, levels of authority, and regular internal reporting method (it is important to rememberthat the external and internal organizations for the project are temporary and will dissolve when the projectterminates)
Product breakdown structure showing headline products, subproducts, and components to a level of detail usefulfor understanding the plan
Work breakdown structure in terms of a Gantt chart, showing stages, tasks, efforts, precedents, time schedule, andresources
Critical path assessment
Task definition including product or component to be delivered, client, attributes, method for delivery, quality
control method, dependencies
Internal project reporting approach
External project reporting approach
Internal control methods — monitoring, assessment, reporting and response
External control methods — monitoring, self-assessment, and reporting
Acceptance methods
Dependencies on the client
Assessment of stakeholders
Commitment register
Project’s risk assessment and risk monitoring method
Overview of the project’s production and delivery methods
Issues management method
Change control method
Configuration management method
Quality management method (quality plan, quality control, quality assurance)
Benefits summary and monitoring method
Allowances for contingency
With this will be required an acceptance note from the client or purchaser signifying agreement with the project plan,
agreement to fulfill its obligations as set out in dependencies, and commitment to assist the project team to secure theinput of other parties.
The task manager should assess whether these planning objects are comprehensive, credible, complete, and consistent withthe project (ICT component) objectives and the loan objectives.
During execution
1. Progress reports, with periodicity declared in the project plan (usually monthly or quarterly) and including
Summary of significant events
Factors for attention of the steering committee
Plan tracking product delivery performance:
products due and completed, due but not completed;clarifications;rate charts.

22

Good practiceTechniques and topics

Project management

Plan tracking tasks
active tasks, tasks due to start, tasks completed
clarifications
rate charts
Plan tracking resources
resources engaged, due but not engaged. extended engagement
clarifications
Plan tracking finances
period and cumulative expenditure — planned vs. actual
clarifications
rate charts
Milestone events
Log frame tracking, measures of indicators
Revised risk assessment (per project plan)
Issues summary — overall assessment of the issues portfolio, issues raised, issues cleared, issues to be cleared
Changes summary — overall assessment of the changes portfolio, changes raised, changes cleared, changes to becleared2. Exception reports upon significant late performance (expected) or performance failure consisting ofdescription and diagnosis of summary of exception
effects of exception on other project tasks, on schedule, on costs, on other parties
proposed resolution
3. Audit reports at scheduled intervals (usually annually or around specified milestones) or at the request of the purchaserand consisting of:terms of reference for the audit
summary of findings
client’s overall impressions of performance
auditor’s assessment of overall performanceassessment of use and effectiveness of project procedures: management, delivery and engineering, quality,
configuration management
assessment of use and effectiveness of financial controls
assessment of effectiveness of project organization
recommendations
conduct of audit

23

Good practiceTechniques and topics

Project management

4. Change control reports: The project can be expected to assess and negotiate requests for change jointly with the client.
Many may be minor. They nevertheless require proper administration and consideration. Some may have significant effecton the project. Some may involve a cost implication.
5. Quality evidence: Quality control documentation, quality review appointments and minutes, configuration
management records, test plans, test results, issues administration records, change administration records, sign-offs.
6. Acceptance evidence: Notices that identify products and announce that they are ready for acceptance procedures plus,
signed acceptance notices.
7. Revised plans: At significant scheduled events or in response to significant unexpected events, format according toproject plan.
At termination
Final acceptance — in the form of an acceptance notice
PIR — akin to a project audit together with summaries of key feedback for future projects

Where to seek further guidanceWithin the World Bank:
Project preparation toolkit
Log frame toolkit
M&E toolkit
External to the World Bank:J. R. Meredith and S. J. Mantel, Project Management a Managerial Approach, John Wiley & Sons, 2000, ISBN047143620
Good practice in developing sustainable information systems, Supporting Guides (esp. SG1), Department for International
Development (U.K.), CCTA 1998
Project Management Institute — www.pmi.org
Project Management Body of Knowledge (PM BOK ) Guide 2000 ed. ANSI/PMI 99-001-2000, ISBN18841023620
Carnegie Mellon University Software Engineering Institute — www.sei.cmu.edu/managing/managing.html
www.ausaid.gov.au/ausguides

24

Good practiceTechniques and topics

Project management

Annex A
to Chapter 1
Role of the steering committee

The steering committee1, or project board, will be a small group, of around five executive managers appointed from within
the beneficiary and perhaps the borrower. The steering committee takes ultimate responsibility for the project. A senior
executive of the beneficiary will chair the steering committee. A secretarial role will be established. The committee’s
constituents will be representatives of the business, user and technology authorities within the organization, andauthoritative representation from organizational elements with essential inputs to the project. The project manager will
typically not be a member, especially if from an external supplier, but will be invited to present to each meeting. The
World Bank’s task manager will not usually be a member but will be invited to attend.
The responsibilities of the steering committee include:
Appointing the project manager and committing project resources
Commissioning, assessing, and approving project inception report, log frame, project plan, and any revised plans
Reviewing project progress reports: project performance, any underperformance, summary of issue reporting,summary of change reporting, risk assessment, impending events and external requirements
Seeking clarifications on project performance either from the project team or through an independent party
Assessing change control requests, especially those that entail change in contract, or significant change in time,
resources, or products
Assessing the project’s performance from the perspective of the beneficiary’s corporate business, user andtechnological objectives, policies and procedures
Assessing project performance in terms of the business plan and expected benefits
Considering, seeking, assessing, and authorizing proposals for preventative or corrective actions
Appointing acceptance team(s)Accepting key high-level project products, usually based on analysis made by an acceptance team
Coordinating the activities of the project in the context of other coexistent projects and activities
Mobilizing and directing nonproject resources to participate as necessary in project activities
The steering committee will appoint the project manager, a single person in charge of the day-to-day work directed by andreporting to the steering committee. The steering committee will set and agree on the project phasing. It will convene at
predefined decision points (usually tied to acceptance events and go or no-go phase change events) and regular, notnecessarily frequent, progress monitoring checkpoints. The project manager should also alert the steering committee of theneed for an extraordinary meeting whenever serious hindrance to the project prevents ongoing work, or leads to cost orschedule overrun beyond tolerances formally announced in advance by the steering committee.
The project manager will present project status at each meeting. Risk assessments will be summarized. The project manager
could request special instructions or actions to be undertaken by members of the steering committee. The steeringcommittee may seek information on aspects not presented. The project manager will not stay necessarily for the entire
meeting, to permit private deliberations by the committee. Minutes of committee meetings will be distributed as soon as
possible to the steering committee and the organization’s executive. The project manager will receive a subset pertaining atleast to the portion attended.

1 In some project management methodologies the roles of the project board and the steering committee are distinct, with the project board having amore immediate involvement and the steering committee, at a higher level of oversight, providing strategic direction to the project.

25

Good practiceTechniques and topics

Project management

Annex Bto Chapter 1
The sublog frame

The log frame is an analytical, presentational, and management tool which can help planners and managers:
Analyze the existing situation during project preparation
Establish a logical hierarchy of means by which objectives will be reached
Identify potential risks
Establish how outputs and outcomes might be best monitored and evaluatedPresent a summary of the project in a standard format; andMonitor and review projects during implementation.
The tool involves problem analysis, stakeholder analysis, developing a hierarchy of objectives, and selecting a preferred
implementation strategy. The product of this analytical approach is the matrix (the log frame), which summarizes what the
project intends to do and how, what the key assumptions are, and how outputs and outcomes will be monitored andevaluated.
The matrix structure is shown in the following table, together with a brief description of the information that the matrix
contains.
Table 1 Log frame matrix structure
Project Description

Performance Indicators

Means of Verification

Assumptions

Goal:

Measures of the extent to

Sources of information and

Subframe to project log

The broader development impact towhich a contribution to themethods used to collectframe goals.

national and sectoral level.

Used during evaluation.

which the project contributes at agoal has been made.

and report it.

Linked to the overall project log frame.
Purpose:Conditions at the end of the

Sources of information andAssumptions concerning

The development outcome expected at

project indicating that themethods used to collectthe purpose and goal

the end of the project. All components

Purpose has been achieved.

and report it.

linkage.

will contribute to this.

Used for project completionand evaluation.

Outputs:

Measures of the quantity andSources of information andAssumptions concerning

The direct measurable results (goods

quality of outputs and themethods used to collectthe output and purpose

and services) of the project which aretiming of their delivery.

and report it.

linkage.

largely under project management’s

Used during monitoring andcontrol.

review.

Activities:

Implementation and work

Sources of information andAssumptions concerning

The tasks carried out to implement the

program targets.

methods used to collect

the activity and output

project and deliver the identified

Used during monitoring.

and report it.

linkage.

outputs.

Table 2 An example for an ICT project: Tax Administration Modernization
Project Description

Performance Indicators

Means of Verification

Assumptions

Goal:

Indicators

Verification

Assumption:

Broaden the Tax Base

An increase in the active

National registration

The modernization

Control Tax Evasion

taxpayer population of 25

activity and revenue

project has been

Improve Tax Collections

percent above growth

statistics and analyses,

conceived as part of the

Improve Voluntary Compliance.

compounded over period.

especially self-employedstrategic framework for

26

Good practiceTechniques and topics

Project management

Compliance notices sent

sectors.

equitable revenue

automatically.

Forced recovery statistics.

mobilization.

Audit selection automated andTaxpayer survey indicating

audit yield increasing 100%

more qualified, informed

above growth compounded

and fair service.

over period.

An increase in revenue of 50%.
Declining rate of compliancenotices.
Declining yield in random
selection audits.
Purpose:

Indicators

Verification

Assumptions

To implement a common tax

A mature comprehensive

All taxpayer accounts

Unique taxpayer

identification number (TIN).

universally used. registration

accessible through new

identification broadens

To acquire and install business systems

scheme.

identifier.

the tax base.

for tax administration.

Widespread IT supporting all

Absence of active paper-

Improved business

infrastructure for the business systems.

(nonprofessional) aspects ofSurvey of tax officers

effective and as aretax administration.

indicating that job cannot

high priority measures

be sustained if system

to alter taxpayer

unavailable.

behavior.

To acquire and have installed technicaladministrative

based records of account.

systems and IT are

Outputs:

Indicators

Verification

Assumptions

A TIN registration system.

TIN registration advertised.

Evidence of broadcast

Taxpayers will use new

All entities in possession of

TIN registration center

media campaign.

identifier.

registration.

operational by dd/mm/yy.

System generated

Taxpayers use newBusiness systems for registration,

TIN registration matches

statistics.

forms and procedures,accounting, compliance, audit selection,

expected tax population after

Absence of manualsystems and technology

audit, objections, and appeals.

six months of campaign.

Technical infrastructure: Computer andTaxpayer accounts exclusively

data communications hardware andonline.

system software compatible with the

Systems installed andbusiness systems and adequate for the

maintained.

records.

effectively.

Contracts in place andTax officers will use theexecuted.

new systems.

transaction volumes and staffing levels
for the organization.
Installation of the technicalinfrastructure.

Implementation of the businesssystems: installation, conversion,
training, operationalization.
Support and maintenance for thebusiness systems.
Support and maintenance for thetechnical infrastructure.
Activities:

Indicators

Verification

Assumptions

Specify requirements for technicalTechnical assistance in place

Letter drop statistics.

TIN legislation enacted.

assistance.

by dd/mm/yy.

Opening ceremony for

Organizational change

Acquire technical assistance.

Specifications for systems

registration center.

for TIN designed andregistration campaign.

Specifications for

produced by system.

Population resistance toAcquire and implement a TIN

infrastructure ready byAcquisition procedures.

TIN can be overcome.

administration system.

dd/mm/yy.

Contracts entered.

Commonality ofDistribute identification instruments.

Training center operational by

System installed and in

purpose within tax

Prepare requirements specifications for

dd/mm/yy.

use at pilot site.

administration.

tax administration system.

Taxpayer accounts online at

System installed and in

Feasibility of

Prepare specifications for the TIN

ready by dd/mm/yy.

Registration statistics

implemented.

27

Good practiceTechniques and topics

Project management

Design tax administration system.

pilot site by dd/mm/yy.

use at roll-out sites.

acquisition of a

Acquire tax administration system.

Compliance notices sent from

Implementation complete.

comprehensive tax

Prepare specifications for supply andsystem for pilot site.

Support and maintenanceadministration system.

installation of technical infrastructure.

Compliance notices sent for all

arrangements effected.

Training center built on

Acquire technical infrastructure andsites.

Systems remain intime.

Prepare revised computer-assisted

contracts in place.

superseded procedures.

for new administration

implement in stages.

Support and maintenance

operation replacing

Organizational change

business procedures.

completed on time.

Implement training center.

Capital works at pilot

Implement new procedures, systems,

sites completed on

and infrastructure at pilot site.

time.

Roll out new procedures, systems, andCapital works at roll-

infrastructure.

out sites completed on
time.

28

Good practiceTechniques and to

Stakeholder anal

Stakeholder analysis and human factors
Chapter 2

A stakeholder analysis can determine the interests of stakeholders in relation to the
problems that the project is seeking to address, identify conflicts of interest, recognize
relations between stakeholders which can be built upon (and may lead to coalitions ofproject sponsorship and ownership), and help assess the appropriate type ofparticipation by different stakeholders.
What this chapter is about

This chapter focuses on the reasons for a stakeholder analysis in the context of an ICTcomponent and provides a checklist of potential interests. It helps to place this analysis
within the lifecycle of planning. It does not give a detailed methodology as this is provided
by the existing World Bank stakeholder analysis toolkit.
In addition, the chapter describes some of the human factors that should influence project
design. The link between stakeholder analysis and the human factors is not direct but in theiterative diagnostic process (labeled under the headings of problem, stakeholder,institutional, and business analysis). Some of these human factors may be the motivating
factors behind attitudes detected during stakeholder and institutional analysis. They willneed to be addressed within the design of the project and through change management.
Structure of this chapter

What is stakeholder analysis?

30

Definitions

30

Who might be ICT stakeholders?

30

Secure participation

31

Human factors

32

29

Good practice2.

Techniques and topics
Stakeholder analysis

Stakeholder analysis and human factors

What is stakeholder analysis?

Stakeholder analysis is the identification of a project’s key stakeholders and an assessment of their interests, and the ways inwhich these interests affect project risk and viability. Stakeholder analysis should always be carried out at the beginning of a
project. Stakeholder analysis contributes to project design through the logical framework. It can be used to draw out themain assumptions and some of the key risks that need to be considered if a project is going to be viable.
Stakeholder analysis can determine the interests of stakeholders in relation to the problems that the project is seeking toaddress, identify conflicts of interest, recognize relations between stakeholders which can be built upon (and may lead tocoalitions of project sponsorship and ownership), and help assess the appropriate type of participation by different
stakeholders.
The technique is based on the assumption that an organization is influenced in certain respects by external bodies and thatin many cases there are reciprocal influences. A map of these influences and their interaction provides the basis for analysis
on how future change would affect the various parties identified.
Definitions

Stakeholders are persons, groups, or institutions with interests in a component, project, or program. Primary stakeholders
are those ultimately affected, either positively or negatively. Secondary stakeholders are the intermediaries in the process.
This definition includes both winners and losers, and those involved in or excluded from the decisionmaking processes.
Key stakeholders are those who can significantly influence, or are important to the success of the project.
Who might be ICT stakeholders?

Before proceeding too far with problem analysis, task managers will want to make use of the stakeholder analysis toolkit.
Who are the stakeholders for an ICT component? Possible stakeholders are listed in Table 3 and this can be used as achecklist for drawing up an interview list. Consultation should include other government agencies and departments, major“customers” and “suppliers”, public and private sector organizations that conduct similar business activities, as well as thetarget organization. The process should confirm information, identify business issues, and gain commitment.
It may not be possible to identify all stakeholders from the outset. As with much planning there will be an iterative aspect
and the list should be reviewed periodically to ensure it is complete and accurate.
Knowledge about stakeholders will grow as more information becomes available from more detailed institutional appraisal,diagnostic studies, or business analysis. During the preparation phase of the ICT component, it may be necessary to revise
the interview list and go into more in-depth analysis of interests to identify those that will benefit and those that may not.
Of particular importance will be the identification of a sponsor or champion.
Such analysis will enable:
The development of a legitimate culture-specific incentive package
The shaping of the project if it threatens interests and risks political interference (this may prompt breaking it into
stages)
The establishing of progress indicators that disclose the degree of political support.

30

Good practiceTechniques and topics
Stakeholder analysis

Table 3 suggests a list of possible stakeholders for an ICT component:
Table 3 Stakeholders with interest in business change
Main stakeholders are those responsible for:
Organization or business area and information management strategies
Turning strategies into operational plans and monitoring and controlling the business area
Financial management and planning
Human resource management (including issues of establishment, pay, conditions, and training)
Trade unions and worker representation
Office services, accommodation, and telephones
Security (equipment and data)

Defining how business activities should be conducted and performance measured
Managing business activity
Conducting business activity
Information and data management
Data protection (where data protection legislation is enacted)
Statistics
Audit and control of business activities
Content and printing of forms, documents, and procedures manuals
Other stakeholders
National institutions for information coding and standards
Government department formulating legislation, policy, and rules for business
Persons and groups impacted positively or negatively by the business change
Ministry of finance (treasury)
National audit officeCentral statistical office
Other centralized government departments (for example, those responsible for property services, staff inspection, and grading)
Stakeholders in the IT system
Potential users (internal or external)
Providers of data to the system (they may not be users of the system)
IT management
Persons or groups from within the organization who will provide first line maintenance and support
Persons or groups responsible for human resources development
External suppliers of IS and technology products, services, maintenance, and support
Persons or groups who may be displaced

Persons or groups impacted positively or negatively by the information that the system generates
Persons or groups that need to provide information or receive information in a different form
Persons or groups who will have additional responsibilities for receiving and sending information
Central government IT department

Secure participation

To secure stakeholder commitment and acceptance, particularly that of the user, there should be agreed mechanisms forbringing them into the development. Participation can be secured by:Formal project management and organization arrangements directly involving stakeholders
Building confidence and improving skills by developing capacity through all stages of the project
Providing appropriate external inputs to facilitate the change process and complement available human resources.
These would need to be factored into the project design. The task manager, with little control over some of thesescenarios, may feel they are not very possible. Remember though, that an effective ICT component will be a partnership.

31

Good practiceTechniques and topics
Stakeholder analysis

The World Bank may be able to facilitate some of these mechanisms financially, as well as through moral suasion, ensure
factors beyond the direct support of the loan are addressed. See also chapter 5 on change management.
Human factors

Introducing or replacing an IS, with or without the use of IT, has a fundamental impact on staff and the way they performtheir jobs. Effects are felt on:
Organization and management practices, organization structure and dynamics, and organizational
culture. Computer aided business systems often revolutionize the way in which processes are undertaken andmanaged. Power may be transferred from senior managers to users with greater control over information. Systems
can take over and perform more accurately the checking and quality assurance previously done by supervisors andmanagers, making tiers of management obsolete. These changes have implications for the structure, management
hierarchy, and the level of autonomy given to more junior staff. Although these changes result from the system,
management of the change and the need to change the organizational culture, rest with senior management.
Jobs. Some individuals will find the technology performing many of the functions they used to perform. For
others it may make their jobs more complex and demanding. Job content and performance measures may need tobe reexamined. This should be done during system design. When evaluating job design attention should be paid to:
Rotating monotonous jobs
Adding new responsibilities to jobs where the system enables existing duties to be carried out more quickly
Enriching jobs with activities that increase the level of job satisfaction.
Incentives and motivation. Beyond strictly financial incentives, the project may offer prestige and opportunities
to learn special skills, and receive international training and advancement.
Training and support. Preparing for the implementation of the new system requires more than formal training
in how to use technology. It requires an education and training strategy embedded within the overall training
policy of the organization. The aim is not for everyone to know everything about the new system, but rather toensure the skills and competencies are present to enable the work to be undertaken efficiently and effectively.
Education and training should therefore be tailored to individual needs. Programs should be based on a training
needs analysis to determine:
Who needs to be trained
What each user community needs to know
What barriers there may be to learning (for example apprehension regarding the new system and technology).
Grading. Increased or decreased complexity in a job may influence the grade of a particular post. This in turn canhave an impact on the amount of money an individual earns. This needs to be addressed as early as possible andprior to implementation of the system.
Skill levels. Information systems can “de-skill” an individual as well as demand the learning of new skills(enhancing job satisfaction and status). Those without previous contact with modern IS may not feel comfortable
and may need time to adapt.
Resources. Implementation of a new system, regardless of size, always requires staff time and investment in
office infrastructure and peripherals in support of the system, such as trainers, training equipment, office space,
paper, disks, and other consumables.
Attitudes to work. These have to be flexible — look out for restrictive practices, which may impede change.
Group working and styles of working. New work groups may be formed and old ones disbanded. Those
accustomed to working alone and not in a group may find the changes difficult.
Working environment. An inhospitable work environment does not create a climate where users are receptive tochange. More work space, better lighting, furniture and equipment, heating and cooling, ventilation, and lesshumidity, dust, and noise can encourage staff to change the way they work. The cost of these improvements
should be taken into consideration when developing the business case (see chapters 1 and 10).

32

Good practice

Quality management
Chapter 3

A quality product is not “what I want” but rather “what I asked for”. A quality
piece of humor: Western buyer to Japanese firm: Please supply 100 widgets —quality criterion: three defects per 100. Package duly arrives with 100 perfectwidgets plus a curious parcel with three defective widgets.
What this chapter is about

This chapter provides a brief overview of the discipline of quality management applied in
the context of an ICT project; that is, it pertains to the quality of the products of the ICTcomponent.
There are close relationships between quality management and project management (since
the tasks associated with quality management need to be recognized, scheduled, resourced
and executed) and system development methods (since the quality and its processes are
dependent upon the nature of the products and intermediate component).
There are as always different approaches to quality management. This chapter describes a
generic approach. Occasionally, for convenience, specific terminology is used.
The technology for quality management extends beyond what applies to the production
function. Institutionalized feedback loops and continual process improvement are levels of
maturity to which the organization commissioning the project should aspire. The project
itself, by definition, being a short-lived entity, cannot have the same aspirations. The
broader maturity levels are not described here. The capability maturity model (see Where toseek further guidance) provides a definitive treatment.
Structure of this chapter

Introduction

34

Definition of “quality”

34

Management of quality

35

World Bank context

40

What to expect from a project40

Where to seek further guidance

41

33

Good practice3.

Techniques and topics
Quality management

Quality management

Introduction

Quality is in some ways the e-business equivalent of the 1980s. At the time seemingly every organization had a project toinstill and install quality principles, a quality function, and quality management processes. Governments were demanding
ISO 9000 qualifications as a supply prerequisite. ISO 9000 certification was a steady line of business. The fervor has died
down, but the application of the principles is now routine.
Definition of “quality”

The definition of quality is something like:“the totality of characteristics and features of a product (goods or services) which bear on its ability to satisfy a prescribed need”,
or simply:“conformance with requirements”.
A quality product is not “what I want” but rather “what I asked for”.
The notion of a client is therefore, emphasised. There is a need for predetermined requirements and a means to verify
conformance. The client sets the requirements (in terms of products and the characteristics of products) and confirms thatthe requirements have been satisfied. The four simple, basic concepts of quality management for all technical products areillustrated in figure 4.
Figure 3 Product — Client — Attribute — Quality concept

defines requirements
in terms ofClientProducts

drivesdefinesare definedby its

Quality Control
and Acceptance
Processes

Attributes
confirm completenessagainst the34

Good practiceTechniques and topics
Quality management

The key to the definition is the absence of any notion that there is some abstract universal measure of quality. Quality does
not mean “goodness” or “luxury”. A Rolls Royce and a Trabant may both represent 100 percent quality according to theattributes set for each. Conversely, if either fails to meet those attributes, then it is not a quality product.
Quality has a cost — not of delivery but of nonconformance — the cost of doing things wrong. Quality is not built in byquality control but by doing it correctly the first time.
The client may be external or internal to the project. Correspondingly, products may be of primary importance to theexternal client, or products may be part of the hidden engineering process and relevant mostly to the project team.
Management of quality

Topics related to the management of quality are outlined in the paragraphs that follow.
Quality management
Quality management requires a system that seeks to ensure the delivery of quality products, using the definition mentioned
above. The system will establish the means to confirm quality and to confirm that the means are effective.
The key processes within quality management are quality planning, quality control, and quality assurance. These processes
are outlined in this section together with other, perhaps technical processes (configuration management, change
management, version control, and release management) that are vital for quality.
Quality plans
The quality plan contains guidelines for the management of product quality through various stages of the project. The plan
evolves with the major stages of the project. The planning of each major stage will include a quality plan.
Responsibilities for quality need to be assigned to each project — there will be responsibilities shared between
The development group, perhaps supplemented by a quality control group, during its day-to-day activities
A distinct quality assurance group, to assure that a quality plan exists, is being executed, and is effective
The client naturally seeking to obtain products according to their defined requirements.
While the quality plan describes broad procedures, the plan actually manifests itself in:
Product descriptions that contain details relating to client, attributes, quality reviews, review checklists, andapproval levels, preferably guided by standards for the corresponding class of product
Activity charts (such as Gantt charts) that include inspection and hand-over activities
Resource plans that identify the personnel (within the project or without) involved in quality management, control,
and assurance activities
Plan narratives (especially at the time of detailed stage plans) that elaborate upon the products, their attributes, andthe delivery techniques
Work instructions — where the expectations steps should be explicit for the worker (the availability ofunambiguous work statements is a key to the delivery of quality products).
Quality planning is therefore part of the technical plan for product development — that is, the products of the project andthe means by which they are to be delivered. Quality is built into the process of identification of products, investigation of
product requirements prior to its build, acquisition, and delivery. Confirmation is addressed by the application of quality
control techniques. The effectiveness is addressed by assurance techniques.

35

Good practiceTechniques and topics
Quality management

Quality control
Quality Control involves inspection, correction, and sign-off.
Inspection is typically performed by a collaboration of the product deliverer and peers from within the project team prior
to verification by the client.
For any development, there may be distinct categories of products and corresponding sets of inspection techniques.
Identification of categories and techniques for each should be documented well in advance of the delivery of a productwithin a category.
For documentation products peer inspections are common
For software engineering products, a combination of peer inspections, walk-through, and detailed tests based upon
test plans should be employed for unit and system level products, and system acceptance testing for acceptancelevel products
For technical infrastructure, tests are usually formulated in accordance with predefined quantities and physicalattributes and performance characteristics. System acceptance testing may be applied to system software products.
The appropriate techniques should be documented in stage plans. Quality review structures and procedures (formallyestablished review groups, notice of meetings, review checklists, review minutes, and follow-up actions) may be established.
The steering committee and the project manager will determine how formal the review should be.
Client personnel play a critical part in the quality control processes. Client groups will be asked to inspect and confirm thequality of products.
AcceptanceFor the most part acceptance is really a type of quality control. Readiness for acceptance is a statement by the supplier thatit has assessed that a part of its task is now complete. In this sense, there may be a commercial significance to theacceptance of the product.
There are three perspectives to an inspection: user, business, and technical:
The user perspective involves verifying that the product conforms to the actual user’s requirement, assessing the
integrity of the requirement, and the business and operational impact of the product. The user may be anotherpart of the development group or project for lower level component products. The user will be a representative of
the client for significant products.
The business perspective involves consideration of the costs (implementation and operation) and availability of a
product, and whether in the narrow context of the individual product, the implied or expressed business case (setof benefits outweighing the costs or alternatives) remains valid. The business perspective may be difficult to verify
for lower level components and is often subsumed in the overall product. Client reviews of major products should
include consideration of the business perspective.
The technical perspective involves verification that the technical integrity has been maintained according to agreed
standards. The development group of the project has an interest in maintaining technical quality for components.
The client will also have an interest in the technical characteristics of products and components in order to install,
operate, and maintain them.
Note that the project’s champion may be placed in any of these three roles but will usually be a user or business
representative.
Acceptance tests are tied to the requirements agreed with the project team. Ideally acceptance test specifications will beagreed upon before the commencement of a contract. In practice the project often includes investigation and elaborationof requirements, in which case, the test specifications should be part of the requirement specification process.

36

Good practiceTechniques and topics
Quality management

Systems acceptance testing
Systems acceptance testing (SAT) is applied to software systems releases based on parameters to be developed by the clientand usually with the assistance of the development group or project.
Typically, SAT should apply to each release and revision of a product set to confirm completeness and correctness and also
to confirm that the product set is suitable for operation.
Elements of SAT could include:
Detailed functional tests — to verify that a function is correctly performed and to validate that the software istraceable to a requirement — that involve meticulous design of test cases seeking to confirm proper operation andto “crack” the system, compile expected results, and compare results to expectations.
Testing of the computer-assisted business process — seeking to confirm that the verified and validated functions
fit together with the noncomputerized parts (often the majority) of the complete business process
Scenario testing — construction and execution of real-world business events (incomplete data, nonsense, gooddata, fraudulent data, and so on) to confirm that the computer system or at least the computer-assisted businessprocess is robust.
Simulated offices — scenario testing in a simulated office environment
Pilot tests — use of the computer-assisted business process in a small scale but real-world environment
representative of the broader organization
Parallel tests — parallel running of both old and new systems and the comparison of results — cautions:
resources to operate two systems are needed, new system may not overlay very well on the functions of the old,
and the test may reveal deficiencies in the old systems as well as the new
Simulation — usually useful only for volume testing, where events are simulated by computer at and above the rate
anticipated for the live operation, to confirm adequate capacity in the new system and its technical infrastructure— once popular but now not often used.
Quality assurance
Quality assurance involves steps that seek to confirm that the quality plan is in effect and is effective. Quality assurance
reviews should be conducted periodically during the project life cycle and within the stages of the project to confirm
adherence to policies and procedures and to assess whether these policies and procedures are effective.
In some sense clients provide a quality assurance function through their monitoring of the acceptability of the products ofthe project. High rejection rates will indicate a systemic failure. Improvements in project processes would become a naturalconsideration if quality control and acceptance were to drive a great deal of rework.
There should also be a formal and distinct quality assurance role separated from quality control and acceptance. As
products are delivered, documentation relating to quality should also be created — typically notices of review, review
minutes and notes, specifications of test plans, reports on test results, corrections notices, product issue reports, offspecification reports, requests for change, and the paraphernalia for the administration of such documentation. These
documents form a product information database and facilitate quality performance investigations. This in turn may lead toadjustments to existing procedures or reviews of existing procedures when the procedures are followed but products do
not conform to their requirements.
Project audit
Project audit should be undertaken periodically throughout the life of a project. The project audit monitors the practices ofproject personnel from the perspectives of the client, in terms of project relationship, contract performance, management
efficacy, technical conformance, and quality assurance.

37

Good practiceTechniques and topics
Quality management

Configuration management
Configuration management is a technical process that facilitates the identification and location of products andcomponents. It is a scheme for:Identifying the totality of all project products and components — technical products, management products, andquality management products
Maintaining versions of products and components, and the modification, validation, and release histories ofversions
Maintaining assembly products, or those describing the assembly of components and productsManaging the location and movement between locations of the products
Identifying and associating the status of products
Maintaining security for product containers (such as files and directories on PCs).
Each product development should define the configuration management applicable to the type of product(s) being
delivered.
Change management (control)(Not to be confused with planning for and managing the impact of change in the context of organizational development
interventions — see chapter 5) Change management (change control) concerns the studied and conscious amendment of
products, taking into account the ramification of making or not making the changes.
Changes often and usually incur unscheduled, unanticipated work. New products, product enhancements, productcorrections are all within the ambit of change management. The procedures for Product Issue Reports (PIR), Requests for
Change (RFC), and Off-Specification Reports (OSR) are applicable.
PIRs may be raised by anyone with a legitimate interest in a project product. RFCs may and OSRs usually will lead to work
to be undertaken by the project team. The diagram that follows illustrates the process.
With appropriate authority a PIR may lead to an RFC where a change is required to the specification of a product (andhence to the product as well). An RFC will then lead to new work (issued as tasks). It is also valid for an RFC to be rejected
either by the project if it is assessed as not reasonable, or by the client if it is assessed to be undesirable by reason of effector expense.
A PIR may lead to an OSR when a product does not conform to its specification. An OSR would then lead to new work to
be undertaken. A PIR may also lead to other outcomes: it may be withdrawn by the issuer, there may be no action as aresult of misunderstanding by the issuer, no action due to insufficient information to study and effect it, or advisory
information is sent to the issuer.
Any combination or number of these outcomes may arise from a single PIR. Minimally the PIR-issuer will receive a reply
indicating the disposition of the PIR.

38

Good practiceTechniques and topics
Quality management

Figure 4 Generalized model of change management (control processes)

negotiates
with

ChangeControlCommitteestudied by

Project
ManagerRequestFor
Changemay reject
gives authority formay identify anenhancement
therefore needing

drivesOff
Specification
ReportProduct
Corrective
Maintenance

Formal Design
Workwill lead tois required for

Corrected
Product

New orEnhanced
Product

may bedetermined by
may beincludedin

Product
Issue
Reportmay godirectly toassembled to form

Product
ReleaseVersionundergoes

may have perceived
deficiencies, reported
via

Quality
Control

notice ofdisposition
sent topresents products for

Corrected
Product

in urgentcases may
go directly toUser
Acceptance(incl. SAT)

leads to new

Originator

Product
Configuration

39

Good practiceTechniques and topics
Quality management

Version Control
Version control or version management relates to the maintenance of manifestations of the same product, evolving
through enhancement or repair.
Release Management
Release management relates to:
The grouping of products and components into a useful assemblage
The documentation of the purpose, content, and assemblage
General notes on how to use the assemblage
Notes about how to disengage the assemblage (often referred to as regression notes).
For software systems a release note would commonly arise for new, enhanced, or repaired features, assembled into a
trusted state verified by quality control procedures (typically, SAT).
World Bank context

There is probably nothing about the topic of quality management that does not apply equally to World Bank client
countries and the world at large. Quality management is another layer of discipline laid upon the capacity development
requirement of the recipient. Once again it may seem like a solution looking for a problem. The need for quality
management and its various themes may not be apparent until some early failure of delivery.
If the World Bank client countries are to leapfrog ahead, they will need to adopt management technology more than IT.
There is a broader application of quality management to an organization’s standard products and services, such as
obtaining ISO 9001/9002 certification or (for IT) the certification level in the capability maturity model. This is notoutlined in the chapters of the toolkit, but can provide opportunities for institutional development in private and public
sector organizations in World Bank client countries.
What to expect from a project

Most of the products of a functioning quality management system are probably below the purview of the task manager.
Orientation should be provided to the client. This may be conveniently provided at the same time as project management
orientation. The project should be conducted using a recognized formal method, customized for pragmatic application to
the specific project. The project should:
Identify the mainstream quality management method to be engaged
Document the customized methods for the specific project to the extent recognized at this stage
Subsequent customization should be the topic of information notices distributed to interested or affected parties
Provide at least one set of the literature pertaining to the standard quality management method together with thecustomization notice, preferably in hard copy and soft copy
Conduct an orientation seminar that outlines and explains the key processes, artifacts and nomenclature of themethod, procedures of particular relevance to the client, and an overview of the procedures that the project teamwould use. Activities should be outlined for the specific project, with emphasis on the immediate stages, as the
project foresees it.
There will be quality plans, human and physical resources allocated to quality functions, evidence of quality functions inaction (such as notices of reviews and inspections, review commentary, inspection results, test plans, test results,
acceptance plans and acceptance results, correction plans, quality assurance reports, and project quality assurance reports).

40

Good practiceTechniques and topics
Quality management

Acceptance results may be revealed in connection with the commercial cycle. During supervision the task teams may finduseful indicators, in particular, in the quality assurance reports.
Budget for independent project audits, covering all aspects: technical, political, managerial, institutional, and financial.
Where to seek further guidanceExternal to the World Bank
P. Crosby, Quality is Free, Mentor Books, 1992, ISBN 0451625854 (a light and breezy publication).
The Capability Maturity Model — Guidelines for improving the software process, Software Engineering Institute, Carnegie Mellon
University, 1995 ISBN 0201546647. Also see www.sei.cmu.edu.

41

Good practice

Risk management
Chapter 4

Sustainability is a key issue. There is always a shortage of capital. This means thatinvestments need to be well targeted. There is less capacity for experimentation andgreater need to protect investments. There is a paradox: greater protection means
higher investment. Investment in protection is typically less of a priority when it
should be a dominant consideration.
What this chapter is about

This chapter provides an overview of the topic of risk management as it applies to theprotection of assets by identification, assessment, and monitoring of assets, threats,vulnerabilities, and countermeasures. Disaster recovery (planning and countermeasures) is a
special aspect of risk management applied to a complete or substantial loss of a significant
ICT asset.
Risk management of the type described above is not common in traditional World Bank
components. However, components for a risk management study or for implementing
countermeasures could arise as standard World Bank business, in particular for mature
beneficiaries. Risk management in this context does not include project or component risk.
That would be a project management topic. Annex A to this chapter provides some notesin that regard.
Not included within the overview here, are commercial risk and survival risk related to theall or part of the recipient organization. For example, a product line may be at risk fromtake-over, competition, or absence of demand. This is deemed to be beyond the scope of
ICT considerations.
Structure of this chapter

Introduction
Risk analysis steps
Examples of ICT assets, threats, and vulnerabilities
Protective measures

43
43
44
45

Additional notes
What to expect from a projectWorld Bank context
Where to seek further guidance
Annex A: Managing project risk
Annex B: An example of a project risk assessment

47
47
48
48
49
53

42

Good practice4.

Techniques and topics

Risk management

Risk management

Introduction

Asset risk pertains to the partial or total damage to assets. Risk management covers a cycle of vigilance and action thatentails risk analysis, selection of actions to eliminate, mitigate, or avoid damage, implementation planning (the securityplan), and implementation.
There are various methods that may be used to undertake a risk analysis activity. A generic approach is described here.
Risk analysis steps

The common steps in risk analysis are listed below.
Initiation of the study — negotiating the scope and the people, resources, and time available to the study team;planning of the study; obtaining existing materials (for example security reports, reports of security violation, audit
reports, previous risk analyses, current risk management plan, current business plans, and so on); and establishing
the study team.
Orientation for the client organization in the processes and nomenclature of the risk analysis and management
methods to be used, including the specific process for the current exercise. Literature of the standard methodshould be made available.
Identification and valuation of assets — refer to the next section for some examples of assets. Valuation may not
be straightforward, for example it may include value of reputation, individual business functions, ability to attract
capital, employees, or other resources.
Identification of threats — potential sources of damage to the assets. Refer to the next section for some examplesof threats. This requires observation, investigation, imagination, and experience.
Identification of vulnerabilities. For ICT, vulnerability would be any situation that could cause total or partial lossof the availability, integrity, or secrecy of the asset. Once again imagination and experience are required. A matrixof assets versus threats and vulnerabilities (and compromise of availability, integrity, or secrecy) can be useful.
Note that more than one asset can be exposed by a single threat and a threat may lead to more than one type ofloss. An example:
Table 4 A matrix of assets versus threats and vulnerabilities
AssetsNetworks

Hardware / software / networks

Data

Threats

PeoplePeoplePeopleAccidents

Accidents

Accidents

Physical access

Power

Logical accessLogical access

Environmental requirements

Container vulnerability

Environmental requirements

Human error

Human error

Vulnerabilities

NatureLogical modification

NaturePhysical access

NatureSoftware error

Electromagnetic interference
Human error

43

Good practice

Risks

Techniques and topics

Risk management

FailureFailureTheft

DamageUnreliability

Modification

Message interception

DamageFabrication

Service interruption

Destruction

Disclosure

Fraud

Theft

Destruction

Data protection violation

ErasureFraud

Data protection violation

Estimation of risk — the probability of a threat arising or a vulnerability exploited and the extent of damage —usually on a per annum basis. The weakest link in the analysis is usually the attribution of these probabilities.
Techniques to derive these include:
Observed data from the general population (for example fire or break-in statistics)
Observed data of the specific system (for example. failure rates, unauthorized access attempts)
Best guess based on estimates of historical occurrences to determine actual occurrences, or by interview to rate
likelihood, or a Delphi approach using a calculation on the input of several estimators.
Calculation of loss expectancy based on value of asset, probability of threat arising, and extent to which the threat
would disable the asset — often expressed as an Annual Loss Expectancy report. Some loss is relatively simple tocalculate, such as. loss of hardware. Other circumstances might be more difficult, such as unavailability of service,breach of legal obligations, exposure to legal action, psychological effects, or the cost of lost data.
Identification of potential protective measures. This is a matter of imagination, experience, investigation, anddesign.
Estimate ALE protection afforded by each protective measure. The protection would usually have limits, forexample fire protection systems may not provide any relief in the case of a coincident building failure.
Selection of cost-effective protective measures.
Examples of ICT assets, threats, and vulnerabilities

AssetsPeople: using, operating, administering, maintaining, and developing ICT
Hardware of information infrastructure: such as channels, cables, transmitters, receivers, routers
Hardware of IT: such as database servers, application servers, work stations, processors, random access memory(RAM), disc drives, tape drives, keyboards, monitors, cables, connectors, communications controllers,communication media
System software of information infrastructure: such as operating systems, utility programs, system and network
monitors
System software of IT: such as operating systems, utility programs, data base managers, transaction processors,compilers, system and network monitors, diagnostic programs, configuration managers, distribution services
Application software: such as source and object of bespoke systems, purchased packages, end-user toolsIntellectual property: such as product and system specifications and source code
Data pertaining to business and transactions with the organization’s clients
Documentation concerning ICT
Supplies: such as paper, printer cartridges, ribbons; exchangeable magnetic media; spare parts; diagnostic supplies;
maintenance supplies
Threats
Personnel: people belonging to the organization acting with malicious intent
Assailants: people external to the organization

44

Good practiceTechniques and topics

Risk management

Supplier: power fluctuation, power loss, telecommunications dropout, or other unreliable supplier of service or
facility
Accidents by personnel: human error, loss, fault in design, construction, or use
Physical accidents: fire, building failures, impact, and so on
Nature: earthquake, storm, flood, electromagnetic interference, lightening
Vulnerabilities
The major assets within an ICT environment are vulnerable to four classes of threat: interruption, interception,
modification, and fabrication. Examples are provided in the following paragraphs.
Interruption — asset is lost, unavailable, or unusable
Hardware vulnerable to physical threats: such as of operation outside environmental tolerances for heat,
power, humidity, fire, flood, leakage, liquid spills, dust, corrosion, electrostatics, impact, vermin, sabotage,
theft, and so on
Software vulnerable to physical and quasi-physical threats: such as accidental or malicious erasure oramendment or destruction or damage to the hardware or media container, planned but erroneous amendment,
viruses, worms, date-sensitive logic bombs, theft, and so on
Data may be vulnerable to physical and logical threats, such as through vulnerabilities of the hardware andsoftware that provide access, through denial-of-service attacks, virus causing data destruction, and so on
Interception — unauthorized party gains access to an asset
Hardware — unlikely to be subject to threat
Software — copy, theft, reverse engineering, “trap doors” — an unpublicized entry point in software,
unpublicized functions in software, operating system flaws
Data — through vulnerabilities in software, covert channels that disclose information more widely than was
intended, by theft or copy of media, fraudulent logical entry, access to data via direct local connections, remote
access through telecommunications, tapping disclosure, misuse
Modification — an unauthorized party gains access to an asset and alters it
Hardware — unlikely to be vulnerable
Software — vulnerable to logical threats: such as accidental or malicious amendment, virus
Data — vulnerable to logical threats: such as erroneous software, sloppy access control allowing fraudulent or
simply erroneous modification, tampering via application software after breach of access control, tampering
via utility software, virus, intelligent attacks such as “small slices — rounding down attack”
Fabrication — creation of spurious elements within an asset (such as transactions in a database)
Hardware — unlikely to be vulnerable
Software — unlikely to be vulnerable
Data — vulnerable to logical threats: such as erroneous software, sloppy access control allowing fraudulent or
simply erroneous modification, tampering via application software after breach of access control, tampering
via utility software, virus
Protective measures

Various measures that should be considered for an ICT environment are listed below. The lists are not exhaustive.
Table 5 Protective measures to consider for an ICT environment
Physical security:

Fire retardant materials in construction,

Location other than ground floor, below top floor

furniture, and fittings
Secure walls and structures

Fire retardant systems

45

Good practiceTechniques and topics

Risk management

Pest controls

Antistatic matsDust controls

Environmental monitors and controls

Power supply monitors and regulators

Uninterrupted power supply (UPS) equipment

Backup power generators

Mechanical and electronic locks

Antitheft screens and booths

Bolted workstation harnesses

Lighting and surveillance equipment

Intrusion detection and alarm systems

GuardsInsurance

Physical and logical

Secure operating systems — servers andSecure data base management systems including

access control

workstations (including US NCSC certification

restrictions on use of native facilities

Identification / authentication schemes (user-

More exotic controls: e-tokens, smart cards, retinal

name / password)

controls

where available)

Function level access control

Value based access control

Encryption public / private keys

Closing Internet access

E-commerce security certificates
Shielding
Software controls

Disabling exchangeable media devices

Dongles (hardware access control devices)

Shielding and ducting against physical,

Logical shielding: firewalls, closed user groups, dial-

electromagnetic and light sensitivity

back modems, dial-out only modems

Standards for development process including

Operating system controls that securely isolate individual

modular development and source code peer

users

reviews
Internal program controls for access to data

Control of access to programs

Virus protection software and procedures

Policy and procedure prohibiting introduction of data via
media or e-mail download

Procedures for

Run-time data base journals

Audit trails and transaction logs

prevention andRoutine backup— confirmed to be restorable

Routine and secure change control and configuration

detection of data
accessmanagement

Access control refresh procedures

Design incorporating division of duty

Secure disposal procedures for data on paper,

Tiger teams — planned assaults on system security

disk by shredders, overwriters, burners
Routine electronic data processing (EDP) audit

Centralization of or otherwise restricting system andnetwork administration

Redundancy inMultiple central processing unit (CPU) machines

Redundant self-correcting RAM

hardwareMultiple redundant disk controllers andRaid disks

channels
Multiple redundant power supplies

Redundant local area network (LAN) and wide area
network (WAN) circuits

Redundancy inSpare and standby units and spare parts

Self-monitoring systems

Disk mirroring

Duplicate databases

Installation of security officers with control overRoutine dissemination of security policies, norms andaccess rights

expectations

Procedures for screening and monitoring

Identification badges

Multiple and overlapping responsibility for

Succession: planned and implemented

software
Personnel

personnel

protecting against loss

46

Good practiceDisaster recovery sites

Techniques and topics

Risk management

A large-scale operation where an installation or a service is established such that following a catastrophe
service can resume on a complete backup immediately or over a short time span — the more immediate,
the more costly
Can be owned outright by the organization or available through some shared arrangement brokered by asupplier

Needs to be thoroughly understood and planned — not merely an idle second IT configuration. Could be inconstant use providing some lower priority service
All the procedures need to be in place and be periodically verified
Need to remember that personnel may be lost in disasters too
Usually sufficient distance between sites so that chance of catastrophe striking both is small

Additional notes

Corollary benefits to a risk analysis include:
Improved awareness of security issues
Identification of ICT assets, associated vulnerabilities, and existing security controls
Improved basis for the trade-off decision between security controls and production
Justification of investment in security measures
There is a trade-off between prevention and recovery. Instinctively, preventive measures seem preferable; however,they may not be economically rational or pragmatic. The overall cost of recovery, including lost production andother damage consequent to some damage to an asset may be less than any preventative measure.
An overriding concern is survival. Occasionally the monetary value of an asset may be indescribable — the cost ofclassified information or loss of human life. Other than economic concerns, rationalism should determine theextent to which protective measures would be selected and implemented.
There may be obvious attacks for which there are obvious protections. Analysis may be deemed be unnecessary.
It is important to recognize that experience suggests that more is lost (in dollar terms) to accident: errors andneglect by users, operators, programmers, and analysts, than intentional theft or damage. It is difficult to be
definitive: underreporting of loss and damage (regardless of cause) is endemic — to protect risks associated withdamaged reputation. In any event: it is best to use structured methods, have backup assets and procedures in place,and include fail-safe operation for at least core activities.
ICT security should interact with general premises and other (such as financial) security systems that may be inplace. There should be liaison with security personnel. There may be opportunity to extend existing insurance
cover arrangements at least for ICT physical assets.
What to expect from a projectA large-scale modernization project should include the preparation of an ICT security plan, entailing:
Security policy, goals, responsibilities for policy, limitations
Current circumstances: risk assessment
Security organization, procedures, roles and responsibilities for security procedures, procedures for unanticipatedvulnerabilities
Initiatives to upgrade security and to sustain the security policy, implementation plans (objectives, outcomes,
schedule, responsibility, resources)
Review mechanism.

47

Good practiceTechniques and topics

Risk management

ICT specifications should include some measure of redundancy.
Sound operational procedures for security should attend any system design.
A sufficiently large investment might warrant a disaster recovery plan together with the capital investment that this would
entail.
World Bank context

Risk management would appear as relevant within or without the World Bank context. In the World Bank context stress
may be laid upon:
The size of the ICT component (and financial exposure of borrower and lender);Resources for supervision of the ICT component;
Borrowers and beneficiaries in environments of greater social instability, for example at greater risk of civil unrest— the information technology assets too may be at greater risk;
Sustainability as a key issue:
Borrower or beneficiary may lose technical staff to the private sector in most World Bank funded ICT
projects. If compensation cannot be changed, nonmonetary incentives need to be present, for example variety
of work, staff development opportunities, travel through attachments, and so on.
There is always a shortage of capital. This means that investments need to be well targeted. There is lesscapacity for experimentation and greater need to protect investments. There is a paradox: greater protectionmeans higher investment. Investment in protection is less of a priority when it should be a dominantconsideration. It is better to sacrifice some functionality for a more secure installation.
Where to seek further guidanceWithin the World Bank
Contact staff that has managed large and complex ICT components of projects.
External to the World Bank
C. P. Pfleeger, Security in Computing, Prentice Hall International, 1996, ISBN 1033374866
J. A. Cooper, Computer and Communications Security, McGraw-Hill, 1989, ISBN 0070129266
Good practice in developing sustainable information systems (Theme 6) / Supporting Guides (esp. SG1), Department for International
Development (UK), CCTA 1998

48

Good practiceTechniques and topics

Risk management

Annex A
to Chapter 4Managing project risk

Projects implement changes. Change is risky business. Risk management of a related but different variety pertains toproject management (see chapter 1). Rather than vulnerabilities and threats that may lead to loss or damage of some assets,in the context of the project risk pertains to the process and its successful completion.
Risk for a project may be said to be failure to
Meet the agreed business needs
Provide the expected benefits
Provide feasible solutions (organizationally, socially, culturally, politically, technically)
Complete on-time and on-budget
Deliver quality products (that is, those required and with the attributes agreed)
A well-managed project will include risk management so that the project team and the client are more aware of thepotentialities, better informed in the selection of actions (including deferral of preventative actions), and better preparedand more responsive if the risks actualize. Risk assessment informs the client of the extent of obligations of all parties(including those of the client) and the effect of failure or delay in meeting these obligations. Thus, it should reduce surprise.
Risk management involves risk assessment, monitoring, and implementation of agreed actions. Risk assessment withinprojects is subjective and experiential. It is concerned with identifying threats, assessing them, defining passive and active
responses, and implementing or requesting implementation of responses. It is a process continually repeated until projecttermination.
A risk assessment takes the form of a list of threats and for each risk an analysis. An example is provided in table 6.
Table 6 Format for analysis of threats

THREAT: a short description
Description

Long description of threat

Likelihood

High / Medium / Low2

Disturbance level

EffectOutcomes should the threat materialize

Contributors

Events and actions that will contribute to the threat arising

Triggers

Indicators that the threat has arisen or is increasingly likely to arise

Preventative actions

Steps that can be taken to prevent or circumvent the threat

Reactive actions

Steps that can be taken if the threat arises

High / Medium / Low2

2 Estimation beyond these suggested bands is usually highly subjective. It needs to be questioned whether effort to better evaluate estimates isjustifiable.

49

Good practiceTechniques and topics

Risk management

Subsequent to risk assessment is decision making regarding which threats, if any, to address immediately, an assessment of
the costs and selection of any actions that would be implemented, and gathering resources for those steps.
The risk assessment and management processes are ongoing through the life of the project with republication either as aconvenient section of the regular progress reporting, or in exceptional circumstances.
The actions are not usually listed in the project’s Gantt chart. The project plan includes actual committed steps andresources to be engaged. Risk assessment will identify circumstances that arise probabilistically. If the probability were
sufficiently high and preventative action sufficiently low (and of certain effect), it would be reasonable to incorporate thepreventative action into the project plan (and acquire the necessary resources to execute that action). However, if either
does not hold, that is probability is low or the cost is high and perhaps of uncertain effectiveness, then the preventative or
corrective responses are usually reserved in the project manager’s kit bag. By definition, the project has access to fixedresources calculated by the extent of its work program. To the greater extent, then, the project will not be able toeffectively respond to threats without the intervention of the project champion, sponsor, and steering committee. In manycases the response will remain an obligation for external parties and never within the scope of the project.
Possible threats

Formally the project will be established for the delivery of an agreed product. The project will be judged, however, on theeffective implementation of its products, whether or not they are within the agreed scope. Some types of threats that may
arise are listed below, separated in two parts: threats concerning the process of the project and threats concerning the
project’s products.
Process threats
Changes in key personnel
Dependencies not delivered adequately and on-time
Total inability to deliver dependencies
Slowness on the part of the client to accept intermediate products or components
Unwillingness to pay — due to inability, lack of funds, or bureaucratic red tape
Other party commitments not delivered adequately and on-time
Other party unable to deliver its commitments
Ongoing vital business imperatives drawing resources from project
Complexity — there are many parameters, such as:
Table 7 Parameters for complexity
Size of projectSize of project teamHeterogeneity of products

Heterogeneity of client

Number of client functions affected

Number of implementation sites

Familiarity of project team with tool set

Familiarity of client with the project and its processes

Stability and understandability of existing process

Project goal: automate (easier and lower benefit) vs.
modernize (harder, greater benefit)

Novelty, importance, and “realism” of requirements

Schedule or budget adequacy

Technology gap between existing and planned systems

Ease of adoption of new technology

Tolerance levels in requirements perversely two edged: high tolerance can mean high discretion and perhaps difficulty in focus,
whereas comprehensive and hard-edged means no slips but easier to plan and execute50Good practiceTechniques and topics

Risk management

Ineffective training and skills transfer
Presence of subcontractors and their manageability
Poor project-client relationship
Strong technological imperative can lead to low client participation
Not the client’s requirement — project foisted on themContinual process of improvement within the organization impinging on the domain of the project and disturbing
requirements, or providing opportunity for conflict, or undermining acceptability of project products to end-users
Internal resistance — through pressure of on-going business, for political reasons, or through jealousy of project’spresence, access to resource, access to senior management, and so on
Estimated time and resources are inadequate
Supplier unable to deliver products or personnel of adequate ability
Inability of in-house resources to perform agreed tasks
Loss of project profitability leading to corner-cutting or walk-out by supplierInsolvency of supplier
Novel technology — no support in the input process
Unfamiliarity with the tools engaged
Capable supplier but has labor-supply or stability problem, inability to follow essentially sound process
Tight budget, changed supplier circumstances or greed, leading to corner cutting
Poor selection of supplier
Damage to project assets
Misunderstandings — ambiguous requirement or offer
Unstable requirements
Exploitation of change control
Underestimation of problem or management dimensions in conversion, migration, support, and maintenanceReluctance to lose a poor supplier because of opportunity loss of restarting caused by ineffective contractual
provisions or contracting problems — difficult to change, and a lengthy process
Product threats
Beneficiary does not implement or maintain use of the project’s products, because“Wrong” product — impractical in the context, unsustainable operation and maintenance cost, hinders rather thanhelps businessTechnological imperative drove the product rather than operational need or business opportunity
Service levels not set and agreed or not met (This can be a key factor: the system needs to perform tasks deemed
adequate and sensible by its users, and also to do so reliably during the hours of operation and according to agreed
service levels. It requires only a small degree of underperformance to undermine a system.)
Human machine interface ugly, unfriendly, or obstructive and hence system is avoided
System is avoidable, allowing users to resort to paper or previous methods of work
Inadequate technical infrastructure meaning poor performance of the overall system
Poor system design as a result of time constraints
Insufficient involvement by beneficiary during preparation
Technical product in a change vacuum
IS without context
Benefits of changes not appreciated51Good practiceTechniques and topics

Risk management

Benefits of changes too small or less than expected
No commitment to change
Delivered too late — so that alternative methods are engaged or business activities or priorities have changed
Improper project — client relationship leading to resistance to use of new products
External resistance (that is, from the client’s clients) to change too high,Internal resistance to change too highClient technically unable to effectively use, operate, or maintain
Ineffective use and underutilization
Relative technical obsolescence (an information system may be quite effective — merely dated in terms of thenewness of its technology base and deemed unwanted for that reason)
Commercial, technical obsolescence, that is, the product can no longer be maintained, or the cost of maintenanceis very highChange in business imperatives
Loss or damage — refer to risk management in the main text of this chapter.
World Bank context

All the above factors may apply in the World Bank context but emphasis may be placed on:
Political stability and associated stability of key persons and requirements
The source of funds may distort establishment of a project on sound footing; capital requirements are almost
invariably technology-driven and often too quickly initiated without due consideration of real parameters
Change issues beyond the introduction of technology may not be sufficiently addressed in project design, leading
to the impact of technology being suboptimal
Actual end-users may not be sufficiently engaged in the initiation and design of the projectTechnology, technology products, and technical infrastructure in the countries may not be sufficiently established.
What to expect from the project

The task team should anticipate a risk assessment that lists perceived risks, attributes probability (“high-medium-low” isusually as accurate as could be expected), and responses. It will be difficult to challenge the risk assessment as a result of
the dominance of local factors; however, attention may be directed to complexity factors.
Progress reports should reflect revised risk assessment.

52

Good practiceTechniques and topics

Risk management

Annex Bto Chapter 4
An example of a project risk assessment

1. THREAT: Availability of any new stationery in sufficient quantity
Description

The application design is likely to lead to redesign of input and output stationery for reasons ofphysical structure and content
The introduction of the new system requires that any new stationery be available

Likelihood

High

EffectSystem cannot be deployedDisturbance level

High

Reduced system effectiveness and need for later data repair
Use of backup procedures such as raising manual checks
Schedule in delay
Cost increases
Delay in benefits
Contributors

Indecision concerning form design
Delivery lead-times for new stationery stocks
Late changes in form design

Triggers

No decision on redesigned forms and notices by dd/mm/yy
Stocks of stationery not delivered in time for acceptance testing

Preventative actions

Early decision on redesigned forms as soon as practical after design is completed
Ordering new stocks in good time for acceptance testing

Use of plain paper A4 structures with graphics that can be merged at the time of printing or that canbe done in-house using laser printers
Reactive actions

Delay implementation

If possible, produce some samples or some small stock quantity in-house
Modify systems and procedures for interim use of existing stocks of old stationery

2. THREAT: Dissatisfaction with system
Description

The system requirements were prepared using representative requirements and assessments ofneeds and the build will also be based on representative inputs and estimates of delivery efforts
There may be errors and omissions in the process
The system requirements were framed by a concept of an entry-level system that excludes several

areas of administration, or at least defers several areas of functionality to an unspecified subsequent
project
Consequently not all expectations are included
Likelihood

High

EffectDissatisfied client

Disturbance level

Medium to Low

Dissatisfied constituents
Dissatisfied supplier
Poor adoption of the system

53

Good practiceContributors

Techniques and topics

Risk management

Unrealistic expectations
Misunderstanding of limits imposed in terms of functional coverage within requirement specification
Incomplete requirement specification
Requirement specification is not understood by client, leading to drift in requirement
Requirement specification not understood by supplier
Shifting expectations from client

Flawed assessment of work by supplier at bid or subsequently
Incomplete design (business and technical)
Design not understood by client
Design not compliant to requirement specification
Build not compliant to design
Flawed design theory
Deployment requirements not understood
Project integration failure
Triggers

Change requests
Difficulties in review processes
Grapevine critique
Monitoring attitude toward the project and the system from the client

Preventative actions

Communication at various project stages to explain project rationale and system scope, design, andimplication
Early communication and discussion of topics as they arise
Early resolution of issues as they arise

Reactive actions

Changes in project scope
Communication

3. THREAT: Late deployment of technical infrastructure
Description

Technical infrastructure required for the system to operate may be delayed for several reasons
Experience suggests that procurement does not proceed at the pace theoretically possible

Likelihood

Medium to High

Effect

The project will be in delay

Disturbance level

High

Potentially, parties may seek equitable compensation for delay beyond their control
Morale may suffer
Legacy systems will need to be retained for longer periods, possibly incurring costs
Contributors

Delays in procurement process
Delays in commissioning by supplier(s)Client premises and site not ready to accept equipment

Triggers

Schedule slippage at issuing ITT(s), and dates of evaluations(s), award(s), and contract(s)Schedule slippage in supplier(s) commencement and execution of delivery and installation tasks
Schedule slippage in site preparation

Preventative actions

Monitoring schedules for all project contributors
Scheduling adjustments for affected projects

Reactive actions

Penalty provisions in supplier contract(s)4. THREAT: Ineffective skills transfer and training
Description

The project provides skills transfer specific to the development and implementation process for the
IS and training for users
If ineffective, the client will not be able to provide required service, or sustain required levels of
operation, support, and maintenance

Likelihood

MediumDisturbance level

High

54

Good practice

EffectTechniques and topics

Risk management

Operation of the system impaired
Support and maintenance impaired
Public attitude to client diminishedContinuance of business threatenedContributors

Poor selection of trainees and candidates
Unreceptive trainees
Poor trainers
Poor training materials
Inadequate facilities or environment for deployment
Inadequate or inappropriate training

Ineffective training measurement system
Training not adequate for deployment environment
Triggers

Help desk evaluation indicates training problem
Observation by supervisors and users

System errors as a result of human errors
Preventative actions

Minimum qualifications set for training
Help facilities on system
Continual assessment by supervisors
Refresher courses

Reactive actions

Revised training courses
Retraining

5. THREAT: Changes in key personnel of project
Description

Changes in project champion, sponsor, and key personnel may weaken drive and knowledge within
the project and diminish its chance of a successful completion

Likelihood

MediumDisturbance level

EffectLoss of corporate intelligence

High to Medium depending on phase

Loss of momentum in decision making
Loss of enthusiasm for project
Changes in requirements and priorities
Schedule slippage
Lower morale
Contributors

Poaching
Disenchantment of key personnel
Increased career opportunities
Diminishing job satisfaction

Poor project performance and personal performance
Diminished interest level
Triggers

Key people leaving, being redeployed, or being given additional duties

Preventative actions

Monitoring of key persons to recognize potential burn-out
Succession planning
Budget for replacements

Reactive actions

Recruiting competent and interested replacement

6. THREAT: Data cleansing or migration slippage
Description

Client and supplier need to work together to have data migrated to the new systems
Client has to ensure that clean data are ready at the time of deployment

Likelihood

MediumEffectDatabases not ready for deployment

Disturbance levelLow for cleansing, High for migration

Integrity of databases compromised
Contributors

Ineffective collaboration in data conversion exercises

Legacy architecture may not convert easily to new technology

55

Good practiceTechniques and topics

Risk management

Poor quality in existing data stores leading to large work volume for client
Underestimation of the size of the task, especially for cleansing
Unavailability of staff for cleansing activities
Triggers

Imperfection in current reporting on existing databases
Data conversion for test data in development phase incomplete
Pilot site testing in delay for reasons of converted data
Converted data or conversion and take-on suite not ready according to deployment schedule

Preventative actions

Early planning and execution
Early commencement of cleansing
Plan monitoring
Quality reviews

Reactive actions

Delay schedule
Engage more resources
Segment taxpayers to be converted and implement with phasing of segments

7. THREAT: Poor performance of client staff at direct project tasks
Description

Client staff not only support the development team, but are vital for several activities, such as

procurement specification, design input and review, business-rule expertise for design and build,
acceptance design and testing, complementary procedures development, technical infrastructure
acceptance, T3 training, and so on
Inadequate performance by client staff would affect project performance

Likelihood

MediumEffectSchedule delay

Disturbance level

Low to High depending upon task

Imperfect design
Lower quality of products
Difficulties in making the system operational
Poor first-line support of system
Poor training
Cost change as a result of extensions and rework
Contributors

Person not dedicated to the project task
Low morale

Inadequate skill or experience for assigned tasks
Lack of management support and direction
Slow executive decision making
Unclear tasks or misunderstanding
Unclear accountability, responsibility, or authority for individuals
Inappropriate influence to obtain sign-off
Triggers

Morale problems detected by project managers
Tasks not completed or completed late
Tasks not completed for reasons of skill or experience
Quality reviews illustrating tasks not completed or product is of poor quality
Sloppy configuration control
80:20 syndrome

Preventative actions

Policies, procedures, and standards clarified and communicatedClear role descriptions
Project should not lead to habitual overtime
Task monitoring and mentorship
Continual monitoring of morale
Training
Reward structures for project personnel

56

Good practice

Reactive actions

Techniques and topics

Risk management

Discipline
Changes in personnel
Attitude modification
Executive intervention

8. THREAT: Client not ready for deployment
Description

Client premises need to be established and ready and officers selected, appointed and trained

Likelihood

Low to medium depending on site

EffectDisturbance level

High

System not deployable
Poor quality sites may lead to public dissatisfaction, staff dissatisfaction, and disaffection withsystemSchedule delay
Direct cost increase

Delay in opportunity benefit
Contributors

Officers not ready: appointed and trained and aware
Sites not ready: late and inadequate capital works, site preparation, furniture and fixtures, data
communication infrastructure

Supplier(s) failure on various goods and services
Client failure on various services
Triggers

Site not ready
Implementation tasks late
80:20 syndrome

Preventative actions

Monitor implementation projects
Add penalties for delay in contracts
Plan backup source of supply
System design and implementation should lead to disruption of existing practices only when there
are clear benefits

Reactive actions

Cancel supplies contracts and use alternative source of supply
Delay implementation

9. THREAT: Late deployment of WAN
Description

The WAN will be used in the system to aggregate data for national statistics, system management,

Likelihood

Low to medium

payment and account transfers, and other data or software distribution

Effectdepending on site

Disturbance level

Low to medium

Proof of design would be delayed
Transfers may need to be done by slower physical means and be less reliable

Contributors

Late delivery by WAN supplier(s)Installation and commissioning difficulties
Instability of network design and delivery schedule for subsequent sites

Triggers

Progress reports of WAN project
Information from other earlier WAN users
WAN service unavailable for initial sites
WAN service unavailable for subsequent sites

Preventative actions

Monitor progress of WAN project
Seek information from other users

Reactive actions

Use of magnetic media and physical transportation
Seek alternative WAN service

57

Good practiceTechniques and topics

Risk management

10. THREAT: Poor performance of WAN
Description

The WAN will be used in the system to aggregate data for national statistics, system management,
payment and account transfers, and other data or software distribution
Volume of usage is anticipated to be low

Likelihood

Low to medium

EffectTransfers may need to be by slower and by physical means that will weaken achievement of design

Disturbance level

Low to medium

objectives and introduce operational impediments
End-of-day procedures may not be completed in the allotted time period
Access to sites impaired
Contributors

WAN is untested
Contention on channels by other users of the network
Bandwidth requirements of new application system beyond expectation, such as volume usage
resulting from design or from volume of business transactions beyond expectation
Interoperability problems between new technical infrastructure and WAN
Unreliability of WAN availability due to drop out

Triggers

Progress reports of WAN project

Information from other WAN users
Performance monitoring and diagnostic analysis when new system is deployed

Preventative actions

Simulation of volumes by supplier during load testing
Use of efficient protocols anticipated within technical architecture
Decentralized design of new system

Proper load and performance testing by WAN project
Warranties within the technical infrastructure contract concerning interoperability with the WAN
Restricting ad hoc access to new system sites
Reactive actions

Resolution of interoperability issues between new system technical infrastructure and WAN suppliers
Purchase of increased bandwidth for the WAN service
Use of magnetic media and physical transportation
Seek alternative WAN service

11. THREAT: Poor performance of technical infrastructure for deployment
Description

The technical infrastructure may not perform to expectations for reasons of speed and throughput,interoperability, or hardware or software failures

Likelihood

Low

Disturbance level

High

EffectStaff disaffection toward new systems

Contributors

Interoperability problems between components in any particular contract

Public disaffection toward new systems
Interoperability problems between components in different contracts
New application system unexpectedly resource-hungry
Poor sizing of technical architecture

Poor sizing or changes in demographics concerning business volumes
Bad batches of equipment
Poor quality of hardware and software
Errors or omission in commissioning
Triggers

Observation of acceptance test performance
Observation of pilot site performance, especially for load tests
Monitoring calls to help-desk

58

Good practicePreventative actions

Techniques and topics

Risk management

Various parties contribute toward specifications
Postqualification trials on hardware and software
Prime contractor relationship built into contract(s)Minimizing the number of supplier contracts
Scalability provisions in specifications

Inclusion of support and maintenance and warranty provisions in contracts
Burn-in and commissioning of systems before deployment
Reactive actions

Increase quantities or sizes of purchased equipment
Invoke performance bonds or penalty provisions in supplier contract(s)Defer deployment — but see Threat 1

Invoke support and maintenance and warranty provisions

12. THREAT: Poor performance of the second new complementary application subsystem
Description

The new subsystem is vital for timely, accurate, correctly-formatted input data

Likelihood

Low

Effect

Untimely or inaccurate data to accounts providing opportunity for spurious interest and penalty

Disturbance levelHigh

notices, inaccurate account enquiry

Potentially, disaffection with new system
Contributors

Software failure
Interface design imperfections
Indirectly, end-users’ attitude to new complementary application subsystem

Triggers

Acceptance testing reporting failures
Exception reports in payment posting

Preventative actions

Comprehensive testing of new complementary application subsystem

Reactive actions

Repair subsystem or interface

Comprehensive two-way interface testing between the system and the subsystem

13. THREAT: Unavailability of client’s staff for direct project tasks
Description

Client’s staff are vital for procurement specification, design input and review, business-rule
expertise for design or build, active participation in the development environment, acceptancedesign and testing, complementary procedures development, technical infrastructure acceptance, T3
training, and so on

Likelihood

Low

EffectSchedule delay

Disturbance level

High

Imperfect design
Lower quality of products
Difficulties in making the system operational
Inability to provide first-line support of system
Inability to undertake training obligations
Cost change — either because of engagement of alternative skill or extension of contract

Contributors

Higher priority task intervenes
Person has more than one task
Sickness, resignation, or other unavailability of key persons
Skills upgrade of team increases marketability
Project participation retards rewards within client

Triggers

Person physically unavailable for various project task
Morale problems detected by project managers, leading to suspicion of underperformance
Perceived priority of project diminishes either officially or through perception
Personnel turnover

Preventative actions

Responsibility overlap between team members
Continual monitoring of morale
Succession planning

59

Good practiceTechniques and topics

Risk management

Team building activities
Built in reward structures for project personnel
Reactive actions

Changes in personnel
Executive intervention

14. THREAT: Resistance to change within client
Description

The system needs to be fully and properly used if benefits are to be realized

Likelihood

Low

EffectSystem not used properly

Disturbance level

Low to High

Data not fully captured

Sabotage of equipment or databases
Contributors

Morale of user community
Inadequate training

Inadequate communication and conditioning
Lack of buy-in by key trendsetters
Poor system performance
Unexplained, not-understood new or additional duties
Changing of staff power bases
Incomplete system design — necessary functions not included in design
Triggers

Observation of staff attitudes
Help-desk logs
Organizational conflict concerning implementation of new system

Preventative actions

Training
Communication
Management is tolerant of disturbance caused by implementation

Reactive actions

Retraining and reconditioning
Consultation

Disciplinary actions

15. THREAT: Security of project offices and their content (including assets of contractors andsubcontractors)
Description

The key assets of the project are development tools and information on paper and disk, the loss or

Likelihood

Low

EffectDisruption of scheduledamage of which would retard progress
Disturbance level

Low to high depending upon asset

Loss of information
ReworkProject termination
Contributors

Software viruses
Fire and other accidental damage
Deliberate damage
Theft of equipment or of media holding data

Triggers

Event causing damage
Other security violations at client’s premises

Preventative actions

Secure premises
Backup of data off-site
Antivirus measures
Insurance

Reactive actions

Purchase new equipment
Resort to latest backup
Rework as necessary

60Part 2: Good practice

Change management
Chapter 5

It is in the nature of organizations to change, and the most successful ones are thosethat anticipate and adapt to changing circumstances. Change needs to be predicted,
planned, and managed. This is the key to real success.
What this chapter is about

This chapter provides an overview of a very wide topic of organizational development
interventions attendant to ICT that seek to change human activity systems.
Issues related to change are not specifically about ICT. An ICT component may be used asa change agent (to motivate some development objective), or the component may be anelement of a wider reform. But an ICT component is always about realizing change against
the uncertainty of a successful outcome. The issues are to do with people, businessactivities, and work practices and can have a significant impact on an organization.
This chapter defines change management by making a distinction between change control(a vital part of project management) and change management, that is planning for andmanaging the impact of change. It is this latter topic that is the subject of this chapter. The
chapter focuses on the need for awareness of change issues (perhaps a neglected aspect ofmany World Bank ICT components), and provides a checklist for preparing and planningfor change, overcoming resistance, and encouraging acceptance of change.
Task managers should be aware of resistance to change. It will impact the absorptive
capacity of an organization. Some gauge of this should be attempted in the institutional
appraisal. Timeframes should not be too ambitious. Contractors are likely to be able tomove more quickly than the organization can take change.
Structure of this chapter

What is meant by change management

62

Business change management

62

Checklist for change management

63

Related issues

64

61

Good practice5.

Techniques and topics

Change management

Change management

What is meant by change management

There is room for some confusion about this title. It could mean change management or managing change. What is thedifference? There is none! The terms are often used interchangeably. But this chapter is going to differentiate by ascribing
the meanings as follows:
Managing change will be taken to mean controlling change within a project. Change in any project needs control.
In the context of ICT it requires particular care. Proposed changes should be properly assessed and approved
ideally before a project is started. Change after a project is started is likely to delay completion and defer benefits.
When, inevitably, changes arise they should not be obstructed. But if there is no formal mechanism to control
changes, an ICT project can quickly go out of control with delay and cost build up, until what is delivered bears
little resemblance to what was approved. To avoid this a change control procedure should be set up. Changes canbe managed more easily if there is a firm foundation of approved plans, specifications, and an infrastructure ofprocedure on which to base the management. Change control is therefore, a function of project management andis therefore, dealt with in chapter 1.
Change management, the subject of this chapter, is different. It will be taken to mean managing the impact ofchange, some of it planned some unplanned, both within and beyond the project. A great deal is written aboutchange management, business culture change, and so on. The subject is often clouded by management consulting
jargon and becomes too esoteric for the issues to be sufficiently grasped and acted upon. The jargon may also
disguise the fact that there is no substitute for clear direction and firm management, and that all good managers
should see change management as part of their job, rather than as a separate, or one-off function. Equally, mostchanges will not be accomplished by management edict. They require explanation, understanding, and total
acceptance by those affected.
A reform program of any scale will mean significant change. The impact can be felt across the organization. It will have
implications for the culture of the organization, its stakeholders, and its customers. It must be anticipated that the change
will be continuous but that there will inertia and many obstacles to overcome, including staff uncertainty, fear, and moraleand motivation problems. There will be a need to pay attention to:“Soft” human resources (HR) issues with positive efforts to obtain commitment and participation
Management commitment at the most senior level: implementation will present major difficulties and obstacles,
and will require determination to surmountSupport for internal management: the reform may attract negative attention from public sector unions, the press,
and the public; internal management will require political support if the changes are not to be deflected
Change management is not a complete, alternative way to manage. There is still a need for management of project, risk,
quality, and benefits.
Business change management

The successful introduction of ICT can involve fundamental change affecting most or all of an organization. Change needs
to be predicted, planned, and managed. It requires the commitment of senior managers and staff acceptance. Some if not
all stakeholders will inevitably see change as a threat. Considerable effort may be required to overcome resistance. The
process will be assisted by:
Avoiding change for its own sake
Gaining the support of effective champions of change within the organization
Being prepared to explain changes to doubters, and modify plans where there is a case for doing so, for example,
because someone has a better idea or because the change seems likely to provoke more trouble than it is worth.

62

Good practiceTechniques and topics

Change management

Checklist for change management

While the following checklists contain some points that can be considered as specific actions, they describe more a way of
thinking, an approach, an awareness of change issues in the planning and management process. The project plan can havesome specific actions included that will result from change management awareness — the most obvious would be HR
activity in the form of workshops and training. Such a program would not only develop technical skills but increaseawareness of IT and provides a forum for keeping people aware of developments. The project timeline may be lengthened
or extra stages may be added.
Preparing for change
Always identify the basic problem or opportunity and the desired outcome.
Plan changes to achieve specific results.
Change as little as necessary to achieve the desired improvement.
Evaluate the driving and restraining forces before planning the change.
Anticipate the problems likely to be generated by the change.
Consider how changes may interfere with work in business areas not concerned with the change.
Decide who needs to be involved in planning the change and who is likely to be affected — invite them toparticipate in planning.
Planning the change
Will the benefits outweigh the costs in time, effort, resources, disruption, and so on?
Plan the change in terms of what needs to be done, in what order and by whom.
Cost the change in terms of time and resources needed.
Put yourself in the shoes of those affected by the change, from planning to consolidation.
Ascertain the degree of support the change will have from top management.
Decide how change will be monitored during the change and consolidation period.
Work out criteria to judge whether people affected by the change are behaving appropriately and achieving the
expected improvements.
Devise early warning systems to detect difficulties, discontent, shortages, interference and unexpected snags.
Keep a “fire-fighting” reserve of time and resources to deal with unexpected problems.
Overcoming resistanceAppoint a change champion who believes in and is committed to the change.
Get the support of key opinion leaders whose attitudes can make or break the project.
Identify people who are likely to resist the change, and find out their reasons for doing so.
Make sure potential resisters understand the potential benefits of the change.
Let resisters know how their opposition would affect people expected to benefit from the change.
Seek areas of agreement with resisters.
Remain open to the possibility that the change may have unexpected drawbacks.
Invite resisters to contribute to the change by suggesting modifications.
Show genuine willingness to make justifiable modifications in line with their suggestions.
Insist that emotional opposition be converted into constructive suggestions.
Have change supporters present at any important discussion where resisters are likely to be expressing discontent.
If necessary consider how resisters can be given special incentives.
Consider taking on resisters by giving them roles in the design or implementation of the change.

63

Good practiceTechniques and topics

Change management

How to encourage commitment to change
People will be more committed if they have helped plan the change.
Those affected should have as much understanding of the change and its consequences as possible.
Explain in simple and specific terms how people will benefit from the change.
Always maintain the self-esteem of those affected by the change.
Avoid creating win-lose situations wherever possible.
Collaborate with formal and informal leaders to gain their support.
Look for ways to change negative concerns into positive opportunities.
Generate as few surprises as possible.
Remember that change of any kind demands considerable unlearning as well as learning.
Lead by example on the job — demonstrate behavioral support and commitment.
Be willing to admit mistakes and learn from failures.
Related issues

To foster good communications and a participative style of management:
Treat staff with respect and pay attention to concerns regarding new equipment and work practices.
Take advantage of staff familiarity with work processes and cultural circumstances, which can hinder or support
the introduction of new ways of working.
Review organizational structure and job design, paying attention to overlapping jobs, boring and routine jobs,
unnecessary tiers of management and supervision, and tasks that are outside the project needs.
Provide a supportive work environment.
Make the best of the workspace available, although ICT introduction may require additional workspace.
If required, improve the building infrastructure and the services for its upkeep, so that technology is not exposed
to rain, vermin, dust, or humidity).
As part of this planning process do not ignore health and safety issues.

64Good practiceExternal expertise, skills, and capacity
Chapter 6“Here lies a man who knew how to enlist into his service better men than himself”(Andrew Carnegie, who coined his own epitaph). With advances in technology andthe increasing number of complex systems and specializations, the principle behind
Carnegie’s epitaph is even more relevant today.
What this chapter is about

Organizations cannot bring about and sustain improvements in the performance ofbusiness activities unless they have the necessary skills to carry out these activities using
effective work practices and sound information systems. Organizations need to develop
their capacity, in particular the capacity to identify and solve problems, to manage
information, and to use IT as a tool for implementing business strategies. But the range ofskills needed is very wide and, for certain skills, very specialized. Organizations cannot rely
entirely on their in-house capacity. This is particularly so during any project involving
business change.
In the planning and implementation of an ICT component task managers should assess
what external expertise may be needed: what type, in what quantity, and when. This chapter
identifies a set of skill profiles for expertise that may need to be brought to bear.
This chapter also gives some pointers on capacity development in the context of an ICT
project component. Task managers should assess what capacity may need to be built within
the organization and plan to achieve it.
Structure of this chapter

The need for external expertiseWorking with external expertise
Assessing the need
Examples of when to use
Examples of activities
Range of skills
Sources of skills
Capacity development
Good practice tips for capacity development
Where to seek further guidance

66
66
67
67
68
68
71
72
72
73

65

Good practice6.

Techniques and topics

External expertise

External expertise, skills, and capacity

The need for external expertise

A project concerned with business change involving the introduction of ICT should not be contemplated without theprovision of some form of expertise (whether a consultancy operating as external expertise, or someone from within theorganization), an essential ingredient of a sustainable IS project. Different expertise may be required at different stages ofthe project lifecycle, or several may be involved at any one time. Usually expertise will be required to assist the organization
to define, choose, and contract for a system. Most projects will require a multidisciplinary team of external experts throughall stages of the loan and component lifecycle. The skills needed from time to time would entail knowledge and experiencein terms of:
Sector or business domain: each sector has its own strategic dimension, particular requirements and, in one or two
sectors, an emphasis on particular technologies, which makes previous experience a useful asset
Management of the design, deployment, and operation of IS
Technology (that is, of the relevant IT hardware and system software)
Commerce (that is, the ability to negotiate fair commercial conditions, such as for a fair and realistic contract).
The need may be obvious, as in the case of a project that is in trouble but sometimes problems are less obvious. It is muchharder to recognize problems that may evolve along the planning and development route. Remember, consultants cannot
work miracles. Expertise is often used too late in ICT projects, especially when it is brought in as an emergency measure tohelp solve pressing problems. The appropriate use of expertise in the early stages of a project or strategic development
creates a good foundation and is more likely to be cost-beneficial than fire-fighting measure later on.
Working with external expertise

Managing this expertise will be an essential ingredient to success.
External expertise is that which is brought in from outside the beneficiary organization. It may be local, regional, orinternational. Local or regional expertise is less expensive and may establish useful, affordable relationships to meet theorganization’s future needs beyond the life of the project. In the field of ICT, however, the best resource may beinternational.
The organization should have ownership and commitment and should provide the project manager (see Project
management below). The tasks of external experts should be to advise, facilitate, build capacity (see section in chapter 6),transfer knowledge, and provide training. This should be based on a joint undertaking between the expert and the client.
Best results are achieved when there is mutual trust and full understanding. The aim of should be to help bring about
effective and beneficial change, not simply produce neatly bound reports. In the best assignments human interactionchanges minds and stimulates action long before a report is written.
This ideal may be incompatible with the demanding contractual obligations when the external expert may, in certain
circumstances, have to act as contractor (rather than adviser), or almost as an internal resource adopting a near line
management role. Notwithstanding, the relationship should be one of partnership and shared objective.
External experts should provide impartial and independent service. They should advise and act solely in the best interestsof their clients. They should accept responsibility for their work, including any subcontracted work. They should bring to
the project:
Specialist knowledge of IS techniques, technology, and management
Experience from a range of clients
High level of intelligence66

Good practiceTechniques and topics

External expertise

Good analytical skill and the ability to synthesize
Ability to present and persuade
Good report writing skills.
Briefing
It is counterproductive to expect external experts to find out everything for themselves. It is the responsibility of the hiring
party to provide as much information as possible. A briefing should cover:Background information, including history, corporate philosophy, culture, key people and their responsibilities, andrelevant documentation
A discussion of the problem and the work to be undertaken
Scheduling of time for senior and middle management interviews
Ensuring the terms of reference (TOR) are thoroughly understood and there is awareness of the depth andemphasis of various parts of the TOR
Methods and techniques to be employed and what sources to be investigated
How outputs are to be delivered and how each expert is expected to contribute
Procedures for monitoring progress and altering course
Where mixed teams are involved, ensuring individuals have clearly defined responsibilities
Discussing and agreeing on arrangements for knowledge transfer
Identifying existing arrangements for carrying forward recommendations.
Assessing the need

Assessing the need for external assistance should be part of the planning process. It will require some knowledge of theorganization’s capacity (see chapters 2 and 10). Consideration should be given to:
The stages of the plan that require inputs from external expertise
The activities within the stage that require help
Skills, knowledge, and experience that the expert must have
Where this expertise may come from, depending on the nature of the component, its complexity, and the project
strategy (for example, a turnkey model would mean a greater portion of expertise coming from a single
contractor)
How long the inputs may be required.
The following paragraphs look at these points in turn.
Examples of when to use

External assistance may be needed throughout the lifecycle. Remember, depending on complexity, help may be needed forboth the loan preparation and the analysis and design phases of the component, through implementation and closure.
Inputs may be appropriate in the following circumstances:
Management and organization
Where there is lack of experienced management personnel to guide and control matters
Where there is wide divergence of view on IT and IS matters which is hard to reconcile
Planning
Where assistance is needed in planning strategically for IT and IS

67

Good practiceTechniques and topics

External expertise

Where assessment is needed of IT and IS investment
Business analysis, feasibility study, full study
Advice on methods, procedures and standards
Specialized IT and IS training, such as project management
Development and implementation
To supplement in-house resource with essential expertise
Where there are delays
StagesLoan and project preparation
Analysis, specification, and design
Implementation, supervision, and quality assurance
Closure and completion
Examples of activities

The activities required of external experts would depend on the project or component (whether a component to produce
an IS strategy or implement a system), its complexity (whether a low complexity hardware supply and installation or highcomplexity business change and automation). Examples of activities that may need help from external expertise follow:
Loan preparation
Problem analysis
Institutional appraisal and diagnostics
Assessment of IT maturity — internally, locally, and regionally
Project management training
Implementation
Strategic or business planning
IS strategy development
Business diagnostic or business analysis
Feasibility study
Full study
Design of business change program
Capacity development
Project management
Procurement
Training
Technical audit
Range of skills

Most organizations will need a range of skills to run their business and, in considering their ICT resource needs, will haveto determine whether the resources are available in-house or have to be identified externally. It helps to categorize thetypes of skills into broad headings and then subheadings as shown in table 8.

68

Good practiceTechniques and topics

External expertise

Table 8 Hierarchy of skills required by an organization
1

Primary

Secondary

Analysis

Business

5

Primary

SecondaryOperations

Technical support

SystemOperations
Help desk2

DesignDatabase

6

Other specialists

ScreenProcurement

Forms

Sizing

ProgramIT security

Network
3

Programming

Relational data base management

Systems

Training
7

Telecommunications

Applications

WAN
LAN

Voice
Image

4

Planning

Strategic
Tactical

8

Management

Line

Program

Project

Project

Infrastructure

Team

Typically a business change project involving ICT will require inputs from a similar range of experts, including:Analysts
Business — experts who have a good understanding of the sector and business at strategic, tactical, andoperational levels. For example, a project to modernize a customs department would require customs officers,
even if the project were largely to automate entry processing using package software. The task is to help identify
the problems with the business activities and advise on the opportunities for improvement.
Business and systems — experts with experience in the sector or the target business function (for example,.
financial management), and in the use of soft systems analysis, structured systems analysis, and modeling (humanactivity systems, business activity, and work practice models). This may require two (or more) specialists.
Analysis and programming — experts who will combine investigative, analytical, and design skills with the ability
to use software tools or programming languages to produce properly engineered and tested software.
Depending on complexity, this type of expertise will be needed to scope and prepare the loan as well as to be involved at agreater level of detail in the analysis, design, and development of the ICT component. In a medium to high complexity IS
component the source of expertise will almost certainly be external to the World Bank and the target organization (avoid“we can do it ourselves”).
Technical specialists
These are experts who can advise on or perform the technical aspects of the project. There is a variety of expertise that
may be required, including:
Programming — ability to use software tools or programming languages to produce properly engineered andtested software solutions to meet defined needs
Database — to provide specialized expertise and practical assistance in the database design and the use of databasemanagement systems (knowledge of a proprietary database may be needed)
Operating system — knowledge of operating systems such as Unix, Microsoft NT
Hardware — knowledge of hardware and platform architecture configuration and selection, sizing, and so on
Communication — knowledge of standards and specifications; options include telephone infrastructure, radio,
satellite, the Internet, line of sight microwave
Networks — knowledge of LAN and WAN (see also communication) design and installation including cabling,
channels, hubs, switches, routers and so on

69

Good practiceTechniques and topics

External expertise

Environment — knowledge of physical environment design for ICT including electrical supply, health and safety,
security, maintainability
Security — knowledge of electronic and other technical security tools including telecommunication modems,
firewalls, and guarding against criminal or negligent abuseContingency planning — ability to plan, design, and test procedures and mechanisms to protect the availability,
integrity, and confidentiality of IS and services from catastrophic failure
Project management
Project management (see chapter 1) arrangements must be designed with the recipient organization and:The project manager should be appointed from the recipient organization.
Project control should be carried out by a project board (or steering committee) at formal assessment meetingsand by the project manager at checkpoint meetings.
Project management training should be included as necessary.
However, depending on complexity and the project or procurement model adopted, external project management expertiseshould augment the recipient organization capacity. This may be in the form of:Consultancy advice provided to the component
A management firm appointed to provide a range of services (business or system analysis, specifying, design,
procurement, software build), including a project management role
A counterpart project manager provided by the contractor for software or system.
Procurement
Experts with experience in the complexities of ICT procurement can assist in managing the procurement, ensuring goodpractice, and a transparent process. This knowledge may reside in the business or system analysts. More specifically, theexperts can provide help with:
Finalizing the functional specifications and bidding documents
Developing appropriate contracts
Conducting market surveys of possible suppliers
Producing evaluation criteria and conducting the evaluation
Carrying out negotiations both technical and commercial or contractual
Finalizing maintenance and support requirements.
Human resources
A range of HR expertise may be needed, from HR development (assess training needs, develop training plans, modules,
training material, and deliver training), to addressing strategic HR issues which may be beyond the ICT component but partof the wider project, ensuring the sustainability of the ICT investment: such as HR policy, senior management
development, succession planning, comparative pay studies (particularly for ICT resources), job descriptions, and staff
appraisal systems.
Technical audit
Expertise may be needed for
An independent technical, political, managerial, institutional, and financial audit or assessment of the project or
the ICT component
Software production quality management against acknowledged external criteria (primarily ISO9000)
Review of business and systems operation or performance, where the performance falls short of the expected, or
where an independent assessment of the efficiency of the operational system is required.

70

Good practiceTechniques and topics

External expertise

Technical authorship
Normally the supplier of the software will provide software manuals. System manuals may need to be specially drafted(usually contracted from the software or system supplier). Depending on the complexity (what business processes havebeen automated and what other processes have been reengineered), manuals of complementary procedures may berequired. This should not be underestimated and may require combined business expertise with specialization in technicalauthorship.
Information system services
A specialist may advise on issues related to running an effective IS service function.
Other activities

Audit and control specialists — to introduce modern systems for audit and control that link to the updated
business activities, work practices, and information systems
Work study and organizational analysts — for the study of human and organizational aspects of businessactivities and advise on optimum staff numbers, grading, and so on
Information and data management — to ensure data are accurate, complete, consistent, locatable, andmeaningful when presented to the user (this may be carried out as part of business analysis or as a health check)
Records management — where existing paper-based records need to be modernized
Investment appraisal

Sources of skills

The guidance that can be given here on the sources for the required skills is limited, given the number of different sources.
These will range from an in-house expert from the business, to management consultancy firms that developed into the IT
field from accountancy and audit, IT and IS consultancy firms, other independent consulting firms, software producers,
hardware manufacturers (both of which may also offer some consultancy services), system integration companies, turnkey
contractors, training providers, and so on. Only some general pointers can be provided:
The World Bank’s resources are limited for the skills and activities discussed in this chapter. From its own staff theWorld Bank is unlikely to be able to field resource:
For anything but short term input (although it may be provided over the long term, that is over the project
lifecycle)
For implementation (other than supervision).
With a few exceptions the World Bank is unlikely to be able to provide its own business experts and analysts, or
staff to specify (other than low complexity requirements), design, system engineer, or manage projects. In medium
to complex requirements there is also a limit to the diagnostic work that can be carried out during projectappraisal, posing a risk to the loan design.
The World Bank’s role in milestone reviews is limited. Although these add value, they are not full health or “fitfor-purpose” checks, but only “no-objections”. There is risk to borrower and World Bank reputation if theimpression is given that the World Bank is doing more than confirming that the submission conforms to therequirements of the loan (see section on Technical audit) and the World Bank’s guidelines in terms ofprocurement.
Generally, the source should show experience in solving the type of problem under examination.
Determine if the strength and standing of a large company is needed. Large companies should be able to callupon more resources, be capable of carrying out more research, and be better able to stand by their work andtake responsibility for putting it right if things go wrong. But they are usually more expensive.
Smaller firms often offer better value for money on small assignments.
But the prime factor in choosing expertise remains the quality and experience of the individual who eventually
carries out the assignment.

71

Good practiceTechniques and topics

External expertise

The full range of skills are unlikely to reside in one organization, although larger organizations will be able toidentify the resources with the right skills, either from a panel of experts or from a database trawl of consultants
registered or via an agency. Where a consulting firm or contractor is being called upon to identify specialist
resources, ensure that they have sound policies for recruiting and quality assurance.
Care should be taken with potential conflicts of interest:
Continuation of the service supplier from phase to phase (see section within chapter 8 on procurement
conflicts and the World Bank procurement web site for guidance notewww.worlbank.org/itprocurementforum)
Consultancy from hardware manufacturers (or suppliers), where an interest in maximizing the sale may
conflict with impartial advice
A turnkey approach will reduce risk by measuring achievement of outputs and products rather than inputs and, bybundling deliverables, simplifying contractual arrangements giving clear recourse to one supplier. However, theapproach has its own set of risks, including possible sub-optimal parts of the whole. Turnkey requires careful
procurement and management — see section within chapter 8.
Capacity development

Capacity development in the context of ICT components relates to the development of core competencies within thebeneficiary organization, for sustained, efficient, and effective use of the ICT resources. The core competencies are:Business management encompassing business activities, business rules, and business events
Information management encompassing information, data, and records management
IT management
Project management encompassing benefits, risk, and change management.
Project management is concerned with the full lifecycle of planning, defining requirements, implementing, monitoring, andreviewing.
Key considerations for capacity development
Requirements should be based on what is required to have a sustainable project.
There should be a plan that is flexible, based on an agreed set of core competencies.
There should be activities and outputs within the plan (contained within the log frame) capable of measurement.
Development should start during the process of identifying opportunities and project preparation, and continue
until project completion.
Remember it will take time — often longer than it takes to put in an ICT system.
Ensure that line management give the right priority to developing capacity, and will release staff (despite possible
conflict with day to day work targets).
Ensure external expertise obligations include capacity development (not just training) and the experts are capableof skills and knowledge transfer.
Good practice tips for capacity development

Strategic
Involve the beneficiary organization from the outset in project design, implementation, and review.
Plan for skills and knowledge transfer from external expertise.
Base plans on business and IT and IS strategy for the organization (see chapter 9).
Ensure HR strategy, policy, and management are supportive of developing and sustaining capacity.
Include capacity development inputs (beyond the primary inputs of external expertise) to address gaps.

72

Good practiceTechniques and topics

External expertise

Preparation
Carry out audit of core competencies and capabilities in the business area.
Provide awareness training to senior management.
Include visits to other organizations that have undergone similar project interventions.
Establish sound project management arrangements.
Support the appointment of the project manager from the beneficiary organization (supported by external
expertise as necessary).
Train the project manager and team in project management skills.
Identify, with the beneficiary organization, team members to work with the external expert during the preparationand inception phases.
Incorporate capacity development in the terms of reference for external expertise and include mechanisms formeasuring their performance.
Implementation
Ensure each phase has capacity development inputs, activities, and outputs, and they can be measured.
Encourage close working between beneficiary organization staff and external expertise.
Pace progress so that the organization can understand, participate, and contribute.
Ensure the team has a good understanding of how the business area ought to function and how it actuallyfunctions (including strengths, weaknesses, and problems).
Make full use of the IT skills available within the organization even if this extends the project.
Constraints
Lack of commitment to capacity development
Shortages of skilled staff within the organization, or nationally
Rigid, nontransparent, and bureaucratic public sector recruitment policies
Inadequate incentives (both penalty and reward) and loss of competent staff to other employers
Poor quality education and training facilities.
Where to seek further guidance

Elsewhere in this toolkit
Project management (chapter 1), quality management (chapter 3), risk management (chapter 4), change management(chapter 5), and benefits management (annex A to chapter 10)
Procurement planning (chapter 8)
Within the World Bank
When considering an ICT component try and identify a previous project with a similar component. Consult with those
closely involved on lessons learned and, in the context of this chapter, how problems might have been mitigated by thetimely provision of expertise.
Seek advice from the appropriate ICT resources within the World Bank and outside.

73

Good practiceIntellectual property rights and licensing
Chapter 7

Copyright is the right of the originator, or successors in title, to control the
reproduction of the work. The rights belong to the originator or “author”, unless thecontract commissioning the work provides otherwise. In many countries the law has
now been clarified, putting owners of software in the same position as regards
copying as owners of “literary” works.
Chapter summary

This chapter provides an overview of the meaning of intellectual property rights (IPR) in
the context of ICT, particularly software. IPR is important since it determines thepurchaser’s freedom to use and maintain software products. The purpose of this chapter is
to raise awareness of task teams and to ensure projects are entered into and contracts
issued that adequately protect the borrowers’ position. It outlines a preferred policy for
ICT outputs of World Bank funded projects, whether they are written or technology
related deliverables.
The subject is complex and, particularly for bespoke software, there are no simple solutions
to the conflicting requirements of buyer and seller. Annex A to this chapter gives further
guidance on IPR for bespoke systems and outlines issues related to source code.
Structure of this chapter

What is intellectual property?

75

Why is it important to consider IPR?

75

What is the policy?

76

Who has responsibilities

78

What are the risks

78

Where to seek further guidance79

Annex A: IPR in bespoke systems ─ further guidance

80

74

Good practice7.

Techniques and topics

Intellectual property rights

Intellectual property rights and licensing

What is intellectual property?

The inherent flexibility of the computer has led to a vast software industry from which new applications are emerging
daily. This gives the market impetus to support development and inventions, the products of which are exploited bylicensing. The industry depends on the protection and enforcement of IPR for its existence.
The application of intellectual property law can be of concern for some fundamental reasons. IS can be at the very heartof the way an organization operates. The organization’s ability to continue to operate efficiently, or to maintain its
competitive advantage may depend on protecting its right to operate, maintain, and enhance the system it has purchased.
These issues have led to developments in intellectual property and contract law, giving the subject an added complexity.
It is important that World Bank funded IS projects are carried out with an awareness of the issues and that steps are taken,
through contractual measures, to protect the parties involved. This goes beyond ownership of the copyright in written
work. Consideration must be given to the IPR and licenses for all work produced throughout the project lifecycle.
As a generic term
In this toolkit the term IPR is used generically (unless the context requires otherwise), to refer to all forms of rights:
Copyright
Patents
Design (registered or unregistered)
Trade and service marks
Trade secrets
IPR is contained in publications, reports, drawings and designs, hardware and software. In the latter context, especially for
bespoke software, the issue has particular complexity (and is discussed in more detail in annex A). For the purposes ofWorld Bank funded IS the most important form of IPR is copyright.
The principle
Copyright is the right of the originator, or successors in title, to control the reproduction of the work. It is governed
substantially by statute and has extensive international implications through international conventions, allowing protection
in signatory countries. The rights belong to the originator or “author”, unless the contract commissioning the work
provides otherwise. Any related contract should therefore clarify, by confirming or otherwise, this ownership
Why is it important to consider IPR?

Impact on system sustainability
An organization’s ability to continue to operate efficiently, or to maintain its competitive advantage may depend on
protecting its right to operate, maintain and enhance the system it has purchased. Failure to consider the implications of
IPR and to make adequate contractual provision could threaten this right. It is important therefore, that the IPR
implications are considered carefully.
Protection of World Bank’s position
In accordance with international obligations, the World Bank should observe strictly the rights and obligations associatedwith IPR. The World Bank must ensure that it is not responsible through encouragement, negligence, or failure ofprocedure, for the infringement of IPR. This applies to the IPR arising from work it has directly commissioned, the rights

75

Good practiceTechniques and topics

Intellectual property rightsof third parties (for example third party software), or for IPR related to work that the World Bank is partly or wholly
funding.
Written work
These guidelines refer to the different purposes for which expertise may be hired throughout the lifecycle of a project(section of chapter 6). Each stage will include written deliverables, reports or recommendations, to which there will be an
IPR issue attached. For example:
Assistance with project preparation
Feasibility study
Strategy study
Business analysis
Operational and training manual
Drafting of functional specification
Many of these deliverables will contribute fundamentally to the development of a beneficiary’s organization and therefore,
regardless of whether proprietary tools have been used in the preparation of the study or review, the beneficiary must be ina position to make use of the results by building upon, adapting, or releasing the contents to other experts engaged in the
project.
Technology related work
This includes the existing, off-the-shelf or shrink-wrapped packages, which are always purchased on the basis of a license,
and any specially commissioned software. The latter can include a full-bespoke system provided through a formal
development contract, or an application developed by experts from a standard (usually database) software package. The
latter requires equal care in considering IPR (and other contractual) issues.
What is the policy?

It is policy to observe strictly the rights and obligations arising from IPR. Efforts should also be directed at ensuring that
staff, consultants and borrowers do not infringe IPR. The following paragraphs give guidance on policy on IPR, as it
applies to ICT components.
For written deliverables
Where there is a contract of employment (that is, the originator is operating as employee) the IPR (unless the contrary isstated) will vest with the employer. This would apply to World Bank employees. The position for other World Bank funded
operatives is less certain and therefore, specific provisions should be included to ensure the position is protected.
Where expertise is contracted, whether via a company or as a single individual, the expert will assume rights, unless specificmeasures are taken. The policy is not necessarily to claim ownership of the IPR,3 which the World Bank or its borrowers
may not be in a position to defend or exploit commercially. Instead, a broad license from the owner will give sufficientrights. Contracts should therefore seek to:
Oblige the consultant to take steps to ensure they have ownership of IPR
Ensure the consultant grants the buyer a license[Give entitlement to sublicense]
Oblige the consultant to indemnify for any infringement of third parties’ IPR
Oblige the consultant to apply for registered protection of IPR, if required by the buyer.

3 Although for work contracted for the World Bank’s own use the standard approach is to claim copyright.

76

Good practiceTechniques and topics

Intellectual property rights

In the case of World Bank funding, contracts for external expertise should contain the appropriate clauses (OCS have
simple and complex model clauses for use in the special conditions of World Bank consultancy contracts). Where theborrower is contracting the expertise, the borrower should be advised to safeguard their contractual position in a similarmanner.
Technology related work
Standard software
For any software bought with the World Bank’s own funds for the use of a project where the software may be transferredto the borrower at the end of the project, the beneficiary organization should be named at the time of purchase, as thelicensee. Any consultant using the software should have contractual obligations placed upon them not to infringe the IPR
for World Bank-purchased software, to which they have access.
System software
Guidance should be provided to the borrower to ensure their interests are protected. Sample bidding documents (SBD)
contain model conditions; as with any models they must be carefully reviewed for suitability in the context of the project,
but they form the basis of a recommended approach. These clauses have a similar purpose as the clauses for the
consultant’s written work, except that provision for “site license” only is sought.
While the principles may be similar to “literary” copyright, there are different types of software, or parts to the software
making up an IS, which call for an expanded set of clauses to deal with copyright:
Specially written software (written by the contractor for the purchaser)Contractor’s own software (existing software incorporated into the system)
Third party software (supplied by the contractor through license arrangements)
Embedded software (machine readable software, supplied as an integral part of the hardware).
The contract should therefore, seek to:
Grant licenses for the purchaser to use the software
Confirm that the purchaser does not acquire ownership of the IPR in the specially written, contractor’s,
embedded, or any third party software
Grant a perpetual, irrevocable, nonexclusive license to the purchaser to use, reproduce, modify, adapt, and enhance
the specially written software
Grant a nonexclusive license to the purchaser for the contractor’s software
Grant a sublicense to the purchaser for third party software (or procure for the purchaser the granting of a license
for the third party software)
Similarly for the embedded software
Arrange for the purchaser to be supplied with the source code of the specially written software
Give the purchaser the right to engage a third party to use, reproduce, modify, adapt, and enhance the speciallywritten software, and to use the contractor’s, embedded, and third party software, subject to the agreement
Give the purchaser the entitlement to copy for archival and backup purposes the specially written, contractor’s,
embedded, and third party software.
In addition, the contract should provide an IPR indemnity in favor of the purchaser for any infringement of third parties’
IPR, and guarantee the contractor that instructions issued by the purchaser to use third party items will not violate the third
parties’ IPR. The contract should also warrant confidentiality by having both parties warrant that they shall not disclose
confidential information, including the source code, to third parties.

77

Good practiceTechniques and topics

Intellectual property rights

There is no entirely satisfactory way in which to cover IPR in IS. Further guidance of the manner in which IPR applies tosystems, including an explanation of source code and the implications of bespoke software, are contained in annex A. If
there is any doubt, expert advice should be sought.
Hardware
While general copyright principles apply to the design of computer hardware and patent protection is of great importanceto the large subsystem or component manufacturers, these have less relevance in the context of a loan for an IS project.
The same may be said of other types of IPR such as semiconductor chip rights, design rights, registered design, andtrademark. It would be for the hardware or turnkey system supplier to ensure that there is no infringement of these IPR,
and contracts for supply should include the supplier’s indemnity to this effect.
Who has responsibilities?

The following paragraphs summarize the responsibilities of the various parties involved.
Task managers
The prime responsibility rests with the task manager who, in designing the projects, must consider the IPR implications andarrange for contractual inputs that ensure project sustainability, While protecting the World Bank’s position. The task
manager must arrange for the borrower to receive appropriate advice to ensure that IPR issues do not jeopardize theinvestment.
External expertise
Experts will be expected to work within the World Bank policy on IPR. They must also have sufficient understanding togive advice to the borrower or to flag the issue as requiring expert (specialist legal) input.
Procurement advisers and agents
For the supply of goods (hardware and software) procurement agents should routinely disclose the principal for whomthey are acting and the end-user of the equipment. They should have standard clauses that instruct the supplier to arrange
for the software licenses to be made out in the name of the end-user.
Where procurement agents are involved in the procurement process for an IS, they should consult with the borrower andthe appointed experts on the requirements for IPR clauses. If it proves necessary during negotiation with the preferredbidder to move away from the standard wording, this also should be done in consultation and with great care.
Borrowers and beneficiaries
Borrowers should be advised of their responsibilities for IPR. Care should be taken to ensure that the buyer understands
the importance of the IPR, adopts the model clauses, or obtains appropriate advice where it is necessary to move from themodel clauses.
What are the risks?

The risks are substantial and have the potential to threaten:
The sustainability of the project
The sustainability (maintenance and enhancement) of the system
Legal action for breach of copyright.
The following table expands on these risks and relates them to the types of contract:

78

Good practiceTechniques and topics

Intellectual property rights

Table 9 Risks from inadequate contractual provision for IPR
Situation

Risk and Implication

Contracts for expertise
Written deliverables

Originator claims copyright and refuses to allow written deliverable from their input tobe released for the benefit of the project or to inform later stages and phases.
Ultimately this could mean:
The contract for expertise has to be repeated with consequent waste of funds
Time delay implications for the borrower and the project.

System delivered as part of a contract for

The provision of a system in an ad-hoc way (whether intended or occurring in anexpertisealmost accidental manner) may result in the issues of IPR ownership and maintenancenot being adequately considered. It has potential for
No maintenance being provided

Inability to negotiate cost effective maintenance
Legal action for breach of copyright.
Contracts for hardware, software, andsystemInsufficient thought given to contractual
provisions for IPR

Borrower is left in a position where there is:
No maintenance being provided;

Inability to negotiate cost effective maintenance
Legal action for breach of copyright.

Business case includes competitive
advantage provided by the system

Supplier on-sells system to other parties and removes the competitive advantage

Where to seek further guidanceWithin the World Bank
Legal advisers
External to the World Bank
Specialist lawyer on advice from the internal legal advisers. Ensure the borrower or beneficiary seeks assistance from theirlegal advisers.

79

Good practiceTechniques and topics

Intellectual property rights

Annex A
to Chapter 7
IPR in bespoke systems ─ further guidance
Software licensing

The crucial point, all too often omitted from software contracts, is who owns the software. What is the nature of the rightto use it that appears to be conferred? In many countries the law has now been clarified, putting owners of software in thesame position as regards copying as owners of “literary“ works. There remain considerable problems for the softwareowners in enforcing the law.
The problem is most acute with PC software. While the position on standard (“shrink wrapped” or off-the-shelf) softwareis relatively clear, the licensor has potentially the most to lose by neglecting to protect their rights, for their customer may
proliferate the package among other potential customers.
In the case of bespoke software the position may be reversed, for the customer may be paying for new software which hehopes will give him a commercial edge over competitors, but may find that the software is sold to competitors at a reduced
price. If the transaction does not involve commercial advantage, there is benefit in allowing the software supplier to keep
the title since they may increase the number of users of the package and thereby increase the viability of support andenhancement.
There are further issues related to licensing and source code that need to be addressed. These are discussed below.
Source code

Computer programs exist as source code in a high level (eye readable) language that is not directly operable by a computer;and object code, a version on which the computer can work (machine readable). The process of moving from source toobject is by compilation and there may be other intermediate codes produced on the way. Both source and object codes areprotected by copyright.
The source code is more vulnerable to infringement, as it reveals the originator’s planning and programming methods toachieve a given function. For this reason the source code is usually guarded because, while protected by copyright, theunderlying ideas are only protected as trade secrets or confidential information.
In entering into a contract the first position should be for the system supplier to provide the source code for the speciallywritten software to the buyer. It may be necessary to negotiate from this position and agree for each version of the sourcecode to be deposited with a third party (held in escrow), who then is placed under an obligation to deliver the current
version to the buyer in the event of failure of the software maintenance contractor (which may be the system supplier),whether a failure of capacity, such as liquidation, or failure to fulfill the terms of the contract.
Contractual contradiction

It is worth expanding on the impact and practicalities of the contractual relationship between buyer and supplier. From thesystem supplier’s point of view the chief aspect of the title is the anxiety that in parting with all rights the supplier may
limit the ability to profit from the programming skills acquired during the course of the work. The recommended approach
whereby the supplier retains title and the purchaser is granted a license addresses this issue. It has the added advantage ofencouraging the supplier to keep the software maintained. Further, the supplier may sell to other purchasers, expanding theability to support and improve the software, thus potentially reducing the costs to the buyer.
Where it is important for the buyer (for example, where competitive advantage may be involved) that the title passes tothem, there remains an issue of the programming tools and skills used. Tools are different from skills: tools include actual

80

Good practiceTechniques and topics

Intellectual property rights

coding, a sequence of instructions for handling a type of file which has become a standard for work on particularmachines, in particular languages. Skills are wider and not so much solutions to particular programming problems as theapproach to programming and design. The supplier may be prepared to grant the title but wish to retain the programming
tools and skills.
There is an implicit contradiction in this definition as the title to the software is the title to the programs written andincludes the programming tools and skills. This can be tackled by reserving to the supplier the programming tools andskills, but this merely transfers back to the supplier a license to use these tools. This is satisfactory provided the supplierdoes not try to use them for another client. It is evident that these issues are breaking new ground and are insufficiently
tested. Consequently, there is no entirely satisfactory clause that covers the point, but if both sides are aware of the issues
the need for legal intervention may be avoided.
Maintenance

It is important for a World Bank funded IS that adequate provision for maintenance is built into the arrangements. The
originator of a system cannot assert rights in intellectual property to prevent the buyer of a system from maintaining thatsystem at an economical price and in an efficient manner. Further, the buyer needs to be able to continue to maintain thesystem in the event that the contractor or software supplier goes out of business.
Maintenance of software requires the correction of errors in the program as supplied, or the enhancement of the facilities
or performance. It usually involves reproduction of parts of the program. The software license should include express
provisions for maintenance either by the licensor (at reasonable prices), or by the licensee. In the latter case the licensemust include the right to copy or adapt for this purpose. Either way the source code is essential to effect maintenance.
Escrow arrangements
It is common for invitations for bids to specify that the buyer would require a copy of the source code for all software. It
may be appropriate (and hence be possible to negotiate) for a largely bespoke system where the nature of the business ofthe buyer makes it essential for reasons of competitive advantage. It is likely to increase the cost of the development.
Except in the circumstances described, provision of the full source code is unlikely. Most contractors will offer thealternative of placing the source code in escrow. This is an arrangement whereby for a fee a third party will enter into anagreement to receive the source code, releasing it to the buyer only in the event of certain conditions: usually only if thebuyer is being prevented from economic or efficient maintenance, or the contractor or software supplier is going out ofbusiness.
Several recognized escrow service providers exist, operating to standard terms and conditions.
Open-source software

Definition
Open-source software (OSS) are software programs whose licenses give users the freedom to run the program for any
purpose, to modify the program, and to freely redistribute either the original or modified program without further
limitations or royalty payments. It is differentiated from “shareware” or “freeware”. While there is agreement on the broadterm “open source”, the term has lost some of its precision. Examples of OSS include the Linux operating system (possibly
the most visible), Netscape’s Navigator, and the Apache web server.
The basic idea is simple: when programmers can read, redistribute, and modify the source code for a piece of software, thesoftware evolves. This can happen rapidly. It is argued by proponents, and disputed by commercial software developers,that OSS improvements are more rapid and produce better software than the traditional closed model. Data on market
penetration are confusing or incomplete.

81

Good practiceTechniques and topics

Intellectual property rights

OSS does not just mean access to source code. Distribution terms are intended to comply broadly with the following
criteria:
Free distribution: the license shall not restrict any party from selling or giving away the software as a component ofan aggregate software distribution containing programs from several different sources. The license shall not
require a royalty or other such fee for sale.
Source code: the program must include source code. It must be the preferred form in which a programmer would
modify the program. Deliberately obfuscated or intermediate forms are not allowed.
Modifications: the license must allow modifications and derived works and allow them to be distributed under thesame terms as the original.
Integrity of the originator’s source: the license may restrict source code from being distributed in modified form
only if it allows the distribution of “patch files” with the source code for the purpose of modifying the program atbuild time. The license must explicitly permit distribution of software built from modified source code.
Discrimination: the license must not discriminate against any person or groups of persons or any specific fields ofendeavor.
Distribution of license: the rights attached to the program must apply to all to whom the program is redistributed
without the need for execution of an additional license by those parties.
Not specific to a product: the rights attached to the program must not depend on the program being part of aparticular software distribution.
Not restrict other software: the license must not place restrictions on other software distributed along with thelicensed software. For example, the license must not insist that all other programs distributed on the same medium
are OSS.
OSS copyright and licenses
The simplest way to make a program free is to put it in the public domain without claims of copyright. This allows sharing
and improvements. However, it also allows conversion to proprietary software. The alternative is a copyright statement anddistribution terms, a license arrangement sometimes referred to as “copyleft”, a reversal of the original meaning. Versionsof licenses are available from the Internet — see www.opensource.org/licenses/ — as are details of other products. This
site and other such sites also reveal some of the debate and controversy surrounding the subject. The thinking behind OSS
is still evolving, as are its implications in the commercial world.

82

Good practiceProcurement planning and project models
Chapter 8

Procurement planning should start at the beginning of the project. Decisions on thenature of the system will have direct implications for procurement, for the phasing of
the project, for the type of expertise required, for the number and scale ofprocurements, for the choice of SBD and types of contracts and for the relationships
between the parties involved.
What this chapter is about

ICT and IS procurement has particular complexity. It requires care to avoid problems. This
chapter is not the definitive guide to ICT procurement, but it discusses the importance of
procurement and the need to develop a procurement strategy and plan during the project
preparatory phases.
In some respects, measures for optimal ICT procurement conflict with the World Bank’s
well-constructed and robust procedures for procurement. For good reasons, theWorld Bank’s procedures are dominated by transparency and administrative imperatives.
But these would not constitute best practice in a commercial environment and there is atrade-off between openness and transparency, and lower quality components and projects.
Some of these issues are discussed and guidance given on an acceptable approach andsafeguard measures.
Brief notes are given on the selection of SBD.
Finally, several examples of possible commercial structures for ICT components giving
options for the phasing and the role/relationships of external contractors are given.
Structure of this chapter

Importance of procurement85

Conflict with World Bank guidelines

85

What is being procured?

86

Procurement planning

86

Hiring consultants

87

Complex systems

88

Turnkey88

Contractor continuation

89

Models92

Evaluation

92

Support and maintenance

92

83

Good practice

Choice of SBD

93

Where to seek further guidance93

Annex A: Examples of possible commercial structures for ICT components

94

84

Good practice8.

Techniques and topics
Procurement planning

Procurement planning and project models

Importance of procurement

A successful ICT component is not solely a procurement issue. The problems and risks to success should not have to be“sorted out” during the procurement process. There are procurement risks. If the requirement is not specified properly, if
the right supplier and solution are not selected, and if the contract is weak, then business, financial, and legal problems canarise. Only some of these risks will be addressed by good procurement practice. Nevertheless, a well-managed procurement
is fundamental.
Conflict with World Bank guidelines

ICT procurement shares with other World Bank funded procurement the need to be free, fair, and transparent. There arealso common issues of value for money. However, there are several complexities to ICT procurement (for which it has
been necessary to produce special SBD). These complexities can appear to lead to conflict with World Bank procurement
guidelines:
Proprietary products
There is a particular difficulty with the World Bank’s normal strict obligation to open procurements for functionallyequivalent products (refer to Guidelines — Procurement under IBRD Loans and IDA Credits):
The software industry is dominated by de facto monopoly suppliers.
Organizational and national IT and IS strategies can lead to strong borrower preference.
Certain sectors have limited product choice.
Therefore, the World Bank’s approach to brand names and single sourcing needs to be considered at an early stage ofprocurement planning. Single sourcing (or direct contracting) would need to be justified per World Bank rules. The
World Bank effectively makes a special case for ICT procurements (see procurement guidance notewww.worldbank.org/itprocurementforum). In documenting and reviewing requests for exceptions to the guideline on useof brand names at least one of the following four main arguments must apply strongly:
Required hardware and software platform for proposed application“de facto” industry standard
Enterprise technology standard
Prior material investments
A case may also be developed based on the organizational or national IT and IS strategy, for example the standardized useof one of the major relational database management systems, or specialized products such as geographical information
systems (GIS). A “prior material investment” justification would usually apply in these circumstance but not if the adoptionof the strategy is recent. In these circumstances the case should be reviewed objectively. In the event that an initial decision
goes against the case, it may also be reversed through the persuasiveness of task managers, the client, or the consultants.
Conflict of interest
Complexity can create a strong argument for consultant or contractor continuation from phase to phase. See section
Contractor continuation below.
Two stage bidding
For more complex ICT requirements the exact solution and what the market may have to offer can be uncertain.
Specifications are often best expressed in business and functional terms and in a nonprescriptive manner, leaving the85

Good practiceTechniques and topics
Procurement planningmarket to proffer solutions. A two-stage bid process allows the bids to inform the requirement, allowing adjustment to an
optimal solution and reducing risk to both buyer and seller. The process however, increases the effort for buyer and seller,
is less obviously transparent, and can lead to accusations of misprocurement (partly because the supplier that submits thebest offer at stage one may not, ultimately, be successful).
These issues are discussed further below and in more detail in the IT guidance notes produced by the procurement unit
(and available from their web site opcs.worldbank.org/p/index.html)
What is being procured?

Let us start at the beginning. What is being procured? For ICT components in the context of a World Bank loan there will
always be some procurement aspect — at least one procurement and at one or more levels of the delivery (for example fora turnkey, or for technical assistance, or for technical infrastructure or some combination).
The difficulty in structuring the guidance in this chapter arises from the question “what is being procured?”:Goods (hardware and off the shelf software — and maintenance)? This should be relatively straightforward and is
not really the subject of this chapter. However, if the quantity or value is high enough, the risk from exposure issuch that great care needs to be taken. Advice should be sought on technical issues — a small technical oversight
can lead to major waste. In addition there may be a range of soft issues, such as whether the major investment isreally going to produce the benefits anticipated.
Services? If services, is it consulting services, or support and maintenance services?
A system? If a system, how complex? Will it be broken down into packages, and if so how?
For medium to high complexity systems there is another significance to the question “what is being procured?” and that is:“what is the system to do?” Defining the data needs is relatively straightforward (what outputs, what reports, whatmanagement information may be needed) but automated processes are more difficult, leading to possible ambiguity in
specification:
What processes?
How do they work?
What are the business rules?
Here are further questions:
Are there multiple sites? If so what processes will be undertaken at the local level, what at the central? How will
the data be shared between the local and central offices, and how frequently is it necessary to update data between
the two?
What of the capacity of the organization? What help will they need? What support and maintenance services will
be needed? What level of maturity of service is available from the private sector locally or regionally?
The answers to these questions will have significant implications for the system: for its complexity, cost, how it is to bedelivered, what expertise will be required. The earliest consideration needs to be given to these issues and what they will
mean in terms of the procurement strategy.
Procurement planning

The previous section should have illustrated that it is difficult to separate the planning associated with the design of thesystem from that associated with procurement; both are important and interrelated elements in the strategy for thecomponent. A systems plan that does not take account of the procurement process from the beginning is likely to run into
difficulties later on. The procurement planning should create a structured decision chain that complements the systematicmanagement of the rest of the component.

86

Good practiceTechniques and topics
Procurement planning

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 phasing of the project, for the type of expertise required, for the number
and scale of procurements, for the choice of SBD and types of contract and for the relationships between the parties
involved. As examples, decisions on the following will have an impact on the procurement arrangements:
Scale of the system
Package or bespoke software
Use of prototyping, replicating
Any sole source need
Capacity of the beneficiary organization
Need for external expertise
Having considered the implications from the outset and established a procurement strategy and plan, 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.
An iterative approach allows the procurement to be “sliced” into manageable portions: for risks to be identified, steps to betaken to minimize risk, and risks to be revisited in the light of developments. New risks may be identified or at least
become recognized as having a greater significance. Factors influencing the procurement strategy are primarily concernedwith risk identification and reduction and (in addition to the issues of scope listed at above) will be influenced by:
Length and rigidity of timescales for implementation
Priorities of the business benefits to be achieved
Possibility of change to the organization’s operations
The technical and project management skills available.
Remember, project and procurement timescales are always longer than anticipated.
Hiring consultants

Issues related to hiring consultants for an ICT project are not significantly different from those in projects without any ICT
component.
The procurement plan should include consultancy inputs. Remember, depending on complexity, help may be needed forboth the loan preparation and for the analysis and design phases of the component, through implementation and closure.
Potential external assistance needs, including consultants, are discussed in chapter 6. Using consultants is invariably
expensive and there is a clear need for a businesslike approach. By following good practice good results and value formoney can be achieved.
Defining requirements
It is obviously very important to analyze accurately the problem which needs consultancy support. Some effort should be
expended in consultation with the organization. Sometimes it is apparent that there are problems but there is no clear wayof resolving them. In such cases an initial survey will help define a fuller study. With particularly difficult tasks more than
one study may be needed. Remember to define tasks as specifically and correctly as possible in order to avoid imprecise or
unwanted recommendations and unnecessary costs.
Terms of reference
The terms of reference should include the following principal elements:
Definition of the problem and statement of the task to be undertaken

87

Good practiceTechniques and topics
Procurement planning

Relevant background information
Scope functionally, organizationally, and geographicallyTimescale and phasing
Statement of skills, experience, and qualifications
Description of how the consultants and organizational staff are to work together
Description of knowledge transfer
Outline of control mechanisms envisaged for steering and monitoring the work
Statement of any constraints, standards, or particular quality requirements
Output, deliverable or product.
Sizing
It is good practice, and often necessary for budgetary purposes, to try and size the task before approaching the industry. Is
it a twenty-day or a forty-day task? Must it be completed by a required date? This can be done by breaking down the task
into a number of parts (a logical sequence of events), and then estimating how long each will take: for example, research
and familiarization, interviewing, analysis and consultation, report writing, meetings and presentations, final editing. Forinterviews a list of locations and the number of people will give further indication of size and cost.
Complex systems

Components that involve large, complex systems engineering work should be done in phases. A typical phasing strategy
consists of:
Project strategy and system scope
Request for information (RFI), prequalification, and request for proposal (RFP)
System engineering
System implementation
System maintenance
Linked to these phases there are likely to be four procurement tracks:
System specification and project management support services
System engineering/integration services
Supply and maintenance of technology
Independent technical audit services
There are conflicts of interest issues here — see options for Contractor continuation below.
Turnkey

Said to originate in the building and furnishing industries, the idea is that at the end of a contract the contractor provides“a key” to a new computer room with a fully working system. Responsible for the provision of hardware and software andmaintenance for both, the main advantage of a turnkey or single responsibility contract is that the purchaser only deals
with one supplier. Thus, in the event of nonperformance, it is not necessary to decide if the failure is one of hardware orsoftware. The clear line of recourse is to go to one supplier for a remedy. This contrasts with the situation with twocontracts (one for hardware and one for software), where each supplier may be tempted to blame the other. Performanceof the maintenance and support provisions of the contract (and it is important that this is procured and contracted
simultaneously) is measured by the availability of the system to meet the requirements specified. In other words therequirement is defined as far as possible in terms of a product (although in fact it is largely services being procured).
This arrangement is particularly valuable where the beneficiary organization lacks the capacity:88Good practiceTechniques and topics
Procurement planning

To manage multiple contractors and suppliers
For system administration and diagnosis of system faults.
The negative aspects of the turnkey concept are:
The risk that the supplier will deliver the minimum that can be got away with, or having underestimated the costs(and with the contract price being fixed) will attempt to economize, very often in the areas of documentation andmaintenance support
By leaving the contractor to devise a system solution rather than prescriptively give specification details for thesystem elements there is a risk of the different elements being suboptimal.
It is important therefore, that the turnkey supplier is managed, and that those responsible for approving the award of aturnkey contract satisfy themselves that the solution provides sufficient quality, and that proper arrangements formaintenance of both hardware and software have been included, before awarding the contract.
Contractor continuation

Conflict of interest
In most medium to complex components there will be need for preimplementation consultancy work, appointment of asystem supplier, system supply, and the management of system implementation. However, borrowers often face acounterproductive impact from World Bank conflict of interest guidelines.4 These recognize that the involvement of acompany in any upstream work (such as consultancy in drawing up plans or system specification) will have the potential
for:Bias in system specification — designing with a given product in mind is of concern as it may skew thespecification in favor of the incumbent’s (potentially substandard or inappropriate) solution
Information asymmetries — can translate into unfair advantage for downstream work
Personal or early knowledge (a form of information asymmetry) — particularly when this type of advantage
operates in a dishonest way.
These may lead to a suboptimal solution or criticism that the process was not handled in a transparent manner.
Conflict of considerations
On the other hand, expertise in system applications for many business areas often resides with companies that haveacquired their knowledge through involvement in all phases of the project cycle. Thus, firms best able to define thebusiness requirement and its scope are often best able to implement the project. Further, the flexibility to contract a single
party to take responsibility for all stages of a project provides important continuity benefits as well as advantages ofsimplification of the contractual relationships. But expert firms best able to deliver upstream work often abstain fromparticipation in order not to disqualify themselves from the implementation phases. This may deprive World Bank clientsof a significant talent pool at a time when this talent may have the most impact. The uncertainties of a complex systemcomponent may, in any event, discourage the buyer, and probably the seller, from entering into a single responsibility
contract from the outset.
A time-tested approach is to divide the project into phases and enter into no wholesale commitment with a single
contractor. Division into phases however, should not be at the expense of acquiring the best expertise for each phase.
These conflicting considerations are difficult to resolve. To what degree should risks of conflict of interest be offset by thenegative impact of disallowing contractor continuation? If contractor continuation is desirable, under what safeguards canit be allowed?

4 See Guidelines: Selection and Employment of Consultants by World Bank Borrowers, section on Conflict of Interest.

89

Good practiceTechniques and topics
Procurement planning

Services rather than goods and works
World Bank guidelines already acknowledge that continuation of downstream contracts is often in the interests of theborrower. If the implementation contracts are viewed as goods contracts, the policy is unequivocal — “A firm which has
been engaged to provide consulting services for the preparation or implementation of a project…shall be disqualified from
subsequently providing goods or works under the same project.” From a business perspective however, contracts for asystems project (software engineering and system integration) are more properly considered as consulting services, withenhanced delivery obligations and liability on the part of the contractor; and the concept of competitive continuity inconsulting services is already established.
Conflict of interest in perspective
Bias in system specification — expert firms can rapidly demonstrate the bias in a rigged specification and encouraging
expert review by the IT industry can create an environment of accountability. However, bidders may prefer not tochallenge publicly, thus casting doubt on a client’s impartiality. Further measures are necessary.
Information asymmetries — inside knowledge may in any event be gained from other types of contact between clientorganization and bidding firms. Good practice in disclosure obligations, high documentation standards, allowance ofsufficient preparation time and flexible and liberal bid clarification and site visit provisions, all will help to close
information gaps. Provided that bidders perceive the evaluation process as being fair they will not be discouraged if:
They believe they have full information on the problem to be solved
They are confident of their capacity relative to the incumbent
They deem their capacity is sufficient to overcome any information advantage of the incumbent.
Personal or early knowledge — this type of advantage can operate as a result of normal business practice, such as priorengagements outside the scope of the World Bank’s loan. It is considered “fair game” by all parties in competitive
procurement. Competing bidders know that if past performance had not been acceptable there would be disadvantage tothe incumbent. If satisfactory, then this is fair advantage. It is when this type of advantage operates in dishonest ways, withknowledge fraudulently acquired, that there is a problem. Unfortunately, fraud is neutralized neither by existing conflict ofinterest guidelines, nor by the measures proposed here. To conclude, personal or early knowledge is not per se a conditionof conflict of interest under the World Bank guidelines, which do not prohibit it from being used even as a qualification
criterion. Therefore, the issue narrows to the concerns of specification bias and information asymmetries, for which thesafeguards are the same.
Continuation options
Continuation of the incumbent between upstream system specification work and downstream system engineering or
system integration contracts can be allowed as a procurement strategy under certain circumstances and subject tosafeguards:
Specify-and-engineer option
Under this type of continuation, a firm may provide consulting services to develop the specification and thefunctional design of a complex system and continue to perform the engineering of the same system (detailed
design, construction, testing, and deployment) under two scenarios:
The incumbent qualifies for, and wins, a subsequent competitive procurement of the system engineering
services.
The borrower, in agreement with the World Bank, decides to forfeit competitive bidding of the downstream
systems engineering contract and assign it directly to the incumbent.
This continuation option facilitates procurement of complex, technology neutral IS because neither the client nor
the contractor is forced, at the time of the upstream system specification contract, to make decisions related to thedownstream contract, for which neither party, typically, has sufficient information.
Under the specify-and-engineer option, procurement of the technology platform must occur separately and theincumbent firm is disqualified from that procurement.

90

Good practiceTechniques and topics
Procurement planning

Other procurement strategies may be indicated for technology neutral systems. Seek advice from procurement
staff.
Specify-and-integrate option
Under this type of continuation, a firm may develop the specification and the functional design of a system andthen compete for the system integration contract for the same system, including system engineering (detailed
design, construction, testing, and deployment); supply of the hardware and commercial software; and installation,
conversion, training, and testing services, to achieve operational acceptance of the system.
This continuation option will facilitate procurement of certain complex IS such as process control, payments
processing, environmental monitoring, and electronic government systems. In these and similar systems,
technology integration problems are of paramount importance, and expertise on the entire project lifecycle resides
most frequently with specialized systems integration firms.
Safeguards
Both continuation options need special safeguards to avoid real or apparent conflict of interest. The objective of these is toprevent the exercise of bias in the upstream contract and to ensure that any remaining unfair advantages of the incumbent
is rapidly identified and corrected during procurement for the downstream contract.
At a basic level, continuation options must be:Agreed upon between the borrower and the World Bank in advance of the request for proposal for the upstream
contract. Ideally this would happen as part of the project procurement plan or at the earliest time during
formulation of the procurement strategy for the IT component of the project.
Announced as part of general and specific procurement notices and in invitations to bid.
Upstream contract safeguards
The terms of reference for the upstream contract must include the following provisions to neutralize the information
asymmetry advantages of the incumbent in competing for the second-phase contract:
Contractor must be clearly obligated to develop a system specification suitable for implementation with technology
provided by a majority of the relevant industry suppliers, and to document explicitly any design aspect that may
operate in favor of their own downstream solution.
Incumbent contractor must be required to document all critical parameters of the client’s business that affect thesubsequent design of a technical solution. There should be an explicit understanding that these reports will
eventually be shared with other bidders, as part of the technical specifications for the downstream systemengineering or integration contract.
For system specification and functional design outputs (including entity-relationship diagrams, data flow diagrams,
data dictionary entries, and display output specifications), the incumbent contractor must adhere to industrystandard documentation and diagramming conventions and include all essential business functions (that is, those
directly addressing business requirements irrespective of technology constraints).
The incumbent contractor is disqualified from participating in all work related to the preparation of bidding
documents for the downstream contract.
Downstream contract safeguards
Preventive safeguards discussed for the upstream contract must be complemented during procurement for the downstream
contract.
Full documentation, as part of the technical specifications, of the client’s technology strategy, business operations,peak transaction volumes, and so on. The documentation should be consistent with the related requirements forthe upstream contract specified above.
Unless fraud is alleged, hold bidders accountable for raising issues of specification bias exclusively through the bid
clarification process.

91Good practiceTechniques and topics
Procurement planning

Conclusion
Two medium-term policy decisions of governments and the World Bank would be strong safeguards for fairness incontractor continuation and would help improve IT procurement across the board. They are:Encourage the use of Internet-based public procurement systems that allow communication among the parties ina bidding process at any time, from anywhere in the world.
Establish a fast-acting dispute resolution mechanism, such as a standing panel of experts from several countries
charged with resolving disputes through virtual deliberations over the Internet.
The enhanced documentation standards and process safeguards specified are likely to facilitate contractor continuation
options in complex systems procurements, when these options would be to the advantage of World Bank borrowers.
Some of the items included above must be implemented at the time of drafting the terms of reference for the upstream
system specification contract, and they require no change to the standard bidding documents. Other items involve changes
to the invitation for bids and the instructions to bidders in the downstream system engineering or integration contract.
Check that the documents proposed are suitable.
This is a complex and critical area. A more detailed discussion of this topic and World Bank policy is provided by IT
procurement guidance notes available on the procurement web site: www.worldbank.org /itprocurementforum. If in doubt
seek advice.
ModelsAnnex A provides eleven different models of possible commercial structures for ICT components — the parties, their
responsibilities, and the number of contractors involved. Notes against each structure describe their merits and suitability
for different circumstances. Some assume substantial in-house capacity (reduced need for external expertise). Some place
more emphasis on transparency than, possibly, on the optimum solution. Nine of the models would be acceptable undernormal World Bank guidelines. Two (10 and 11) would not satisfy the normal transparency drivers and should beconsidered in the context of the contractor continuation considerations described above.
Evaluation

The more complex the requirement, the greater the pitfalls in using price as the sole or major evaluation criterion. In
general the World Bank’s guidelines have price as a lower weighting for goods than for services (where issues ofunderstanding track record and individual experience become dominant). A system procured on a turnkey basis provides auseful example. Although requirements may be phrased as if the supply is of products (hardware, software, system
availability), in reality the contractor is providing a series of services (analysis, design, integration, installation, training,support and maintenance). As such evaluation criteria for services with a low weighting for price may be more appropriate.
Broad guidelines have been developed for inclusion of nonprice factors, consistent with the nature and complexity of thegoods and services being procured. See the IT procurement guidance note available on the procurement web site forfurther comment: www.worldbank.org/itprocurementforum.
Support and maintenanceIn the past there have been problems with procurement of IT maintenance and technical support services. Care should betaken to avoid these problems including:
Linking of supply and maintenance contracts
Extending validity of performance securities into the maintenance period
Contracting arrangements that reflect commercial terms and conditions
Using World Bank funds to finance up to three years of maintenance
Treatment of warranty services as special type of maintenance period services.

92

Good practiceTechniques and topics
Procurement planning

The World Bank’s IT SBD may need to be amended accordingly. See the guidance note on the procurement website:www.worldbank.org/itprocurementforum.
Choice of SBD

The World Bank’s SBD for IT comes in two broad varieties: for goods together with installation and support andmaintenance services, and for services alone. Many comprehensive services combine both aspects. In conceptualizing
projects, allowances are needed for procurement and contract models that encompass both goods and significant
consulting as well as other services such as expert support, facility management, operational support, training.
Further assistance with choosing the right SBD is provided in part 1, chapter 3. See also the guidance note on the
procurement web site: www.worldbank.org/itprocurementforum. This is summarized as follows:
Single stage
Use single-stage SBD for supply and installation of low to medium complexity IS where the required solution is certain anddoes not need to be informed by the bid process.
Two stage
Use two-stage SBD for supply and installation of medium to high complexity IS, system engineering or system integration
procurements where the required solution is uncertain (and needs to be informed by the bid process) or where the buyer isopen to different solutions.
Language versions
While many countries will use or accept English as the language for commercial transactions, particularly those involving
international suppliers, certain non-English-speaking countries will expect to issue bid documents in their own languages.
Translations of SBD are not available in all the languages. This could have an impact on bringing the World Bank’s latest
pooled knowledge of best practice to everyone. Even greater care therefore needs to be exercised in selecting the SBD and
in adapting the version selected to the procurement need.
Where to seek further guidance

Elsewhere in this toolkit
See also sections on external expertise and developing capacity
Within the World Bank
When considering an ICT component try and identify a previous project with a similar component. Consult with those
closely involved on lessons learned and, in the context of this chapter, how problems may be mitigated by the timely
provision of expertise. Seek advice from appropriate ICT resources, even if it is only to know where to seek advice, within
the World Bank and outside.
The World Bank procurement department, the staff of which have a breadth of experience, are seeking to incorporate thelessons they have learned in guidance material and SBD. In particular in the ICT context the procurement staff understandthe potential conflict between transparency and optimum results, and will be able to give advice on the latest thinking inrelaxing or interpreting the strict procurement guidelines to suit the particular circumstance.
See also the procurement web site: www.worldbank.org/itprocurementforum.
External to the World BankThe TAP (Total Acquisition Process) Systems Guide, CCTA UK, The Stationery Office, ISBN: 011 3300840.

93

Good practiceTechniques and topics
Procurement planning

Annex A
to Chapter 8
Figure 5 Examples of possible commercial structures for ICT components

Structure1
Fully managed in-houseproject

information technology(technical infrastructure)
installation services
support and maintenance services

Company 1
In-house
ISSP / System Design

Company 2

Company 3

In-house information system development(or packaged IS) and implementation

Project Implementation Unit
with or without Company #4 for Project Supervision

Structure 2
In-house systems withintegrated IT supplier

In-house
ISSP / System Design

1. Implies sufficient in-housecapability for the strategicplanning and design work.
2. Implies sufficient in-housecapability for the development
and implementation work.
3. Implies sufficient in-housecapacity to manage several
suppliers (including the in-housesupplier).
4. Fits the standard 'transparency'
drivers.
5. In principle, leads to better
subcomponents of technicalinfrastucture.
6. Increases administration workload.
7. Can lead to interoperation
problems.
8. Can lead to conflict concerning
under-performance (1) between
technical infrastructure andapplication and (2) between
technical infrastructure suppliers.
1. Implies sufficient in-housecapability for the strategicplanning and design work.
2. Implies sufficient in-housecapability for the development animplementation work.
3. Fits the standard 'transparency'
drivers
4. Can lead to method conflict
between the in-house team andco. #1 concerning underperformance issues.
5. Provides the advantages anddisadvantages of turn-key supply
for the IT, e.g. some inferior
components in the products andservices.

Company #1
forinformation technology(technical infrastructure)andinstallation services
andsupport and maintenanceservices
In-house information system development(orpackaged IS) and implementation

Project Implementation Unit
with or without Company #2 for Project Supervision

Structure 3
Out-sourced IS / self-integrated IT

In-house
ISSP / High level
System Design

Company #1
forinformation system
andimplementation
services
andsupport andmaintenance services

information technology(technical infrastructure)
installation services
support and maintenanceservices

Company 2

Company 3

Company 4

1. Implies sufficient in-housecapability for the strategicplanning and design work.
2. Fits the standard 'transparency'
drivers
3. Can lead to method conflict
between the in-house team andco. #1 and some re-work by co.
#1.
4. Can lead to conflict concerning
under-performance (1) between
technical infrastructure suppliers
and application supplier and (2)between technical infrastructure
suppliers.

Project Implementation Unit
with or without Company #1 for Project Supervision of Companies 2, 3, 4

94

Good practiceTechniques and topics
Procurement planning

Figure 6 Examples of possible commercial structures for ICT components (page 2 of 3)

Structure 4
Out-sourced IS / integrated IT

In-house
ISSP / High level System
DesignCompany #1
forinformation system(technical infrastructure)andinstallation services
andsupport and maintenanceservices

Company #2
forinformation technology(technical infrastructure)andinstallation services
andsupport and maintenanceservices

1. Implies sufficient in-housecapability for the strategicplanning and design work.
2. Fits the standard 'transparency'
drivers
3. Can lead to method conflict
between the in-house team andco. #1 and some re-work by co.
#1.
4. Provides the advantages anddisadvantages of turn-key supplyof IT.
5. Can lead to conflict concerning
under-performance (1) between
technical infrastructure suppliers
and application supplier and (2)between technical infrastructure
suppliers.

Project Implementation Unit
with or without Company #1 for assistance with specifrication and supervision of Company 2

Structure 5
Full turn key

In-house
ISSP / High Level
System Design

Company #1
forturn-key (single responsibility)for
information technology (technicalinfrastructure)andapplication software
andimplementation services
andsupport and maintenance services

1. Implies sufficient in-housecapability for the strategicplanning and design work.
2. Fits the standard 'transparency'
drivers
3. Can lead to method conflict
between the in-house team andco. #1 and some re-work by co.
#1.
4. Provides the advantages anddisadvantages of turn-key supply.

Project Implementation Unit
with or without Company #2 for Project Supervision

Structures 6 to 8
Structures 2 to 4 with design assistance

IS / IT supply per structures 2 to 4

1. Fits the standard'transparency' drivers
2. Can lead to loss of knowledge
and method discontinuity
between co. #1 and subsequentcompanies.
3 other comments pertaining tostructures 2 to 4.
4. Provides for international
experience and good practice indesign.

Company #1
for
ISSP / System Design

Project Implementation Unit
with or without Company #1 for Project Supervision95

Good practiceTechniques and topics
Procurement planning

Figure 7 Examples of possible commercial structures for ICT components (3 of 3)

Structure 9
Full turn-key with design assistanceCompany #1
for
ISSP / System Design

Company #2
forturn-key (single responsibility)for
information technology (technicalinfrastructure)andapplication software
andimplementation services
andsupport and maintenance services

1. Fits the standard'transparency' drivers
2. Can lead to loss of knowledge
and method discontinuity
between co. #1 and co. #2.
3. Provides the advantages anddisadvantages of turn-key supply.
4. Provides for international
experience and good practice indesign.

Project Implementation Unit
with or without Company #1 for Project Supervision of company 2

Structure 10
Out-sourced IS with design assistance - retaining
design knowledge / integrated IT

Company #1
for
ISSP / System Design

Company #1
forapplication software
andimplementation services
andsupport and maintenanceservicesand assistance withspecifrication andsupervision of Company
2Company #2
forinformation technology(technicalinfrastructure)andinstallation services
andsupport andmaintenance services

Project Implementation Unit

1. Does not fit the standard'transparency' drivers
2. Closer to normal commercial
relationships.
3. Efficient but requires fair andhonest relationship between
purchaser and supplier.
4. Provides the advantages anddisadvantages of turn-key supplyof IT.
5. Provides opportuinity for
conflict between suppliers overapplication performance.
6. Provides for international
experience and good practice indesign.
7. Provides an informed twostage process with no loss ofknowledge or method conflict.

with or without Company #3 for Project Supervision.

Structure 11
Full turn-key with design assistance - retaining
design knowledge

Company #1
for
ISSP / System Design

Company #1
forturn-key (single responsibility)for
information technology (technicalinfrastructure)andapplication software
andimplementation services
andsupport and maintenance services

1. Does not fit the standard'transparency' drivers
2. Closer to normal commercial
relationships.
3. Efficient but requires fair andhonest relationship between
purchaser and supplier.
4. Provides the advantages anddisadvantages of turn-key supply.
5. Provides for international
experience and good practice indesign.
6. Provides an informed twostage process with no loss ofknowledge or method conflict.

Project Implementation Unit
with or without Company #2 for Project Supervision.

96

Good practice

IS and IT strategy
Chapter 9

In principle any continuing enterprise of significance should be functioning on thebasis of a strategic plan, especially one for IS and IT. It is good practice to initiate
the process when the organization anticipates embarking upon a program of broad
impact or significant investment.
What this chapter is about

An IS and IT strategy for an organization seeks to align IS and IT and investment with thecurrent and future direction of the business for enhancing the effectiveness and efficiencyof the organization. This chapter provides an overview of the rationale of IS and IT
strategy, the content that might be expected within an IS and IT strategy, and the process
to develop the strategy.
Annex A provides an alternative, if inferior, approach of a strategic “snapshot” where an
ICT component is initiated but no IS and IT strategy exists. The tacit or undocumented
strategies of key stakeholders are documented to pave the way for the execution of thecomponent. Annex B presents a perspective on the role, content, and process of a national
ICT strategy. Annex C gives a brief outline of soft systems methods that may complement
harder engineering methods in complex and unstructured problem situations. Annex Dlists political, technical, managerial, and institutional factors that are crucial to the successof strategic IS projects.
There are many different, sometimes proprietary, methods that can be applied. The
information here is intended to be generic to most methods.
Structure of this chapter

Introduction
Rationale
Content
Process
Notes in the World Bank context
Where to seek further guidance
Annex A: An alternative: the strategic snapshot
Annex B: National ICT strategy
Annex C: A brief note on soft systems analysis methods
Annex D: Key success factors for the formulation and execution of strategic
IS projects

98
99
100
101
103
105
107
108
112
113

97

Good practice9.

Steps in process of delivery

IS and IT strategy

IS and IT strategy

Introduction

In principle all ICT, IS, IT projects should be set in a context laid out in an IS and IT strategy. The IS and IT strategy seeks
to identify IS and services that support the corporate objectives, policies, and procedures.
IS may be purely that — an information system — that is, primarily a vehicle for presenting information. More usually, andcertainly for greater worth, IS may be process orientated where the process uses and manipulates data, typically to improve
efficiency and effectiveness, and enhance the processing of some business transaction. These might be called computeraided business systems that do not merely report upon data about activity but leverage production from IT. The
presentation of information for operational and senior management is a byproduct of such systems.
In vernacular, the term IS has come to mean many things. It may mean:
Personal systems — small systems and tools used by an individual
Office systems — interconnected (through networks, files services, or mail services) or disconnected andindividual tool sets that are used for the preparation of documents, spreadsheets, graphics, presentations, and soon
Data capture systems — some scheme whereby data external to a computer are brought into it, usually by entry ata keyboard but also by optical character recognition (OCR) scanners or bar code readers, usually en masse, andinvariably as input for some other purpose
Imaging systems — a scheme whereby a readable document is scanned to create a digital image that can be stored
and organized for retrieval and presentation as an image. Invariably digitized images are input for some otherpurpose, often as part of a work flow system.
Image character recognition (ICR) systems — an extension to the imaging systems where the digital image isanalyzed to recognize the content, in order that the content may be digitally manipulated. ICR is usually used inprocessing en masse, and invariably as input for some other purpose, often as part of a work flow system or more
traditional processing systems.
Management information systems (MIS) — use of data captured either as part of the same system or via anothersubsystem (a data capture system or transaction processing system) to provide routine and ad hoc analysis of
aggregates, counts, comparisons, tables, and other summaries to provide information, for example, oforganizational performance. The worth and effectiveness of MIS that is not a byproduct of some other system
must be questioned on the grounds of process superfluity.
Transaction processing systems — online systems involving operators on terminal equipment (usually personal
computers) interacting with transaction processing and database servers to perform some part of a service toclients, such as entry of motor vehicle registration details and issue of certificates, entry of unemployment records
and printing of social welfare checks, entry of in-patient records and scheduling of ward, procedures, and theatre.
Geographical information systems (GIS) — systems that combine digitization of spatial images with statistical
data and static descriptions that enable, in particular, analysis and presentation by spatial parameters.
Workflow systems — transaction processing using tools that extend and facilitate the design by encoding anorganization’s process flow, such as encoding the path of an insurance claim from the mail room through thereview process, premium confirmation, to payment.
e-business systems — subsystems, using the Internet as the connection layer to enable global anywhere, anytime
interaction with other IS.
Executive information systems (EIS) — tools to collate and summarize data and present information pertinent to
the decision processes of executives. Most existing IS deal with data generated internally through internal
processes or through dealings with the “customers” of the organization. However, strategic information —information that is of most use to the executive — originates externally. The executive, while retaining98

Good practice

Steps in process of delivery

IS and IT strategy

responsibility for effective and efficient management of the organization, has the special role of scanning theexternal environment of the organization. EIS seek to fill this niche. There have been many experiments, however,truly effective EIS remains elusive.
Decision support systems — tools that help decision-makers use data and models to solve semistructured andunstructured problems.
Expert systems — interactive systems constructed using a tool set with an inference engine that applies specialized
symbolic reasoning to a database of encoded knowledge to perform at a level of competence better than that ofnonexpert humans, for example, Banker credit evaluator, Dipmeter oil location advisor, Mycin medical
diagnostician.
The foregoing is illustrative and certainly not exhaustive or definitive. There are other types and categorizations. The
taxonomy of IS is somewhat blurred. The essence is a methodical application of some scheme that manipulates data forsome purpose that is perceived to be worthwhile. Frequently the term “system” is fused with IT tool sets that facilitate
analysis. And then there are IT tool sets that facilitate the development of other tools and systems.
Almost inevitably, and increasingly so, an IS will be implemented via an IT based approach.
Rationale

The IS and IT plan responds to the basic purposes, objectives, policies, and strategy for the company 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 directions laid out by the executive, such as:
An analysis of organizational strategies, plans, policies, and procedures that seeks to identify information
requirements
An assessment of information assets to identify opportunities for new products and services
An assessment of existing services, service levels, systems, infrastructure, and organization for IS and IT and theeffectiveness in meeting the requirements and opportunities
A determination of affordable services and service levels appropriate to the organization
A revision of the management system that measures the effectiveness of the strategy, service delivery, andexecution of projects
A revision of existing projects and identification of new projects seeking to sustain the services and service levels
A revision of the organization to provide the services and service levels
An investment framework
A framework within which unidentified future proposals can be assessed
Technical, commercial, and user guidance to existing service providers and personnel in ongoing projects and new
projects.
The benefits sought from the strategy include:
Improved delivery of relatable 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 competitivenessInformed selection, control, and coordination of investments
Control and coordination of services and systems

99

Good practice

Steps in process of delivery

IS and IT strategy

Clear understanding of ideals, purpose, and limitations in the provision of services related to IS and IT.
In the World Bank context 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
A sound basis for project proposals
A baseline for measuring effectiveness of initiatives.
Content

The IS and IT strategy should be structured and address most of the topics as follows:
Executive summary
Introduction and overview
Commission, scope, boundaries, conduct, acknowledgements
Summary of the businessMission, strategies, policies, procedures, staffing, functional–management–geographical organization, stakeholders, external
environment
Recognized problems
Recognized opportunities
Information analysis
Summary of key information use within the organization
Analysis of organizational processes
Description of processes, process flows, functional decomposition, ICT support of functions
Organizational entity model
Opportunities for improved information flows
Candidate functions for new or improved ICT
Current circumstances
Current ICT Services
List of products and services provided to external clients
List of services provided to internal users and clients
List of IS and IT management services
Assessment of current products and services
For each product and service: description of product and service, client community, service levels subscribed;
list of service levels achieved; survey and assessment of use and satisfaction within client community; service
provider; IS and IT used
Summary of recognized or observed problems
Unrequited service demands

100Good practice

Steps in process of delivery

IS and IT strategy

Current IS and IT assets
IS and IT organization: structures, staffing levels, skill levels
List of IS assets: description, relationship to services, ownership and commercial arrangements, functions, age,outline of architecture, and assessment of suitability and sustainability
List of IT assets: description, relationship to services, ownership and commercial arrangements, age, quantities,
disposition, capacities, use, and assessment of suitability and sustainability
Other service providers
Capacity requirement projections
Summary of recognized, observed, and impending problems
Desired circumstances — one to five years window
Ongoing services and discontinued services
Opportunities for new and revised products and services — over a five-year window
Products and services to be provided — to external clients, to internal clients
Service levels to be attained
ICT management objectives
Quality of service, staffing, assets, organization
Achieving the desired circumstances
Options
Services, clients, service levels, implications for: organization, users, other parties, IS organization, IS staffing
levels, training, IS, IT, IT architectures, IS and IT management systems, IS projects, IT projects, investments, cost–benefit assessment
Selection and prioritization
Services, clients, service levels
Plan of action: IS projects, IT projects, other initiatives, investments
Implications: organization, users, other parties, IS organization, IS staffing levels, training, IS, IT
Investment summary — expenditure for each period
Appendices:
Detailed material concerning surveys, organization, services, IS, IT, and so on
Process

In principle any continuing enterprise of significance should be executing under the influence of a strategic plan and astrategic plan for IS and IT. It would be good practice to initiate the process when the organization anticipates embarking
upon a program of broad impact or significant investment. The strategy should be revised cyclically with annual review andadjustment. Periodically — say three to five years — there should be a complete re-planning exercise.
There are also cyclic linkages within the planning process whereby the IS and IT plan and subsequent initiatives are framedin the context of the corporate strategy but may also by the analyses conducted by them influence the corporate strategy.

101

Good practice

Steps in process of delivery

IS and IT strategy

Figure 8 Linkages between corporate strategy/plans and IS/IT strategy/plans
Corporate
Strategy

Business Plans

IS and IT Plans

Projects
andother Initiatives

Detailed
Business
Analyses

etc...

The effort and duration of the full IS and IT strategic planning is a judgment call. It will be influenced by size oforganization, value of current and anticipated IS portfolio, quantum of impending investment, number and disparity ofservices to be provided currently or in the future, “feeling” about the current circumstances.
There are unlimited analyses that may be undertaken. The end of strategic planning and the commencement of projectplans and detailed business analyses are blurred. Parkinson’s law applies — the exercise will generally expand to consume
available resources. Typically the plan will take over two to six elapsed months expending four to twenty-four person
months. There will be little other direct expenditure except for perhaps study tours to acquire an insight of good practice.
The annual revision exercise will be prepared over one to three elapsed months expending two to six person months.
Other than those explicitly involved, there will be a large number of key persons involved in interviews, brainstorming, andreviews. The study team requires well-known and respected members who are enthusiastic for change, and understand therole of information flow within the organization. An appreciation of contemporary approaches in the business sector isuseful. An understanding of the applicability of IT is useful but should not dominate. The team should be composed of an
executive or senior manager together with analytical business driven persons. The injection of good practice, fresh ideas
and the benefits of looking beyond the constraints and normative practices of the organization inevitably mean someexternal input. Method guidance may also be required. Depending upon the scope of the activity and the abilities andproclivities of the team members, document preparation and administrative support may be required.
The steps in the process will vary in nature and emphasis depending upon the method engaged. The contents suggested
previously should guide the investigations, conceptualizations, and formulation of the plan. Some generic guidelines follow.
An initial step would be to reach an agreement on the terms of reference, scope of work, team composition,
available resources, and active executive support. In some cases more than one strategy may be relevant. This may
be a function of organization structure, for example, if disparate and autonomous structures exist functionally,geographically, or politically. On the other hand technology may be engaged to help unify disparate andautonomous structures. The approach is a management prerogative. Consult the sponsor for the study and chief
executive. Study materials such as corporate plans, annual reports, project appraisal documents, reports frombilateral and multilateral organizations, old IS and IT plan, IS and IT department reports, project proposals.
Determine and assess any pertinent preexisting organizational or national standards.
The client may need orientation concerning the processes and nomenclature of the strategic planning method to
be engaged, and the specific process to be conducted. Literature of the standard method should be made available.
Conduct fact finding about the organization: its missions, strategies, procedures, norms, products, internal andexternal environment, clients, stakeholders, structures, capacities, assets, and so on. Interview executive and senior
managers, study available materials, and confirm findings. Reassess the readiness of the organization for strategic
IS and IT planning.
Identify any information products made available externally. There may be an added element of exposure risk toexternal products, especially if these are widely available or significant to influential entities. Interview executive
and senior managers, study available materials, and confirm findings.
Conduct preliminary, high-level business studies of current operations: process flows and functional
decomposition. Interview senior and middle managers, study available materials and confirm findings.
Investigate information flows. Interview senior and middle managers, inspect reports, investigate otherinformation channels, determine efficacy of and sources for reports and other information, study available

102

Good practice

Steps in process of delivery

IS and IT strategy

materials, and confirm findings. Investigate the information flows pertinent to the executive, how these are fed andthe cascade and tributaries from management and operational levels.
Solicit planned or desired business directions, perceived business problems, planned solutions, perceived
opportunities and perceived actions to understand them. Interview executive and senior managers, study available
materials and confirm findings. Investigate source of funds including donor and lender initiatives for theorganization.
Conduct fact finding surveys about current information services: services, service levels, performance andadequacy, service providers, existing policies, standards and procedures, HR, IS and IT assets, capacities, capacity
projections, recognized problems and opportunities. Interview executive and senior managers, interview ISPs,
interview IS and IT service clients, study available materials, and confirm findings.
Solicit planned or desired IS and IT directions, existence, and status of ongoing projects or initiatives. Interview
ISPs, study available materials, and confirm findings.
Assess current status, perceived problems and opportunities, and desired status. Investigate and summarize goodpractice through study tours, literature review, web reviews, links (e-mail) with contemporaries. Synthesize findings
and conceptualize options and candidates for new, revised, and ongoing services, computer-assisted businessprocesses, products, systems, organizations, and investments. Outline approach, and initial estimates. Consider
risks. Consider broader impacts. (In contentious areas or where there is suspected rush to solution, soft systems
methods may be applied, refer to annex C). Present initial findings and interview executive and senior managers
and service clients.
Sift options for recommendations: new, revised, and ongoing services and service levels, IS organization forservice provision, IS and IT investments, source of funds, procurement strategy, support and maintenance.
Document reasons of selection from among the options. Outline projects and initiatives for training,organizational change, IS and IT. Describe project objectives, products, anticipated time scales, and resources
needed. Allocate responsibility. Consider any migration or transition requirements (refer also to guidance in annex
D). Present elaborated options, seek consensus on preferred portfolio and priorities, identify “quick wins”, market
and negotiate preferred portfolio, review and revise with executive and senior management. Define monitoringand evaluation schemes for the strategy and for the initiatives within it. Settle upon agreed strategy to be
implemented.
Finalize and publish strategy.
Commence implementation.
The process must be managed with a routine of planning, direction, controls and accountability, suitable to the relatively
small team structure.
Notes in the World Bank context

A project champion from within the executive or senior management will be a good candidate for the role of teamleader. Absence of such enthusiasm will mean that it is inappropriate to commence the project. It will also indicatethat large-scale investment in ICT is not appropriate. As a precursor to IS and IT strategy, consider whether theorganization needs first a business strategy, or capacity development that may lead to a business strategy. There isan underlying assumption of stability of purpose, direction, and leadership. Politics at large needs to be considered
as well as internal government politics.
Prior to commencement, orientation and capacity development through training should be undertaken for the
study team and the executive. Mentorship and skills transfer should be complementary objectives of the process.
Strategy acceptance will be enhanced if the projects and initiatives are designed in short stages with genuine
benefits delivered in short time scales — say less than one year. Implementation of some initiatives may bepossible without significant investment in new IS and IT.
The strategy needs to draw upon direction but focuses upon the means to achieve them. It is a guideline foraction. Consider the organization’s client environment — is there sufficient stability, will the community use andtolerate the IS and IT? Consider the organization’s social environment — will the organization rank and file use
and tolerate the IS and IT? Consider the reality of the technology — is it proven, is it practical, is it practical in the103

Good practice

Steps in process of delivery

IS and IT strategy

particular country, region, is it beyond the maturity of the organization to sustain it, should there be interim
enhancements? Consider the external infrastructure — does it rely on fictitious infrastructure, services, and levelsof service? Consider financial reality — can the organization fund the implementation and sustain it? Is it
justifiable or just a grand solution in a low return, low volume, or poor country context?
Project definitions and cost estimates are problematic. On the one hand the practicalities need to be assessed todetermine whether it is worth doing. On the other hand, the vision from the viewpoint of the strategic plan teamis very restricted. Sizes, quantities, availability, supplier approaches, and so on cannot be determined without muchinvestigation that would likely be beyond the scope and timescales of the study. The key is toForesee possible project profiles using best available information within a fixed investigation time frame
Estimate conservatively highAnnounce contingencies
Recognize that these may prove incorrect
Be willing to replan.
Emphasizing the last point: a project will gain momentum beyond reason. If costs expand and benefits do not (sufficiently)
expand, the project should be abandoned or at be least reconstructed.
It will be convenient to express programs and projects through logical frameworks.
The IS strategic plan is not sacrosanct. It reflects the intuitions and desires of individuals. While there may beevidence to validate the choices, the IS strategic plan complements a corporate plan grounded in the experience,
limitations, hunches, prejudices, and whims and fancies of an executive often swayed by the changing fortunes oftechnology policies. On top of this shaky platform, the IS strategic plan is built with the experience, limitations,hunches, prejudices, and whims and fancies of IS planners who are equally vulnerable to changes around them.
Even if the key planners involved remain in place and in favor, attitudes will vary and new ideas, preferences, andpriorities will arise. More likely, new people will arrive or gain ascendancy and new directions will be chosen. This
perspective is not meant to diminish the value of the IS plan. Great value lies in the communication of direction
and forum for debate.
Technological imperatives need to be kept in check. Technology can bring many benefits, but it is by its applicationand not of itself that the benefits would arise. Its use and consequences need to be understood. By definition,technology brings uncertainty — it introduces new means of performing tasks that disturb existing systems.
Electronic business is the buzz. It provides many new and valuable opportunities. However, it cannot be
implemented in isolation. Its limitations need to be appreciated.
With few exceptions, it relies on processing systems. Instead of writing through the post, using a telephone, orvisiting a counter, clients of the organization may be online over the Internet. That is, electronic business ismerely a new interface between an organization and its clients. The vast machinery of the organization’s
internal processes still needs to be in place. Do water billing systems or social security systems consist only ofdata entry for new application forms? Does a tax office merely accept returns? How does the rest of thesystem work? Traditional, perhaps dull, the “bread and butter” system needs to be there and it is likely to
consume 95 percent of the investment. What is more, the interfaces for the mailroom, telephone operator, andcounter clerk usually still need to be there, especially in the public sector where equity of access is a drive.
It requires security and legality. Government policies, legislation, legal precedence, and commercial agreements
are required to underpin Internet transactions.
It needs continuous maintenance. E-governance (improving access, timeliness, accountability, andtransparency) only works if the sites are updated. There are ample sites that have been constructed but haveno systematic update.
Successful introduction of new information systems and application of technology requires institutional change,and skills and resources of appropriate quality and quantity to understand, plan, use, and operate. At the corporate
level, incentives and not IS and IT controls are appropriate, and there need to be incentive structures for theacquisition and retention of skills. Also, to return to a recurrent theme: IS and IT cannot be handled as mereprocurement activity since they usually affect human activity systems.

104Good practice

Steps in process of delivery

IS and IT strategy

Developing strategic plans for IS and IT is the same whether it is in the World Bank client base or in any otherenvironment. There may be some small distinctions in the developing context. The baseline of familiarity at alllevels — executive, managerial, and technical — with the technology, the implementation process, and the value ofthe planning process may be lower. Ambition may be unrealistically high; patience may be too low. There may be
too much emphasis placed on the leading edge, dismissing the need for bread and butter transaction processing.
Vital but uninteresting ancillary systems — network management systems, system management systems, asset
management tools, configuration management tools and so on may be undervalued. There will be overambition in
the ability to deliver, and in the ability to develop and implement in-house. The personal computer has a lot toanswer for. The façade of empowerment unfortunately too often obscures and deceives. There is a large
distinction in the delivery complexity between a single-user or small-department system and that of a large-scale
system. Although the problem resides almost exclusively in the management domain, it is taken sas an affront by
the in-house team when qualified external resource is engaged. There will be underambition too. Dazzlingtechnology will eclipse the rather more important, sometimes irksome task of grafting vital, concomitant change
to the culture, structure, and procedures of the organization.
In the formulation of projects, there should be consideration of private sector capability and project models (seechapter 8, and figure 5 to figure 7 of annex A). It should not be assumed that the domestic private sector iscapable or the international private sector interested in every project.
The IS and IT strategy should preferably already exist prior to the loan. Alternatively, some initial preproject
preparation facility or an early component of the loan may be employed to prepare it. As a last resort, as a distinct
component within the loan or as part of a significant ICT component, a strategic snapshot should be prepared.
Technical assistance will be beneficial, especially for the general process of IS strategy or for good, contemporary(inevitably international) practice in the sector.
Following on from the previous point an organization is likely to benefit from good practice advice. Inevitably inthe public sector the advice will come from international experience. A loan component is an efficient means tomobilize such experience as technical assistance embedded in a development process. There are advantages ofcommonality of direction when embedded. There may be advantages of quality of supply when supplied
separately.
The World Bank has well-constructed and robust procedures for procurement supporting investment decisions
that may arise from the strategic plans. For good reasons, the World Bank’s procedures are dominated bytransparency and administration imperatives. It should be recognized that these will not constitute best practice in
a commercial environment and that there is a cost: lower quality components and projects.
SBD come in two broad varieties: for goods together with installation and support and maintenance services, andfor services alone. Many comprehensive services combine both aspects. In conceptualizing projects, allowances areneeded for procurement and contract models that encompass both the goods aspects and significant consulting
and other services such as expert support, facility management, operational support, training.
The World Bank’s attitude to brand names and single sourcing needs to be understood when determining the sourceof funds for the investments that may arise from the strategic planning. Single sourcing (or direct contracting) willneed to be justified per World Bank rules (refer to Guidelines — Procurement under IBRD Loans and IDA
Credits and see section in chapter 9). Bureaucracy notwithstanding, such justification is also swayed by the
persuasiveness of task managers, the client, or the consultants engaged.
Where to seek further guidanceWithin the World BankWorld Bank Group Sector Strategy Paper
GICT for IS and IT strategy and business analyses
External to the World BankJ. Ward and P. M. Griffiths, Strategic Planning for Information Systems, John Wiley and Sons, 1996, ISBN: 0471961833
Business Systems Planning, IBM, 1984, ISBN 999627182X.
P. Gray, W. R. King, E. R. McLean, H. J. Watson, Management of Information Systems, Dryden Press, 1989, ISBN 0030215978

105

Good practice

Steps in process of delivery

IS and IT strategy

R. H. Sprague and H. J. Watson, Decision Support Systems, Prentice-Hall International, 1993, ISBN 0130422355
M. Klein and L. B. Methlie, Expert Systems: A Decision Support Approach, Addison-Wesley Publishing, 1990, ISBN
0201175622
Tim Schwartz, David Satola, and Camilla Bustani, “Telecommunications Reform in Emerging Markets,” in Walden andAngel eds., Telecommunications Law, Blackstone Press, 2001, ISBN: 1841741213.

106

Good practice

Steps in process of delivery

IS and IT strategy

Annex A
to Chapter 9
An alternative: the strategic snapshot

More often than not ICT projects are initiated without the benefit of an IS and IT plan. The project may have no mandate,and neither the resources, nor the time to deliver one. The right course of action can be to defer the project, however that
may be unpalatable for the client. The preparation of a strategic snapshot is an alternative that will be recommended whenthese conditions arise.
Usually, in the minds of the key stakeholders and decision-makers there is some sort of vision for the project and its role ina broader context. The strategic snapshot seeks to capture, and present this vision of the context in which the project isbeing launched. It seeks to align the project with the multipartite client expectations of IS and IT. It seeks to mitigate
downstream opportunity loss, inability to integrate with other products or initiatives, divergence from strategic directions
or standards, and the resultant dissatisfaction or criticism.
The notable distinction of the snapshot is the absence of creativity and analysis. There will be no conceptualization of
threats and opportunities, candidate systems, and so on. The content of the snapshot will not necessarily be justified bystudies — merely a comment on the context as it is currently understood. The review process will usually need to arrive atsome consensus of opinions or, failing this, at least define the dominant opinion acceptable to the project’s sponsor and its
client. The work to produce the strategic snapshot may illuminate the benefit and need of a proper study.
Content should include:
Purpose, overview and limitations
Summary of current business
Purpose, organization, functions and procedures, key volumetrics, continuing programs, and key problems andopportunities
Summary of current ICT
Portfolio of ICT assets, HR resources, anecdotes on usage and satisfaction, continuing projects
Summary of key business strategies and policies
Vision, priorities, projects, changes proposed to purposes, organization, functions and procedures, key
expected volumetrics, technology
Summary of ICT strategies
Computer hardware and system software, data communications, other communications, HR, procurement,
ICT projects, source of funds
Project perspectives
Impact of strategies, projects, and others on the project
The process can be undertaken in less than four weeks and may consist of the following actions:
List stakeholders, decision-makers, and influencers to be interviewed.
Structure, arrange, and conduct interviews
List pertinent documents as recommended by the client and through interviews
Study existing documents, such as corporate plans, yearly plans, budget submissions, old IS Strategy Papers,
reports of multilaterals.
Summarize and present.
Revise as necessary for both accuracy and completeness.
Sign-off.

107

Good practice

Steps in process of delivery

IS and IT strategy

Annex Bto Chapter 9
National ICT strategy

This section addresses strategic planning for ICT in an organizational context. Exploitation of ICT for economic growthand social equity may also be planned as a national strategy. While the level of activity within the World Bank’s portfolio
may never become large, the World Bank is particularly well placed to participate in the initial and ongoing preparation ofnational ICT strategies.
Information and knowledge and access thereto are deemed intrinsically good. Studies indicate strong positive correlation
between wealth and exploitation of knowledge. For example, Ghana and Korea forty years ago had similar per capita GDP.
There is a now a six-fold gap with acquisition and exploitation of knowledge assessed as a key determinant.
Governments have a role to mobilize information and knowledge as economic drivers — a direct role and a policy andpromotional role — to create preconditions for investment in the development of a knowledge economy. Information
exploitation accelerates economic transformation in many ways. These include: better understanding of and increased
responsiveness to trends, broader and faster dissemination of market information, trade facilitation, 24x7 marketing andadvertising, supply chain shortening, smoother and more efficient payment systems, increased efficiency andresponsiveness of government, and upgrade in labor market mix. Knowledge rather than natural endowment determines
competitiveness and wealth. Globalization increases competition and allows domestic economies to grow. Global
investment requires information.
Status and Scope
The development of national informatics strategies is still in its infancy. Few countries have yet to produce and implement
such strategies. Those that have embarked upon the process have achieved varying degrees of success. Only a few have aformally documented and published strategy and most strategies only cover the public sector.
National strategies differ in their scope and content. In some cases, the strategies concentrate only on the provision of atechnical infrastructure, while others concentrate on the provision of a national IS and IT system where all government
ministries are to be linked electronically.
The major problem in all cases has not been the ability of technology to provide solutions but the rate at which policy
makers are able to adapt their understanding of and thinking on the future shape of government. The United States“reinventing government” initiative of the mid 1990s is one example of a “visionary approach”, which has challenged
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, central government has adopted a “business driven” (rather than “IT led”) approach to theharnessing of IS and 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 and IT strategies. Key areas for examination include:
The 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 policy makers
Integration of the future strategy with other government initiatives, such as a citizen’s service charter andoutsourcing and privatization policies
The links between central and local government

108

Good practice

Steps in process of delivery

IS and IT strategy

Administrative arrangements for development and management of the strategy.
Policy dimensions
Policy dimensions as described in table 10 may be considered in national ICT strategies:
Table 10 Policy dimensions for national ICT strategies
Competition policy

Access infrastructure

There is need for a market-based infrastructure, service

Policy, legal, regulatory, supervisory frameworks are required forPart and parcel of this would be privatization of public assets inneeds to recognize the dynamism within the sector and canthis domain.

includeprovision and operation for telecommunications, in particular.

telecommunications and broadcast sectors. The framework

Promotion of competition
Investor–user security
Independent regulators
Licensing that balances open elastic markets and fair andtransparent competition
Allocation of spectrum for market entrant with assurance oftechnical and financial viability

Realistic and fair income from public asset divestment
Enabling new infrastructure investment and guaranteeing
fairly priced, fair-share access to established legacy (usually
land-line) infrastructureMarket segmentation by content and convergence
Regulating for frictionless selection and switch of serviceprovider by user
Access — social equity

National skills base

Recognizing that market force alone would not provide access toEnhancement of national skills pertinent to the national strategy

all sectors without encouragement:

for self-sustainability through education and training:

Schemes for rural, remote, disadvantaged access

ICT in schools for both technology familiarization and

Schemes for USO such as license packaging and subsidy

literacy, and pedagogical purposes

policyHigher education partnerships

Telecenters (community access points with combinations ofSupport for continuing education and distance learning

services, backed by and subsidized networks) for the
disadvantaged

109

Good practice

Steps in process of delivery

IS and IT strategy

IT industry policy and ICT exploitation in the private sector

ICT in government

Recognizing the relevance of ICT for industry, government can

Government has a direct role through its own use of ICT:

help foster conducive environments that are appropriatelyInterdepartmental coordination on technology policy,

targeted:

standards, and procurement

Assessment of IT appropriate to and sustainable throughImplementation efficiency through panel of suppliers

local industry

Government product preferences to concentrate skills baseMeasures for competitive IT: streamlined licensing

Public-private sector partnerships

bureaucracy, taxation incentives, encouraging foreign

ICT — skills enhancement byproductas subsidized networks

transactional processes in all departments

Support for trade facilitation schemes

Enhancing service such as through GIS in government

Clarifying taxation treatment of electronic commerce

Providing telecenters for the disadvantaged

Domestic preference for supply

Electronic payments by government and to government

Reduced or removed import tariffs for technology

Transparent public accounts through web sites kept up to

Promotion of technology parksdate, including a government-wide portal

Support for technical education and knowledge diffusion

Web sites for public use to apply for government services

Supporting, underwriting or providing micro-lending for ICT

Interdepartmental data flows (subject to data protection)

capital investment, providing technical infrastructure suchsector business, such as for telecenters

Streamlining bureaucracy by computerization of major

Preferential use of local IT suppliers

Policy for outsourcing of government functions and services[A caution on e-readiness within government. Bread and butter
systems need automation before benefits can be fully leveraged
through electronic government. Sufficient public access to theInternet is required, for example, e-filing of tax returns is viable
only if more than ten percent of taxpayers can get online. While
promoted as altruistic and as better service to society, it brings
major benefits to government. For example: through e-filing adata entry bottleneck is farmed out to the community or private
sector agents, thus relieving government of a costly andburdensome chore.]e-commerce

Other legalities

The rush to e-commerce should be contained within a security

Other matters of legality arise in the digital world:and legality framework providing some certainty:

Copyright and IPR of software and electronically recorded

Recognition and enforceability of digital contracts

works

Digital signatures: authentication, a certification procedure,

Censorship of web sites and other electronic broadcast bothand national certification authority

for domestic and foreign sites

Public and private key infrastructure and encryption

Criminal law: electronic break-in, fraud and electronic

procedures (including technology import permission)

impersonation, attacks (passive, destructive, disclosure,

Issues related to data privacy, access and data retention

passwords

Domain names and domain names authority

denial of service) through viruses, theft of codes andElectronic payments systems
Currency exchange regime under electronic trading
Consumer protection
Service limitations (for example in telemedicine, gambling,
pornography, trade in illicit goods)

Process
The planning of initiatives as always will begin with an honest appraisal of the current status, a vision for a future status andthen the plan to bring the vision to reality. National ICT strategies likewise require an assessment of current status; a visionof long range goals with the projection of realistic, shorter term steps toward them; and identification of concrete
programs, projects, and agenda. Fruition clearly needs sustained commitment at the most senior levels of politics, a crosssection of key industries, legislature, and government. For the vision to be realized would require a critical mass of110

Good practice

Steps in process of delivery

IS and IT strategy

consensus of objective and direction, a national program of technical assistance, national coordination office, and tangible
actions and outcomes.
The programs need to be demand driven, that is through market driven private involvement. Large-scale engineering
project approaches would be inappropriate. The initiatives by government then are policy focused: emphasizing theremoval of policy and institutional barriers and encouraging the adoption of technology.
The process will be highly political, intensely consultative, and of necessity entirely driven by domestic players. The
World Bank’s role will be to first mobilize interest and enthusiasm and then facilitate technical assistance from persons ofappropriate seniority, skills, and experience. Correspondingly the highest possible level of authority should be involved —ministerial and executive. It is vital to maintain cautious optimism without underselling the difficulties of the process andthe lag in benefit realization, and without overselling the benefits.

111

Good practice

Steps in process of delivery

IS and IT strategy

Annex C
to Chapter 9
A brief note on soft systems analysis methods

Hard system engineering is presumptive — the problem is presumed, the solution is fixed and thought apparent, and themethod of implementation is procedural. There is a rational structure, however, if the situation is not well understood, thismay lead to inappropriate or disappointing outcomes.
The unstructured environments of most human endeavors give rise to significant problems. Modernization and reform oforganizations in the developing context are programs that address significant problems. A problem is a situation whereexpectation is not matched by observation. Circumstances are interpreted by our stock of ideas and experience. If the
problem is not understood, a too hasty, too exclusive solution is unlikely to be successful.
An alternative approach is the soft systems methods characterized by:
The concept of problem situations being a mismatch between expectation and observation (the expectation may
be a desire for measurable improvement, and the problem is the selection and detail of a course of action)
Focus on a whole entity whose exhibited properties have no complete meaning in terms of parts of the entity
Application of models to construct holons (abstract descriptions of the entity) to illuminate reality by a process of
systemic enquiries (phenomenologies)
A flexible, iterative cycle of inquiry using a seven-stage process of investigating, expressing, defining, modeling,
comparative analysis, debating, and action
Human activity systems or holons that are sets of activities (transformations) connected to make a purposefulwholeForming root definitions pertaining to holons and analysis in terms of “customers”, “actors”, “transformations”,“weltanschauung” or “world view”, “owners”, and “environmental constraints”
Use of “rich pictures” to solicit analysis of the intervention itself and more obscured social and political systems
The actions arising will lead to new problem situations and a new cycle of interventions.
Soft system methods aim to bring about improvement in an area of social concern by activating people involved in a neverending learning cycle. Learning is an iterative process of modeling from various perspectives, debating perceptions andcourses of action, taking action and reflecting again.
In the creation of IS, the difficult first question is which of the constellation of choices should be put together. The raisond’être for an IS is to serve some real world purpose. An IS manipulates data that upon presentation are attributed meanings
according to the actor. The actor’s weltanschauung needs to be understood for the attributed meaning to be truly useful.
Information flow models may then be constructed from the activity model. From these data models data manipulations
systems could be elaborated. At points along the way in this simple process, the “common” understanding may becomeless common. New light may be shed on the system pertaining to the broader problem of reform or transformation. Thismay circumvent “in-the-box” thinking, leading to entirely different IS, or entirely different or reprioritized approaches.
Where to seek further guidanceWithin the World Bank
Robert Schware, Information and Communications Technology Agencies: Functions, Structures, and Best Operational
Practices, info, vol. 5, no. 3, 2003
External to the World Bank
P. Checkland and J. Scholes, Soft Systems Method in Action, John Wiley and Sons, 1999, ISBN 0471986054
D. Patching, Practical Soft Systems Analysis, Prentice Hall, 1990, ISBN 0273032372

112

Good practice

Steps in process of delivery

IS and IT strategy

Annex D
to Chapter 9
Key success factors for the formulation and execution of strategic IS projects

The success rate of IS projects can be increased by applying the following practices during the formulation of projects, forexample as part of the IS and IT strategy. The practices should be observed also during detailed planning and execution ofprojects.
Political

Technical

Consider the interests of champions and sponsors,

Ensure project fits with IS strategy, or in absence of formal

influence networks, users, policy makers, financiers, and all

strategy carry out snapshot strategic analysis

other stakeholders

Carefully consider scope and over or underambition

Develop a legitimate culture-specific incentive package

Determine feasibility through prototypes and pilots

If a project threatens interests and risks political

Keep realistic time horizons (one year, maximum twointerference, break into stages and concentrate on

years)

comprehensiveness and security in data collection

Implement in stages to reduce risks

Define progress indicators that disclose degree of political

Deploy hardware only after application software is readysupportSynchronize training, conversion planning, installation

Suspend swiftly if political conditions are not favorable:

work, and application roll-out within as short a time as

Resist pressure to downgrade development objectives

possibleto simple equipment upgrade or office automation

Use professional system engineering standards

But consider catalytic impact of supporting a network

Buy instead of building software, whenever possible

facility or simple e-mail on organizational
development
Managerial

Ensure viable project management structure, but make line

Institutional

Synchronize business and IS strategies

management rather than technical management

As far as possible contract with the private sector for IS

responsible for project successdesign, construction, and operation

Ensure professional project management input andSimplify and reengineer procedures to avoid automating

practices adhering to modularity, standardized

inefficiency

documentation, clear progress and financial reporting, andDecentralize implementation and provide central support

early detection of problems

through formal agreements

Maintain project visibility by publicizing objectives, target

Address within the project wider institutional issues that

dates, and progressmight threaten the full impact of the ICT component

Budget for independent project audits, covering all aspects:

Consider incentives (reward and penalty), particularly pay

technical, political, managerial, institutional, and financial

scales for IT staff

Allow scaling up or down depending on progress, if at all

Have professional training program designed andpossible predefine the triggers for change of scale

implemented

Provide mechanisms to terminate nonperforming projects

Have components to address other change issues

and switch funding to more promising ones

Ensure close coordination between project and staff

Courtesy: E.Talero, 3/98—File: IT Bestpract.doc

113

Good practiceBusiness analyses for a proposed ICT
Chapter 10

The vast majority of applied IT is in support of business processes — to makeprocesses more efficient or, increasingly, to offer new services. Business is the focus.
Naturally then, the process of applying IT must begin with clarity about the businessprocess and how it is to be improved in a justifiable manner.
What this chapter is about

This chapter provides an overview of the process of analyzing the current businessenvironment and proposing a justifiable, feasible, and sustainable future concept ofoperation. Owing to the focus of this toolkit, and despite the distortions that might ensue,
there is a bias in attention to ICT initiatives. The material is consequently not balanced by
the vast array of other initiatives that might pertain in any given circumstance. Therefore,
as a caution: in the conduct of business analysis, be alert to any rush to ICT initiatives atthe expense of, or in the absence of, more fundamental and effective solutions.
Structure of this chapter

Definition and scope

115

The timing of a business analysis

115

Process

116

Some tips

120

What to expect

120

World Bank context

121

Where to seek further guidance

121

Annex A: Managing benefits

122

114

Good practice10.

Steps in process of delivery

Business analysis

Business analyses for a proposed ICT

Definition and scope

A business analysis for a proposed ICT component would seek to satisfy some or all of the following:
Understand the functions of a business area, activities within the functions, the internal and external context inwhich it operates, and the volumetrics
Understand the information needs and information flows supporting the functions and measuring performance
Identify improvements in business activities, work practices, and information needs and flows including
improvements through the introduction of new ICT
Identify new products that may be introduced through the exploitation of ICT
Build a new concept of operation
Trigger an assessment of whether ICT is appropriate or of sufficient priority when other initiatives may have more
fundamental and durable impact
Define the proposed ICT after the elaboration of options
Comprehensively estimate investments required for the introduction of the new ICT
Identify and quantify financial and nonfinancial benefits to identify consequences and risks, and to build a businesscase
The analysis may be conducted in several steps: a step to determine a new concept of operation including identification andderivation of options and implementation steps, that may not include ICT; and a step to identify and derive ICT options.
For example the first step may anticipate ICT as an initiative several years hence, identifying as the initial priority a need forinstitutional development.
Parkinson’s law applies — the depth of detail in any business analysis will extend to that which the available time andresources permit.
There is a close correlation between business analysis and strategic planning for IS and IT as may become obvious in thefollowing subsections. Differences may occur in the depth of study, business analysis being more comprehensive, or thebreadth of the organization that is studied, an IS strategy being generally broader (see chapter 9).
The timing of a business analysis

Business analysis may arise in several circumstances:
A problem, some unsatisfactory performance, or a new demand may arise for which better understanding andsolutions are sought without any precondition of ICT based solutions.
A proposal for ICT may arise outside the context of any formal IS strategy, from a corporate plan, a business plan,or as part of some loan proposal. (The business analysis may then eventually recommend that strategic planningshould be completed before implementation.)
An IS strategy usually includes business analyses to an arbitrary level of detail, depending upon the significance of
the anticipated investment, the scope of the anticipated ICT, and the resources allocated to the strategic planning
process.
An IS and IT strategy may initiate business analyses to conduct more detailed investigation, to refine or verify
concept or scope, or to establish a business case.
The IS and IT strategy may initiate an ICT project that will inevitably require increasingly detailed analysis of thetarget business area.

115

Good practice

Steps in process of delivery

Business analysis

Process

The process needs to be driven by the senior management of the business area, together with the involvement of thosewith specific knowledge of the current circumstances, interest in improvements, and general knowledge of good practicewithin the business area. In addition, the process requires experience, sensitivity, imagination, and a capability to analyze,
synthesize, plan, and present. Inevitably, the search for improvement involves external intervention. Facilitation of theprocess of business analysis also usually requires external intervention. Participation of internal IS personnel (not IT
personnel) of sufficient experience and ability is desirable. The overall direct team should be kept small — not more thansay six.
There are several methods that may be used to conduct the study. Some are proprietary. The method will usually be
introduced under the guidance of the external intervention. The following paragraphs outline the general process of acomprehensive study.
The process must establish:
An understanding of problems and opportunities that are agreed upon by a wide group, including influential andauthoritative persons within the business area
A set of initiatives understood and desired by business area managers
Corresponding plans for change and investments that are:Practical (useful, usable, and likely to be used)
Optimal (the best recognized application of time, money, and effort)
Feasible (politically, culturally, socially, and technically)
Justifiable (promoting organizational objectives with benefits sufficiently outweighing costs)
Sustainable (affordable at introduction, and affordable on operation)
Schemes for monitoring the effectiveness of implementation and the realization of benefits.
The business analysis is unlikely to provide complete definition of requirements and design. The business case should be
limited in scope, to prepare sufficient grounds to justify the commencement of the analyzed and selected implementation.
There would generally be investigations, analyses and specifications of increasing detail in subsequent stages. The outcomesof such stages could revise the business case.
Typical steps in the process are listed below:
1. Initiate the study
Establish the leadership of the study.
Establish a steering committee.
Negotiate basis, scope, exclusions, and expectations.
Plan the study, including methods, cost and resource requirements, and dependencies.
Assess readiness of the business area for business analysis (senior management participation and interest anddetermination for change, business area has clear goals and objectives, access to people and information facilitated,
sufficient institutional capacity in the business area, an information culture with an understanding role ofinformation systems).
Establish the study team.
Obtain existing information sources, such as corporate plans, business plans, IS and IT plans, performance
reports, previous analyses.
Publish study plan.

116

Good practice

Steps in process of delivery

Business analysis

2. Provide orientation to the client organization
Identify the method to be used.
Make available literature of the standard method.
Describe the processes and nomenclature of the method.
Describe the specific process to be conducted in the current exercise.
3. Investigate the business area
Solicit the purpose of the business area.
Solicit the relationship to the organization.
Review past and current business plans and policy documents.
Summarize targets, performance, and measurement schemes of current and past years.
Summarize perceived constraints to performance and performance improvements.
Solicit recognized business problems, weaknesses, and threats to performance.
Solicit recognized strengths and opportunities for improved performance.
Document structure: management, personnel, geographical locations, office characteristics, and layouts.
Build business process and activity models.
Build functional decomposition models.
Solicit examples and the degree of variations in processes according to locality.
Catalogue samples of all input and output forms (those used in transactions with clients) and internal documents.
Summarize statutory requirements within the business area.
Inspect and assess procedure manuals for completeness, accuracy, currency, readability, and alignment withpractices.
Study and assess control and audit methods.
Investigate and assess security procedures and devices.
Survey skills levels and labor levels, skills and labor requirements, and assess any discrepancy, potentiallycommissioning an analysis of training needs.
Document productive assets and services and the purposes for which these are engaged, and solicit age, condition,
maintenance, sufficiency, and effectiveness.
Survey business volumetrics by type and location: staffing levels, numbers of clients, numbers oftransactions(correlated with business activity models and functional decomposition), and records held.
Inspect and assess or have assessments made of records kept and records handling.
Reassess business problems, weaknesses, and threats, seeking to supplement preconceived deficiencies.
Publish findings, invite critique, revise as necessary.
4. Study and assess information flows
Solicit information needs and flows.
Construct information and information flow models, for example, generalized entity-relationship models and data
flow models (cognizant of the audience and hence with a minimum of distracting IS engineering jargon andnomenclature).
Solicit perceived deficiencies in information flows.
Study IS and IT currently engaged, document the purposes for which these are engaged, and solicit and assess age,condition, maintenance, sufficiency, and effectiveness.
Reassess information flows, seeking to supplement preconceived deficiencies (for example, what does each level ofmanagement actually use to monitor and control).

117

Good practice

Steps in process of delivery

Business analysis

Which dominates: formal or informal flows?
What do operational people need?
Are formal reports succinct, accurate, complete, timely, useful, and used?
Is there a cascade of summaries with drill-down capability?
Can the business area provide an information service to other parties, and if so is there any cost recovery
option?
Does the business area use information supplied by other parties, and how could this be effectively andefficiently ensured?
Consider e-business opportunities: for new disclosure opportunities, efficient interfaces, or new products andservices.
Publish findings, invite critique, revise as necessary.
5. Identify opportunities for business improvements
Document recognized business opportunities to address problems, improve efficiency or effectiveness, or deliver
new products. Opportunities may be reorganized structures, capital works, revised forms, revised procedures,
revised work practices, new or supplemented skills and labor, education and training, new or supplemented tools
and techniques, new IS and IT, and so on.
Investigate good practice and technologies engaged elsewhere in comparable business.
Conceptualize additional opportunities.
Synthesize options for change that encompass subsets of nonexclusive opportunities.
6. Conceptualize options for the information of non-ICT products and services[No elaboration provided; consult relevant specialists.]
7. Conceptualize options for the implementation of ICT products and services
Elaborate upon options for the role of ICT in support of business improvement.
Commission prototypes to substantiate concepts if these are not clearly understood by the user community.
Commission larger-scale prototypes or pilot implementations to fully explore, assess, and refine nontechnologicalrequirements and impacts, for proof of concept, or confirmation of concept.
Consider minimum and desirable service levels.
Consider IS architecture, IT architecture, physical and environmental implications and requirements, organization
for administration, operation and use, acquisition approach, and support and maintenance.
Research off-the-shelf solutions — give preference to such approaches.
Consider integration with existing systems.
Study any extant IS and IT strategy and assess applicability to the circumstance. Weigh the strategy to determine
the degree to which it facilitates or obstructs an initiative.
On the one hand, the many and various, often hidden or obscure, aspects of implementation, such as physical,
technical, and human infrastructure, and ongoing contracts, may be facilitated by current strategy.
On the other, a sufficiently large initiative can provide grounds for a revision of any IS and IT strategy.
Conceptualize the operation of envisioned ICT products and services.
Assess capability of in-house supplier (consider, for example, demonstrable prior success for the delivery ofcomparable products, familiarity with proposed or likely technologies, capacity and current work load, strategic
choice within the in-house supplier).
Assess the capability of local, domestic, or regional suppliers (consider, for example, commercial capacity, technicaland labor capacity, familiarity with proposed or likely technologies and contracts of similar profile, and current
portfolio).

118

Good practice

Steps in process of delivery

Business analysis

Assess attractiveness of any likely contracts to international suppliers with local partners (consider, for example,
prestige, size, complexity, set-up and mobilization factors, and profitability).
8. Prepare a preliminary business case for each option
Estimate the costs of options.
Identify and quantify benefits (refer to Annex A).
Identify and quantify risks.
Confirm that the options are:Practical (useful, usable, and likely to be used)
Optimal (the best recognized application of time, money, and effort)
Feasible (politically, culturally, socially, and technically)
Justifiable (promotes organizational objectives, benefits sufficiently outweighing costs)
Sustainable (affordable at introduction, and affordable at operation)
Revise options accordingly.
Prioritize the options.
Identify “quick wins”.
Publish findings, invite critique, revise as necessary.
9. Define a new concept of operation
Synthesize opportunities and practices to model redesigned business activities and functional decomposition.
Explain the new concept via narrative and models.
Revise performance measures or devise new or supplementary measures.
Revise information needs, and revise information flows, or devise new or supplementary flows.
Make an initial assessment of impact on image, client interface, organization structures, roles, and cultures.
Consult with representatives of affected business areas concerning expectations for input and disruption during
implementation.
Consult with representatives of affected business areas concerning new inputs required of them, or new orreorganized outputs for them.
Publish concept of operations, invite critique, revise as necessary.
10. Outline implementation plans (including implementation for sustainability)
Arrange initiatives into implementation packages and indicate steps within each package.
Set timescales for the implementation packages and indicate milestones within the packages.
Identify and bundle purchases of goods and services of all types that are required by the initiative.
Identify inputs to the implementation processes from within the organization, such as financial, legal, technical,
asset management, capital works, security, IS, records management, and affected business areas.
Define measurement schemes to test the efficacy of implementation.
12. Finalize the business case
Assemble findings of the business analysis.
Refine cost and benefit estimates.
Finalize the business case for the selected options.
Prepare log frames.
Publish business case, invite critique, revise as necessary.

119Good practice

Steps in process of delivery

Business analysis

Obtain final acceptance of the business case from the executive of the business area.
Some tips

It is unlikely that the business area is perfect. Inevitably initiatives for performance improvement will emerge even
if severely constrained by access to funds.
In benefits think positive — staff reduction is both unlikely and petty. It would be preferable to find methods toredirect staff from clerical and administrative to productive activity.
Benefits are likely to be overstated — use mitigation factors — realism also protects the senior managers fromhaving to deliver ambitious targets.
Costs are likely to be understated — you can only budget for what you can foresee.
Costs are difficult to estimate at the time of the business case. For example:
The system requirement is preliminary.
Design should not even have been contemplated since there is world full of ideas.
IT is dynamic — the next wave will break by the time the study is finalized — nevertheless investment cannot
be put off forever.
IT costs are dynamic (product price revisions every few months suggest prices for off-the-shelf hardware andsoftware are constantly dropping, but this rarely results in lower overall spending, because higher specification
goods are purchased for the same price, and software is increasingly hungry for hardware resources. Plus, theservices element is increasingly costly).
Supplier attitudes to supply or discounting are uncertain, especially for noncommodity purchases such asservices.
Availability of packages may not be verified, the degree of customization almost certainly will not be.
Despite difficulties it is better to have a decision based on best information, rather than do nothing.
For new IS, think packages and beware of “we can do it ourselves” or “we are different”. Bespoke development isgenerally costlier and riskier with high rate of failure to implement. Bespoke development is wasteful — as it tends
to reinvent the wheel. A package or an application framework should encapsulate modern good practice, for which
the beneficiary should be willing to reorganize. A package usually reduces delivery lead-time, ability to obfuscate,and distractions from the business goals by build activity.
At the level of the business case, for ICT, prototype cautiously. Prototyping can mushroom to be a large exercise.
At this stage, it could distract from the business study. If the circumstances are sufficiently novel or if there issignificant difference of opinion in the value of an ICT application, or its purpose and value are not understood,
perhaps a thin prototype — a short exercise — can be commissioned. A study tour may be more illuminating. If
significant time, effort, or investment is required, it should probably be executed as an independent project.
What to expect

Typical outputs of business analysis are indicated within the process outlined above.
Business analysis can be expected to provide:
A plan for the study
Interim outputs that confirm the findings as they are documented
A final report that may include a log frame and sublog frameSome formal confirmation that the report has been accepted by the business area, which intends to implement theinitiatives that it can sensibly implement from its own resources, and submit the proposal for financial andtechnical support for those that it cannot.

120

Good practice

Steps in process of delivery

Business analysis

World Bank context

A World Bank country representative or task manager may be confronted with a request for financial and perhaps technicalsupport for some conceived investment. In principle, the request would have been based on a sound business plan —however this may not often be the case. At the very least before discussing the proposal to any great degree, the intended
beneficiary should be required to document a convincing summary of its business plan that would include:
What it wants to do — the fundamental objective (which should not be something in the order of implementing acomputer system, or modernizing or upgrading a computer system)
Why it wants to do thisWhat it entails in some detail
Cost estimate
Benefits summary
Risk summary
Complementary organization development initiatives
Why this is the right option, which should include other options considered and discarded.
The intended beneficiary may need assistance to prepare even this summary.
The business case should be assessed from many perspectives: desirable World Bank business; compatibility with theoverall loan; convincing business case; informed, realistic technical proposal that considers and caters to the true
consequences of implementation, realistic cost estimates, and realistic benefits estimate.
In general, there should be no need for proof of theory for ICT initiatives. The investments should not be “leading edge”.
If concepts are difficult to sell through lack of understanding within the intended user community, thin-prototyping may becontemplated. Prototypes require capital equipment and there may be impediments such as effecting these quickly underWorld Bank procedure, and prejudicing any downstream procurement activity.
Where to seek further guidanceWithin the World Bank
Consult PADs containing large ICT project components.
External to the World BankJ. Ward and P. M. Griffiths, Strategic Planning for Information Systems, John Wiley and Sons, 1996, ISBN: 0471961833
Business Systems Planning, IBM, 1984, ISBN 999627182X.
Good practice in developing sustainable information systems / Supporting Guides (esp. SG3, 6, 8, 11), Department for International
Development (UK), CCTA 1998

121

Good practice

Steps in process of delivery

Business analysis

Annex A
to Chapter 10
Managing benefits

Business change requires investments: financial, time, effort, and other resources. The motivation for the investments is anintended improvement or benefits . The benefits will not accrue by accident; they may not accrue even with good planningand execution of the initiative. The benefits need to be managed.
The rewards of benefit management include:
Aide mémoire of the purpose in the midst all the fuss of implementation
Signaling to people directly and indirectly involved, the purposes and targets of the initiatives
Current circumstances better understoodMore informed, clearer decisions when major or minor shocks modify direction and priorities
Better knowledge of progress and whether adjustment is desirable
Increased likelihood of a successful investment
Feedback for future initiatives
Steps for benefit management.
1. Identify expected benefits
Identification requires imagination, experience, and an appreciation of the planned initiatives.
Benefits should be related to a business activity.
Identification may be
Objectives-driven: using objectives of the initiative to derive expected benefits
Activities-driven: analyzing the way activities are affected by the initiative to derive expected benefits
System-led: based on the purported benefits of the system to be implemented applicable to the business area(reactive and complacent, at risk of a flawed system, and least effective for genuine change).
Benefits may be direct or indirect, quantifiable financially or otherwise, or not quantifiable.
Business benefits rarely flow directly from IS. It is the new and improved business process in which the IS is
engaged that delivers the benefits.
Table 11 gives some examples of high level benefits that may accrue through the introduction of an effective IS.
Table 11 Examples of high level benefits from an IS
Imperatives

Business area better able to fulfill policy, legal, regulatory imperatives

Quality of service

Quicker response to clients; more detailed, accurate, and timely information

Management

Less time spent in superfluous record keeping
More informed, timely, accurate basis of decision
More responsive to internal and external trends

Productivity

Decrease in resources spent in nonproductive activity, duplicate recording, record searching, and so on
Increase in resources in productive capacity

Cash flow

Accurately, timely accounts
Improved debt situation

Motivation

Reduction or elimination of routine and tedious work

Strategic fit

Support for effecting and monitoring other initiatives

122

Good practice

Steps in process of delivery

Business analysis

2. Quantify expected benefits
Expected benefits may be used as performance measures or performance indicators — proxy measures.
Performance indicators should be quantified in SMART terms — specific, measurable, achievable, results oriented,
and time oriented.
Establish baselines of current performance.
Quantification may require detailed activity statistics, performance statistics, and other volumetrics from theexisting business practices to establish baselines.
Benchmarks of good practice and results from comparable initiatives elsewhere may provide a frame of reference
Apply mitigating factors: for example, not all additional time may go to productive activity; if clerks are redirected
to productive duty, newly trained persons may perform less ably than old hands; be aware of the law ofdiminishing returns such as in debt collection, in tapping the informal economy. The business area manager should
protect himself from too ambitious targets. Bear in mind the business case needs to be established.
In quantification, it may be prudent to apply sensitivity analysis to factors that contribute to the measure orindicator and adjust targets accordingly.
In the anticipation of benefits it is better to think positively. An IS can reduce clerical effort and permit it to be
redirected toward more productive effort. For example: IS may relieve a nurse from the burden of administrative
work, freeing up twenty percent additional time for patient care; or IS may eliminate effort spent in inspection oftax returns, permitting 100,000 additional hours of debt recovery or audit per annum. This is preferable to twenty
percent reduction in nursing staff or letting go of fifty revenue clerks.
Care should be taken in formulating measures and indicators. There can be unintended effects. For example,
reduction in the portfolio of social insurance claims under investigation can be achieved by slowing theadministrative process so that claims are held in an alternative category, or by simply accepting them without
investigation.
3. Define benefits management plan
Benefits do not accrue automatically, they require to be managed and some effort is needed to achieve them.
Establish and publicize a scheme for monitoring, diagnosing, reporting, and responding performance measuresand indicators.
Establish IS to record and analyze performance data.
Assess and revise the benefit management plan as the needs arise.
4. Monitor, diagnose, and respond
Follow the benefit management plan.
Be alert to J-curve effects — initiatives may, in the short term, degrade performance during familiarization withnew procedures, personnel, and so on.
The initiative may be one of many concurrent initiatives. It may be difficult to ascribe cause and effect.
There may be changes in the business environment that influence measurements to accentuate or diminish
performance measures and indicators.
Output of benefit management

Benefits identified and quantified
Benefits management plan in place(These first two outputs may be part of a business case, IS and IT plan, or implementation project plan.)
Benefits tracking system in place
Benefits tracking reports — quantitative measures from some MIS and qualitative (surveys, proxy measures)
together with diagnosis and response123Good practiceIS engineering
Chapter 11

Software development is too often characterized by approaches that are haphazard,
and trial-and-error (more error than trial!). Costs can spiral and benefits can be
stubbornly elusive. This is unnecessary. Disciplines can be applied to deal with
software as an engineered product that undergoes planning, analysis, design,
implementation, testing, and maintenance.
What this chapter is about

This chapter provides an overview of the processes involved in delivering the IS part of the
proposed future concept of operation.
There are many well-documented technologies (methods) applicable to some or all of theprocesses involved. The information described here intends to be generic.
There is an abundance of narrow and interchangeable specialties, some more enduring thanothers, and some that burn brightly but only for a short while. Despite the ocean ofminutiae that pertains in this domain, paradoxically this chapter is quite short.
The domain is littered with jargon and nomenclature. Online glossaries may be useful, forexample, www.webopedia.com.
Structure of this chapter

Introduction

125

Where to begin — contingent on where we are

125

Definition phase125

Build phase

130

Prototyping

137

Web applications

137

Some tips

139

World Bank context

139

Where to seek further guidance

140

Annex A: Elements expected in definition phase products

141

124

Good practice11.

Steps in process of delivery

IS engineering

IS engineering

Introduction

There is a marked difference in the process of delivering ICT, when the stage is reached for the actual delivery of the IS
and technology. To the greater extent, Parkinson’s law no longer applies. In earlier stages, the extent of the work expands
to the capacity of resources and allotted time. The outputs are documentation that cannot be fully tested and of arbitrarylevels of detail (determined by the allotted resources and time). When it comes to the delivery of actual and usable systems,
however, the products and components are tangible, testable, of a set quality, and have inescapable and somewhat inelastic
characteristics. The products and components and their predetermined characteristics determine the resources and timeneeded to deliver them, not vice versa.
To illustrate the difference, consider responses to — “how much time and effort should be applied to the business case fora bridge, a hospital, a school…”, versus “how much time, effort, and material is required to build this specific bridge, thisparticular hospital, this school?”
There are influences upon system engineering by project management, quality management, and World Bank procurement
models and vice versa. Those chapters of the toolkit dealing with these other topics should be consulted.
Note that the procedures also apply where prototyping, and in so-called rapid application development methods. There aredifferences and these are highlighted later in this chapter.
Where to begin — contingent on where we are

There are two broad parts of the process of IS engineering: definition of product, and build of product. These parts arethemselves broken into several stages. The process will begin with a definition of the product to be engineered (refer toquality management, chapter 3). Where exactly the definition process begins is contingent upon the process that has
occurred up to this point and the depth of studies so far.
Definition phase

The first part — the definition phase of system engineering — is illustrated in figure 9. The key outcome in the first part isto prepare a definition of a set of products and the attributes of the products that permit the structured approach tocommence.
In a well-structured program, there would already have been steps in this direction. So, the starting point of the IS
engineering is dependent upon the work that has already been done toward corporate planning, strategic planning for IS
and IT, and business analysis in the target business areas.

Figure 9 Processes during early stages of product life125Good practice

Steps in process of delivery

IS engineering

FUZZY
IDEAS
&
CONCEPTSIDENTIFICATION&
DEFINITION
of a
BUIlDABLE
PRODUCT

Increasing focus and detail

Systems engineering- building phase

PRODUCT

toin

Objectives

Collated

pr
od
uc
ts
, c reom asspo em
ne bl
nt y a
s
an s
d
at
tri
bu
te
s

s
tic
ris
ts te
ep racnc haco cof andy
bl vesem ti
ss jecsa b
di nt o
va
le
re

Facts

Iterations ofinvestigation,
understanding,description
andconfirmation

DECISIONSApproaches
Product List
Components

Views

ed
igh
we and edclanba

Attributes
Structures

Opinions
Strategies

The techniques in the first part are applied in an environment where formal structures of problem definition are not yet
present and where the main actors are generally unfamiliar with system engineering (build phase) notions, processes,
products, and most significantly the representational languages and techniques used. The appropriate techniques in thedefinition phase should be correspondingly friendlier and less challenging and must be produced in a manner than can beapplied later in the development cycle.
The techniques will seek to bring increasing focus and definition upon fuzzy concepts — ones that are perhaps welldefined to a business area person, but too fuzzy for the application of engineering procedures.

126

Good practice

Steps in process of delivery

IS engineering

Figure 10 Definition phase — techniques to bring increasing focus

Business Analysis may (should) have been partof 'corporate' planning.
It may (should) have been part of IS & IT
planning, supplementing the earlier work,
It will be part of IS engineering (definition phase)again supplementing earlier work.

Organisation: mission, objectives,
strategies, plans...

Business
Analyses

Information Systems andInformation Technology Strategies

Business
Analyses

IS ProjectIn addition to business analyses, IS
and IT Plan will influence the project,e.g. through establishing technology
guidelines, policies and proceduresfor project managment and systemdevelopment, etc.

IS & IT Snapshot

Business
Analysis
Specification ofsystemrequirements
High level
designBuild phaseengineering

The techniques are used in close working relationships with personnel untrained in system engineering — that is, with
eventual product users and persons responsible for business decisions related to the products. The techniques need toaccommodate differences in both the investigative requirements and language or frame of reference. These techniques
cannot properly be described as engineering. The techniques for early product life are more closely related to problem

127

Good practice

Steps in process of delivery

IS engineeringsolving and decision-making disciplines and the so-called soft systems techniques (see chapter 9, annex A). Refer here also
to chapter 10, concerning business analysis.
The steps undertaken during the early stages of product life vary from product to product and project to project according
to the “point of departure”, and influences. Point of departure depends upon the amount of preparatory work available tothe development team. In some cases there may be strategic plans in place and well defined — these will constrain but also
facilitate and expedite the decision-making. The requirements may already be well defined; the system design options may
have been already presented, assessed, a broad design chosen, even to the extent that the broad design may have been
completed.
Several influences may alter the nature of the products and the steps to their preparation. The product may be constrainedby technical infrastructure or, conversely, the product as it develops may be able to dictate the technical architecture. The
product may be anticipated as a green field development or as an acquisition, or the approach may be constrained in someother manner. The product may be (preferably is) some customization of an off-the-shelf product. It may be a classicalapplication development. On the other hand, the product may require integration of several components such as somebespoke development, some legacy systems, and some enhancement of those systems, some off-the-shelf products, andsome contemporary but independent developments.
There are options for the delivery of the system: by development or by acquisition, and if by acquisition, the degree of
specificity that the client is seeking: ranging from innovative system design based on thin requirements only, to increasingly
constrained design as the definition approaches detailed specification. The client may be cognizant of its budget position
and be willing to “bend” toward an off-the-shelf solution — that solution encapsulating good practice.
The exact sets of steps to be followed and sets of products to be produced are contingent upon the specific circumstances
and will need to be investigated, documented, and agreed upon with the product sponsor, project board, and project
financier(s) such as the World Bank. In general then there is one overriding principle: one size does not fit all. There is only
one universal and common starting point — to determine the current circumstances and then to proceed by an appropriate
set of steps toward the identification and definition of products suitable for software engineering.
One factor that should be emphasized is the priority assigned to cost estimation. Many methods will largely ignore thecosts for a system, conveniently allowing this to be out-of-scope. This is inappropriate. An IS for business area x can be
developed to many different levels of facility for x. Any IS that has no budget constraint is possible to design and build.
However, the client needs to be able to afford it, and should be advised as early as possible of ball-park sizing to determine
what level of facility is sustainable and sensible, and be kept abreast of cost data as knowledge of the requirements anddesign matures. This requires a sufficient but not necessarily complete definition of the product upon which the costestimates are based and from which the build stages will proceed.
For the purposes of this document, the workflow described assumes a broad general approach for a comprehensive set of
products from a point just prior to the requirements definition stage. The point of departure then for this method is a“strategic snapshot”, as figure 11 illustrates.
The steps within these processes are not described here — that would be dependent upon the method that is engaged by
the system developer. Annex A lists some characteristics that may be expected. An underlying concept is that the policies
and procedures for software development are akin to standard plans in a manufacturing environment. The project plan forthe development (akin to an actual production plan) defines in a manner appropriate to the circumstances: the stages, theactivities within the stages, staging points, and the theoretical or real go-no-go decision points.

128

Good practice

Steps in process of delivery

IS engineering

Figure 11 General model for the workflow for product definition and relationship to build phase

Origin1 Project initiation
document(s)2 Corporate Strategy
3 IS Strategy

Methods

PrepareStrategic
Snapshot

Strategic
SnapshotA

1 System Requirements
Catalogue
2 System Design
Options
3 Design Options - cost estimates

B

System Design
Selection

C

1 System Design Statement
2 Technical Infrastructure
Specification

D

Quality Control

A

1 Strategic Snapshot
2 Project Initiation
Document(s)Methods

DefineRequirements

Quality Control

B

1 System Design
Options

Methods

SelectDesign Option

Quality Control

C

1 System Requirements
Catalogue
2 Strategic Snapshot
3 Investigations
4 System Design
Selection

Methods

DesignSystemQuality Control

D

IS and IT Strategy
System Requirements
System Design

Methods

SystemEngineering(build phase)

Software for implementation

E

Technical infrastructure
for implementation

E

Quality Control

D

IS and IT Strategy
System Requirements
System Design

Methods

Technical
Infrastructure
Procurement

Quality Control

129

Good practice

Steps in process of delivery

IS engineering

Build phase

The definition phase should provide sufficient information for two purposes: for the system developer or provider to adapt
the techniques relevant to the selected IS development tool set and deliver the software for the new system, and for thetechnical infrastructure (computer and network hardware, and system software and attendant services) to be specified andacquired. The definition phase should provide some certainty regarding the cost, effort, and timing of delivery of these twoparts of the eventual change in the business process. The last chapter of this toolkit elaborates on other aspects of theimplementation of computer-aided business systems.
For the purposes of this document, there is an assumption of a significant project where the new IS will be operated ontechnical infrastructure to be acquired. There may be instances where the existing technical infrastructure determines theshape of the IS, but such circumstances should be avoided. In those cases there would still be likelihood for supplemental
capacity in technical infrastructure.
The delivery and acquisition of the application software and the technical infrastructure can occur via several paths, forexample, parallel activities, an all-encompassing turnkey approach, or in stages. For the purposes of this section, the steps
to acquire technical architecture and to acquire or develop the software application will be illustrated.
For the technical infrastructure, knowledge of the application software is essential and hence the acquisition of thetechnical infrastructure can only proceed when architecture and performance parameters are known, that is, when asoftware package has been contracted, or for a bespoke development, when the design is sufficiently mature.
As the application solution matures, there may be some influence on the technical infrastructure. If, for example, theapplication software were a customized off-the shelf package, many characteristics of the technical infrastructure would beknown pending the advice of the application software supplier.
Technical infrastructure
While there may be some setting of installation and configuration parameters, technical infrastructure will be bought rather
than made. The method for the build phase therefore has four basic stages: detailed specification of the requirements;
procurement; installation; and ongoing operation, support, and maintenance. No prescription of the method is attempted
here. Some considerations include:
1. Bid lot strategy
The system design provides an initial overview of the goods and services required for the technical infrastructure for the
new system. Decisions need to be made regarding the bid lots pertaining to any acquisition. This may be one bid lot. Lots
may be allocated depending on site or time of supply (for example, a pilot site first with separate procurement for
subsequent sites). Lots may be allocated depending upon component type (for example, personal computers in one lot,
servers in another, system software in another, services combined or let separately). Other combinations can be conceived.
There may be some combinations of such lots.
Certain procurements such as building works, electrical wiring, data cabling, furniture and fittings, stationery and otherconsumables, very possibly will not be supplied competitively by the usual suppliers of technical infrastructure. That is,multiple lots will be common.
Coordination of multiple suppliers needs to be the responsibility of either the purchaser or a designated system integrator.
For example, there will be need to coordinate major and minor building works influenced by the new concept of operation
for the business process and contemporary good practice for smart buildings. Furniture and fittings will be similarly
influenced. Stationery will be determined by the new concept of operation and will determine some of the characteristics ofhardware devices and software drivers. Cabling and wiring, and power supplies will depend on the concept of operationand the operating requirements of the specific computer and network hardware.

130

Good practice

Steps in process of delivery

IS engineering

Considerations of lot design should also include: capability of the market to supply, the cost of administration of multiple
lots, the benefits to component interoperation through prime contractor relationship, obtaining the best components
through multiple lots, testing supplier capability through multiple lots, spreading economic benefits through multiple lots.
Procurement procedures will be prescribed by national and organizational regulation and by any financial agreement withdonors and lenders. Within those parameters, there are choices in procurement route and procedures such as use of
expressions of interest to gauge market capability, and use of multiple-stage bid procedures to improve bidders
understanding of the requirement.
Administrative and transparency imperatives reduce the quality of the procured solution and should be weighed judiciously.
Size and content will dictate whether any process is direct, limited or fully competitive, and national or international.
Capital investment is also a consideration, affecting the use of outsourced systems services, or application service
providers, or whether to go for partial investment in capital acquisition (such as of computer terminals).
2. Sizing
A difficult part of the process is to estimate sufficient quantities of goods and services to satisfy the requirements.
Considerations would be based on knowledge of a mature application design, according to location, and depending on the
broad architecture for the solution. The sizing process will include:
Business transaction rates (such as the rate at which new patients arrive and register per hospital) as determined byobserved statistics and allowing for growth over the life of the configuration; application system transaction rates(usually some multiple of business transaction rates plus derived “system” transactions); target service time for thetransactions (such as registration within two minutes); and tolerable queue lengths — to determine the number oftransaction workstations, such as personal computers, receipt printers, scanners, barcode readers
Staff or user numbers per job type plus the degree of workstation sharing — to supplement the number ofworkstations
Type of transactions — to determine characteristics of client workstations, such as integrated cash drawers onreceipt tills
Transaction rates, data characteristics of the application software, response and turnaround times — to determine
LAN and WAN bandwidth estimates
Network topology — to determine numbers of LAN channels, hubs, switches, routers, WAN routers, brouters,
gateways, modems, etc.
Placement and sharing considerations in addition to transaction rates — to determine the population of network
printers
Transaction rates and physical media characteristics — to determine the capacity of high volume printers, postprint paper handlers, scanners, and other such shared devices
Transaction rates and physical media characteristics — to determine the stores of consumables and replenishment
rates
Transaction rates, customer base, and other volumetrics — to determine the amount of disk space, processor
capacity and architecture of equipment for database server, application server, file server, web server, web-filingserverNumbers of workstations or numbers of users — to determine the arrangements for software licenses for server
and workstation operating systems, database managers, system development, data analysis, desktop tools andsystem tools, virus protection and other security software, and so on
The total numbers of devices — to determine services for installation, cabling (and the quantity of cables andconnectors, conduit, racks, power points and so on)
The total number of devices — to determine overall power supply and backup power, UPS requirements

131

Good practice

Steps in process of delivery

IS engineering

Resilience and redundancy should be included — to determine, for example, additional workstations, peripherals,
processors, CPU, RAM and disk configurations of servers, whole servers, perhaps whole sites
Technical good practice — to introduce equipment and influence capacities, for example, training services,development services, test services, configuration management, site preparation goods and services, furniture andfittings, equipment and materials for environmental monitoring, control and response, devices for physical security,
backup devices, power supply monitors and regulators, firewalls on Internet connected services, network andsystem management hardware and software, diagnostic and repair equipment, tools, spare parts, consumablesupplies
All this sizing data contributes to the estimates of number of user staff, operator staff and specialist staff, and any specialist
temporary or permanent services for implementation and operation.
The technical infrastructure is commonly, nowadays, a smaller component of the total real cost of operation of any new
business system. Consequently, the sizing should be conservative — that is, with contingency built in — while not be sounwieldy as to be indefensible.
3. Specification
Following the identification and quantification of goods and services pertaining to the technical infrastructure, the various
classes need to be specified. Specifications will be influenced by factors such as:
Application software requirements
Operational requirements
Ergonomic requirements
Physical environment
Physical characteristics such as of stationery
Durability and reliability considerations
Size and capacity data
Interoperability requirements
Interconnection requirements
Scalability considerations
Derived requirements in underlying hardware and software
Industry standards and contemporary norms for good characteristics in components
Reliability of supply, support, maintenance, and other commercial considerations
National and organizational policies for supply
Organizational, national, and international standards for interoperability, emission controls, safety, and so on.
The specifications need to tread a fine line between being too broad (and potentially not being sufficient for the totalrequirement) and too narrow (and risking incompleteness and a need for supplementary purchases).
It is wise not to be overly specific in the specification. A shopping list would leave the purchaser open to additionalpurchases for components overlooked, or dependent upon a specific supplier’s particular technical and commercial
approaches. Instead, words to the effect “The bidder is required to offer other goods needed for the operation andinteroperation of the specified components and to offer to install such…” should be included in the invitations for bids.
4. Services
Services will usually attend the goods. It is good practice to be very cautious about a purchaser’s technical capability to
install out-of-the-box, despite protests from any technical staff. There are also commercial considerations for warranty andsupport and maintenance.

132

Good practice

Steps in process of delivery

IS engineering

Services should include project management, installation services, training, support and maintenance. Consideration should
also be given to expert consulting to properly use and operate the technology. Depending upon the capabilities and choicesof the purchaser, consideration may also be given to operational support, facility management, and outsourcing.
Quantities also apply to services:
There should be some specification per service type of the required numbers of individuals, number of days of
input, and minimum skill levels.
The number of training events and training event characteristics such as training objective, level of training, classsizes, event locations, and minimum trainer skills should quantify the training. For highly specialized low volume
training travel to a supplier venue might be expected, otherwise training can be located in the purchaser’s premises.
The use of in-house training capability may influence the split in the supply training between the technicalinfrastructure supplier and the in-house trainers, for example, for high volume, low technology training events
such as basic terminal operation, or basic use of desktop tools.
Support and maintenance should be quantified in terms of service levels for hardware and software, times ofcover, response and repair times, and support services included within the agreement.
5. Cost estimation
It is wise to revisit the cost estimate for both acquisition and operation of the technical infrastructure when thespecifications are determined. This provides another opportunity to confirm that costs of this element of the final IS are
acceptable to the organization.
Capital costs
The goods elements of the technical infrastructure are increasingly commodities. Cost estimation for goods isconsequently becoming more reliable. Estimation should be a relatively simple matter of market research.
System software pricing strategies are more mercurial — being a less tangible commodity, driven less bymaterial inputs than by historic investment in the intellectual content. However, an estimate can be derived
from market research and quantities.
Supplier strategies for discounting, purchasing market, and so on cannot be known.
Estimates for services are less reliable. The supplier’s degree of discretion is higher — it can adjust its margins
more or less at will, and will do so according to its assessment of competition and profit potential. Certain
services are better categorized as one-time costs associated with capital acquisition. This will include project
management, installation, and initial inputs by specialists. The estimation process should involve aquantification of days of input by category and some market research for pessimistic rates.
Recurrent costs
In addition to acquisition related costs, there are invariably other recurrent costs for ongoing operation, suchas consumables, electricity, WAN charges, Internet charges, off-site storage charges, standby-site fees, ASP
charges, FM charges, outsourcing charges, and support and maintenance. Consumables (such as preprinted
and standard paper and envelopes, exchangeable media such as magnetic tapes, compact disks, printercartridges and ribbons, maintenance materials, spare parts, fuel for backup generators) can be estimated basedon type of consumable, expected annual consumption, and unit price.
A number can be computed for electricity charges based on the number of devices, estimated power
requirements and prevailing charge rates.
WAN charges can be estimated using the published rates of the WAN provider. The charges will depend upon
the type and capacity of circuits purchased and possibly the distance in circuit segments, the time that a circuit
is used and the quantity of data transferred.
If Internet service is provided or used, other than the purchaser’s own facilities for hosting, ISP charges may
accrue based on quantity of data transferred, time expected for connection, and web-hosting fees.

133Good practice

Steps in process of delivery

IS engineering

Off-site storage usually involves use of secure premises operated, for example, by commercial banks at aconvenient distance from the site housing the backup devices. Charges can be investigated through enquiry
with such banks.
Some installations may rely upon standby sites, and shared commercial operations, for quick restoration ofservice following a catastrophe. The service levels of the standby facility determine the costs that may beinvestigated with service providers.
The system may involve the use of external facilities such as ASP, bureau services, facilities management,
outsource providers. Charging structures vary greatly but may be estimated from an amortization of thealternative corresponding capital investment cost estimate.
For support and maintenance some heuristics can be applied: ten percent for hardware and fifteen percent forsoftware are usually sufficient. If there are other specific inputs in the support and maintenance, such as
routine visits to sites, cost estimates should be supplemented accordingly.
Contingencies
In the cost estimation, it will be wise to include a contingency figure. The specifications will normally only
cover “headline items”. Two forms of contingency may be considered.
Cost contingency — a figure of ten percent will be normal if not particularly scientific and may be used toprovide some protection against unidentified components and cost movements.
A capacity contingency — say another ten percent but dependent upon knowledge of the intended
application, may be used to provide some protection against an unexpectedly resource-hungry application,
unreliable statistics of business transaction rates, or unexpected growth in business volumes.
7. Procurement process
The procurement process will entail detailed rules of procurement, forms of contract, rules of contracting, and proceduresfor contract administration. Refer to chapter 8 concerning World Bank procurement and project models.
In the procurement of technical infrastructure for IS the delivery schedule has a distinguishing characteristic. The industry
is particularly dynamic. The commercial life of products is short — almost all under twelve months and some, such as
personal computers, under three and six months. At the same time predictions about the availability, performance, andrelevance (even existence) of future products are extremely optimistic and unreliable. The World Bank rightly requires thatall goods in an offer be available in widespread distribution at the time of offer. The appropriate responses to this include:
Construct projects with short lead times if possible. Unfortunately a serious project rarely has short lead times.
Expect and cater for changes in the supply of specific components. The right to demand recent models should beincorporated in the contract (together with equitable price adjustment).
Importantly, do not purchase and stockpile quantities of IT equipment, and do not accept and pay for delivery
until immediately prior to operational use.
Application Software
The application software may be delivered or acquired through several approaches: standard off-the-shelf software,customized off-the shelf-software, or bespoke development. These are described later. Regardless of approach, there aremany software engineering methods that can be applied. No particular method is described here. However, the engineeringof the software will involve the elements described in the following paragraphs. For all of the following,
The origins will lie in the requirements and design specification
User participation should be stressed in theory and in practiceThere is a need to balance considered, planned development and “analysis paralysis”.

134Good practice

Steps in process of delivery

IS engineering

Software engineering elements:
Standards, policies, and procedures for specification, development, testing, release, and acceptance (there is arelationship between the software engineering methods and the project management and quality management
methods. Refer to other chapters of the toolkit for guidance)
Tools and procedures for system design and specification such as a CASE (computer aided system and software
engineering) tool; for programming such as editors, compilers, link-editors, and interpreters; configuration
management such as a librarian, or version control tool
A configuration library (a data dictionary, CASE database, a system encyclopedia depending upon the vernacularof the particular engineering methods and tools) that contains all the documentation and software products andcomponents
Detailed specification of functional requirements — that is the tasks that the software should perform and its
input-output behavior, elaborated from the system design
Detailed specification of nonfunctional requirements — characteristics such as the target operating environment(to establish fitness-for-purpose), the manner in which it functions, its technical basis, the human-machineinterface model, simplicity, extendibility, maintainability, performance, reliability, and so on elaborated from thesystem design
Detailed database specification — logical models (pertinent entities, their attributes and relationships represented
according to the database technology used, such as tables, columns, and primary and secondary keys in relational
database systems) and physical models (describing how the tables are organized to achieve performance objectives)
Specifications of individual programs, modules, subroutines, objects, and so on depending upon the vernacular ofthe delivery environment
Test plans for each individual program, module, subroutine, object — so-called unit test plans that confirm thatthe program performs according to its specification, neither more nor less
Unit test results with at least one per unit confirming successful testing
Test plans for the individual programs, and so on working in combination — so-called system test plans that
confirm the interoperation of the programs and that the software satisfies the functional and nonfunctional
requirements
System test results with at least one set confirming successful verification (that the functions work correctly) andvalidation (that all the software is traceable to a requirement)
Acceptance test plans — a form of system test engaged by the user or purchaser
Acceptance test results with at least one culminating in an acceptance certificate
Documentation concerning releases, versions, installation, operation, and usage
Training materials
Hardware and system software environments for development, testing, support, maintenance and training
Documentation describing the installation, operation and use of the these environments
As mentioned previously, the application software may be delivered or acquired through several approaches: standard offthe-shelf software, customized off-the-shelf software, or bespoke development. These are further described in thefollowing paragraphs.
Simple procurement of standard software licenses: this is a relatively straightforward procedure somewhat akin to
the purchase of technical infrastructure. Specifications, test planning and testing, and implementation activities
would nevertheless be required.
Procurement of customized off-the-shelf software: this would be the most likely and preferred approach for mostmodern business systems. The approach:
Tailors the software to the purchaser’s requirements
Builds on past experience
Imports good practice learnt elsewhere

135

Good practice

Steps in process of delivery

IS engineering

Avoids reinvention of the wheel
Reduces risk of delivery
Reduces delivery lead time
Reduces distractions to the delivery process
Reduces the number of problems and hence increases focus and reduces opportunity for obfuscation.
Customization may start with a “package” that substantially fulfils the business requirements through existing softwareor a “framework” that substantially parallels the purchaser’s requirements, but requires software development for the
specific purpose. A package requires more investment by the vendor and is geared toward a deep and wide potential
market, whereas the framework will usually encapsulate good practice in a small niche market that will not warrant fullcommercialization.
There can be disadvantages: for example, if the amount of tailoring is high and the purchaser intransigent to change,
the effort to modify the package may be greater than starting the whole process from the beginning. The cost of the
package may be unsustainable, although in such cases the cost, complexity, and risk of an alternative bespoke
development will also be high, probably higher, and unsustainable. The technical infrastructure needed by the package
may be inexpensive to purchase and operate, but may be dated, unavailable in the purchaser’s country, incompatible
with strategic architectures (however, if the extent of the application warrants, there would be good reason to revise
the strategy), or in some other way undesirable or unsustainable. Ownership is not usually a right of the license — thepurchaser may be restricted in future modifications and extensions.
The first step in the options selection during the definition phase should be to establish whether suitable packages
seem to exist, by expert advice, market research, or inviting expressions of interest.
All the engineering steps listed above would be expected to apply for customization. Customization may involve:
Parameterization — where data are input during the installation to configure the software to the purchaser anduser
Customization — where existing software is modified or supplemented for the purposes of the purchaser anduser
Extension — where new software is specified and developed to meet the requirements of the purchaser anduser
Any of the above in combination
Procurement of off-the shelf-software to be customized by the purchaser: this is a variation of the previous one,and may be considered if the customization effort is small; the purchaser genuinely has the capacity to customize;
the vendor sells the right to customize to the purchaser; warranty and support and maintenance can somehow besustained. There are consequential risks in this approach.
Bespoke development by a supplier: this is risky, and should be entertained only when there is no appropriate
product available. There may be a reinvention of the wheel — unfortunately without the benefit of experience.
Focus in requirement and design is diminished. Learning curve is higher for both supplier and purchaser.
Opportunity for obfuscation is higher. Opportunity for importing good practices is lower. Tendency to automate
existing practice rather than modernize is higher. Attendant features such as documentation and training need also
to be prepared. Focus easily shifts from the implementation of a computer-aided business system to by the meleeof software development. Lead-time for delivery is longer. Costs are usually higher and quality lower. Experienceand statistics suggest that such projects are more likely to fail.
If successful, the advantages can include a better fit, ownership, flexibility for future modification and extension.
In-house development by the purchaser: this is comparable to the previous approach although generally riskier.
The purchaser usually does not have the competency and capacity to undertake a significant development. A
significant project would require a major spike in productive capacity (that is system development staff andresources) that would not be required at termination. There is an absence of the clarity brought through a contract
and the focus that can be provided through intervention by an external party. The opportunity to import goodpractice is severely diminished. The opportunity merely to wastefully automate existing practice is higher. The
project is frail at termination without the security of a contract.

136

Good practice

Steps in process of delivery

IS engineering

Some combination of the aforementioned approaches: a comprehensive project would usually entail a
combination of approaches.
Prototyping

The foregoing applies equally well in the “waterfall” approach for system development or in modified approaches that use
prototyping. The “waterfall” approach usually entails stages of requirement, design, and so on with significant review
points at each stage. It can have the advantage of informed progress with feedback to the business case. It can have thedisadvantage of investing time and effort in documentary products prior to any tangible IS, which may have little impact on
the purchaser or user and take away from the vitality of the project.
In modified approaches, prototyping may be used:
During requirement definition and high-level design to help the purchaser or user define aspects critical to them bydemonstration. Usually the demonstration refers to some key procedure that might ensue from a modernizedprocess. The prototype will not generally be properly engineered, with little or no supporting data structures andonly partial representation of business rules. It will merely demonstrate understandings of requirements, or
proposals for the look and feel of the system. It will be discarded and not used in the eventual system.
During the build phase, in a complex area, a substantial but perhaps still incomplete prototype can be used to fully
clarify a business rule and a design approach in consultation with users. The fragment of software may still beincomplete since the target operating environment may be different, or an 80:20 rule applies to software — muchof the code for software handles exception conditions rather than the core routine of the function.
During the build phase, as proof of the theory for innovative combination of elements such as hardware andsoftware.
As a pilot project for some limited part of the eventual system. This may be limited by users affected, businessclients supported, implementation sites, functions supported, or some combination of these. Usually such a
prototype would be soundly engineered with the intention to retain it as the basis for the eventual system.
In some sense, every IS is a prototype. Requirements are never fully understood or satisfied. They evolve with theexperience of use. The use of prototyping for iterative development of an entire system should be avoided. Retaining amemory on the business case can be elusive. Managing deployment is difficult in such cases. The opportunity for rework isvery high and can mean expensive and embarrassing interaction with the purchaser’s clients, for example to repair data.
Web applications

A short note is included here for web applications since these are currently popular and there are differences in the skill
sets that need to be engaged in a web project.
In general, the same development paradigm should apply for the software part of the web application. Differences lie inemphasis, with less care and attention to requirement specification and system design and more effort toward iterative
development of the presentation layer.
The presentation layer is of paramount importance. The development of web pages involves graphic design. It does not
involve programming in the business system sense. Programmers are not required for that part of the service delivery. It is
more art than engineering and the skill sets need to be adjusted accordingly. (Conversely, web designers are generally not
system engineers.)
Security of access is of primary importance. Many applications are merely presentation of some information or agenda thatthe organization is seeking to project. This is a valid and valuable use of the web. However, commercial and economic
advantage lies in being able to provide an interface for the public to connect to and interact with the organization’s
services. Clearly, an organization would be sensitive to unidentified persons accessing their databases. Therefore, usually,
there is a division in the total service, with the web site projecting data from the organization and collecting data from thegeneral population into a filing center. That filing center is a feeder to a trusted business application that administers the137Good practice

Steps in process of delivery

IS engineeringorganization’s database. Sometimes the design requires the registration and identification of users accessing the service over
the web. User name and password schemes are often used for identification and authentication. Once again, there is adifference in emphasis in the security requirement. Whereas internal systems use similar schemes, the motivation is internalmanagement, prevention of fraud, and so on. The web needs this, but places additional emphasis on privacy and dataprotection, since it is open to all. Pertinent technologies, such as encryption and use of secure circuits, need to be engaged.
The web site also has contractual, and therefore legal implications. For transactions of significance, private digital
certificates are replacing physical signatures. These need to be recognized by law. For the mass of relatively low-valuetransactions, the law needs to recognize a digital contract based on the transaction alone. Often the financial transaction
would rely upon credit providers. Consequently a commercial relationship needs to be established with such providers.
Figure 12 Building blocks for e-services

e-governance e.g. public accounts open to publicview
w ould require access device orservice:e.g. a private PC or a telecentre

m ay be zero investm ent - m ay be several
significant goods-orientated investm entsof f-the sh

elf h/ w an

d s/ wa com m on carrierm od es t h/
w , s/w , and a m od es
we b ap plt
ica tio n se
rv icea reatively m odest investm ent required(e.g. a W ebsite)that access aninform ation servicea m odest connection services ig
c o m n ific ap le n t h /w
xa
p p li a n d
ca ts
io n / w a n
d
sy s
te m
s

Many substantial investm ents incom plex system se.g.
Revenue System s:tax
adm inistration
custom s
adm inistratione.g.
Expenditure
Accounts:
transport
adm inistration
healthadm inistration

fed by various system s:transaction processing system s,data capture system s etc.
etc

138

Good practice

Steps in process of delivery

IS engineering

There are other differences. A web application will be built and delivered through different, supplementary technicalinfrastructure and tool sets. There may be an internal search engine. In implementation, the web site must be registeredwith popular search engines if it is to hope for hits. It may also seek to be included as a link in the web pages of otherorganizations. Some trading of link for link may be expected. The site may include other links for altruistic reasons. All thismay be quite alien to the traditional software engineer.
Unfortunately the differences tend to dominate the process of delivering web applications. The boring, traditional, breadand butter applications need to be there to provide the data to be presented, or to process the transactions that arise fromthe web. The web site will be inexpensive and a simple, self-contained little subsystem and may distract from the difficult,expensive, risky, but vital traditional systems.
The artifacts of the definition phase and the build phases of IS engineering include many documentary specification
products, software products, licenses, and hardware. These are described within the preceding subsections.
Some tips

Beware of “this is the only way …”. This is an argument of a narrow-thinking technologist rather than a businessorientated person. A virtue and vice of IS engineering is the variety of defensible approaches.
Never ask a technologist, “could you…?”. That can be taken on as a challenge regardless of whether it is worthwhile to theorganization or not. IS and IT have potential to perform all manner of things but whether these efforts are useful needs tobe considered. It would be better to ask “would you…?”.
IS engineering is fraught with faddism. Some new wonder products burn brightly but are short-lived. The latest productoften represents many steps backward as well as forward. For example web development tools circa 2002 are bereft of
productivity facilities such as field descriptors that were normal in third and fourth generation tools circa 1990. The
selection of engineering approach should therefore be based on proven technology.
IS and IT are beset by relative obsolescence — working systems fall to disfavor simply because the underlying tool set is
not the newest and shiniest. This applies to the technology as well as the end products. It is easy to be carried away by awave of technology imperatives that contribute little or nothing to the bottom line. Again, the selection of engineering
approach should be based on proven technology. There should be a business basis for the selection.
Prototyping has a place in the panoply of IS engineering methods. However, prototyping should not be a cover for “I’mtoo lazy to think”. It can lead to incomplete fragments that fail to solve the whole requirement. Analysis of requirement
and specification of design should not be neglected.
IS engineering paradoxes:
Planning saves time — but there is never enough time to plan.
Engage users fully in system requirements and design — unfortunately users know what they want only after they
have used a system for a while and decided on what other bits they would like.
World Bank context

IS engineering should be much the same regardless of environment, perhaps with a few minor differences:
Absence of experience — also known as “having failed before”. There will be open questioning of (or polite
indifference to) the need for the apparent periphery to “getting the computers”. Again, good practice boils down,
not to the obvious, but to a host of seemingly arcane management and procedural solutions to problems notrecognized; for example, importance of tools and procedures for configuration management, system and network
management, why a package. “We can write our own, why prepare and agree on specifications when we can moreeasily write the software.” The answer is that these arcane procedures encapsulate good practice that would
improve the likelihood of a successful implementation.

139

Good practice

Steps in process of delivery

IS engineering

False presumption of capability. The ability to write software is relatively easy to attain — in fact is can be very
easy to write even good software for a small application with one or few users. Developing and implementing
systems is much harder and mostly for non-IT reasons. This can be a difficult argument to win prior to the firstfew catastrophes, despite the litany of IS failures.
IS and IT people still bluffing the business. There was a time when all computer departments were left alone by
the business executives — through fear, absence of knowledge and understanding of what went on there, and therelatively minor impact on business. The excuses and many demands of the computer people were not challenged.
Most developed country businesses are now less inclined to be bluffed and insist that decisions have sound basis
and contribute to the bottom-line. The same may not be true in World Bank client countries. The IS people usually
have a high standard of education and may appear to be able to contribute above their experience — they may berelied on too much for advice, especially in their own domain. Executives should be encouraged to prevent the IS
department becoming the experimental workshop for its IS staff. Competitive advantage in the internal group lies
not with knowledge of IT but with knowledge of the organization. Use of specialist suppliers for IT installation,
support and maintenance, and for application software customization and development should be encouraged.
Retention of high caliber personnel. The ability of organizations in World Bank client countries to retain highcaliber IT personnel is low. Good people are very mobile, nationally and internationally. Coupled with a wide arrayof technologies of relatively short life, this reinforces the use of skilled suppliers for technology-related aspects ofthe delivery, support and maintenance of IS. The organization would be better placed retaining personnel that
become custodians of system requirements and system exploitation and personnel that have the skills to manage
suppliers. Beyond strict financial incentives retention may be enhanced by the project giving prestige andopportunities for the learning of specialist skills, international training and future advancement (see also chapter 2,
Human factors).
Encouragement of software package based approaches. An organization in World Bank client countries, recipientof a loan, credit or grant, is unlikely to be in possession of innovative good practice. Therefore, the argument for
bespoke development is weak. The organization should be encouraged to work within existing products providing
either a framework or a complete or near complete software solution. The advantages of this approach over a
bespoke development were described previously. The organization should accommodate change, importing thegood practice encapsulated in the selected software package. The IS is usually part of an institutional development
after all, and therefore, changes in the organization should be expected.
Web sites are not one-time projects. Web sites are usually quite inexpensive and can be rapidly put together but
they need to be backed up by a system that refreshes them. There are many developing country web sites that werebuilt once and are never or rarely kept up to date. Browse the web sites of developing country government
departments, for example in India.
Where to seek further guidanceExternal to the World Bank
R. S. Pressman, Software engineering — a practitioner’s approach, McGraw-Hill, 1997, ISBN: 0070521824
Good practice in developing sustainable information systems/Supporting Guides (esp. SG4, 6, 9, 13), Department for International
Development (U.K.), CCTA 1998

140

Good practice

Steps in process of delivery

IS engineering

Annex A
to Chapter 11
Elements expected in definition phase products

Requirements Specification
The requirements specification should entail:An analysis of the business areas
Descriptions of business problems
Lists and summaries of system requirements.
The contents would be used
To prepare system design options
To prepare the broad design statement
To validate the system design statement (the system design elements can be traced to requirements)
As reference material for system design and more broadly for system understanding.
The specification should be tuned to the business requirement and is largely technology independent. It should define what
the system is to do. It can be expected to contain:
Table 12 Requirements specification contents
Introduction

Purpose of the study and layout of the specification

Summary

Brief outline of salient points

Problem description

Problems in the current system that frustrate the business or operational objectives

Business objectives

Relevant objectives for business ambitions of the product sponsor; product champion; source ofOperational objectives

Objectives for the operating concepts of the user system being describedTechnology objectives

Objectives for the development and implementation environments

System design objectives

funds; and other key business personnel

Functions that when implemented would resolve or effectively lessen the problems defined and,

where possible, quantitative targets for each function

Performance

A list of broadly defined performance characteristics required of the new system

Function chart

A two-dimensional list and categorization of functions that are required from the new system incharacteristics

terms of discrete business functions to be supported with brief details of each

(The level of detail is of some complete business function that can be handled at one time by one
officer. Steps to be completed within each such function are not needed at this time and in any
case are better described by the process models — see below.)Business process models

Merger of strategies, models of the current organizations, and discussions to synthesize a

Generalized entity-

An entity-relationship model at a generalized level needed to satisfy the requirements

Conclusions andSubsequent steps that are necessary and actions prescribed as a result of the SRC

AppendixBusiness process models (existing operation)

relationship model
recommendations

proposal for future operations

141

Good practice

Steps in process of delivery

IS engineering

System Design Options
There are two steps in the selection of a high-level design: preparation of system design options, and debate and selection
leading to documentation of the selected system design.
The system design options should:
Illustrate a range of options available in terms of components that would be used in the IS (whether computerized
or complementary to the computerized procedures), as well as the implications for the technical infrastructure
Illustrate the extent to which and how the option meets the requirements as described in the requirements
Illustrate cost drivers associated with each option
Provide a start point for the refinement and selection of a design approach to underscore the system design.
The contents would be used
To facilitate decisionmaking during the preparation of the system design statement
As reference material for system design and more broadly for system understanding.
The system design options contain a number of models (usually at least two) that briefly outline approaches to the systemdesign. The design options would be revised by review and debate to result in a selected option. The selected option would:
Document the selection decision incorporating variations introduced during the debate of the options
Document the rationale for selection
Frame the broad design statement
Provide reference material for system design and more broadly for system understanding
Illustrate the extent to which and how the selection meets the requirements as described in the requirements
Illustrate cost drivers associated with the selection.
The options should outline how the system is to satisfy the requirements. It could be expected to contain:
Table 13 System design options contents
Introduction

Purpose of the study and layout of the SRC

Summary

List of the options described and a brief outline of salient points of each

Option comparison

List and brief explanation of the advantages of the illustrated options

For each option:
System size and scope

A brief outline of the system anticipated in terms of system size and scope

IS components

A brief outline of the key components (bespoke subsystems, package solutions, customized off-the-shelf products, legacy systems, complementary procedures, external information services, andso on) to be deployed to satisfy the requirements
Users and usage

A brief outline of the anticipated involvement of personnel during its operation, styles of userinterfaces, and styles of operation

Broad technical

Brief representation and description of the key components and issues of the technical

Performance

A list of broadly defined performance characteristics anticipated under the option

architecture

characteristics

architecture of the deployment environment

Delivery strategy

An overview of the approach to deliver the system

Cost overview

An overview of key drivers for the development, acquisition, implementation, and technicalinfrastructure costs in addition to implications for operation

System Design Statement
The system design statement takes the requirements and expands upon it in a manner consistent with selected systemdesign option. It is distinguished from the requirements in that the design describes how the requirements will be met. It

142

Good practice

Steps in process of delivery

IS engineeringdefines the system in broad but sufficient detail to allow it to be confirmed in terms of the completeness andappropriateness of the design. It may or may not be of sufficient detail for commencement of the build steps. Detailed
specification steps may also be required subsequently. It is often of sufficient detail for an acquisition step depending upon
the degree of flexibility of design judged to be appropriate by the purchaser.
An important decision to be documented within the design is the mapping of the functions to a component of theavailable delivery set, for example, complementary procedure, bespoke development, legacy system, customized off-theshelf product such as a business specific package or more standard product such as desktop tools. The design can be
expected to contain:
Table 14 System design statement contents
Introduction and overview
Concepts of operation

To outline the design and its purpose, to repeat system design objectives and to provide an

overview of major features

To briefly describe the modes of operation, for example, the “business day”, numbers of locations,transaction styles (batch, online, intranet-based, web-based, email based, and so on), officeprocessing systems, distributed and centralized operating characteristics, security, and recovery
and fall back requirements, data retention and archiving

To clarify the intended beneficiaries and operators of the system and the mode of operation
To highlight necessary changes that will result in operational procedures

To highlight organizational changes
Human-machine interface

The style of interaction between the new system and its operators

System input

To list and provide a sample of each form of input that must be accommodated by the system andSystem output

To list and at least briefly describe the content, format, and style of each output expected of the

System functions

To list and at least briefly describe all functions to be supported by the system, the manner into briefly describe the form flow

system and the purpose of the output

which supported, and by what component

To list and briefly describe relevant input and output flows, data base usage, formulae andalgorithms
Generalized entity-

To modify and elaborate the entity-relationship model to introduce design constructs

Complementary

To list procedures that complement the automated systems and are necessary for their

Performance

To specify per function or category of function the broad performance parameters which may

Technical infrastructure

To describe the broad technical architecture that would be required to support the system

Start-up activities

To describe briefly implementation activities such as office preparation, procurement

Extensity features

To describe extensions to the system that should be anticipated in the original design

relationship model
procedures

characteristics

introduction into the workflow of the organization

include response time benchmarks, turnaround times, operating peaks, service availability
requirements

requirements, data cleanup requirements, data load requirements, and the schedule of suchactivities

Sizing information

To briefly describe data volumes of abstract entities and approximate size per abstract entity orentity class, transaction volumes, process schedules, growth rates

System installation cost

To provide a preliminary overview of the likely installation costs of the system

System operating cost

To provide a preliminary overview of the likely operating costs of the system

Estimate

estimate

Delivery strategy

An overview of the approach to deliver the system

Delivery costing

A preliminary estimate of the delivery costs

Conclusions andSubsequent steps that are necessary and actions prescribed as a result of the design

recommendations

143

Good practice

Making the computer aided business system operational
Chapter 12“… Nothing is more difficult to handle, more doubtful of success and moredangerous to carry through than initiating change…. The innovator makes enemiesof all who prosper under the old order and receives only lukewarm support from those
who would prosper under the new. Their support is lukewarm from fear ofadversaries, … and because men are generally incredulous of new things until tested
by experience.” (Machiavelli)
What this chapter is about

This chapter provides an overview of the processes involved in placing IS and IT within
the intended business process(es) and making operational the whole computer-aided
business system. This is an area of neglect within many IS and IT projects, where people
prefer to hide in the safe, familiar, contained domain of technology tools and processes.
Structure of this chapter

Introduction

145

Implementation begins at conception

145

Nowhere to hide145

The cornucopia of implementation tasks

146

Where to seek further guidance

148

144

Good practice12.

Steps in process of delivery
Making CABS operational

Making the computer-aided business system operational

Introduction

Implementation applies to all projects. IT systems also need to be “operationalized”. While some of the topics listed in thischapter are perhaps “overcooked” for simpler, small scale (unambitious, low benefit) projects, none of the sound businessplanning, and diligent engineering counts for anything if the desired changes in business processes are not actualized.
The major task of this chapter is to repeat again that an IS is much more than software and hardware, therefore, a term like“computer-aided business system”(or CABS) is more accurate and descriptive. Hardware and software is relatively easy todeliver being routine application of proven often-used tools and techniques by informed and experienced practitioners.
Not at all routine is the new computer-aided business process. It will be unique in space and time, with the hardware andsoftware merely a fragment of a much more complex intervention for change.
Implementation begins at conception

Implementation starts when the project is conceived and carries forward throughout the long dark night of delivery, during
which time patience is tested, interest wanes, credibility diminishes, other initiatives distract, supplement, replace, obstruct,and so on.
Courtesy Machiavelli: “… nothing is more difficult to handle, more doubtful of success and more dangerous to carrythrough than initiating change…. The innovator makes enemies of all who prosper under the old order and receives only
lukewarm support from those who would prosper under the new. Their support is lukewarm from fear of adversaries, …
and because men are generally incredulous of new things until tested by experience.” This applies very well for changes inbusiness processes. Change requires the dedication of a visionary project champion with strong allies.
Also per Machiavelli: “armed prophets conquer while unarmed come to grief”. In the context of ICT in World Bank
projects, this could be interpreted as “be prepared and be able to force issues”. Conceiving the change, designing for it,planning for it, and guaranteeing the necessary resources are the “armor” for successful outcomes.
Implementation tasks begin with sensitizing the organization for change. The right environment is one where theorganization’s constituents become willing to accept change. This may come about through apathy or complacence, aculture of compliance, a belief and trust in the leadership, or the dominance of leadership. In all cases, the key issue isleadership: a grand view that defines, builds, and maintains a purpose that is achieved by influencing other persons toaccomplish goals.
Nowhere to hide

There comes a point in time when approximations and estimations no longer suffice, when consigning a task to a
subsequent stage is not an option since there is no subsequent stage. Implementation is definitely the most intricate part ofthe process. Whereas plans and specifications are at best approximations, and software and hardware may be tested in the
cocoon of the test environment, when the change is implemented in the business environment, when the organization’sclients are brought under the influence of the new business system, there is nowhere to hide. Every little piece of theminutiae of getting the project actually up and running has to be properly put in place.
The process of implementation is interdisciplinary. Implementation will involve senior management, local management,
and personnel, perhaps at remote quasi-autonomous sites, and IT and IS persons — either internal persons or external(supplier) persons, more commonly both. It could involve people from finance and asset management, capital works, andan array of other external suppliers. Each of these various persons and groups have to get involved beyond their own
comfort zones and get things done. The IS and IT people will not readily accept the gap between the theory of the new
system and the reality of the business environment. The business area people will not be equipped either as individuals or

145

Good practice

Steps in process of delivery
Making CABS operational

as business persons for the IS and IT part. Every piece of the minutiae has to be assigned to some group or individual,
regardless of whether it is “below them”, very difficult to comprehend, or seemingly a triviality. The trivialities arenevertheless critical. This myriad of inputs needs to be scheduled, coordinated, executed, and tested. Progress needs to becommunicated to other parties. Somehow in the midst change the business needs to persist — it would be rare luxury to beable to suspend business while the changes are implemented.
It is certain however, that without successful implementation the technology is worthless and the investment wasted.
The cornucopia of implementation tasks

There are many activities with many interrelationships. Many are performed in parallel and have lead times that can bequite short or very long. Several are mechanical, some have dependencies that are uncertain, most will have unexpected
incidents and diversions. The network diagram for an implementation plan can be an unstable. Persons with specialist
knowledge pertaining to each task should be engaged to plan and execute the various tasks.
Some of the tasks, in no particular order or priority:
Continuing program of sensitizing for change: explaining why, what, when, where, by whom, for whom
Implementation policy — such as big bang versus some partial segmentation (for example, by client type, site,
functions, or combinations of these or other segments)
Implementation planning — a blueprint taking into account everything that is to follow
Site and segment specific plans that interpret the blueprint into the specific instance taking into account theidiosyncrasies pertaining to the specific site or segment
Legal changes, legislative changes, regulation, commercial arrangements necessitated by the new methods ofoperation, and continuous monitoring of the regulatory environment for other changes to ensure that the systemremains valid — including public forum to debate new legislation and regulation
Potentially several procurement processes each involving conceptualizing bid lots, determining applicable bid
procedures, site surveys by bidders, site plans for bidders, satisfaction of any regulatory approval processes (suchas for building or other civil works, or for private telecommunications circuits), the actual procurement process,contracting, the attendant works, contract administration, inspection planning or acceptance planning, inspectionor acceptance, sign-off, ongoing services contracts
Civil works — for the IS and for new business procedures — such as for new or refurbished “smart” buildings —with flexible saturation wiring — could be part of some prime contractor arrangements but there are
disadvantages for, say the technology supplier who would have no competitive advantage
Electrical works for connections, power supply, supply regulation which may be part of capital works
Data cabling which may also be conveniently let as capital works to share conduits
Negotiation to permit works if the buildings are leased
For already wired buildings, permissions and rights to use, monitor, and control existing backbone and network
UPS — depending upon approach can be reasonably let with an IT supplier, especially where UPS is online to thecomputer, but if a comprehensive scheme is to be engaged, then more likely with the electrical contractor
Backup power — best left to an electrical contractor as civil works
Physical security systems — procurement of civil works, equipment and services
Environmental monitoring and control — procurement of civil works, equipment and services
WAN supplier — negotiation of circuits, rates, service levels, support and maintenance, allocation of circuits,interconnection with communications equipment, testing circuits and interoperation, ongoing monitoring andcontrol
Web service provider — procurement of services, negotiation for domain names, negotiation of service levels,and so on.
Negotiation for web domain names

146

Good practice

Steps in process of delivery
Making CABS operational

Procurement of technical infrastructure — there are interrelationships:
Such as elements of the technical infrastructure will require a certain operating environment if warranty andsupport and maintenance conditions are to remain valid
The technical infrastructure can usually be engaged relatively rapidly but determines a part of the requirements
for civil works that usually have a long lead-time. Therefore, usually civil works commences ahead of theidentification of the technical infrastructure supplier in the knowledge that some rework or additional work
may be required.
Off-site security — procurement of a service provider
Installation of the technical infrastructure — including the installation and configuration of system software suchas DBMS on each relevant device
Installation and configuration of software application on each relevant device — may also require changes in theconfiguration of the technical infrastructure
Data conversion, a process involving
Inspection and validation of machine readable records to be carried forward into the new system
Mapping between old and new data stores
Development of download and upload software
Execution and verification of data conversion (per site or segment as necessary)
Data take-on, a process involving
Inspection and validation of physical records that are to be carried forward into the new system
Development of software, procedures for the one-time capture of data from physical records, and the process
by which such data is entered and verified of accuracy
Regression plans — plans to be prepared, tested, and used should the switch over to the new systems prove
temporarily or permanently ill-fatedFall-back plans — plans to be prepared and tested for degraded operation should part of a service be unavailable
for some period of time
Resolution of interconnection and interoperation difficulties:
Perhaps off-set to some degree by bundling supplies into parcels under one or more prime contractor
arrangements (but at cost over at least some inferior components)
Nevertheless there is invariably more than one supplier involved, for example, capital works supplier, power
supplier, telecommunications carrier, forms supplier, and so on
Insurance for new tangible assets
Securing financial capital for the many and varied installation tasks
Securing ongoing finances for recurrent costs of operation, for example, power, telecommunications, insurance,
security services, stationery, consumables, spares, software enhancement, specialist consultants, and so on
Establishment of a help desk as a point of contact for users encountering service difficulties with internal orexternal suppliers
Establishment of system administration and support services with internal or external suppliers
Procuring and directing expert consulting
Establishment of service level agreements with internal and external suppliers
Conceptualization and engineering of new workplace procedures and work flows that complement the newautomated procedures and provide and end-to-end service to the organization’s clients
Design of new forms and other stationery, coordination with software development (to ensure fields captured orprinted correctly), and with technical infrastructure procurement (to align characteristics for printers), ordering ofstocks, distribution of stocks, and establishing replenishment regime
Conceptualization and engineering for new operating and administration procedures for the new IS and IT

147

Good practice

Steps in process of delivery
Making CABS operational

Implementation of the benefits monitoring scheme
Change management program covering enunciation of organizational ethics and of the image, presentation, andposture sought by the organization, clarification of the organization’s expectations of the behavior and norms of
its constituents, establishing reward and disciplinary regimes, and so on
Organizational redesign — new and revised roles, new complements in each role, elimination of redundant roles,
redeployment strategy and programs for staff — new job descriptions; new supervisory positions; new assessment
profiles; IS management positions; new operating hours, such as after hours operation for end of day procedures,back up, preventative maintenance; new and revised salary and conditions
Preparation, publication, and distribution of educational materials in sufficient quantity
Internal education programs concerning the new systems
Public education campaign concerning the new systems
Preparation and publication of sufficient quantity of training materials
Establishment of training facilities and training services, training trainers
Specific training — for the elements to be introduced: new business procedures, new application systems, system
operation, system administration, operation of equipment, and so on
Planning the move from existing to new procedures
Actual implementation — getting everything in place by the day before it gets turned on
Pilot site monitoring with feedback for revised business procedures, IS, IT, implementation methods
Roll-out of systems to all sites and for all segments of the new systems
Ensuring an environment for the ongoing operation, support, and maintenance of the new procedures, systems,
and technology
Post implementation reviews in preparation for the next change!
Where to seek further guidanceExternal to the World Bank
Good practice in developing sustainable information systems / Supporting Guides (esp. SG5, 9), Department for International
Development (U.K.), CCTA 1998

148