A Guide To IFMIS Project Implementation v1

A Guide to IFMIS Project Implementation
Harish R Bhatt Soft-Tech Consultants Ltd. Page | 1

Table of Contents
1 Preface ..........................................................................................................................................................5
2 Introduction to IFMIS ...................................................................................................................................6
2.1 Challenges.............................................................................................................................................6
2.2 Objectives of IFMIS ...............................................................................................................................6
2.3 Functional Areas to Consider for IFMIS Implementation .....................................................................9
2.4 Why IFMIS? .........................................................................................................................................10
3 Components of IFMIS Project .....................................................................................................................12
3.1 Application Solution ...........................................................................................................................12
3.1.1 Package Solutions .......................................................................................................................12
3.1.2 In-house Development ...............................................................................................................13
3.1.3 Potential Solutions......................................................................................................................14
3.1.4 Licensing .....................................................................................................................................16
3.1.5 Updates & upgrades ...................................................................................................................17
3.1.6 Support & Maintenance .............................................................................................................18
3.2 Infrastructure......................................................................................................................................19
3.2.1 Determinants for Infrastructure Design .....................................................................................19
3.2.2 Centralized vs. Decentralized Implementation ..........................................................................21
3.2.3 Primary and Backup Data Centers ..............................................................................................22
3.2.4 Wide Area Networks (WAN) .......................................................................................................23
3.2.5 Local Area Networks (LAN) .........................................................................................................25
3.2.6 Remote Site Systems ..................................................................................................................25
3.2.7 Security & Access Control ...........................................................................................................25
3.2.8 Business continuity .....................................................................................................................27
3.2.9 Hardware Obsolescence .............................................................................................................28
3.2.10 Support & Maintenance .............................................................................................................28
3.2.11 Top of the Range versus Appropriate Technology .....................................................................29
3.2.12 Data Center Hosting and Software as a Service .........................................................................29
3.3 Capacity Building ................................................................................................................................31
3.3.1 Support Team .............................................................................................................................31
3.3.2 End User Training........................................................................................................................34
3.3.3 Management Training ................................................................................................................34
3.3.4 Auditors Training ........................................................................................................................35
3.3.5 Skills Transfer ..............................................................................................................................35
3.3.6 Assessment .................................................................................................................................35
3.3.7 Retention ....................................................................................................................................36
3.3.8 Issues in capacity building ..........................................................................................................37
3.4 Change Management .........................................................................................................................38
3.4.1 Stakeholders ...............................................................................................................................38
3.4.2 Impact Assessment .....................................................................................................................41

3.4.3 Risk Assessment and Management ............................................................................................42

3.4.4 Communications .........................................................................................................................43
3.4.5 Transition Arrangements ............................................................................................................44
3.4.6 Benefit Realization ......................................................................................................................45
3.4.7 Organizational Restructuring ......................................................................................................45
3.4.8 Sustainability ..............................................................................................................................46
3.4.9 Impact of other PFM initiatives ..................................................................................................46
3.4.10 Consultants and Dependencies ..................................................................................................47
3.5 Quality Assurance ...............................................................................................................................48
3.5.1 Methods & Reporting .................................................................................................................48
3.5.2 Standards for Deliverables .........................................................................................................50
3.5.3 QA Plan .......................................................................................................................................52
3.6 Human Resources ...............................................................................................................................53
3.6.1 Competency assessment ............................................................................................................53
3.6.2 Meeting competency requirements ...........................................................................................53
3.6.3 Key issues with HR ......................................................................................................................54
3.7 Project Management ..........................................................................................................................57
3.7.1 Project Steering Committee (PSC) ..............................................................................................57
3.7.2 Project Management Team (PMT) .............................................................................................58
3.7.3 Project Manager (PM) ................................................................................................................58
3.7.4 Application Team ........................................................................................................................59
3.7.5 Core Technical Team ..................................................................................................................59
3.7.6 Workgroups ................................................................................................................................59
3.7.7 Project Methodology ..................................................................................................................60
3.7.8 Project Progress Control .............................................................................................................60
3.7.9 Key issues with project management.........................................................................................61
3.8 Funding ...............................................................................................................................................62
3.8.1 Project Planning & Procurement Stage ......................................................................................62
3.8.2 Project Implementation Stage ....................................................................................................62
3.8.3 Change Orders ............................................................................................................................63
3.8.4 Post Implementation Stage ........................................................................................................63
4 IFMIS Project Process .................................................................................................................................64
4.1 Planning and Requirements Specification ..........................................................................................64
4.1.1 Vision, Objectives and Strategies ...............................................................................................64
4.1.2 Functional requirements ............................................................................................................65
4.1.3 Organizational scope ..................................................................................................................65
4.1.4 Determinants for Infrastructure Design .....................................................................................66
4.1.5 Timeframes .................................................................................................................................67
4.1.6 Expected Outcomes ....................................................................................................................68
4.1.7 Phasing........................................................................................................................................68
4.1.8 Funding .......................................................................................................................................70

4.1.9 Key issues in Planning and Requirements Specifications ...........................................................70

4.2 Procurement .......................................................................................................................................71
4.2.1 Tender Compilation ....................................................................................................................71
4.2.2 Bidder Briefing ............................................................................................................................72
4.2.3 Evaluation ...................................................................................................................................72
4.2.4 Negotiations ...............................................................................................................................73
4.2.5 Contracts.....................................................................................................................................74
4.2.6 Key issues in Procurement Process ............................................................................................74
4.3 Implementation Preparation ..............................................................................................................75
4.3.1 Project Management ..................................................................................................................75
4.3.2 Requirements Validation ............................................................................................................77
4.3.3 Preparation of Various Solution Build and Operational Documents..........................................78
4.3.4 Data Requirements .....................................................................................................................82
4.3.5 Interfaces to Other Systems .......................................................................................................82
4.3.6 Solution Build..............................................................................................................................83
4.3.7 Infrastructure Setup ...................................................................................................................83
4.3.8 Acceptance Testing .....................................................................................................................86
4.4 Implementation ..................................................................................................................................88
4.4.1 Systems Configuration ................................................................................................................88
4.4.2 Data Take On / Migration ...........................................................................................................88
4.4.3 System Cut-Over .........................................................................................................................91
4.4.4 Parallel runs ................................................................................................................................91
4.4.5 Report Production ......................................................................................................................92
4.4.6 Key Stage Review ........................................................................................................................93
4.5 Post Implementation Support ............................................................................................................93
4.5.1 Transfer of Key Roles to Client Teams ........................................................................................94
4.5.2 Infrastructure Support ................................................................................................................94
4.5.3 Application Support ....................................................................................................................97
4.5.4 On-Going Training.......................................................................................................................98
4.6 Project Total Cost of Ownership .......................................................................................................100
4.6.1 Key Cost Components...............................................................................................................100
4.6.2 Computing Total Cost of Ownership ........................................................................................102
4.6.3 Key Issues in Project Costing ....................................................................................................102
4.7 Audit .................................................................................................................................................103
4.7.1 Audit of Computer Based Systems ...........................................................................................103
4.7.2 Proactive Audit .........................................................................................................................104
5 Legal Framework - Guiding Principles for the Formulation of an Act for the Management of Public
Finances ............................................................................................................................................................105

1 Preface
The objective of this document is to present general guidelines on implementation of an IFMIS Project.
Each topics covered in the document would individually merit multiples of books to exhaustively cover
all aspects. The document therefore aims to present an overview of components of an IFMIS project,
present pertinent aspects of each component and discuss the IFMIS project implementation process.
It is expected that the document will help readers better understand the scope of an IFMIS project and
enable them to relate to the various project activities. It may also be useful as an input to the IFMIS
project planning process.
The information presented is based on experience of implementing IFMIS systems over the past 11
years for various governments in Africa.

2 Introduction to IFMIS
The term IFMIS (Integrated Financial Management Information System) is generally used to describe a
combination of software, hardware and communication technologies implemented to enable operation
and management of key areas of government operations namely budget formulation and budget
execution.
The budget formulation process occurs at both macro level (policy, planning and over all resource plans)
and the micro level (program formulation, detailed planning and detailed resource allocation). The
process takes place under a budget framework defined and agreed upon based on the overall policies
and targets of the government.
Budget execution on the other hand focuses on implementing the budget and tracking performance. A
major aspect of budget execution is the allocation, disbursement and tracking of financial resources
governed by a strict set of regulations and compliance requirements and is subject to both internal and
external oversight. Other aspects of budget execution entail tracking of non-financial aspects, mostly
related to outcomes of various planned activities.
2.1 Challenges
Budget formulation and execution involve a large number of people across various organizational
structures in geographically dispersed locations processing large volumes of data under fixed
timeframe. All this is carried out under a set of frameworks, guidelines / regulations and operational
procedures which invariably change with time based on government policies, introduction of new
requirements, cessation of certain requirements or in response to problems and issues encountered.
From an operational perspective, the key challenges faced by governments in budget formulation and
budget execution can be summarized as below:
• Communicating and ensuring compliance to policies, guidelines / regulations and operational

procedures;
• Managing large volumes of data;
• Lack of skilled manpower;
• Problems with overall management of critical processes;
2.2 Objectives of IFMIS
An IFMIS system focuses on alleviating challenges from an operational perspective. It is not and
cannot be a solution for every problem associated with budget formulation or execution. The
implementation strategies of an IFMIS as a tool have to therefore be based on objectives which can
assist governments in overcoming operational challenges. The table below illustrates some objectives,
strategies and challenges addressed:

No Objective Strategy Challenge Addressed

1. Ensure compliance to regulations Build business process rules (to Poor compliance to
and operational procedures the extent possible) into IFMIS regulations and operational
that enforce compliance. procedures
Enable reporting of non- Recognition of non-

compliance on a timely basis. compliance early enough to
enable rapid action
(proactive rather than
reactive)
Track all activities to individuals Identification of individuals
responsible for certain
activities
Automate processes to the Reduce workload necessary
extent possible to ensure compliance
Lack of uniformity in
operational procedures
2. Move operational focus from Automate processes to the Reduce need for manual
“processing data and documents” extent possible processing of data and
to “interpreting information and documents
management”
Inability to produce a wide
range of operational and
statutory reports
Enable rapid access to data Poor access data stored in

diverse locations
Enable processing of data to Effort required to collate
provide meaningful information data and convert it into
and hence assist in evaluation information in a timely
and decision making in a timely manner
manner
3. Manage data Securely collect, store and Poor access to data located
provide access to all data and in diverse locations.
documents in a centralized
manner. Movement of documents
across various locations
Loss of data and documents
Manipulation of data and

documents in process
leading to fraud
Inability to audit due to loss

of data or documents
4. Provide staff with tools to Train and enable users to use Workload associated with
improve performance the IFMIS and associated tools manual processing of data
and documents

No Objective Strategy Challenge Addressed
Poor morale associated with

high workloads
Lack of skills in managing

processes
5. Improve Management of Enable production of Inability to produce a wide

processes and resources operational, analytical and range of operational,
statutory reports analytical and statutory
reports
6. Improve confidence of all Provide timely information to Inability to provide

stakeholders in government stakeholders information to stakeholders
operations
An accountant reading this document would be tempted to think of objectives differently e.g. ability
to exercise control on expenditure, ensure revenues are accounted for, be able to produce statutory
reports, ensure bank accounts are reconciled, enable timely production of final accounts etc. These
requirements are technically covered under compliance to regulations and operational procedures.
A manager would view objectives differently in terms of having an overall view of operations but in a
summary form with key result indicators or performance indicators. These are represented in terms of
compliance, ability to manage data, ability to produce operational & analytical reports etc.
An auditor would view objectives as adherence to regulations, ability to access data and documents
for review, ability to determine value for money etc. These are covered under compliance, ability to
manage & access data and ability to compile analytical reports.
Other stakeholders similarly would view objectives from the requirements of their roles and
responsibilities but all of these would fall under the major categories of objectives defined in the
table.
The objectives and strategies aim at addressing the key “pain points” (or problems) faced by most
governments from an operational perspective. It must however be understood that there are other
aspects that need to be considered in order to realize the benefits of implementing an IFMIS. Some of
these aspects are as outlined below:
• The political and administrative will to change. Implementing an IFMIS brings about
profound changes to the manner in which the government operates and in the absence of
strong desire for change backed by political and administrative will, a IFMIS system
implementation in unlikely to succeed or lead to realization of envisaged benefits.
• Employing, developing and retaining personnel with the requisite domain knowledge i.e.
budget planners, accountants, procurement specialists, technology specialists etc. The
IFMIS system as has been pointed out is a tool that tremendously assists in improving
operational capabilities but cannot substitute for requisite expertise essential for
management and effective utilization.
• Subscribing to best practices in planning and financial management. Implementing an IFMIS

system to merely duplicate current practices is counterproductive as it inherits all existing
problems and adds little value at a high cost. The IFMIS project implementation should be

seen as an opportunity to reconsider all practices with a view to adopting best practices
around the world. These could be in approaches to planning using modern models to
manner of accounting and reporting of financial transactions.
• Harmonizing initiatives. Most governments have a multitude of reform programs in process

at any given time and failure to harmonize at least related programs is likely to result in a
multitude of systems that eventually fail to deliver desired results while incurring a huge
cost. In many instances, multiple initiatives have the negative effect of derailing an IFMIS
project due to changes and delays. An IFMIS implementation should be viewed as an
opportunity to reconsider deployment of systems in a manner that will be complimentary
and must be thought of at the planning rather than the implementation stage.
• Ensuring adequate funding for an IFMIS implementation. It is essential to consider the total
cost of ownership (TCO) of the project on a realistic basis and then make provisions for
funding over a period of 5 - 7 years (at least). An IFMIS project can be implemented just to
flounder and fail in a short span of time due to funding constraints. There is a general
concern while planning an IFMIS project in relation to the costs but what helps in
rationalizing the cost of an IFMIS project is a comparison with the costs associated with
poor compliance, misappropriations, poor management of resources, loss of stakeholder
confidence etc.
2.3 Functional Areas to Consider for IFMIS Implementation
The key areas that can be targeted for coverage under an IFMIS Project can be listed as follows:
• Budget formulation at the macro level. The key areas for consideration are the ability to
define overall objectives based on policies and programs and distribute resources based on
the approximate requirements and overall resource envelope. The process is iterative with
continuous negotiation requiring numerous trials and requires capability to record data and
manipulate the same to arrive at an optimum outcome reducing the need for extensive
manual work associated with such an exercise.
• Budget formulation at the micro level. This requires the ability to allow allocation of
assigned resource ceiling to various levels e.g. cost center, program, sub-programs,
objectives, activities. The process should lead to the production of the budget document for
legislative approval. Subsequently it is equally critical to be able to conduct budget
performance monitoring.
• Allocation of Funds. A critical process allows for allocation of funds based on the final
budget to various entities (authority to spend) and needs the ability to track all allocations
& sub-allocations. This also forms the basis for commitment control and should facilitate
reallocation and withdrawal of funds (if required).
• Procurement. This covers all areas from requisitions, request for quotations, purchase order
processing, contract administration, receiving of goods & services, recording of supplier
invoices and associated authorizing procedures. Commitment control forms a major
component of this process ensuring compliance to the budget.
• Revenue Accounting. Provide for billing (invoicing) and recording of receipts for tax, non-tax
and any other revenue including banking of the revenue and reconciliation.

• Payment Accounting. The area focuses on processing of procurement and non-procurement

payments (salary, debt etc.) issuing cheques and bank transfer instructions.
• Bank & Cash Management. This entails managing various bank accounts (in multiple
currencies) and reconciliation capabilities. The tasks also include cash flow planning based
on income & expenditure budget, revenues, commitments, planned procurement etc.
• Inventory Management. This requires tracking of inventory items from procurement stage
to the issue stage in a number of warehouses and storage locations.
• Asset Management. Assets are constantly being procured by governments and it is essential
to track assets from procurement stage and able to carry out asset management functions
such as allocation, changes to assets, movements and disposal including all accounting for
the same.
• Asset Maintenance. Typically asset maintenance management is essential for vehicles,

structures, computer systems etc. There is a need to plan and execute maintenance and
track costs and make decisions such as when to retire high maintenance assets.
• Sourcing. This is different from procurement as it focuses on the procedure for sourcing of
goods and services. Typical tasks include tendering, tender publication, receipt of bids,
evaluation, award and publication of outcomes.
• Payroll. Human resource costs form a major component of government expenditure and
needs to be well managed. Most governments have large number of employees and payroll
processing poses a major challenge due to the need to regularly update data and process
payroll on a tight fixed schedule.
• Public Debt Management. Public debt forms a substantial component of government’s

financial operations and requires effective management of all public debt, terms &
conditions and repayment plans.
• Human Resource Management. This deals with the entire human resource process like
recruitment, employment, appraisal, promotions, disciplinary actions, transfers, leave
administration, competency assessment, succession planning, capacity planning and
capacity building etc.
2.4 Why IFMIS?
Outlined in section 2.1 and 2.2 are the key operational challenges faced by governments and the
possible objectives & strategies of an IFMIS.
It is essential to understand that an IFMIS is a tool and the central objective of investing in a solution is
to overcome the operational challenges. Many IFMIS procurement procedures focus more on the
acquisition of technology rather than on the acquisition of a solution to address challenges and end up
implementing technology without realizing the benefits or only partially realizing the benefits. The
issue will be covered later under Change Management but it is essential to outline the key objectives
and strategies for implementing an IFMIS and focus project implementation around the same.
An IFMIS solution properly implemented can greatly alleviate operational problems such as:

• lack of compliance to procedures by automating majority of processes;

• poor access to information by securely storing and providing instant access to data;
• lack of operational, statutory and analytical information by providing means to produce a
wide range of instant reports;
• poor transparency by providing access to information in a timely manner and an ability to
make information accessible to a wide range of stakeholders;
• difficulty in coordinating operations in geographically dispersed areas by being able to
operate centralized systems over networks;
• poor control by enforcing business rules;
• lack of consistency in operational procedures by ensuring uniformity of operations;
• inability to handle large volume of data to process by storing and automatically processing
data;
• increasing personnel which does not result in corresponding gains in efficiency of
effectiveness by automating most procedures and reducing manual intervention;
• limited availability of suitably qualified personnel by automating most procedures and
reducing manual intervention and the need to a large number of personnel;

3 Components of IFMIS Project

3.1 Application Solution
The term application solution refers to the Application Software. This is generally a suite of program
modules designed and developed to facilitate operations for the functional areas identified in section
2.3.
In the following sections is a brief overview of aspects to be considered in relation to Application

Software:
3.1.1 Package Solutions
A number of products exist in the market and the choice of which system to implement depends on
how closely the solution meets the objectives and strategies of the government. A representative list
of vendors with solutions in the public sector includes Epicor®, SAP®, Oracle® etc.
Package Solutions offer the following key benefits:
• They are developed by a team of experienced domain experts, analysts and developers with
input from a wide range of customers. The solutions are developed by teams of hundreds of
experts over many years.
• Offer an extensive set of features and functionality to meet most requirements. The features
and functionalities are developed over many years by dedicated teams of developers.
• The solutions are tried and tested (have been successfully implemented before) which
reduces implementation risks;
• The solution are well documented in terms of user guides, online help, system
documentation, implementation guides etc.
• There are specific implementation methodologies which are continuously improved based on
executed projects and feedback from various implementations;
• The training programs for the solutions are well developed and offer key benefits during
implementation in terms of building skills. All solution providers offer certification exams that
enable government staff to measure capabilities.
• The solutions are regularly updated and upgraded based on developments in the domain area
and advances in technology;
• The solutions are supported by many organizations and provide access to a number of
qualified personnel;
• The solution providers provide warranty and support services;
Some perceived disadvantages of packaged solutions are:
• They are expensive. It is important to note that governments have an option to select from a
wide range of solutions from low end limited functionality options to extensively

customizable high end options. The choice would depend on objectives, strategies,
functional requirements and ability to fund the project.
• They require governments to change their operational procedures. In most instances the
systems are configurable but more critically they are built on best practices and as pointed
out earlier, an IFMIS project should be used as an opportunity to re-evaluate all operations
and adapt best practice standards as long as they meet the overall objectives and strategic
requirements.
• They are difficult to implement. Again there is a wide range of choices from the simple to
complex. In many cases government procurement exercises tend to over specify
requirements in bids without proper consideration towards actual requirements or ability to
implement. This is common when a consultant is asked to compile requirements and they
just copy from some document that was used to procure such systems without conducting
in-depth analysis of institutional reality. The end result is, suppliers bid for complex systems
which then fail during implementation.
3.1.2 In-house Development

An alternative to procurement of packaged solutions, is to develop solutions in-house i.e. by
employing software developers and writing software solutions based on requirements.
This approach was common in the 60’s and 70’s when suitable solutions were not available in the
market and organizations resorted to developing their own solutions. It must be noted that software
development is not a core competency of governments and to be able to develop systems to the
same standards as products available in the market, it would require employing a large team of
domain experts, analysts and developers who would have to work for many years on developing the
systems. There are clear challenges and risks in doing this considering the costs, availability of skilled
manpower and above all the ability to retain highly skilled manpower over a long term.
In most instances where in-house development is still pursued, the teams tend to be very small and
continuity is highly questionable. In many cases there is realization that the path is not an
appropriate one but change is resisted either due to the costs already incurred or partly due to
personal interests of those involved in such development efforts.
Since in-house development teams tend to be small, they and their output suffers from the following
problems:
• There is limited domain, design and development knowledge within the team and the solution
tends to focus on duplicating existing processes rather than modeling the solution on industry
best practices;
• The solution is not tried or tested and requires extensive trials to fully test and implement;
• The features and functionality tend to be limited with little or no integration between
modules;
• There generally is very limited or no documentation at all and in many cases this causes
excessive dependence on the small team; There are situations in some governments when
there is only one person who can understand and operate an in-house developed system;
• There generally is little effort in developing the required implementation methodology and
the systems generally don’t get deployed beyond a small central implementation;

• Training programs are not well developed and lack well developed training manuals making it
difficult to develop skills across the government;
• There is no warranty on the system and support is limited and can only be provided by the
development team;
• The systems are rarely updated or upgraded primarily due to the extensive effort required for
the same. It is also common to find that software maintenance can only be carried out by the
team that developed it because the software development does not follow standards and is
poorly documented;
• Initially the systems meet the requirements (duplicating existing processes). However
requirements change and developers are required to modify the solution to meet the ever
changing needs. Over a period of time the constant change in the developed system
destabilizes the system, thereby requiring redevelopment;
Some perceived benefits of in-house development are:
• It results in a solution that meets requirements, but in most instances it just duplicates
existing processes with all its deficiencies;
• It costs less then packaged solution. This is an illusion as the products are not comparable to
tried and tested packaged solutions nor are the full costs and risks to the organization
properly computed.
In the present date and time the option of in-house development should only be considered if the
requirements can absolutely not be met by commercially available solutions. It would be important
to seriously evaluate such a requirement as it is increasingly unlikely to exist.
From the cost perspective it is important to note that governments have an option to select from a
wide range of solutions from low end limited functionality options to extensively customizable high
end solutions. The choice would depend on objectives, strategies, functional requirements and
ability to fund the project.
3.1.3 Potential Solutions
The functional areas to target for an IFMIS implementation are outlined in section 2.3. Below is a list
of potential solutions for the target functional areas. The module names and facilities are generic
and could vary from product to product. Depending on the product chosen the number of features
and functionality would vary. Low end solutions would have limited capabilities but lower cost and
simpler to implement, whereas high end solutions would be extensively customizable, offer
extensive features & functionalities and would require extended timeframe to implement and would
obviously cost more.
• Budget Module: The systems available can be used to define overall objectives based on
policies and programs and distribute resources based on the approximate requirements and
overall resource envelope. The process is iterative with continuous negotiation requiring
numerous trials. The tools make it easier to record data and manipulate the same to arrive at an
optimum outcome reducing the need for extensive manual work associated with such an
exercise.

The Budget Module allows allocation of assigned resource ceiling to various levels e.g. cost
center, program, sub-programs, objectives, activities. The process leads to the production of the
budget document for legislative approval. Subsequently the system also allows budget
performance monitoring with information from the budget execution sub-systems.
• General Ledger Module: Forms the base of the systems and provides for definition of
organizational structure (and hence operational and reporting structures), chart of accounts
and is the repository for all transactions for production of a wide range of operational and
statutory reports by organizational unit as well as at the entire government level.
• Fund Management Module: The module allows for processing of fund allocation based on the
final budget to various entities (authority to spend) and track all allocations & sub-allocations.
This also forms the basis for commitment control. Facilities exist for reallocation and withdrawal
of funds.
• Procurement Module: This covers all areas from requisitions, request for quotations, purchase
order processing, contract administration, receiving of goods & services, recording of supplier
invoices and associated authorizing procedures. The system also facilitates input and storage of
all documents associated with the procurement process. Commitment control forms a major
component of this process ensuring compliance to the budget. Most processes are automated
reducing manual intervention and ensuring compliance to procurement procedures.
• Revenue Accounting Module: The system enables billing (invoicing) and recording of receipts
for tax, non-tax and any other revenue including banking of the revenue and reconciliation. The
system also facilitates input and storage of all documents associated with the revenue process.
Most processes are automated reducing manual intervention and ensuring compliance to
revenue accounting procedures.
• Payment Accounting Module: The system enables processing of procurement and non-
procurement payments (salary, debt etc.) including printing of cheques or automatic payment
transfer to banks as required. The system also facilitates input and storage of all documents
associated with the payment process. Commitment control forms a major component of this
process ensuring compliance to the budget. Most processes are automated reducing manual
intervention and ensuring compliance to payment accounting procedures.
• Bank & Cash Management Module: The focus is on managing various bank accounts (in
multiple currencies) and tracking all transactions with full reconciliation capabilities which can
be automated subject to banks providing requisite data. The cash management function
enables cash flow planning based on income & expenditure budget, revenues, commitments,
planned procurement etc.
• Inventory Management Module: The system enables tracking of inventory items from
procurement stage to the issue stage supporting any number of warehouses and storage
locations. There is support for bar-coding to reduce manual processes while receiving and
issuing. It enables tracking of consumption and also valuation of inventory (essential for full
accrual accounting).
• Asset Management Module: The system facilitates tracking of assets from procurement stage
and enables all asset management functions such as allocation, changes to assets, movements
and disposal. There is full support for all accounting procedures associated with asset
management. Assets can also be bar-coded to facilitate easy management.

• Asset Maintenance Module: The capability allows defining requirements and capturing of all
asset maintenance costs. Typically maintenance management is used for vehicles, structures,
computer systems etc. There is support for elaborate planning and execution of maintenance
tracking all costs and making decisions such as when to retire high maintenance assets.
• Sourcing Module: This is different from procurement as it focuses on the procedure for
sourcing of goods and services. Facilities include tender definition, tender publication, receipt of
bids, evaluation, award and publication of outcomes. All of this is done in a transparent manner
over web based systems allowing registered suppliers to access the system over the internet.
Confirmed contracts then pass on to the procurement system for further processing.
• Cost Accounting Module: A major system integrated into an IFMIS system is the cost
accounting capability that allows most costs to be apportioned to cost centers, programs etc.
which allows elaborate cost accounting analysis. The process is automated once defined.
• Payroll Module: Human resource costs form a major component and are managed in the
payroll system which manages details of personnel pay & deductions elements including
pension related processes. A elaborate organization structure management facility allows
grouping personnel and analysis of costs across the entire organization structure. Most
processes are automated reducing manual intervention and ensuring compliance to payroll
procedures.
• Public Debt Management Module: Public debt forms a substantial component of a

governments financial operations and the system allows recording of all public debt, terms &
conditions and repayment plans. It interfaces directly with the financial system for payment
processing.
• Human Resource Management Module: This deals with the entire human resource process like
recruitment, employment, appraisal, promotions, disciplinary actions, transfers, leave
administration, competency assessment, succession planning, capacity planning and capacity
building etc. The system allows storage of all documents associated with employees and allows
personnel to manage some of their data by themselves through self service capabilities. A
comprehensive workflow control ensures compliance with all Human Resource Management
procedures.
3.1.4 Licensing
There are many approaches to licensing of software solutions and below are some of the common
key approaches to be found in the market:
(a) Concurrent User Pricing: In this case software modules are licensed on the basis of number of
users who can use the software “concurrently” i.e. at the same time. It means that a
government might have 100 potential users but only 50 would be using the software at anyone
given time. In this case 50 licenses would be adequate and serve the needs. Normally the license
allows all users to use all the facilities of the software.
(b) Named User Pricing: Software in this case is licensed by the total numbers of users expected to
use the software irrespective of whether usage is concurrent or not. Again if a government has
100 users, then licenses need to be procured for all 100 users. There may be variations in cost
per user between users who operate the system (i.e. enter and process transactions) and report
only users (users who only access the system to view or print information).

(c) Processors Based Licenses: In this category license costs are based on the number of processors
in a server (computer hardware) being used. The cost would vary based on type of hardware,
number of processors, operating speeds etc. The higher the server capacity, the greater the
costs.
(d) Per Employee Licenses: The approach is more commonly used in licensing of payroll and human
resource software. The costs of various modules are computed on the basis of number of
employees required to be supported. There is generally no limit on the number of users who will
then operate the software.
(e) Per Computer License: In a network, there can be many personal computers / terminals that will
use / access software. The software is then licensed by number of personal computers /
terminals on the network and limits access to the licensed number of computers. Different users
can use the personal computers or terminals. It should be noted that under this licensing basis,
the software can either be installed on a central server and accessed by personal computers /
terminals or can be installed on individual personal computers.
3.1.5 Updates & upgrades
All software products are offered with two distinct services. These are updates and upgrades.
3.1.5.1 Updates
The term updates is used for provision, by authors of software, of regular software “patches”.
These generally tend to focus on resolution of problems (bugs) in the software, improvements in
performance and minor changes to functionality. In case of security software this would entail
details of new viruses or other threats to security that have been identified and need to be
updated for protection.
Updates are issued regularly (weekly for anti-virus software) to quarterly for many application
systems. Implementation of such updates is normally carried out in the background without users
becoming aware of any changes and do not require any changes in operational procedures.
3.1.5.2 Upgrades
The term upgrades is used to describe provision, by authors of the software, of new software that
would replace the old and would contain major changes to functionality, additional functionality,
major improvements in performance or major changes in technology employed. Upgrades cannot
be applied without first conducting an impact assessment. An impact assessment would entail:
• review of any customizations and how the upgrade will affect the same;
• impact on operations due to changes in functionality;
• need for changes in operations;
• need for retraining of staff on new functionality or user interface;
• review of documentation such as user guides, operations manuals;
• changes in data requirements and migration of data from the old system;

• need to upgrade operating system and database software;

• need to upgrade hardware and network;
• potential downtime (non availability of systems for operations);
• cost of all changes;
• potential benefits;
• time required to carry out an upgrade;
A decision then needs to be made whether the benefits from upgrade justify the investment and
time. It must be understood that an upgrade will resemble a project in its own right and will need
to be managed as such.
3.1.6 Support & Maintenance

The term maintenance is used to describe the provision, by the supplier, of updates and upgrades
subject to payment of an annual maintenance fee. The fee is generally payable annually from the
date of purchase of the software and entitles the client to receive regular updates and upgrades.
In addition to the provision of updates and upgrades, maintenance services (support) may include
the following services:
• Remote Assistance: This is technical support provided by the supplier over telephone, email,
fax or by remotely logging into a client’s system. The service has the following general
parameters:
o Hours of service – working hours only, including holidays, 24 x 7 etc.;
o Response Time – how soon is the supplier required to respond to a issue from the
time the problem is reported;
o Resolution Time – how soon should a issue be “resolved”;
o Criticality – segregating problems into degree of criticality and how they should be
managed;
• On-Site Assistance: This refers to assistance provided at site by a technical person from the
supplier. The parameters would be similar to those of Remote Assistance.
Software maintenance is not well understood and often neglected in many implementations. In the
event a client chooses not to pay for maintenance, all updates are charged for as required and
upgrades amount to buying the software all over again at a huge cost.
It is essential that maintenance must be included in IFMIS project RFQ and contract over a period of
not less than 5 - 7 years.

3.2 Infrastructure
Infrastructure refers to the hardware, network and system software required to implement an
application solution. It also includes solutions to overcome problems associated with poor power
supply and frequent power outages.
3.2.1 Determinants for Infrastructure Design
The design and provision of infrastructure depends on the following key aspects:
• Application Software and Modules to be implemented. This assists in determining a number

of key aspects such as:
o Transaction volumes (directly related to target areas to be covered based on

modules to be implemented);
o Deployment Approach – this will depend on supported technologies such as client –

server model, web based model, terminal emulation model etc.
o Processing requirements – low end systems have lower processing requirements

compared to large high end complex systems which have very high processing
overheads;
o Databases to be supported – which will assist in determining processing and storage

requirements;
o Features and Facilities – need to be closely studied especially when implementing

aspects that target extensive automation. Examples are use of MICR cheque
printing, bar code printers & readers for inventory / asset management, use of
biometric identification systems, automatic interface to banks etc.
• Number of Institutions – e.g. number of ministries, departments, regional offices etc. to be

catered for in the project This will have an impact on transaction volumes and number of
users;
• Geographical Location of Institutions – location of each site, potential number of users and
anticipated volume of data flow at each site will determine the manner in which the sites
need to be connected to a central site where the main systems will be located. It is
important to note that it may even transpire that sites cannot be connected due to
limitations of available connectivity options and hence alternative implementations models
may need to be contemplated;
• Transaction Volumes – the term generally applies to all transactions to be processed on the
system (inputs and outputs). Examples are numbers of requisitions, purchase orders,
payments, cheques, receipts, funds transfers, inventory issues & receipts, asset transactions,
number of personnel etc. Transaction volumes need to be specified in relation to time e.g.
daily, weekly, monthly and annually. The key infrastructure aspects determined based on
transaction volumes are:

o Processing Capability - should be able to handle the number of transactions at any

one time and provide users with a reasonable response time;
o Online Storage Capability – should able to store data and documents online for a
defined period of time (7 – 10 years);
o Offline Storage Capability – should be able to handle storage of data and documents
outside the system on backup media for long term storage;
o Printing Capability – should be able to cater for printing of various documents

generated by the system including various reports;
o Scanning Capability – should enable scanning of documents for processing and

storage on the system;
o Number of Users – required to handle the processing of various transactions. It

should be noted that this is not the only criteria and many users will also be added
based on roles & responsibilities e.g. managers, authorizing officers, senior directors
etc.
• Number of users – this assists in determining the following important infrastructure

components:
o Number of workstations;
o Number of printers;
o Number scanners;
o Number of various software licenses (concurrent / named users etc.);
o Furniture requirements (if provided for);
• Details of Existing Infrastructure (hardware, network, software, power backup) - would

essentially assist in establishing whether any components can be used as they are, through
upgrades or would need replacement. It also assists in establishing integration requirements
with the proposed system.
• Power – Infrastructure requires power to operate and the availability of stable power supply
is critical. Evaluation of power situation is essential to establish interventions necessary. This
would be in the form of:
o Uninterruptible power supply units to safeguard against transient outages, under /

over voltages etc.
o Generators or invertors (with battery banks) to safeguard against extended power

outages;
o Solar power for remote sites with limited requirements;
• Planned or Anticipated Growth – would apply to additional applications, institutions,

transaction volumes, number of users etc.

3.2.2 Centralized vs. Decentralized Implementation
Infrastructure can be designed using two fundamental approaches namely centralized or

decentralized systems.
A centralized system is designed on the basis that all data (for the whole organization) is stored in a
central system and is stored and processed by users located in dispersed geographical locations. All
application software necessary for processing and storage of data also operates on the central
system.
A decentralized system on the other hand is designed on the basis that each geographically
dispersed location has its own system for processing and storage of data including application
software necessary for the same.
The table below outlines the key variations of each design option:
No Attribute Centralized Decentralized

1 Server System Powerful servers to cater for Entry level servers to cater
processing requirements of for small number of users
all users. at each location.
Servers are required at A server is required at each

central location only. site.
2. Storage Capacity Large capacity to enable Low capacity storage
storage of data and adequate for individual
documents of entire location requirements.
organization
3. Connectivity between geographically Reliable connectivity with Not required
dispersed locations (Wide Area appropriate throughput
Network (WAN)) speeds essential
4. Application Software installation Installed on central system Installed at every location.
only. Normally requires only Normally requires base
one base software license. software license for each
User licenses will depend on site. User licenses will
total number of users. depend on number of
users at the location.
5. Server Operating System Software and Installed on central system Installed at every location.
Database Software only. Normally requires only Normally requires base
one base software license. software license for each
User licenses will depend on site. User licenses will
total number of users. depend on number of
users at the location.
6. Data Consolidation and Integration All data stored centrally and Data stored at each
fully integrated. This allows location. Production of
production of enterprise Enterprise wide reports
wide reports. All data is requires consolidation of
current and provides an data from each location
enterprise wide snapshot of and integration which is
activities. normally complex and
prone to many problems.
Data is available and valid
only up to the last
successful consolidation &

No Attribute Centralized Decentralized

integration.
It also requires extensive

coordination between
various locations to ensure
all data is made available.
7. Administration and Maintenance of All key software i.e. All key software i.e.
software application, system software application, system
and databases need to be software and databases
administered and need to be administered
maintained in one central and maintained at every
location. location greatly increasing
support requirements.
8. Data Backup All data can be backed up Data needs to be backed
and managed in one central up and managed at each
location. location.
It is common to find many

sites have no backups at
all.
9. Disaster Recovery Capability A backup central system can It is not cost effective to
be setup to enable setup a disaster recovery
continuity in the event of a site for each location and
disaster at the primary hence is generally not done
central system. leaving such locations
highly vulnerable in the
event of a disaster.
10. Datawarehouse Easily setup and Implementation is complex
implemented as all data is in due to data consolidation
one location. problems and rarely meets
objectives.
The explanation in the following sections assumes a centralized approach for infrastructure design as
it is most appropriate for realization of key objectives of implementing an IFMIS.
3.2.3 Primary and Backup Data Centers
The data centers are the nerve centers of a centralized infrastructure approach. In essence it entails
installation of high capacity computer and storage systems to enable to cater for the entire
organization. The key components of a data center can be summarized as follows:
• Servers (single processor to multi processors computers of varying speeds and operating
capabilities);
• Operating System Software (manages computer operations, security, enables administration
of infrastructure ...);
• Application software (provides all IFMIS functionality);
• Database Software (for organizing and storage of data);
• Online Storage Systems (disk units from single to multiple disks of various configurations);
• Backup Storage Systems (offline storage systems like tape backup units..);

• Uninterruptible power supply units (to provide continuous & stable power and backup
power during transient power outages);
• Generator (to provide continuous & stable power during extended power outages);
• Cooling systems (to maintain environment at optimum operating temperature);
• Local Area Network components (to enable connectivity between data center computer
systems and other computers at the location);
• Wide Area Network components (to enable connectivity to geographically dispersed
locations);
• Physical Access Control system (to control and manage physical access to the data center);
• A Fire Protection system (to enable rapid response to fires);
Though modern computer systems are highly reliable and can operate non-stop for prolonged
periods of time, it is common to include redundancy in the design. To ensure rapid recovery from
component failures it is common to have redundant components for critical systems such as servers,
storage units and network components. These are installed and configured so that in event of a
failure of any one component, the redundant component automatically takes over and enable
uninterrupted services.
While specifying requirements and selecting any technology, consideration must be given to the
following aspects:
• Compliance to Standards – equipment that complies with industry standards is highly

desirable. Not only does it ensure that equipment will perform to specified standards, it also
implies that it will interoperate with other equipment which is compliant to such standards;
• Equipment Track Record – hardware changes rapidly and it is increasingly difficult to have
long term performance results, however selecting untried technologies increases probability
of operational problems;
• Vendor Track Record – vendor support in terms of implementation guidance, resolution of

problems and supply of spares is essential.
3.2.4 Wide Area Networks (WAN)
The term wide area network is used to describe connectivity between geographically dispersed
locations. These could be locations within a city or in different cities and even countries (e.g.
embassy offices).
Sometimes a network connecting locations within a city is also referred to as a Metropolitan Area
Network (MAN) but in essence refers to the same concept.
Numerous options exist for connectivity but before exploring the same, it is important to first
consider desirables features of a connectivity option. These can be outlined as below:
• Available for Deployment – the solution must be available for deployment at all sites to be
connected. It is common to find that availability is restricted to certain locations only and
this requires implementing hybrid solutions (using multiple connectivity options based on
availability);

• Reliable – the connectivity solution must be reliable i.e. it must be operational at all times.
Frequent breakdowns adversely affect operations and leads to frustration amongst users.
• Capacity – this refers to the data communication throughput of the connectivity option.
Depending on key determinants defined in section 3.2.1 the required throughput capacity
can be computed. This is normally specified in bits / second (bps). Throughput capacity
available with commercial connectivity solutions ranges from 64 kilo bps to multiples of
mega bps.
• Consistent – is different from being reliable as it refers to continuous availability of required

capacity. A connectivity option may be available and reliable but may not be consistent i.e.
throughput varies over a period of time. This is common in shared networks commonly
deployed by many service providers. The alternative would be dedicated networks but
would carry cost implications.
• Cost – there are many cost components and each must be clearly outlined and computed to
arrive at the total cost (further elaborated upon in section 4.6).
The major options available in most countries for connectivity are as outline below:
• Cable Connectivity by Service Providers – all countries have at least one telecommunication
service provider and in many countries there are more providers. This option entails use of
cable based physical infrastructure provided by the service provider. Common problems
include availability (not all locations are covered), capacity and consistency. In countries
where there is only one service provider costs tend to be very high and services tend to be
poor.
• Wireless Connectivity by Service Providers – due to the very high costs of deploying fixed
cable based networks many services providers use alternative wireless technologies to
provide connectivity solutions. Advantages are lower costs and rapid deployment, where as
common problems include availability of frequency spectrum, congestion (as most networks
operate on shared basis) and interference associated with uncontrolled deployments.
• Hybrid Networks by Service Providers – this implies a deployment that consists of a

combination of fixed cable and wireless networks.
• Cable Connectivity – Private Network – some governments have decided to invest in their
own infrastructure especially within the city where majority of government offices are
located. The best option is to install fiber cables which are highly reliable and provide large
capacity. Common problems are time to deploy and huge implementation costs of such an
option with the largest proportion of costs being taken up by civil works associated with
laying of such cables. Since the network is private due consideration must be given to
maintenance costs.
• Wireless Connectivity – Private Networks – an increasingly common option which offers the
advantage of rapid deployment and lower cost. Key constraints are availability of frequency
spectrum especially in highly competitive environments but regulators do make exceptions
for government by allocating frequency spectrum reserved for government and military use.
The key benefit of this option is that there is no capacity usage cost though there is a
maintenance cost and there is usually a fee payable to the regulator for use of frequency
spectrum.

3.2.5 Local Area Networks (LAN)
The term LAN’s is used to refer to the connectivity of computers within a location (within buildings).
This enables connectivity for all personal computers / terminals and even printers & scanners.
Properly structured, LAN’s can cover large buildings (internally) or a cluster of buildings (in close
proximity);
There are two primary options for LAN connectivity, these are:
• Cable based connectivity – which involves laying cables from a pre-determined location to
various offices (where users operate from). The network consists of cables, switches and
termination points (where computers can be plugged in). Key benefits are reliability, high
throughput and consistent performance while common problems are need to lay cables
across the buildings and time required to install;
• Wireless Connectivity – this entails positioning of wireless access points at strategic locations
and would enable personal computers (equipped with wireless access hardware) to
communicate through the access points. Key benefits are rapid deployment while common
problems are congestion at access points (if not properly planned), security (if not properly
managed), problems with consistent performance and reduction of signal strength while
passing through walls. The problems can be overcome by proper planning of access points;
3.2.6 Remote Site Systems
In a centralized infrastructure design, remote sites are any location apart from the primary or backup
data center connected via a LAN or WAN to the data centers.
In essence these are buildings with where offices of various users are located. Major infrastructure
components include:
• LAN (as elaborated in 3.2.5 );
• WAN interface (link of the location to the WAN as elaborated in 3.2.4);
• Personal computers;
• Printers;
• Scanners;
• Uninterruptible power supply units;
• Software - personal computers can be installed with productivity software such as Microsoft
Office. Alternatively all software can be installed on the servers in the data centers and is
accessed over the WAN;
3.2.7 Security & Access Control
Security needs to be considered at various levels but is generally split into two major categories
namely physical and logical.
Physical Security focuses on securing assets (computers, network devices, printers, scanners, storage
devices etc.) against unauthorized access. Common approaches are:
• Limiting access to central data centers to authorized personnel only and keeping track of all
activities and movements. This can be achieved in variety of ways including using biometrics

(fingerprint or iris scanning and recognition), using access cards (which need to be swiped),
using combination locks, using locks that require passwords, manual control by security
guards etc. It is important to note that some of the access controls can also be used to
control access to computers e.g. use of cards and fingerprint recognition is quite common;
• Tracking Activities – this is normally achieved by means of various forms that need to be
filled for all tasks being performed and also by means of CCTV cameras that can be
strategically located to continuously record all movements (cameras can be triggered by
movement).
Physical security at remote locations (i.e. in offices where users work) is more difficult to achieve and
the most effective method is for users to secure the rooms where they work by conventional means.
It is not unusual to find personal computers / laptops missing from offices or at times components
are stolen from personal computers with items like hard disks and memories being most popular.
Logical Security on the other hand focuses on securing the system from unauthorized access to the
data and software on the system (assuming the person had physical access to a computer or
network device). Logical security is controlled at the hardware and software levels on the system.
Typical approaches are:
• Configure hardware systems to only allow a pre-determined list of equipment (uniquely

identified by means of addresses that are built into hardware by manufactures and are
unique) to connect to each other. Example a LAN can be configured to reject attempts to
connect from devices not defined on the network, a wireless access point can be made
inaccessible by means of requiring specific keys and passwords to access, routers can reject
traffic from devices whose addresses are not pre-defined on the router etc.;
• Restrict access to devices on the network – this approach assumes a user has legitimate
access to the network but limits the user to access only certain computer systems on the
network. This avoids users gaining access to all computers and thereby eliminating their
ability to cause problems on such computers;
• Restrict actions a user can perform on a system – this is implemented at the operating
system software level which controls what users can and cannot do on the system. Normally
all users except a few members of the technical team working at the data centers are
prohibited from accessing any component of the operating systems and therefore
eliminating possibility of changes to configuration settings on the system;
• Define access restrictions to application software – this level of security is implemented at

the application software level which controls what each user of the system is allowed to
access. Normally this limits users to only access functionality directly related to their role
and responsibilities and prohibits access to all other functionality. Further, even in areas
where access is allowed, additional restrictions can be imposed on whether the user can
enter, change, delete or just view data on the system. All application systems maintain
extensive logs of all actions and each activity is tied to a user, date and time thereby making
it easier to track actions to a user;
• Restrict access to databases – this is where all the data of the system is stored and normally
direct access to the database is prohibited to all users except the support team responsible
for database maintenance. Users can only access data through application software which
tightly controls user activities and maintains extensive data integrity checks;

Logical access control is managed by defining each user who is authorized to access the system and
assigning them passwords to access the system. Each user has a profile and access rights assigned
which the computer systems use to regulate and log all user activities. Based on the security policies
users are required to set passwords according to specific guidelines and are also required to
frequently change passwords.
3.2.8 Business continuity

Since the data center is critical to operations, it is essential to provide for a backup data center to
reduce the risk of operational paralysis due to a disaster. The term disaster is used to imply complete
destruction of the primary data center from catastrophic events like fire, floods, building collapse,
earthquakes etc. The backup data center is normally a duplicate of the primary data center and
should ideally be located at a substantial distance from the primary center (especially to safeguard
from natural disasters which would most likely affect nearby sites also).
There is always a concern related to the cost associated with setting up a backup data center.
Unfortunately there is no choice in terms of the hardware and networks required (everything needs
to be duplicated) but it is important to bear in mind that system software, database software and
application software does not need to be procured for the backup data center. Most software
vendors allow the installation of the same software on a backup system under the licenses provided
subject to the limitation that only one system i.e. primary or backup is used at any one time. This
provides substantial relief in terms of software license costs. However if a client chooses to use both
the systems at the same time then it is mandatory to procure licenses for both sites.
For the backup data center to be effective, it must be at a level of preparedness, such that in the
event of a disaster, operations can resume in the shortest possible time. This presents a set of
challenges like:
• Duplication of all data stored at the primary data center onto the backup data center;
• Switching of wide area network links from primary to backup data center;
• Redirecting users to work with the backup center;
To enable duplication of data from the primary to the backup center some of approaches adapted
are:
• Option 1: Instant duplication of a transaction from primary system onto the backup system.
This implies that a transaction is considered complete only after it is duplicated successfully
onto the backup system. For this option to work both sites must be operational at all times
and the network must be very reliable and must offer high throughput speeds. In the event
of a network failure, the primary system cannot function as it is unable to successfully
duplicate the transaction onto the backup system.
• Option 2: Duplication of a transaction from primary system onto the backup system. In this
case the primary system does not wait for confirmation of completion of transactions on
backup system. In the event of network failure between the sites, the primary system
continues to function and transactions are accumulated and are applied onto the backup
system when the network link is restored. There is however a possibility of inconsistency and
loss of data in this option.
• Option 3: This approach transfers transaction logs (with all changes) from the primary
system to the backup system at pre-determined intervals e.g. 10 minutes, every hour etc.
The logs are then used to update the backup system automatically. This option also requires
a network link between the two centers but maybe of lower throughput. In the event of
network failure, logs are accumulated and transferred when the network is restored. In this

option, if there is a disaster, transactions on the backup system are updated only up to the
last transaction log received from the primary center. Prior to commencing operations on
the backup system, it would be necessary to establish which transactions have been lost and
would then need to be re-entered from documents available at each site.
• Option 4: Data is backed up from the primary data center on a daily basis and stored off-site.
In the event of a disaster, data from backup media is restored on the backup system. All
transactions since the last backup need to be re-entered prior to operations commencing.
This option does not require a network link between the two sites. This option is only
practical for systems where volume of data is low. If volumes are large, maintaining the
same on backup media on daily basis is a major challenge.
Each option has its benefits, shortcomings and costs. The most appropriate approach would depend
on availability of connectivity, cost and perception & management of associated risks. It must be
understood the disasters are relatively rare and any perception of risk must be evaluated on that
basis.
3.2.9 Hardware Obsolescence
Computer hardware is a rapidly changing commodity. It is common knowledge that over the past
many years hardware systems are rapidly becoming more powerful, have larger storage capacities
and offer a wide range of features and facilities. It is also common knowledge the hardware costs are
continually reducing in terms of cost per capabilities basis (more powerful systems are available at
the same or lower price compared to a less powerful system bought maybe 6 months back). The key
issue is the rapid rate of change and its impact on infrastructure design.
Some years ago it was common to procure computer systems that offered a number of upgrade
options so that when there was growth in operational requirements the systems could be upgraded.
It is now debatable whether such an option should be pursued for most implementations. Highly
upgradable systems are expensive to procure but when time comes to actually upgrade the systems
(in 2 -3 years time), the cost of upgrade would probably be higher than the cost of a new and most
likely a more powerful system. With the exception of very highly specialized hardware it is no longer
a good idea to procure highly upgradeable hardware upfront as it is more economical to add more
powerful systems at that stage.
Another important aspect to understand is that due to the rapid rate of change vendor support for
systems ceases in ever decreasing time spans and access to spares also becomes an issue.
3.2.10 Support & Maintenance
Infrastructure requires regular maintenance. Maintenance programs could be any one of the
following:
• Regular cleaning of equipment;
• Replacement of consumable items (e.g. toners, ribbons, cartridges, print heads, UPS
batteries …);
• Repair of faulty equipment, cables etc.;
Some maintenance tasks can be carried out by end users (replacement of toners, ink cartridges etc.)
while others require skilled technicians and for high end hardware systems experienced engineers.

Warranty
All equipment is supplied with warranty which provides for free replacement of failed components
free of cost. The duration of warranty varies from vendor to vendor and also on equipment types.
Warranty for 1 year is common, while some equipment is provided with up to 3 years warranty.
Warranty only provides for replacement components and not services to actually carry out repairs.
3.2.11 Top of the Range versus Appropriate Technology
It is very tempting to think in terms of procuring top of the range technology as opposed to
appropriate technology. Top of the range technology might come with features that probably would
never be implemented or used and would come at a high cost. In many instances there is also little
regard for what can be managed and maintained in a country.
There are many instances in tender situations where requirements are specified far in excess of
actual requirements. Due consideration should be given to the many options available that could be
used to meet objectives at reasonable costs.
3.2.12 Data Center Hosting and Software as a Service
There many emerging concepts in the field of information technology that needs to be mentioned
for consideration for anyone planning implementation of systems.
The first concept is data center hosting. In this model clients use data centers setup and operated by
service providers. This means the service providers cater for all requirements that a client would
cater for by setting up their own data centers. All task such as ensuring adequate capacity,
operational availability, updates, upgrades, data backups, provision of backup data centers and
support are outsourced to such service providers. Client’s users access the data centers over
networks (either through secure internet connectivity or dedicated network links). In essence
therefore the client does not setup own data centers. The arrangement also eliminates problems
associated with hardware obsolescence as it becomes the service provider’s responsibility to ensure
systems are maintained at specific standards. Clients still retain control over all data and system
configuration aspects. The services are charged on a fixed basis. There currently exist a number of
such services providers and large organizations outsourcing data center hosting to such service
providers.
Key concerns of adapting such a model are that data is stored at the service provider’s data centers
(though still under the client’s control) and reliability of such services. Both concerns arise due to the
significant shift from conventional thinking associated with infrastructure setup.
The second concept is software as a service. In this model, a client does not buy application software
but instead uses software for operations and pays a fee based on usage. The software as a service
concept is based on the data center hosting model. The service provider not only hosts the hardware
systems but also provides all the application software too (clients can select modules). The solution
is then configured to suit clients needs and is accessed through networks. The service provider
retains responsibility for all updates, upgrades and support requirements. A number of low and
medium tier software solutions are now available only as a service and not for purchase.
The two concepts may not find immediate application in the IFMIS implementation strategies but
are important to understand.

An extension of the above two concepts is however very relevant within a government environment.
Once a government has invested in and setup data centers for an IFMIS project there exists the
potential for extending the facility to many government organizations, agencies etc. In many
countries it is common to find different government organizations duplicating effort by setting up
numerous independent systems with different platforms and application solutions. It is equally
common to find donor funded projects having their own independent accounting systems which
neither communicate with each nor offer the ability to consolidate information. This duplication of
effort is a poor use of scare resources.

3.3 Capacity Building
Effective implementation, operation and maintenance of the application solution and infrastructure
require knowledge and skills. While some personnel in the government might have some of the
required skills, a majority do not and building up this capacity constitutes the third major component
of an IFMIS project.
Capacity building essentially consists of recruiting suitably qualified personnel, training, skills
development and retention of trained personnel.
In many projects it is common to find consultants being employed by governments to assist with a
number of project tasks due to lack of adequate capacity. The consultants are assigned counterparts
to work with and the overall objective is to train counterpart staff and ensure transfer of skills. The
success (or lack of it) of this approach is debatable.
The primary objectives of capacity building should be:

• Employ suitably qualified personnel;
• Promote suitably qualified from within;
• Encourage personnel to pursue on-going education;
• Provide training to suitably qualified personnel as part of various projects;
• Provide terms and conditions that promote growth and retention;
An IFMIS project design should consider all the above objectives to ensure long term sustainability. On
an IFMIS project, training is essential for a number of personnel who can be broadly grouped as:
• Support teams;
• Managers;
• End Users;
3.3.1 Support Team
The objective of forming a government support team as part of the IFMIS project is to promote
ownership and ensure sustainability. The team should participate in the implementation process and
acquire the necessary knowledge and skills in a practical environment.
3.3.1.1 Team Roles and Responsibilities
The proposed role and responsibilities of the team can be summarized as follows:
• Operate and Manage Infrastructure – there are many aspects of routine operations and
system administration that need to be managed at the central data centers. Examples are
regular review of system performance (hardware, databases, software, networks,
security…), user administration (create, change remove users & their access rights), routine
software maintenance (applying updates), routine hardware maintenance, data backup
and safe storage etc.
• 1st Line of Support - i.e. all calls for support / assistance should be directed to the teams
who should attempt resolution. Calls that they cannot resolve should then be escalated to
the supplier’s team.

• Train end users – training is an on-going requirement in any organization resulting either
from turnover of staff in existing locations or the need to train new staff as part of system
rollout to additional locations. The team’s ability to provide training further consolidates
ownership and reduces dependence on supplier (with corresponding reduction in costs).
• Test Applications – from time to time there will be changes to application system either in
configurations or changes to the software. It is essential to retest the application system
prior to moving to production (i.e. putting it into regular operations).
• Develop / Customize Reports – in any implementation, there is a constant requirement to

change or add reports and the support team is ideally suited to carry out such work
reducing dependence on supplier and also reducing costs;
• Supplier Liaison – the team should be primary liaison and should work closely with the
supplier team. This includes responsibility for overseeing supplier deliverables in terms of
support and maintenance.
• Reporting to Management – an integral part of the role would be to regularly report to

management on the status of the systems and also advice management on any
development required. Risk assessment and management is an essential component of this
management role.
From the role and responsibilities it becomes evident that the team requires capabilities in two
domains namely application solution and infrastructure. The requirements for each are very
different and it is therefore essential to have two separate teams for the two domains.
An application support team should focus on all application solution related tasks which include
review of requirements, solution build, testing of the solution, implementation preparation,
implementation, training end users and providing support on the application solution.
The technical team on the other had should focus on installation, testing, commissioning,
maintenance and support of all infrastructure components.
3.3.1.2 Team Formation
Ideally the teams should be formed from existing government employees or through recruitment
of suitably qualified personnel and it is recommended that employed personnel should be part of
the government and not on special contracts.
While it seems like a good idea to entice suitably qualified candidates from the open market to join
the team through special contracts (funded through project funds) the concept becomes counter-
productive once project funds run out. The pay scales and benefits offered under special contracts
are far higher than the government civil service provisions and it becomes very difficult to absorb
these personnel into the civil service. In almost all cases they leave for better opportunities taking
with them all the knowledge and skills developed at a considerable cost during project
implementation and in the processes weaken the support teams. A similar situation exists when
consultants are employed to form such teams. It is common to find that the entire implementation
team has left and in such projects continuity and sustainability become major concerns and
probability of failure becomes very high.
In many instances the emphasis on reducing dependency on suppliers is highly stressed (and rightly
so) but dependence on special contract employees and consultants within the government is

largely overlooked with serious negative consequences as the project moves beyond the
implementation stage.
With the above aspects in mind, governments must strive to build the teams from within or
through suitably qualified personnel employed on civil service terms as it is the most sustainable
approach to retention of knowledge and skills. Simultaneously the government must consider a
review of the civil service terms for specific skills and make them attractive enough to enable
retention of trained staff.
3.3.1.3 Team Training
In all projects, provision of training within a project focuses on developing knowledge and skills on
the proposed solution (application and infrastructure). The training planning assumes that
personnel designated for training have the requisite qualifications (domain knowledge) prior to
attending training programs in the project.
Members designated to join the application support team need background in accounting,
materials management, procurement, human resource management etc. (depending on modules
selected for implementation). Experience of working within the government in any of the areas
would certainly be an added advantage.
Personnel designated to join the technical teams on the other hand need background in hardware,
operating systems, databases, software development tools, networks etc. and again experience in
either of the areas is highly desirable.
Both teams however would also need knowledge and skills in areas of personal performance
management, time management, problem solving and decision making, quality awareness, project
management, leadership and team management, change management, business communications,
etc. (normally referred to as “soft skills”).
The training program for the support teams tends to be long (not less than 6 months) and must
therefore be taken up very early in the project. Where feasible training should be carried out
before commencement of project implementation, especially on those aspects that are not
dependent on any solution likely to be proposed e.g. soft skills training. The reason for proposing
this approach is to reduce team training time during implementation and hence enable the team to
participate in the implementation process.
Team members should be encouraged to appear for professional exams that lead to product
certification by the various vendors. The objective of proposing this is for the team members to
gauge their knowledge and skills against international standards and for the government to have
an indication of the capabilities of the team members.
3.3.1.4 Team Participation in Implementation
The teams should be formed before project implementation commences and should participate in
the entire implementation process which gives them extensive opportunity to use their knowledge
and acquire practical skills. The fact that the team participates in project implementation creates
institutional history and leads to a keen sense of ownership. These are critical aspects for
successful implementation and maintenance.

3.3.2 End User Training
End user training is the term used to define training required for various users of the systems, who
will eventually be responsible for operations in their respective locations and domains.
All training under this category is based on the application solution and is segmented based on areas
of responsibility. Examples of end users are accountants (in different areas), procurement officers,
human resource personnel, stores personnel, asset management personnel etc.
Personnel designated for training must be those who will eventually have operational
responsibilities. For each role, the requisite knowledge and experience background must be
specified and personnel must be selected on that basis. It is essential that the designated personnel
be available for training and for implementation tasks and must not be transferred for a period of
one year after go-live (unless it is for exceptional circumstances). Regular attendance for training
should be mandatory and managers should refrain from disturbing staff during training session to
maximize benefits of training.
The approach to training can vary based on organizational requirements, the application solution,
background of personnel etc.
One option would be to train all users on all aspects. The benefit is that users have an understanding
of the entire system which improves their ability to function effectively and also enable rotation of
staff during operations. The issues with this approach are it takes longer to provide training and not
all users will be able to understand all aspects due to differences in background knowledge.
The other option is to restrict training exclusively to the domain the user is working in. The benefit is
reduced training time and specialization. The disadvantages are lack of overall perspective and
inability to rotate staff without additional training.
For simpler applications solutions the first option is suitable while for more complex / large solutions
the second option would work better.
All training should be practical with examples and case studies tailored to the government’s
operations. During training users should therefore work on a training system configured to operate
in a manner similar to what they would expect in their offices. Some general training related to
concepts, navigation, parameter setting etc. can be generic (common to all users of the application
solution) but a substantial portion should be mapped to proposed operations of the government.
3.3.3 Management Training
Training for managers is based on enabling them to review work done by staff in their departments,
authorize transactions and use information on the system for decision making and reporting.
Managers do not process transactions but need an overview of the systems operations to be in a
position to review the same.
Most managers in government have risen through the ranks and hence already possess significant
domain knowledge and experience. This however may not apply to managers specifically brought in
for the project.
Training for managers should provide an overview of operations and devote significant time to
facilities that allow monitoring, authorization and production of reports (online / printouts and both
operational and analytical).

3.3.4 Auditors Training
Auditors are singled out as a special group for special training as their role is very different from end
users and managers. The requirements for internal auditors and external auditors are again
significantly different and need to be catered for as such.
Training for all auditors in general requires overview of all operations but is more specifically
centered on monitoring, compliance and reporting functions. An IFMIS solution implemented using a
centralized model provides avenues for auditing that do not exist in a manual system. Specifically,
the IFMIS system provides auditors with the ability to review system operations online and hence
notice anomalies much faster. This enables audit to become a proactive function rather than a
reactive after the fact function.
Training for internal audit, which has the responsibility for monitoring on-going of operations, should
focus on the wide range of monitoring capabilities which includes alerts, ability to monitor workflow
online, review operational logs, produce instant reports and identify deviations from compliance
requirements.
Training for external auditors, who have the responsibility of evaluating performance, while similar
to that internal auditors focuses more on the capabilities to produce statutory reports, test system
operations & controls, evaluate adherence to compliance requirements, download system data into
external audit systems and also produce statistical and analytical reports for tasks such as value for
money audits.
3.3.5 Skills Transfer
Having knowledge and the ability to apply the knowledge to real life situations are two different
things. The term “skills” is used to imply the ability to apply knowledge. In capacity building
situations, it is common to find people with theoretical knowledge who then struggle or are unable
to perform practical tasks based on the knowledge. Skills transfer therefore looks at encouraging
personnel to apply knowledge gained during training to practical work and demonstrating
competency in this capability.
The most effective approach is for support teams, end users and managers to participate in the
implementation process and carry out tasks under guidance of the supplier team personnel (or other
consultants). A skills transfer checklist is very helpful in this regard. The checklist should contain
tasks that need to be carried out by various personnel and it is supposed should be signed off once
the personnel have demonstrated competency in carrying out assigned tasks.
3.3.6 Assessment
Training activities must be regularly assessed both from the delivery and recipient view points.
To ensure that training is delivered to requisite standards by the supplier, profiles of trainers must
be carefully scrutinized to ensure training is delivered by qualified and experienced trainers. Course
content must be designed in line with proposed solution and must provide adequate coverage of all
concepts and features expected to be implemented. Course material must be reviewed to ensure
that both content and presentation reflect the proposed solution and is easy to use as a reference by
trainees. For practical sessions, the training infrastructure must be adequate for users to carry out
exercises and case studies in a manner that reflects actual operational scenarios.

Training deliver must be constantly monitored through quality inspection and participant feedback.
Any deviations must be corrected during course delivery which is only possible through regular
assessment. End of course feedback helps in improving subsequent programs but does little for
participants who have complete a program.
Assessment of recipients for training is equally important and can be carried out by means of
assignments and tests. Recipients must be made aware that a minimum performance target must be
achieved in order to qualify and be considered suitable for participation in project activities. At times
there is reluctance to be strict with such requirements in government. It must however be
understood that failure to do so will eventually reflect poorly in the performance of the individuals
and decrease the probability of achieving a successful implementation.
3.3.7 Retention
Retention of trained personnel especially support team members should be a high priority to the
extent feasible. The team is trained at a considerable cost, have most of the institutional history of
the implementation and have developed skills necessary for provision of support. While it is always
possible to train new personnel to replace departing ones, it is a matter of cost and maintaining
continuity.
There are numerous reasons for people leaving. Some have solutions that are relatively easy to
resolve while some are complex. Some common issues that can be resolved with relative ease are:
• Lack of clarity of role and responsibilities;
• Inability to work with managers;
• Frustrations resulting from poor decision making processes;
• Lack of growth path;
• Inadequate resources to execute tasks;
Issues that are relatively difficult to resolve are:
• Ability to retain contract employees and consultants once project funds run out;
• Ability to match employment terms with what is offered in the market;
• Promotion to higher level position;
If retention of personnel is difficult as a result of inability to match employment terms, an alternative

strategy to train more personnel must be pursued.
A costs benefit analysis of either improving terms for existing employees or employing more
personnel and training should be carried out to decide on the optimum approach.
The objective is to ensure that there is adequate capacity to operate and maintain the systems.
Many system failures originate from poor capacity (especially where high end rather than
appropriate solutions have been implemented) and not from the systems themselves though in
many instances project review reports tend to blame systems as they are easy targets whereas
talking about capacity problems is not very popular.

3.3.8 Issues in capacity building
Some issues associated with the 4 key areas of capacity building namely employing qualified
personnel, training, skills development and retention are outlined below:
• Employing suitably qualified personnel.
o Due to differences between government employment terms and those offered in

other sectors, it is a challenge to recruit personnel with knowledge and skills which
are in high demand.
• Retention - issues related to retention have been highlighted in section 3.3.7.
• Training
o Inappropriate personnel designated for training – personnel sent for training are not
the ones with operational responsibilities. The training effort is then wasted as the
actual operational staffs are not trained;
o Unqualified people designated for training – personnel sent for training lack
essential education or experience background. Net result is poor performance
during implementation;
o Poor Attendance – personnel designated for training either never turn up or attend
only some training sessions. One reason for poor attendance is a result of personnel
being called back to offices for routine work related issues. Net result is poor
performance during implementation;
o Problems with allowances – this varies amongst governments but in some countries
there is an expectation of being paid allowances to attend training otherwise
personnel do not turn up for training. There are times when such payment are not
agreed upon, considered inadequate or delayed and this leads to problems with
training programs;
• Skills Development
o Poor participation in implantation activities – this happens during the systems

installation and setup activities. The result is inability to understand what has been
done and affects ability to operate and support the systems;
o Lack of willingness to accept responsibility – leads to a situation where dependence

on supplier personnel or consultants continues long after implementation is
complete.
o Inability to translate knowledge to practice – leads to a situation where dependence

on supplier personnel or consultants continues long after implementation is
complete and sustainability is threatened.
• Other issues
o Transfer of trained candidates once implementation commences causing various

tasks to be affected as personnel who take over are not trained;

3.4 Change Management
Successful implementation of an IFMIS system can bring clear benefits to the government in terms of
compliance, reporting, utilization of resources, planning etc. (please refer to section 2.2 on
Objectives of an IFMIS). The implementation however also brings along significant changes in
operations and roles & responsibilities of personnel.
Key changes from the operational procedures point of view can be summarized as follows:
• Automation of procedures;
• Introduction of new procedures;
• Changes to existing procedures;
• Elimination of procedures;
Correspondingly changes to roles and responsibility are:
• Introduction of new roles and responsibilities;
• Changes to existing roles & responsibilities;
• Elimination of roles & responsibilities;
Under change management, the objective is to establish consequences of such changes and to
manage them effectively in a manner that will cause least amount of disruption, reduce probability
of resistance & sabotage, foster greater ownership and ensure long term sustainability.
Managing change in a conventional business environment is difficult and to do the same in

bureaucratic organization like government is even more difficult. It requires strong political and
administrative will.
3.4.1 Stakeholders
An IFMIS affects some of the most sensitive of government functions such a budgeting, resource
allocation, expenditure control, procurement, revenue accounting, human resource management (if
implemented) etc.
To effectively manage the process of implementing IFMIS it is essential that the expectations of
stakeholders are carefully managed. Their acceptance can be enhanced by ensuring that they are
fully aware of their involvement in achieving milestones, their contribution to deliverables and the
likely impact on their current mode of interacting with the government in whatever way.
Defining the stakeholders of the project is thus an essential task. A stakeholder can be an individual
person, a loose group of people, or an organization. The interested parties who directly benefit from
a project - funding, management, shareholders etc are the internal stakeholders. The internal
stakeholder also include top, functional and line managers. On the other hand there are external
stakeholders such as the general public and donor community who are very important in
contributing to the project and directing the project. The following table lists some of the key
stakeholders of an IFMIS project and the roles they are expected to play.

3.4.1.1 Internal Stakeholders
No Internal Stakeholders Role

1 Parliament Institute legislative framework to support the new
Members of Public Accounts way of working
Committee
Parliamentary Committee Members
Clerk to House
2 Ministers Provide top level support and demonstrate
Permanent Secretaries and Deputies commitment to the project implementation and
Directors and Deputies related changes
Auditor General
3 Project Management Team Facilitate the communication process during
implementation
4 Application and Technical Teams Take responsibility for facilitating user sensitization
and reinforcement at all levels
5 End users – (Pilot ministries) Ensure compliance to a different model of working
Accounting Staff
Procurement Officers
Stores Officers
Examinations
Main Cashiers
Public Debt section
Reconciliation Sections
Ministry planning staff
6 Internal and External Auditors Ensure compliance to a different model of working
and review of internal controls.
3.4.1.2 External Stakeholders
External Stakeholders Role

1 Central Bank Set up required information exchange with the
Treasury
2 Suppliers Ensure registration with tax authorities
Honor system generated Purchase orders
Confidence in doing business with the Government
3 Donors Confidence in the new model – compliance,
adherence with respect to number of bank
accounts, report requirements etc.
4 General Public Awareness about the government initiative to
improve national economy vide accountability and
transparency.
3.4.1.3 Project Owner
The project owner is the Government and is generally represented by the Principal Secretary of the
Ministry of Finance. The Accountant General’s Department of the Ministry of Finance is also a Key
Stakeholder, member of the Steering Committee and is expected to champion the project. The PS

Finance is expected to provide high-level support and monitor the progress of the project. Where
Human Resource System implementation is included in the IFMIS Project ownership and
responsibilities may be structured differently.
3.4.1.4 Project Steering Committee
The Project Steering Committee comprises government representatives and is chaired by the
Principal Secretary, Ministry of Finance. This committee focuses on the broad issues, such as
schedules, budgets, quality management, opportunities, and constraints as well as ensure that the
project's vision is realized. Senior officials of suppliers attend meetings of the Steering Committee
by invitation to provide project status updates, identified risks and proposed mitigation measures.
3.4.1.5 Project Champions
Project champions are individuals that need to be identified from every Ministry. These
stakeholders are expected to be advocates of the change and where necessary willingly take up
responsibilities, which will positively, drive the project forward.
The overall project champion is the Minister of Finance. The strategy throughout the project
should be to identify project champions for each major change element. These individuals should
be named where possible and given all the support required to back them up in championing the
required changes. Below is a representative list of likely champions and as the design progresses
should be encouraged to support specific processes and play specific implementation roles. They
are as follows:
• Minister of Finance
• Minister of Communications
• Minister of Public Service
• Principal Secretary – Ministry of Finance
• Accountant General
• Budget Controller
• Auditor General
• Application team
• Technical team
• Workgroup members
• Project management team members
3.4.1.6 Change Agents – Project Workgroups / Financial Controllers
Change agents are stakeholders charged with responsibilities that will culminate in the successful
realization of the project objectives.
The primary change agents are project team members with responsibilities as per the project
structure. The change agents are expected to fully share the vision and espouse it. They are also
expected to be aware of their responsibilities and project obligations. They should share the key

value of integrity, and be open and forthright with their communication so that issues are properly
flagged and resolved as they arise.
3.4.1.7 Change Targets
Other internal stakeholders are all individuals who are the owners or users of the processes being
affected by the implementation of IFMIS. Such processes change their procedures and controls
e.g.:
• Chart of Accounts Structure
• Budget preparation and management
• Fund management and allocation
• Bank Reconciliation
• Financial Reports
• Commitment Accounting
• Imprest / Advances
• Revenue Accounting
• Payroll processing
• Procurement processing
3.4.2 Impact Assessment
The most evident impact of the IFMIS implementation is when business processes change. This
happens from a technology perspective, as well as from accounting and budgeting perspectives.
With changes in business processes, change management issues are expected to be identified both
by the workgroups and the project management team. These groups are made up of government
staff, supplier’s representatives and specialist hired consultants. As such these groups should be
structured to be a forum where issues can be discussed and consensus formed on issues arising.
Decisions should also thus be collectively owned and must reflect the views of different
stakeholders.
The workgroups should highlight all key changes expected to occur for which they expect challenges
to arise. The workgroups should then recommend mitigating actions. The overriding assignment of
responsibility should be made by the project management team and where it exceeds their authority
level or is beyond their mandate, the issue should be referred to the project steering committee for
advice.
The result of this assessment is captured in a plan that outlines the following:
• Change Management Issue;

• Affected stakeholders;
• Impact of change;
• Required Interventions;

• Action and action owners;

Impact assessment is not a one of activity but an on-going activity as change management issues are
identified at various stages of the project and need to be managed accordingly.
3.4.3 Risk Assessment and Management
Just as change management issues are identified, it is important that associated risks are correctly
identified so that they can be managed. In order to deliver the project objectives it is important to
have a system of issue reporting that will enable the key risks that need to be managed to be easily
identified, categorized and mitigating measures implemented. Risks can originate from various areas
and some of these are defined below:
• Project Organization and Reporting - project organization is the key to establishing the
vision, determining the most appropriate strategies to be adopted, assigning responsibility
and ensuring tasks are executed properly. Where for any reason this is not happening as
expected the risks should be flagged for attention.
• Project Commitment from various stakeholders -This should be assessed on an ongoing
basis since the commitment of all stakeholders is crucial if the project is to realize its
benefits.
• Project Resourcing – this includes People, Technology and other infrastructure, other
logistics. Assessment should capture any people issues, attendance at meetings, lack of
competencies, unavailability of end users to be trained, delays in infrastructure setup etc.
• Communication – an essential component for dissemination of information which requires
frequent briefings and appropriate disclosure of information to stakeholders through
various communication channels including intranet, web, newsletters, meetings etc.
• Process Changes - the most evident impact of an IFMIS implementation is from changes in
business processes and hence it is important that associated risks involved in changing
these processes are correctly identified so that they can be managed.
The result of risk assessment is a Risk Log wherein:

• Project risks are defined;
• Rated;
• Reasons are provided for the rating;
• Required actions to mitigate risks are specified;
• Responsibility is assigned;
• Timeframes for actions are defined;
The evaluations are best made at an operational level wherein workgroups are expected to flag and
categorize their own issues, rate them and indicate the reason for the rating, the action required to
resolve the issue and the impact of not resolving the issue.
Once the action has been determined, it must be assigned to a group or individual. That group or
individual is then responsible for ensuring the mitigating steps are implemented. Each action once
determined, should be given a specific completion date.

Where the approach to resolving the issue is protracted, the full strategy should be stated on how to
resolve the problem and the date of the first deliverable stated.
As a dynamic activity, risk assessment and management is expected to be done weekly at the very
least. Critical issues should be left on the worksheet even after they have turned green. Issues that
stay as high risk issues for more than a month must be escalated to the project steering committee
so that they are fully aware of the potential impact of the situation and where possible can intervene
as appropriate.
3.4.4 Communications
An organization relies on its people thinking as a single cohesive unit to maximize the attainment of
set goals. For change to be enduring and effective, it is essential that an integrated approach be
adopted in transforming, the organization, its systems and processes and most importantly the
people whose efforts will culminate in the achievement of the desired improvements and
efficiencies. There is no point making changes to systems and processes if the people are not
prepared to accept and maximize those changes. Thus people and not processes are the central
focus of change management and communications approach.
The strategy should be aimed at supporting those who will be affected by the implementation of the
IFMIS to understand the changes to their day to day tasks as a result of the IFMIS implementation
and to foster acceptance, involvement with and commitment to the IFMIS implementation project. A
central principle of the approach should be recognize and acknowledge the differing needs of
individuals and groups of individuals and to create the conditions that encourage all stakeholders to
engage with and enact the change through consultations and collaborations between all relevant
stakeholders.
A two way communication and participative approach is essential. Following are the phases that
occur in relation to the communication life cycle and change management of a project. The phases
do not necessarily occur in a sequential manner for all stakeholders.
• Awareness - Stakeholders develop knowledge of the change. This process should begin with
presentations and consultations with various stakeholders within the government. This
process continues throughout the project lifecycle.
• Understanding - The various stakeholders need to understand what the changes brought
about by the implementation of the IFMIS means for them. It is essential at this stage that
people understand the change and are given the opportunity to provide as well as receive
feedback. This is normally addressed through presentations to stakeholders, team briefings
and fora. The focus should be on smaller groups and allow for question and answer feedback
sessions. The training program for the implementation is a key component of engendering
internal stakeholder understanding of what the changes mean for them in the performance
of their day to day duties and provides the opportunity for these stakeholders to practice
the changes in a learning environment with active support from experienced trainers.
• Acceptance - People need to accept change for that change to be enduring. They may not
necessarily agree with the change, but it is important that they accept the need for the
change as well as the rationale behind that change. Communications to engender
acceptance should be both formal and informal in nature and should largely be driven by
change agents and champions. Communications should be designed to address individual
concerns as far as practicably possible and may be delivered on a one-to-one basis by the
change agents to bolster understanding of messages delivered through other
communication media.

• Involvement - People are more receptive to change if they are involved in making the
change happen. Consistent with a participative approach to project implementation,
emphasis should be placed on skills transfer throughout the project lifecycle and the training
program for the project should be designed to be interactive and hands on, allowing users
and other stakeholders who directly interact with the system to familiarize themselves with
the system and gain practical experience of how the IFMIS will affect them in the
performance of their day to day duties as well as an appreciation of the importance of each
of their roles within the bigger picture.
• Commitment - Ultimately people need to become committed to the change if the change
will be successful and commitment is best achieved through ownership. Throughout the
lifecycle of the project the key message that, the IFMIS is owned by the government through
all the stakeholders, must be emphasized and a range of both formal and informal
communications should be provided to reinforce people’s understanding of the change and
what it means for them individually.
• The result of a communication formulation exercise is a communication plan that defines

the following:
o Event or strategy;
o Timing
o Stakeholders Targeted;
o Purpose of communication;
o Method of communication;
o Feedback Mechanism;
o Communicators;
3.4.5 Transition Arrangements
The point of transition from one system is the culmination of a host of preparatory work done from
the onset of the project and is a critical period in the project implementation life cycle. For transition
to occur the following conditions must be fulfilled:
• Users are trained;
• Infrastructure is installed and commissioned;
• Application solution is configured, tested and commissioned;
• All data required for commencement of operations is available and setup on the systems;
• Management approval has been granted for the transition;
The phase marks the start of a new way of working with significant changes taking place across
various departments affecting various roles. It is therefore critical that the stage must be preceded
and followed by a concerted change management effort.
This is normally achieved by regular communication of events leading to the transition to ensure
awareness and to prime all stakeholders for the event. The communications must focus on
anticipated changes, management of impact of such changes and availability of support during the
transition period.

In the days following the transition and for a period of at least 1 month, support team members
must be positioned within various locations from where users are operating to ensure immediate
guidance and support is available for difficulties encountered. The objective is to ensure that
operations proceed with least amount of hurdles. Initial successes can provide a very powerful
impetus to the acceptance of the system and further implementation of the system.
3.4.6 Benefit Realization
The basis for implementing IFMIS should be a set of objectives backed by strategies resulting in
anticipated benefits. This register of anticipated benefits must be used as a reference throughout
the project life-cycle and must guide all actions on the project. Every activity on the project plan,
training plan, change management plan, communication plan etc. must be aligned towards
realization of anticipated benefits.
A key component of change management therefore is to define and document anticipated benefits
(in a measurable way) and to assess the implementation in terms of the extent to which the benefits
have been realized. Where anticipated benefits have not been realized, effort must be made to
establish the causes and develop resolutions to ensure that the benefits are realized.
Ultimately it is the attainment of objectives and realization of benefits that will determine the
success or failure of the IFMIS implementation project.
3.4.7 Organizational Restructuring
Changes to business processes, as outlines earlier, lead to changes in organizational structure in

terms of introduction of new roles and responsibilities, changes to existing roles & responsibilities
and elimination of roles & responsibilities.
An integral part of impact assessment under change management is to review the existing
organization structure, identify changes, define impact of such changes and define interventions
required.
Typical example of new roles would be those associated with the introduction of application and
technical support teams.
Example of changes in roles can be found at almost every end user levels as processes are
automated, done differently or eliminated.
Examples of roles becoming redundant can be found in bank reconciliation (wherein IFMIS allows
centralized reconciliation by a small team) as opposed to it being done at individual locations.
Document examination personnel at central locations may no longer be required as responsibility
shifts to ministries etc.
The challenges in various scenarios are:
• Introducing new roles requires personnel can be inducted into the civil service and ensure
they are accepted in their new role by other personnel within the government. It also
requires all personnel to understand the role played by the new personnel.
• Changing roles requires training personnel on their new roles, encouraging acceptance of
the new role and to foster ownership of the new system;

• Making roles redundant is more complex as it requires redeployment of personnel to new

roles and encouraging acceptance. In extreme cases it might require termination of
employment if the personnel cannot be provided alternative employment suitable for their
knowledge and skills.
This task of organizational impact assessment must be carried out by a team of human resource
specialists supported by management and support teams as it is a cross functional exercise. The
support teams contribution comes in the form of defining new processes and its impact, human
resource specialist’s role would be to define the new role and corresponding responsibilities (plus a
host of other HR related aspects like pay scales, position in structure, eligibility for facilities etc.).
Management’s role would be review and approve changes.
3.4.8 Sustainability
The issue of sustainability has been highlighted in various sections and is reviewed and managed
under change management activities. Focus areas for sustainability are:
• Ability to recruit, train and retain qualified personnel to operate and manage the systems;
• Ability to operate and maintain the application solution;
• Ability to develop internal structures for supporting the implementation;
• Ability to maintain the infrastructure;
• Ability to fund the various operational and maintenance requirements.
3.4.9 Impact of other PFM initiatives
Most IFMIS projects are conceived as part of broader public financial management projects which
apart from the IFMIS (which focuses on reform of financial management) would involve parallel
reform projects in policy & planning, procurement, audit, civil service etc.
Since implementation of an IFMIS system affects some aspects of all the other reforms, it is essential
to conduct an impact assessment on both sides i.e. from the financial management reform
perspective and the perspective of all other reforms.
This requires excellent coordination and sharing of information at the program level. This however
does not happen often and at times the reforms progress on individual paths either duplicating
effort, conflicting at a later date.
For effective coordination, in environments where numerous reforms are progressing

simultaneously effective change management strategies must be put in place at the program level.
Individual project change management activities should not be expected to perform this role.

3.4.10 Consultants and Dependencies
Similar to the issues presented in section 3.4.9, numerous reform activities also mean numerous
consultants on the various projects causing dependencies which if not well managed leads to
conflicts in advice from various consultants and this adversely affects project implementation. The
most common impact is scope creep & delays (due to changes in objectives, strategies and scope of
work). This aspect must also be well managed at the program level.

3.5 Quality Assurance
Quality Assurance is a continuous process and all key project deliverables including all scheduled
documentations and meetings must undergo quality reviews. Project activities have to be designed
with quality standards to facilitate project management and quality control.
The QA strategy should identify planned interventions and milestones within the project cycle during
which critical quality checks have to be conducted and approved by the client as a pre-requisite for
ongoing project activities. The strategic activities envisaged under the interventions should involve the
constitution of relevant purchaser and supplier teams, conducting tests in accordance with pre-
defined acceptance criteria and identify issues in order to arrive at mutually acceptable conclusions.
These tests should be carried out in accordance to agreed Acceptance criteria and test plans which
should be developed and documented by supplier and client Teams. Any defects identified during the
tests should be marked and prioritized for resolution.
3.5.1 Methods & Reporting
Example of methods for use to monitor and control quality on IFMIS projects are:
• Reviews;
• Testing;
• Surveys / questionnaires;
• Audit of the QA activities;
3.5.1.1 Reviews
The general purposes of reviews are to:

• Provide a forum to evaluate the content and correctness of the deliverables;
• Help ensure consistency among deliverables;
• Verify deliverables conform to specified standards and guidelines;
Reviews provide a method of verifying and evaluating completeness, consistency, conformity,

objectives and clarity of work in progress and the ultimate deliverable.
However, reviews can easily become more subjective than objective if not managed effectively.
Review objectives vary depending upon the magnitude, complexity, or type of work to be reviewed
and it is therefore important that the objectives and purpose of each deliverable are clearly
defined.
3.5.1.2 Testing
Testing is the other important quality control technique to be primarily used to determine and
control the quality of application-level deliverables. Testing is used to compare and verify actual
results against expected results or established standards in an objective manner. Therefore, test
objectives should be defined clearly, as early as possible in the project lifecycle. Comparisons
between expected and actual test results are generally quantified and classified to highlight
strengths and weaknesses.

Testing does not just apply to software, but to other aspects of the project. Testing could be used
as a quality control for:
• Specifications.
• Procedures.
• Sub-systems.
• Operations.
Testing may be performed during specific project phases and activities. Automated tools for testing
should be used wherever applicable.
3.5.1.3 Surveys and Questionnaires
A third quality control method that can used on a project is surveys and questionnaires. Surveys
are particularly valuable when conducted at the end of a project to measure stakeholder
satisfaction with the project approach, processes, and techniques, as well as a measurement of
satisfaction with the end product.
For example, they may be used on a regular basis to measure stakeholder satisfaction with services
provided. Input and data from the survey instruments are used to modify service offerings, adjust
internal training programs, and improve the overall quality level of professional services rendered.
For the IFMIS project, it is intended that they would be mainly used for training and sensitization
sessions.
3.5.1.4 Audit
QA Audits are formal reviews conducted when the deliverable produced becomes the foundation
for future work or sign-off; and diverse participation is necessary to verify accuracy and
completeness.
The key objectives of a project review and audit which normally involves all the methods described
in the preceding sections are:
• To review current project management processes, controls and organization against best
practice.
• To assess the status of current plan(s).
• To highlight significant project risks and to make recommendations to remove or mitigate
these risks.
• To agree critical milestones with the project team against which progress will be reviewed.
• To agree future reviews and sign-offs.
• To recommend short-term changes and to agree an implementation plan for longer-term
actions.
3.5.1.5 Reporting
The outcome of the activities above are usually captured in a Quality report. A Quality report
establishes the status of the project and its performance within its contractual obligations. It
provides an assessment of the current satisfaction of the customer’s expectations and an objective

assessment of where the project management team, planning, resource co-ordination and
approach for the project may be strengthened.
QA Reports would be prepared on a quarterly basis to align with the Quarterly Project Reviews.
Quality Reports prepared by Supplier QA resources arising from scheduled Quality Audits and
reviews should be forwarded to client project management team for consideration.
3.5.2 Standards for Deliverables
Standards are essential for quality assurance work. All outputs need to be measured / evaluated
against agreed standards.
Standards differ by project component and below are some examples of requirements for standards:
3.5.2.1 Application Solution, System Software and Infrastructure
Each process / infrastructure component needs to have the following standards defined:
• Process / Infrastructure component;
• Conditions to be tested;
• Expected outcomes;
During the testing process, the actual outcomes are recorded in a test log and variations if any are
recorded in an issue log. The issue log should have the following details:
• Issue Number & Date;
• Type e.g. Requirement Clarification, System Related, Malfunction … (this helps in
categorization, assignment and prompt resolution);
• Module / Component;
• Description;
• Priority – Low (0 – 1), Medium (2 – 3), High (4 – 5) (normally a product of impact &
probability);
• Recommended Action;
• Status – (Open / Closed);
• Resolution;
3.5.2.2 Documents
Standards for documents need to be agreed upon at the project inception stage. Minimum details
required are:
• Objective / Purpose;
• Evaluation Criteria;
• Timing;
Below is an example of a document standard:

Document: Requirement Validation Document
Objective / Purpose: To map IFMIS requirements from the bid document to the application
solution, identify gaps and define customization requirements.
Evaluation Criteria: the document should:

• Explain the purpose of the document and how it was derived;
• Conform to all Bid Specification Requirements;
• Present all the process maps showing input, outputs (reports) and processing;
• Overview of product functions;
• Provide gap analysis between the product functions, bid requirements and client
processes;
• Show snap shots of relevant screens and the customization requirements;
• Provide a detailed description of all the reports (or make reference to where these are
defined);
• Define the Acceptance Criteria;
Timing: Part of Quality Review process.
3.5.2.3 Project Management Deliverables
Standards for project management deliverables need to be agreed upon at the project inception
stage. Minimum details required are:
• Objective / Purpose;
• Evaluation Criteria;
• Timing;
Below is an example of a project management deliverable standard:
Objective / Purpose: Project is delivered professionally with minimum risk exposure through
use of a structured methodology.
Quality Standards
• Steering Committee meets quarterly and minutes produced promptly;
• Steering Committee is effective in managing issues;
• The PMT and Steering Committee include adequate representation from the
Stakeholder Groups primarily affected by IFMIS with clearly defined roles and
responsibilities;
• Status Reports up to date and produced regularly in accordance with Plan and include:
Quality Outcomes, Issues, highlights of Major Risk Issues arising; and required actions /
recommendations;
• Risk Matrix kept up to date and comprehensive of all the major risks;

• Project Charter Produced. All Project activities and resources clearly identified;
• Quality System / Plan in place, with Quality Log, Files, etc.
• Change in configuration from agreed requirements validation addressed through formal
change process;
• PMT receives timely and regular inputs from project work groups to assure qualitative
delivery including:
- Core Application Team;
- Core Technical Team;
- Training and Change Management;
- MTEF Budget Workgroups;
Timing: This review will be undertaken at commencement and quarterly thereafter.
3.5.3 QA Plan
This document builds upon the Quality Assurance (QA) strategy to identify roles and responsibilities
of parties to the project and provide guidance and formats to specifying quality criteria for key
deliverables on the project. The result of the QA plan is to incorporate a “Quality by design”
approach into the project to ensure that all activities are performed in accordance with project
objectives and all deliverables meet contractual requirements.

3.6 Human Resources
The most critical resource for an IFMIS project is human resources. The best application solution
implemented on a state of the art infrastructure is useless if it cannot be appropriately operated and
maintained. The ability to configure, operate and maintain a system is a critical success factor and this
depends on people.
It is important to have a good understanding of available competency and the extent to which they
can be built up. This assessment assists in adapting an appropriate solution as opposed to one that is
technologically most advanced (which is common in many tender situations).
3.6.1 Competency assessment
Competency assessment involves first identifying the core knowledge and skills requirements for
performing various roles within a government. Since the focus of an IFMIS is in the area of finance (&
human resources if included), the primary objective should be to carry out this assessment for all
roles related to planning & budgeting, financial management, material management, asset
management etc.
The next step should be to compare the competency of the various personnel performing the roles
against the defined competency requirements. The outcome of this assessment will enable a better
understanding of current human resource capabilities. If competency levels are low, even with
training, it is unlikely that the human resource capabilities will scale up to the requirements of
operating sophisticated systems and hence a decision to implement a less sophisticated system
would be more appropriate.
There are instances wherein existing manual systems are in a poor state and the root cause is lack of
required competency e.g. poor accounting skills. Introducing an IFMIS into such an environment is
unlikely to succeed because the IFMIS is a tool that needs to be effectively used by people, it is not a
substitute for people. Many systems implementations have failed due to this reason especially after
the project’s external consultancy input ends. In almost all cases, all blame for failure is placed on
the supplier or the system but the reality is different.
3.6.2 Meeting competency requirements
The outcome of competency assessment helps establish the gap between what is required and what
is available. Ideally the key questions to consider are:
• Do the core competencies exist across the organization? This is in the area of accounting,
procurement, material management, asset management etc. If existing manual systems are
in a poor state already, this question becomes even more critical. Introducing an IFMIS will
not overcome these weaknesses.
• How can the core competencies be acquired? The options are training, recruiting competent
people, consultants etc. These are discussed in later sections.
• How long will it take to develop core competencies? This is a significant aspect and assists in
determining short, medium and long term HR strategies.
• What type of solution to aim for? Organizations with high competency levels can aim for
sophisticated systems as there will be capacity to make effective use. Organizations with mid
level competency levels should aim for mid range solutions that are robust but easier to

implement and operate. Organizations with low competency levels are unlikely to benefit
from implementing any solution and should strive to improve core competency levels before
pursuing information systems strategy. Failure rate of implementing information systems
solution in low competency environments is very high.
3.6.2.1 External vs. Internal Recruitment

One of the approaches to meet competency shortage is to recruit suitably qualified people. Such
recruitment can be from within the organization or from the labor market.
Recruiting from within might sound unusual but there are many instances of availability of suitably
qualified people who are in unsuitable roles without opportunities for growth. An open internal
recruitment drive allows anyone with competency to apply. Key benefits of this approach are that
the personnel are already part of the government, would have some relevant experience, would
have good working relationships with other colleagues and are attuned to working under standard
civil service employment terms. Key issues might be obtaining their release from current roles and
civil service procedures for transferring personnel.
Employing from the open labor market is the second recruitment option. Competency
requirements can be advertised and applications sought through the normal government
recruitment procedures. Key benefit is the ability to seek applications from a larger pool of suitably
qualified persons. The key issues might be availability of competent personnel in countries with
low output from educational institutions, willingness of applicants to work under normal civil
service employment terms and time taken to integrate with existing government personnel.
3.6.2.2 Role of consultants
In situations where required competencies cannot be acquired through normal internal or external
recruitment processes, an option is to employ consultants who can bring in required competencies.
Key benefit is immediate availability of required competencies. Key issues are ability to fund high
costs associated with employing consultants, time taken by consultants to understand roles and
become effective (considering that their tenures are short), gaps left when contracts end and
ability to integrate with other government personnel for effectiveness.
3.6.3 Key issues with HR
Key issues with human resources encountered in many implementations are outlined below:
3.6.3.1 Project contracts
One of the approaches adapted in some projects is to employ people on special contracts for the
project. While this resolves problems of immediate competency requirements, problems surface in
the following areas:
• Ability to fund costs associated with such contracts once project funding ends;
• Contracts ending while projects are being implemented especially if there are delays;
• Gaps left after such contracts elapse and personnel leave;
• Resentment from personnel on civil service employment terms as they do not get similar
terms;

• Skills transfer to understudies especially when such skills transfer is not well managed;
3.6.3.2 Salary Top-Ups
This approach is used on some projects to motivate government personnel. The principle is good in
environments where general terms of employment in government are inadequate. The approach
serves the objective to an extent but starts failing when project funds run out and personnel with
such top-ups loose motivation to sustain project activities. The impact is very similar to personnel
employed on special contracts.
3.6.3.3 Integration of Support Teams in Civil Service
In some projects, the approach to overcoming competency gaps is to employ personnel into
government civil service but to start with on project contracts with the understanding the
employment of such personnel will later be regularized into the civil service. This is done to reduce
time taken to employ which can be substantial under the regular civil service recruitment process.
The major issue with the approach is the time taken to regularize the employment into civil service.
In many instances this takes too long and in the meantime contracts end or funds run out and
there is an exodus of highly trained personnel. This has a major impact on sustainability and causes
projects to fail or limp along realizing very few benefits.
3.6.3.4 Retention
Retention of trained personnel especially support team members should be a high priority to the
extent feasible. The team is trained at a considerable cost, have most of the institutional history of
the implementation and have developed skills necessary for provision of support. While it is always
possible to train new personnel to replace departing ones, it is a matter of cost and maintaining
continuity.
There are numerous reasons for people leaving. Some have solutions that are relatively easy to
resolve while some are complex. Some common issues that can be resolved with relative ease are:
• Lack of clarity of role and responsibilities;
• Inability to work with managers;
• Frustrations resulting from poor decision making processes;
• Lack of growth path;
• Inadequate resources to execute tasks;
Issues that are relatively difficult to resolve are:
• Ability to retain contract employees and consultants once project funds run out;
• Ability to match employment terms with what is offered in the market;
• Promotion to higher level position;
If retention of personnel is difficult as a result of inability to match employment terms, an

alternative strategy to train more personnel must be pursued.

A costs benefit analysis of either improving terms for existing employees or employing more
personnel and training should be carried out to decide on the optimum approach.

3.7 Project Management
IFMIS projects tend to be large, cost a substantial amount of money, involve large number of
stakeholders and have a profound impact on the operations of a government. Managing the project
well is central to achieving success.
Project management can be based on various methodologies; the objective in this document
therefore is not to present any specific methodology but to define the role of project management in
an IFMIS project and present some of the key aspects.
In simple terms the role of project management is achieve project objectives within a specified
timeframe and budget.
The major components of project management can be summarized as follows:
3.7.1 Project Steering Committee (PSC)
The Project Steering Committee functions as the management body for the project. It is the forum
where all-high level decisions and issues relevant to the project are discussed and resolved. It is
made up of the senior management charged with direct responsibility for the IFMIS Project. The
supplier project manager is normally invited to provide monthly status updates to the Steering
Committee.
3.7.1.1 Roles and Responsibilities of PSC
The Steering Committee should meet on a regular basis to review progress reports and make policy
decisions on the IFMIS implementation. The Committee should be responsible for:
• Providing overall policy guidelines for the IFMIS project;
• Ensuring commitment at the highest levels of government to the IFMIS project;
• Articulating a high level description of the IFMIS project scope;
• Setting overall priorities;
• Advocating the impact and benefits derived from IFMIS implementation;
• Confirming IFMIS project goals and objectives;
• Committing and monitoring resources and budgets;
• Reviewing IFMIS project progress;
• Endorsing milestone achievements;
• Providing resolution of escalated issues;
• Endorsing organizational, policy and strategic changes decisions;
• Leading / championing any business changes that may be required by the implementing
entities as a result of IFMIS implementation;

3.7.2 Project Management Team (PMT)
The Project Management Team (PMT) should be a multidisciplinary team that should meet every
week to oversee implementation progress. The Supplier Project Manager should present the weekly
Project Progress Report to the PMT.
The mission of the PMT is to effectively manage the introduction of the IFMIS within the time frames
specified in accordance to the following objectives:
• Clearly defining the scope, goals and objectives of the IFMIS project;
• Identifying the project risks and developing a strategy for risk management;
• Determining project resource requirements and budget accordingly;
• Meeting all quality assurance standards for project management;
• Managing all stakeholders’ expectations and information needs;
• Building capacity within client organization to support effective IFMIS operations;
• Minimizing disruption to the stakeholders, both internal and external during IFMIS
implementation;
3.7.2.1 Roles and Responsibilities of PMT
The role and responsibilities of the PMT are:

• Project scheduling and resource management;
• Risk management;
• Communication;
• Capacity Building, change management and training;
• Procurement and IFMIS contract management;
• Site preparation and readiness issues;
• Technical liaison with the Supplier;
• Assess conformity of deliverables against set quality criteria;
• Advise IFMIS Implementation Manager on quality issues that have to be communicated to
supplier;
3.7.3 Project Manager (PM)

The IFMIS Project Manager (PM) is the single point of contact from client’s side and accountable
within the client’s organization for timely delivery of all aspects of the project. This role has the
following responsibilities:
• Act as an interface for the project between client and supplier;
• Own the Project Plan on behalf of the client;
• Participate in meetings and activities to ensure the project is executed according to the plan;
• Ensure that client staff make themselves available to the Project;
• Ensure that facility and resources required are provided and maintained;
• Ensure that the planned activities that are client responsibility are executed;

• Ensure execution of all project reviews and issue tracking from the client side;
3.7.4 Application Team
This team should be made up of personnel with domain expertise in the application area who can
then be trained as part of the project for internal capacity building. This group should be responsible
for all application systems. The role and responsibilities of the team are:
• Participation in solution build at all stages;
• Overseeing data compilation and verification;
• Acceptance testing for the solution build;
• Production system configuration;
• Implementation preparation;
• Provision of first line of end user support for application issues;
• Training of end users;
3.7.5 Core Technical Team

The core technical team should be made up of personnel with domain expertise in infrastructure
who can then be trained as part of the project for internal capacity building. The group should be
responsible for the technical infrastructure. The role and responsibilities of the team are:
• Installation, testing and commissioning of IFMIS technical infrastructure;
• Implementing user access and security levels;
• Acceptance testing of technical infrastructure;
• Implementation preparation;
• Data importation and migration;
• Provision of first line of technical support;
3.7.6 Workgroups
Workgroups are smaller teams with limited focus on specific project areas. Examples of work groups
are:
• Quality Assurance Workgroup;
• Capacity Building Workgroup;
• Change Management Workgroup;
• Security Workgroup;
• Audit Workgroup;
In general responsibilities of such workgroups should be:
• Contribute on issues pertaining to their domains;

• Review implementation in their domain;
• Liaise and guide users on implementation issues;
• Report progress to project manager;
• Identify issues & risks and mitigation approach in the respective areas;
3.7.7 Project Methodology
The project methodology to be adapted depends on the application system, supplier methodologies
or client preferences. It is essential to adopt a methodology as it will define a number of project
management processes. These include:
• Team formation, roles & responsibilities
• Planning and execution;
• Project documentation;
• Issue management;
• Resource management;
3.7.8 Project Progress Control
Project progress control consists of management of performance against the project plan. The task is
complex at it requires co-ordination of a large number of activities involving many team members
and stakeholders. Since project durations range from 6 – 18 months, the project needs to be
managed on a weekly basis to ensure that there are no slippages. The control function consists of:
• Compiling project progress reports by all workgroups and teams (in their respective areas).
The progress report must contain planned activities, current status against plans, deviations
& reasons for same, corrective action required, targeted dates for resolution and
responsibility for action.
• Review of all deliverables and outcomes of quality reports related to the deliverables;
• Review of resource allocation and resolving any conflicts in allocation;
• Review of issue log – adding new issues and tracking progress of issue resolution;
• Review of risk log – adding new risks and tracking identified risks for resolution;
• Identifying actions that need to be escalated to top management for decisions;
• Tracking project funds and utilization of the same;
• Reviewing any contractual issues for resolution;

3.7.9 Key issues with project management
Project teams can encounter numerous issues during project execution These can originate from
within the organization or from suppliers side. Examples of common issues are:
• Non availability of resources;
• Delays in deliveries;
• Delays in site works;
• Technical problems with software or hardware;
• Problems with availability of data;
There are however certain key project management issues that merit specific mention here and
these are as outlined in sections below:
3.7.9.1 Top Level Management Involvement
For projects to succeed top level management involvement is crucial. Top management has
responsibility for setting objectives, defining strategies, allocation of resources and making
decisions on critical issues. If top management is not involved, show little interest in the project or
are unable to attend important meetings, a number of critical aspects remain unresolved for too
long affecting the project team’s ability to function and hence adversely affecting project progress.
3.7.9.2 Levels of Authority and Decision Making
If project management teams are to be effective, they need requisite authority to make decisions.
It Is not unusual to find that project management teams have limited authority and this requires all
decisions to be made by top management. In practice this approach causes a bottleneck in the
decision making process affecting the project team’s ability to function and hence adversely
affecting project progress.
Another common issue is the approach of decision making by committee. This requires extensive
rounds of meetings, reviews and responding to every possible comment or objection. The issue is
not to discuss the merits or demerits of this approach, but to point out the negative impact on
project execution. This approach causes decision making to take a inordinately long time wherein
every point of view and comment must be considered and catered for. In many instances
incorporating everybody’s point of view leads to change in project scope, objectives and strategies
further impacting project progress.
3.7.9.3 Lack of funding
Inadequate funding for activities especially on projects that require counterpart funding is an issue.
Lack of funds or delays in making funds available, cause activities to be delayed thereby affecting
project execution.

3.8 Funding
Every component of the project requires funding and provision must be made for the same to ensure
project activities are completed on schedule. Projects are financed in various ways. Commonly found
options are:
• Financed from government budget;
• Financed through bank loans;
• Financed through single or multiple donor grants;
• A combination of government budget, bank loans and donor grants;
The financing arrangements are beyond the scope of this document. In the following sections however
is a brief overview of funding requirements;
3.8.1 Project Planning & Procurement Stage
The first stage of an IFMIS project starts from the time project is formally conceived and ends with
the award of a contract for supply and implementation of an IFMIS project. The key tasks typically
performed at this stage are:
• Formulation of objectives and strategies;
• Conducting studies of similar projects (normally by means of site visits to sites where IFMIS
has been implemented);
• Formulation of project. This includes defining requirements, tendering procedures, draft

contracts, funding arrangements, compiling tender documents, evaluation approach etc.
• Recruitment of key team members including project manager and application / technical
team personnel. At this stage sometimes decisions regarding salary topups are also made for
key government officials who will be associated with implementation of the project.
• Conducting the tendering process, evaluation of bids, discussions with bidders and contract
negotiations.
• Capacity building – by means of training programs for key project team members.
The work can be done government personnel or consultants employed for this purpose. It is quite
common to find this work being done by consulting firm or individuals consultants employed for the
purpose.
3.8.2 Project Implementation Stage
The second major stage of an IFMIS project is the implementation stage. This stage commences
when a contract is awarded and project implementation work commences. The project can be
delivered on turnkey basis or by means of numerous contracts. Key funding requirements during
procurement stage are:

• Payment for procurement of goods and services based one or more contracts;
• Costs associated with training of personnel especially where allowances are paid to
personnel attending training courses;
• Costs associated with change management activities – meetings, seminars, various

communications etc.
• Costs associated with site preparation works e.g. civil works, electrical works, environment
conditioning works, furniture etc.
• Costs associated with any consultants engaged by government for various functions;
3.8.3 Change Orders
In every project, there are instances when changes are made to the project which results in
additional costs. These are managed through change orders for which costs are established and
decisions are made based on relevance, priority, cost and availability of funds.
3.8.4 Post Implementation Stage
This stage commences after the go-live stage of systems and final acceptance of deliverables at this
stage the IFMIS system should be in operational status and key funding requirements are:
• Training of users as part of capacity building;
• Maintenance of software and hardware;
• Support services;

4 IFMIS Project Process

4.1 Planning and Requirements Specification
The first stage in an IFMIS project (assuming the government has decided in principle to pursue such a
project) is the Planning and Requirements Specification Stage. The tasks carried out in this stage lay
the foundation for the project, and hence it is essential that significant thought must be given to all
aspects of this stage.
In order to enable planning and requirements specification, it is essential for the government to setup
a cross functional team that will be responsible for the exercise. Team members should have good
understanding of functional (operational) aspects of their respective domains. This should include
knowledge of current operations, drawbacks / problems in current operations and desired outcomes.
Various approaches are used by governments to assist in planning and requirements specification,
some of which are outlined below:
a. Study of projects implemented in similar environment. These could be in the form of study
tours by a representative group and review of project documents (if made available by the
host). The approach generally assists the team to gain awareness of possibilities and pitfalls.
The approach however suffers from the risk of being given misleading information about the
success, failure or capabilities of a solution or vendor based on individual bias.
b. Request for information as part of Expression of Interest. This approach would help in gaining
better understanding of available solutions and vendor capabilities. If required vendors can be
requested to make presentations of their solution.
c. Study of Standards. This requires the team to identify suitable standards for such
implementations and use available information of determining requirements and approach to
project.
d. Employing Consultants. A common approach used by many governments is to employ

consultants to assist with specification of requirements and also to assist with the
procurement process. At times this approach suffers from the problem of consultants
promoting specifications and solutions they have worked with irrespective of suitability in the
client’s environment.
4.1.1 Vision, Objectives and Strategies
Irrespective of the approach used, the starting point is to define the vision for the project. This
should clearly outline the desired outcome and timeframe for achieving the same.
The objectives should be defined with specific targets (quantifiable and time based) (refer to section
2.2 on objectives). Strategies should then be formulated to further elaborate how the objectives will
be met.
While formulating strategies, it must be understood that all objectives will not be met by the
application solution or infrastructure (i.e. automation alone will not meet all objectives). Strategies
must be formulated for all components of the project (section 3). Failure to formulate and articulate
strategies for all components will result in a partial solution with a very high risk of failure and this is
a common problem identified many failed projects.

4.1.2 Functional requirements
Functional requirements refer to the capabilities of the required solution. Requirements can be
specified as mandatory, optional, nice to have etc. Significant thought needs to be given to
specifying requirements for each component of the project and not just software and hardware (as
is common in many tender documents).
Functional requirements must consider current status of government operations, available

competencies, ability to implement, funding constraints etc. Sometimes specifications are copied
from other tenders or are based on what a consultant is familiar with, without much thought to
actual requirements. This approach leads at times to specification of requirements far in excess of
actual requirements and result in large projects that are way beyond the organization’s ability to
implement setting the stage for a costly failure. It is also possible to find the opposite wherein
requirements are very poorly defined, simple solutions are considered adequate and when
implemented, fail to meet actual requirements leading to significant loss of time and the need to
redo the project. The latter is common where in-house or local development is undertaken as an
approach for IFMIS project.
While defining requirements, it is equally important to limit the number of parallel initiatives to a
minimum or in line with the organizations ability to competently manage. Too many initiatives
introduce complexity in terms of coordination, dependencies, allocation of scarce human resources,
competing / contradicting activities, duplication of effort etc. All of these eventually lead to high
costs, severe delays in execution and high risk of failure.
While defining requirements it would also be worthwhile to consider immediate, midterm and long
terms requirements (1 - 2 years, 2 - 3 years, 3 - 4years). The requirements can be phased in the
following manner:
Stage 1 – Data and Operational Procedures - focus on ensuring all data is properly recorded and
processed with appropriate controls. This approach ensures that all information is recorded, is
traceable and that there is compliance with operational procedures. The stage introduces substantial
change in operations and also offers quick successes to sustain implementation.
Stage 2 – Reporting and Analysis – while standard operational reports are produced in the first stage,
more detailed analytical reporting should form the next stage. The objective is to focus on advanced
features, additional controls and analysis of information. The target would be to enhance
compliance, improve decision making and improve efficiencies.
Stage 3 – Planning – with access to considerable data, operational reporting and analytical reporting
the stage is set for to focus on use of available information for effective planning including
conducting what-if analysis. Cash flow management, procurement planning etc. would be ideal
aspects to consider.
4.1.3 Organizational scope
Part of the requirements specification process includes defining the organizational scope i.e. what
components of the government’s organization should be considered for implementation of the
IFMIS. Normally the following organizational components can be considered for implementation
(together or in a phased manner) (please note that terminologies vary across governments):
• Central government ministries;

• Regional sub-treasuries / sub-accountancies;

• Executive Agencies;
• Local Authorities;
• Government Parastatal Organizations;
The organizational scope has a significant impact on requirements specification especially in terms of
the application solution and infrastructure. The objective again should be to phase out the
implementation to avoid excessive complexity and very high costs.
One of the areas that need special attention in this process is the various independent “project
units”. It is common to find that many projects are being executed in various ministries as
“independent” accounting entities. This is normally the outcome of donor requirements to maintain
separate accounting and banking arrangement for projects for control and reporting purposes. The
approach is normally taken due to lack of confidence in the government’s financial management
system and also to “safeguard” funds allocated to projects from being diverted to other uses.
Ideally the projects are required to submit returns to the ministry of finance for inclusion in
preparation of various reports including the government’s final accounts. In reality the process does
not work well and there are major gaps in provision of such information. The government’s accounts
therefore do not provide a correct reflection of all funds flows, expenditure and procurement
activities which subsequently also affects use of the information for any planning purposes.
The introduction of an IFMIS should therefore consider centralization of all project accounts,
integrating them seamlessly with the government’s financial management system but without
sacrificing the need for appropriate controls on use of funds or provision of reports. This will provide
the government with a comprehensive view of all government financial activities while ensuring
donors on application of appropriate controls and provision of reports. The process also eliminates
the need to manage a large number of independent bank accounts. The process however meets with
resistance from various operative staff as they incorrectly perceive it as a loss of control. The IFMIS
system actually allows the project operative staff to have full control over the project budgets, funds
and all payments without having to maintain separate bank accounts.
In defining organizational scope other areas of possible conflict is where some government
organizational units embark on their own independent automation initiatives and resist any
attempts to join the central IFMIS implementation strategy. If a number of independent initiatives
are allowed to go ahead, the end is a multitude of systems that cannot communicate with each
other, cannot be meaningfully consolidated and lead to failure to effectively manage government
resources. It is important to point out that it is not uncommon to find such situations in
governments.
4.1.4 Determinants for Infrastructure Design
Outlined in section 3.2.1 are some of the key determinants for infrastructure design and must be
clearly outlined in the planning and requirements specification stage. Part of the planning and
requirements specification task is also to project anticipated growth over a period of at least 5 years.
Many tender documents have little or no information on the key determinants and hence result in
tender responses that vary very widely depending on the assumptions made by the company
submitting the tender. Comparison and evaluation of such widely varying tender responses is a
major challenge, creates opportunities for misrepresentation of cost of the project and also becomes
a major source of conflict at implementation stage (if issues are not picked at the contract stage). In

the absence of key determinants the stage is also set for submission of “foot-in-the-door” bids that if
awarded (as they will be low in cost) will lead to numerous “change requests” with huge cost
escalation at the execution stage.
4.1.5 Timeframes
The project timeframe defines the anticipated start and end dates for the project (or phases as is
relevant). It is not uncommon to find very ambitious timeframes which quickly point to the fact that
sufficient thought has not been given to the issue of time required to implement.
Some of the aspects to consider while defining the timeframes are:
• Time required for internal reviews and decision making (within the government). In most
instances this time is grossly under estimated. Almost all key government decision making is
by committee and the approach requires considerable time for preparation, discussion,
agreement and approval. An IFMIS project will require many decisions from the planning
stage through to project closure and adequate provision must be made for the review and
decision making process.
• Time required recruiting and employing personnel for key positions. This will be determined
by the government’s procedures for recruitment. Sufficient time must be allowed to ensure
key personnel will be in their respective positions before project execution commences.
• Time required for tendering, evaluation and award. This will be determined by the
government’s procurement procedures (and will also be influenced by the donor’s
procurement procedures of relevant). Some processes can be very elaborate and sufficient
time must be provided for the same.
• Time required for completion of any government tasks on the project. A classic example is
completion of any civil / electrical works for the project. Another common example is
collection, compilation, certification and submission of data required for setup of systems
before commencing implementation.
• Time required to Go-Live. This will be determined by a number of factors like:

o Logistics (time to order, freight, clear and receive goods);
o Time to validate requirements (review of requirements through to agreement on
final blue print);
o Time to build solution (customizing and configuration);
o Time to train personnel;
o Time to execute various change management activities;
o Time to install, configure and commission infrastructure;
o Time to test the solution;
There is a general tendency to require this time to be as short as possible and in many
cases unrealistic / ambitious timeframes are specified. Since the time to implement is a
tender condition, most bid submissions will present plans that fit into the requirement
but the reality off many projects shows that such targets are rarely if at all ever
achieved.

In project contracts, there are numerous provisions for penalizing suppliers / contractors for delays
and this assists in ensuring that suppliers / contractors adhere closely to project schedules. It is
however rare to have similar provisions for delays on client side and as a result the client’s Project
Manager does not have much leverage in ensuring the internal delays are minimized. Sufficient
effort must be made internally to sensitize all concerned on the importance of adhering to project
schedules.
Another important aspect to consider when defining timeframes is the beginning of the client’s
financial year. It is ideal to commence live operations as the beginning of the financial year as
everything starts with a clean slate i.e. new budget, clean bank accounts, new allocation of funds etc.
System setup requirements are simplified and reports are easier to interpret. If on the other hand a
go-live date is within a financial year, a significant number of issues arise. At the time of go-live, the
effort required to derive data for system setup is complex e.g. data required would include details of
unspent budgets, pending allocations, pending payments, pending purchase orders, details of
commitments made, details of pending imprests etc.
An additional complexity of go-live within a financial year is that part of the accounts will be on older
system (manual or automated) and part on the new systems. This affects production of reports and
especially compilation of final accounts. In certain instances, clients have tried to enter all backdated
data (from beginning of financial year up to time of go-live) but this approach is fraught with
problems as it imposes a double burden on staff, most data validation on system cannot be carried
out (as it is backdated information) and is subject to numerous errors. These problems eventually
result more work to clean up the data leading to significant delays in project implementation.
4.1.6 Expected Outcomes
The planning and requirements specification process must clearly articulate expected outcomes.
These must have measurable targets assigned and should form part of the project charter.
Outcomes can be specified for may project components, examples of which are provided below:
• Infrastructure – systems to be installed, network coverage, expected operational capability;
• Application – processes, reports, controls;
• Capacity Building – personnel trained, skills transfer;
• Change Management – activities, feedback;
The expected outcomes must be agreed upon both within the government and the supplier /
contractors. One of the main tasks under change management should also be to regularly evaluate
progress and establish whether the outcomes have been achieved or not providing supporting
evidence. Tender documents must also articulate expected outcomes and request the bidders to
elaborate on how the outcomes can be achieved.
4.1.7 Phasing
The implementation of an IFMIS project can be carried out is phases with each phase having specific
objectives. Some of the reasons leading to breaking up the project into phases are:

4.1.7.1 Proof of Concept
In this case the overriding criterion is to demonstrate that the plan is workable and the approach is
sound by restricting the implementation to a few organizational units normally called the pilot. If
the system can be demonstrated to achieve the objectives in the pilot then a rollout can be carried
out to other sites. Key benefits of this approach include:
• Reducing complexity by focusing on a smaller number of organizational units;
• Reduce possibility of making costly mistakes by reducing initial scope;
• Enable IFMIS team to gain experience of implementation which can then be effectively
employed in the rollout;
• Enables review the pilot and utilization of the experience to improve rollout;
• Enables review of the pilot and redesign the project if required;
• Enables a decision that the concept and plan are not viable thereby cancelling rollout.
4.1.7.2 Complexity
The objective here is to reduce the level of complexity and thereby risks in project implementation.
This can be achieved by phasing applications i.e. most critical requirements are considered in the
first phase and requirements with lower priorities are considered in later phases. Likewise, the
organizational scope can be split by priority areas. Key benefits are:
• Reduced complexity and hence reduced risk;
• Systematic approach based on priorities;
• Reduced simultaneous resource requirements;
• Reduced management requirements;
• Enables review implementation at each phase and utilization of the experience to improve
future phases;
4.1.7.3 Funding Limitations
In the event that there are limitations on funding of the project and that the full funding can
become available over a period of time, the project can be phased using a combination of
organizational scope and applications based on priorities.
4.1.7.4 Implementation Capacity
IFMIS projects require dedicated resources within the government for management and
implementation. If there are limitations on the availability of resources or competency levels of
available resources, it is better to split the organizational scope and applications into phases
thereby reducing simultaneous resource requirements, complexity and management
requirements.

4.1.8 Funding
Funding refers to financing requirements for project implementation. The project planning and
requirements specification either works towards establishing funding requirements or works
backwards based on available funding and focuses on what can be achieved.
The first approach of planning and specifying requirements enables the government to consider all
requirements, arrive at the overall funding requirements and then make necessary arrangements.
The government can still stagger the investment by specifying priorities.
The second approach is restricted by availability of funds and hence the planning needs to focus on
limiting scope and mandatory requirements. Other requirements can still be specified but can then
be subject to availability of funds.
Depending on source of funds (or combinations of the same), additional considerations may need to
be made in terms of scope and requirements. Some development partners and donors insist on
further reviews of plans and requirements by their own technical teams who may propose significant
changes.
The funding component is covered under section 3.8 and more details of total cost of ownership is
covered later in section 4.6 (Total Cost of Ownership).
4.1.9 Key issues in Planning and Requirements Specifications
The planning and requirement specification process forms the foundation of the IFMIS project and
hence due importance must be given to the process. Some common issues to look out for in this
process are:
• Limited participation in the process by key stakeholders (end users, management ..);
• Capacity limitations in carrying out the process;
• Specifying an over the top (want everything possible) or very simplistic requirements (and
hence failing to meet requirements);
• Specifying requirements that will entail multiple initiatives increasing complexity;
• Blindly copying or accepting requirements because of a consultant’s familiarity with some

solution;
• Specifying requirements without due consideration for internal capacity to manage and
implement;
• Very ambitious timeframes;
• Under estimating funding requirements;

4.2 Procurement
The next logical step after completion and approval of the plan and requirements specification is the
procurement process.
The process is highly regulated in most governments and procurement processes including all
standards to be adapted (e.g. tender forms, evaluation, contracts) are normally defined. Further if the
project is funded by bank loans or donors then additional or alternative guidelines may have to be
adapted and applied.
Some institutions require a two step procurement process namely an Expression of Interest Stage and
a Tender Stage which is then restricted to bidders who qualify from the first stage.
Irrespective of the documents or approach used, the objective is to acquire a solution that meets
requirements at a reasonable price. While it sounds simple, the procurement process is, however
fraught with problems. Many IFMIS systems procurements have gone through more than one cycle of
procurement due to failure to proceed to contract signing.
4.2.1 Tender Compilation
The process of compiling a tender involves assembling the document to be issued to potential
bidders. The format and contents of the document varies across governments, banks, donors etc.
There are many standards that can be adapted for such purposes e.g. World Bank standards, EU
standards. Common sections include:
a. General Introduction - to the tender, details of procurement authority, deadlines for

submission etc.
b. Tender conditions – this section defines eligibility and conditions for bidding, required
qualifications, tender currency, submission of bids, evaluation process, contract process etc.
c. Bid Data Sheet – the section contains details of purchaser contacts, data for specific
conditions, variations to any tender conditions, evaluation criteria etc.
d. Tender Specifications – this section (or series of sections) contain a background to the
project, vision, objectives, strategies and detailed requirements specification of application
solution, infrastructure, capacity building and change requirements. It is essential to include
all determinants for infrastructure design (refer to section 3.2.1). Details of any phases
should also be specified (e.g. by organizational scope, applications, infrastructure). While the
other sections of tender document are essential from the procurement process point of view,
this section is the most critical in terms of ensuring that potential bidders fully understand
IFMIS requirements and can provide responsive bids. In many tenders this is the most poorly
written section while other sections tend to be very elaborate. Unfortunately this negates
the whole purpose of the process and clearly reflects the fact that very limited effort has
gone into the planning and requirements specification process.
e. General and Special Conditions of Contract – the section is included to enable bidders to
review the terms and conditions of contract to be signed if awarded the contract. The
general section contains all clauses of the contract, while the special conditions either
elaborates, changes or cancels any provision of the general conditions. The contract terms
cover all major execution areas including organization & responsibilities of client and
supplier, delivery requirements & penalties for deviations, project management & reporting

requirements, payment terms and conditions, supply terms and conditions, insurance
requirements, dispute resolution measures, contract terminations and remedies etc.
f. Standard Forms for Tender Response – normally all mandatory forms required for the tender
are specified in this section. These include bid form, details of bidders, financial information
of bidders, record of relevant experience, price schedules, descriptions of goods and
services, manufacturer’s authorization, bid security etc.
g. Standard Forms for Contract – standard forms to be used if contract is awarded are also
included. These include performance security, advance payment guarantees, change
request, project reports etc.
4.2.2 Bidder Briefing
Once the tender is issued, most tender procedures provide for interaction with potential vendors in
the form of a pre-bid meeting, site visits and clarification of tender documents. The pre bid meeting
is designed to brief the potential bidders on the procurement process and tender specifications. This
is an excellent forum for the government to elaborate upon the requirements and respond to
queries. It is an excellent opportunity for potential bidders to gain a better understanding of
requirements and clarify doubts. Unfortunately in most situations the presentations to potential
bidders are very poor and queries are generally not responded to or poorly responded to. This is a
general waste of an otherwise perfect opportunity to create better understanding.
Site visits are designed to enable potential bidders to assess requirements related to infrastructure.
In large projects, infrastructure constitutes a major component and careful assessment is necessary
for various requirements such as power conditions, local area networks, wide area networks,
logistical requirements and furniture requirements. In some tender situations site visits are
prohibited and this seriously undermines the bidder’s ability to assess the situation on the ground.
Such a prohibition if necessary should be compensated by provision of detailed maps of site
locations and building plans.
Clarification of queries is the third means of interaction wherein bidders can submit written requests
for information and the government can respond to the queries. General experience again shows
that the quality of responses is generally poor and does not assist bidders.
Using all options to brief potential bidders is a critical but poorly used aspect of the bidding process.
An IFMIS project is a critical project with impact across the organization and ensuring clarity of
requirements can be a major benefit for the government as it will enable better quality and
compliant bids. Poor quality and non compliant bids are some of the causes for cancellation of
procurement process.
4.2.3 Evaluation
The evaluation starts with review of bids and ensuring compliance to bidding requirements and
qualifications including submission of all mandatory guarantees and documents. Bids that pass this
stage can then progress to the next stage of technical evaluation wherein the bid responses are
verified again tender specifications and compliance or lack of it is recorded. The assignment of points
depends on the evaluation criteria agreed upon and published in the tender document. Points can
be assigned to the application solution, infrastructure design, capacity building, change
management, project management, implementation plan, resources assigned and experience. The
outcome of technical evaluation enables ranking of bids by points and bids below a certain threshold
may be rejected as being non-responsive.

Technical evaluation is difficult especially when widely different solutions are proposed as it is no
longer a comparison of like to like. For application system variations can occurs in terms of features,
technology, licensing approach, upgrades, updates, competency requirements, complexity and
support requirements. Hardware can again differ in terms of specifications and performance
benchmarks but is increasingly easier to compare due to extensive standardization in the industry.
Capacity building approaches can differ widely with option of in-country training or overseas training
(favored at times as it offers client personnel to travel outside the country). Change management
requirements if not properly specified can also lead to a widely differing response.
Technical evaluations are also difficult in terms of clearly understanding what is included in the bid
price and what is optional. It is common to find bidders quoting low with a lot of costs hidden (“foot
in the door approach”) only for such costs to become apparent at execution stage. Such projects are
subsequently subjected to numerous changes inflating the costs to levels far in excess of other bids
which would have been discarded as being expensive during evaluation. Despite this happening on
many projects, it is surprising that many evaluation teams continue to walk into the same situation
time and again.
Technical evaluation is followed by financial evaluation where all costs are compared. General
categories of costs are:
• Supply of goods (equipment, software etc.);
• Consultancy Services;
• Training Services;
• Implementation, testing and commissioning services;
• Support Services
The financial evaluation strives to compute overall costs to meet tender specifications. It is possible
that some costs are not specified by each bidder and in such instances normally the highest cost
specified by other bidders is used to arrive at the lowest compliant bid. It is important at this stage
to revisit the inclusions and exclusions for each component for each bid to ensure a fair evaluation is
carried out and to quickly weed out any “foot-in-the-approaches” that may distort the evaluation.
A combination of technical scores and financial scores leads to a ranking of bids that can then be
taken to the stage of negotiations.
4.2.4 Negotiations
Negotiations can be carried out with just one bidder (lowest compliant bid) or with top three ranked
bids etc. The approach will again be dictated by the procurement procedures of the government,
bank or donor(s).
The negotiations process is used to:

• Clarify any technical or financial issues;
• Alter quantities or make changes to scope and request for revised quotes;
• Seek efficiencies in costs e.g. government might decide to conduct more training using own
resources then envisaged in the plan;
• Review contract terms and clarify any issues;
• Achieve agreement on contract;
Depending on the number of clarifications, changes and price revisions, negotiations may need to be
carried out in 2 or 3 rounds to arrive at consensus. In the event that there is failure to reach

agreement and depending on procurement rules in effect, negotiations may continue with the next
ranked bidder or be cancelled and the whole bidding process would have to be repeated.
4.2.5 Contracts
The procurement process ends with the signing of the contract and fulfillment of project
commencement requirement, normally the submission of a performance guarantee.
Since the form of contract is included in the tender document and issues are discussed and agreed
upon during the negotiations phase, the contract essentially is a formal task of reducing to writing of
contract terms and any agreed changes thereof. The tender document, the bid and record of
negotiation meetings all form part of the contract and therefore represent a complete set of
documents that govern the implementation of the project.
4.2.6 Key issues in Procurement Process
The procurement process varies widely between governments, banks and donors but below is a brief
list of common issues that affect the procurement process:
• Poor specifications resulting in highly variable bids that cannot be compared;
• Submitted bids are non compliant;
• Poor evaluations leading to selection of inappropriate solutions;
• Poor evaluations resulting in selections that are later rejected by management / donors;
• Excessive reliance on technical evaluators as opposed to business experts leading to
technical solutions that fail to meet business requirements;
• Blatant bias towards a bidder during evaluation process leading to selection of inappropriate
solutions and at times to rejection of outcomes;
• Management interference;
• Political interference;
• Evaluation and award process taking too long necessitating fresh bids;
• Changes in government management teams during the procurement process leading to
change in outlook and repeat of process;
• Complaints by bidders of failures in procurement process;
• Withdrawal of funding due to endless delays in decision making;
• Failure to conclude contract negotiations;
It must be noted that it is fairly common to find failed IFMIS procurement efforts and in many
instances the process has been repeated a number of times losing years in between the various
efforts.

4.3 Implementation Preparation
If the procurement process proceeds to the stage of contract signing and completion of
commencement formalities, the next logical step is implementation preparation. Generally there are 5
key tracks along which the preparation processes progresses as listed below:
• Project Management – The project management process involves setting up of the project
organization structures and implementation of various processes which are instrumental in
management of the project. These have been outlined in section 3.7 and will be further
elaborated upon.
• Solution Build – This is the process of validating requirements, identifying any gaps, defining
customization requirements and configuring the solution based on requirements ready for
acceptance testing.
• Capacity Building – refers to the task of training and skills transfer. This has been elaborated
upon in section 3.3.
• Infrastructure Installation – involves the process of supply, installation, testing and

commissioning infrastructure (data centers, LAN’s, WAN, remote systems etc.)
• Change Management - Under change management, the objective is to establish

consequences of such changes and to manage them effectively in a manner that will cause
least amount of disruption, reduce probability of resistance & sabotage, foster greater
ownership and ensure long term sustainability. This has been elaborated upon in section 3.4.
While reading this section, please note that there are many variations in terminologies and document
names depending on application solutions and implementation methodologies. Where necessary
adequate explanation has been provided to enable readers to relate to other terminologies &
documents names.
4.3.1 Project Management
Formalization of the project management structures and processes form the key initial
implementation process. The task commences with the production of the project charter.
4.3.1.1 Project Charter
The project charter is a document that describes the project organization and management
procedures. The key contents of such a document include:
• A brief background to the project.

• A summary description of the project outlining key objectives, timeframes and expected
outcomes;
• An overview of the project management methodology;
• Over view of project scope – technical infrastructure, application solution, phases,
organizational unit to be covered, number of people to be trained;
• A description of the key project components and activities to include – supply of goods &
services, change management, training plan, solution build, data compilation,

infrastructure, training, implementation, support etc. For each of the role and
responsibilities of the client and supplier are also defined.
• A description of the project organization structure, personnel assigned and roles &
responsibilities. This includes Project Steering Committee, Project Management Team,
Project Manager, Core Application Team, Core Technical Team, Suppliers Team,
Workgroups such as Quality Assurance, Training and Change Management Group, Budget
Workgroup, Security and Controls Reference Group etc.
• A description of the Work Plan (Gantt chart). For each key activity the following details are
generally provided:
o Activity ID and activity name;
o Details of key sub activities;
o Deliverables;
o Pre-requisites;
o Roles & responsibilities;
o Approvals required;
o Expected key decisions;
• Description of project milestones;
• Description of project deliverables;
• Details of required facilities and resources;
• Description of project control procedures to include – project tracking, reporting, meeting
procedures, standards, quality assurance approach, change control etc.
• Format of key project management documents e.g. progress report, meeting agenda,
meeting minutes, approval forms, risk log, issue log, change request, incidence report, site
activity report etc.
The project charter in essence becomes the key project management document and is used as a
reference throughout the project execution process.
4.3.1.2 The Quality Assurance Plan
This document builds upon the Quality Assurance (QA) strategy (refer to section 3.5) to identify
roles and responsibilities of parties to the project and provide guidance and formats to specifying
quality criteria for key deliverables on the project. The result of the QA plan is to incorporate a
“Quality by design” approach into the project to ensure that all activities are performed in
accordance with project objectives and all deliverables meet contractual requirement.
The contents of the Quality Assurance Plan as defined below:

• Quality Assurance Strategy and Milestones which defines Pre-Commission Test , Functional
Tests, Provisional Acceptance Test, Final Acceptance Test and Project Closure And
Completion;
• Quality Assurance Methodology – with description of Methods, Reviews, Testing, Surveys
and Questionnaires, Audit, Reporting, Issue Management, Priority Assessment, Monitoring
and Quality Log;
• Project Management Deliverables;

4.3.1.3 The Training Plan

The purpose of the Training Plan is to define the training needs and objectives, overall approach
and methodology for delivery of training and it contains:
• Information regarding guidelines for selection of training participants based on desirable
qualifications and experience;
• Course structures;
• Schedules;
• Expected deliverables and outcomes;
• Roles and responsibilities;
4.3.1.4 The Change Management Plan

The objective of this document is to define the Change Management Strategy (please refer to
section 3.4) and plan for the project. The contents of the document generally are as follows:
• The case for change – which includes the objective, scope and strategic approach &
methodology;
• Description of stakeholders;
• Issue reporting;
• Monitoring and evaluation;
• Change issues and proposed actions;
• Approach to sustainability;
• Impact of other PFM reforms;
• Organization restructuring;
• Benefits realization;
• Stakeholder sensitization;
• Communication Plan
o Communication Process;
o Stakeholder analysis;
o Plan and scheduled of communication events;
4.3.2 Requirements Validation
The term “requirements validation” refers to a detailed review of requirements specified in the
tender documents. The objectives of this exercise are:
• Verify validity of each requirement.
• Ensure clarity in understanding the required processes, input data, outputs, controls, storage
of data and roles of various personnel in each process.

• Map the requirement to the proposed application solution (i.e. how will the requirement be
met by the proposed IFMIS system). It is essential to note that while mapping requirements
tasks can be fully automated, are a combination of automation and manual tasks and finally
some tasks will be purely manual tasks.
• Identify gaps – while mapping requirements any requirement that cannot be met by the
application solution is identified a gap. Normally the approach would be to customize the
application solution to fill the gaps. Customizing involves developing new features or making
amendments to existing features. One of the most common customizations is development
or modification of reports for various operational and analytical requirements.
• Document each process, inputs, outputs, controls, storage and roles of various personnel in
each process.
• Define test criteria and expected outcomes for each requirement. These are then used for
testing the solution.
While validating requirements and documenting the same in detail, considerable attention should be
given to “Industry Best Practices”. These are a set of standards (processes, controls, inputs,
outputs..) used by governments, public sector enterprises and businesses and have proven to be
effective and efficient in meetings objectives in these various environments. There is no single “best
practice” model suitable for all organizations, but a series of models suitable for specific
organizations e.g. government, nonprofit organizations, banks, telecomm companies.
Most quality software solutions have specific versions or configurations of their solutions that have
features unique to specific organization’s operational requirements. A system that supports unique
government operational requirements is ideal for an IFMIS implementation.
While validating and mapping requirements it is advisable to consider adoption of the best practice
features already built into the application solution rather than changing the application to meet
specific requirements. A system should only be customized to meet requirements that are very
unique, are critical and cannot be met in any other manner by the application system. The need to
extensively customize an application solution is a sign of failure either at the requirements
specification stage or at the stage of evaluation of proposed solution as it indicates a poor fit for
purpose.
The outputs of the requirements validation process are:
• Requirements Validation Document – contains detailed diagrams and explanation of

processes, inputs, outputs, controls, storage and roles & responsibilities of personnel. It also
contains test criteria and expected outcomes for each requirement.
• Customization Document – contains detailed diagrams and explanation of processes, inputs,

outputs, controls, storage and roles & responsibilities of personnel for all new features or
modifications required on the application system (filling the gaps);
4.3.3 Preparation of Various Solution Build and Operational Documents
The requirements validation document forms the blue print for the application solution and leads to
the next stage of formulation of a range of documents that will be used at various stages of solution
build and implementation. It should be noted that different implementation methodologies may
have differing names for such documents and even contents may differ.

No Components Description
A - Application Solution
A.1 Report This document contains the report layout, processing logic, execution
Customization parameters, usage, execution schedule and user access requirements
Specifications for every report that is to be delivered with the system.
A.2 Functionality This document contains the form layout, processing logic, execution
Customization parameters, usage, execution schedule and user access requirements
Specifications for every new or changed functionality to be delivered with the system.
A.3 Interface In most implementations there exists the need for the IFMIS system to
Requirements interface with other systems like Tax System, Public Debt Management,
Specification Payroll etc. The interface generally takes the form of accepting data
from or providing data to, other systems for further processing or
record keeping. The structure and format of data required either for
importing into the system or for exporting from the system is defined in
the interface document. This is then used by providers of the systems
to ensure that data is provided as per the required structure and
format.
A.4 Data Definition and All systems require basic data to commence operations. Examples of
Compilation such data are supplier details, staff details, inventory details, asset
details, bank balances etc. depending on the system being
implemented. The purpose of the document is to define the data
requirements, method of compilation and approach to verification.
A.5 Configuration All application solutions have hundreds of “parameters” that need to be
Parameterization set. Unlike data (which is used as reference and is processed by the
Document application system), parameters control the behavior (operations) of
the application systems. Varying the parameters allows users to vary
the systems response and behavior. Highly flexible systems support a
large number of parameters which can be used in various combinations
to modify system behavior based on requirements. Less flexible
systems have fewer parameters and most of the behavior is
predetermined (is fixed).
The purpose of this document is to define all relevant parameters and

their settings based on the requirements, expected operations and
desired outcomes.
A.6 Financial Procedures The implementation of an IFMIS, leads to substantial changes in any
Manual existing Financial Procedures. Key changes include introduction of new
processes, automation of processes, redundancy of old processes,
changes to existing processes, electronic processing of data, changes in
roles and responsibilities, storage of data on computer systems,
relevance of computer generated documents and reports,
implementation of new controls etc.
A Financial Procedures Manual therefore aims at documenting all
additions, removals and changes to the existing manual. The resulting

document then becomes the basis for Financial Management.
A.7 Application All personnel expected to use the new application system need to be
Operations Manual trained on its usage and the training needs to be tailored to the manner
in which the users are expected to use the system in their day to day
activities. The document that describes the operations of the system
and is used for training the end users is here referred to as the
Application Operations Manual. This should be not be confused with
the general “user guides” supplied with most application software. The
user guides tend to be generic and describe the facilities of the
application with brief examples. The Application Operations Manual is
on the other hand a highly customized document outlining all
government procedures and how they are implemented on the
application solution (including screen shots of actual system for clarity).
B – Infrastructure
B.1 Site Survey Reports Prior to installation of infrastructure a survey of all sites is essential to
identify the following key details:
• Location of buildings and offices;
• Availability and condition of power;
• Availability and condition of backup power;
• Environmental conditions (temperature, humidity, dust..);
• Availability and condition of climate control systems (air
conditioners, heaters, humidifiers..);
• Security (access control);
• Availability and condition of communication facilities (cables,
fiber, wireless systems ..);
• “Line of sight” between proposed central primary and backup
sites (critical for setting up wireless networks);
• Proposed location for placement of networking equipment,
computers, printers, scanners, network points, power points
etc.
• Availability and condition of fire protection devices;
This information is compiled for all sites with photographs and
diagrams to ensure adequate clarity of information.
In addition to recording the status of each aspect, the Site Survey
Report is also required to propose the remedial actions required for
various aspects such as:
• Provision of power;
• Provision of climate control units;
• Requirements for civil works;
• Provision of security;
B.2 Network Installation Based on the results of the site surveys, this document outlines the
& Configuration manner in which the local and wide area networks will be installed and
configured.
It should contain detailed diagrams of Local Area Networks indicating

location of network devises and access points for each and every site.
For wide area networks it should indicate on a scaled map the passage
of cables and location of devices. In case of wireless networks the
details should include location of cell sites and links between the
various sites on the network.
In addition to the physical location of various cables and devices the
document should also specify the network addressing approach and
allocation of network addresses to the various network devices.
B.3 System Installation The infrastructure consists of many devices (computers, storage
and Configuration devices, routers, switches etc.)
Each of the devices has its own operating system which is either pre-
installed or needs to be installed. Further each device has a number of
parameters that need to be set to enable proper operation. These
parameters need to be thought through based on the proposed design,
operational and performance requirements.
The System Installation and Configuration set of documents outlines
the process of setting up each device, installing the operating system (if
required), upgrading (if required) and setting of various parameters.
The document is later updated with details printed from each device
after setup indicating settings of various parameters.
The documents undergo changes every time there is a change made on
any of the devices.
B.4 Infrastructure Test The infrastructure needs to be tested prior to commencing operations
Criteria to ensure that it performs as required. In order to enable this specific
tests need to be defined for all devices (individually) and for the system
as a whole (interaction of various devices).
Initial tests include ensuring that each device meets the specifications
of the tender.
Second stage tests include measuring performance of the device under
operational conditions and ensuring that the performance meets
tender specifications.
The third stage of testing includes testing of all devices working
together as part of the infrastructure resulting in required behavior.
This should include testing of various security features of the system.
The final stage of testing includes testing of the system under stress to
verify its capability and resilience under difficult conditions. This should
include testing of disaster recovery capability.
The objective of the document is to ensure that document the various
tests and expected outcomes which are then used as basis for the
testing process;
B.5 System Operation The operation of the infrastructure is documented in the System
Manual Operation Manual. In essence the areas covered are:
• Simple power on / power off procedures;

• Routine operation of system and interventions required (if any);
• Interpretation of error messages and solutions;
• Regular care of system and routine maintenance requirements;
• Updates and upgrades and manner of application of the same;
• Data back and restoring procedures;
• Offsite data storage;
• Security administration and regular assessment of threats;
4.3.4 Data Requirements
All systems require basic data to commence operations. Examples of such data are supplier details,
staff details, inventory details, asset details, bank balances, budget details etc. depending on the
system being implemented. Normally the requirements are defined in the Data Definition and
Compilation Document, the purpose of which is to define the data requirements, method of
compilation and approach to verification.
This task is both complex and time consuming due to the following reasons:
• Data is scattered over various offices;
• Data is not regularly updated (may be lagging behind by months or years);
• There is duplication of information across various offices which differs from each other;
• Data is incomplete (considerable information is missing);
• Data is inaccurate (validity of data is questionable);
• Volume of data is quite high;
• The IFMIS system requires data that was previously not used by either manual or automated
systems in use.
• Requires considerable time to compile and verify;
In order to ensure that the processes and output of the IFMIS lead to the desired outcomes,
availability and quality of data is critical and must be considered very early on in the project to
provide sufficient time for accumulation, recording and verification.
In instances wherein implementation of IFMIS is planned to commence in the middle of a financial

year the task of ensuring that various balances (bank, budget, commitments etc.) are accurate and
available at the go-live stage is even more critical. In many instances where manual procedures or
outdated systems are being used, making this information available at the right time is very difficult
and hence it is best to plan IFMIS go-live at the beginning of a financial year where the system can
start with the new bank accounts, new budgets etc. This reduces the burden and risk considerably.
4.3.5 Interfaces to Other Systems

Depending on the government systems environment it is common to find situations wherein there
exist other systems that will either provide data to or will need data from the IFMIS system. Classic
examples are:
• The public debt management system;
• Revenue Systems;

• Banks statement data;

• Banks for electronic payments;
• Payroll (if not part of the IFMIS project);
The interface generally takes the form of accepting data from or providing data to, other systems for
further processing or record keeping. The structure and format of data required either for importing
into the system or for exporting from the system is defined in the Data Interface Document. This is
then used by providers of the systems to ensure that data is provided as per the required structure
and format.
One of the most important of such interfaces is the bank statement data interface as it is central to
the automatic reconciliation facilities of the IFMIS system. The format of the bank statement is pre-
determined at the design stage and the bank is required to provide bank statements in the form of a
computer readable file at pre-determined intervals. The file is then read by the IFMIS system for
automatic reconciliation of bank accounts.
An increasingly popular interface is the electronic payment interface wherein all payment
information can be electronically transferred from the IFMIS system to the banks using pre-
determined data formats and security protocols (various standards exist for this). This enables all
government payments to be made through the banking system reducing / eliminating cash and
check based payments. This approach however requires are suppliers, staff etc. to have bank
accounts. It is possible to implement this in stages with electronic payment being made for certain
values / suppliers etc.
4.3.6 Solution Build
The process of solution build involves compiling the application solution in a manner such that it
meets the tender requirements. This would include all standard and customized features of the
solution. The application solution consists of data entry screens, enquiry screens, online and printed
reports, automatic processes, data import / export procedures etc. All of these need to be compiled
and tested individually (unit testing). Once tested individually, all components are tested to work
with each other (system testing). This level of testing is normally carried out by the supplier’s
application and development team prior to delivery to the client for the acceptance testing.
Technically the whole process from requirements validation up to the stage of completion of testing
for delivery to client for acceptance testing is part of the solution build process.
4.3.7 Infrastructure Setup
Installation of infrastructure proceeds in parallel to solution build. The major tasks carried out under
the infrastructure installation are as outlined below:
4.3.7.1 Final Bill of Quantities (BOQ)
In almost all projects, there are variations to specifications and quantities from what was specified
in the tender or in bids. Common reasons for this are:
• Changes to hardware specifications that occur between the time of tender and
implementation preparations. Hardware specifications change almost every 3 months with
newer, more powerful or more feature rich systems replacing earlier models. It is common

to the find that if the time between the bid and implementation preparation is greater
than 6 months, specifications of many hardware devices will have changed.
• Software is constantly updated / upgraded and again depending on the time between the
bid and implementation preparation, newer versions of the software may have been
released.
• After the initial tasks of requirements validation and site surveys, there is a possibility of
design changes that may affect the equipment and software specifications. Likewise
changes are also possible to the number of users, their locations etc. which in turn directly
impact the quantities of various components and equipment.
Generally at the end of requirements validation and site survey, all changes are documented and
discussed between the client and supplier teams. Once the changes are agreed upon and approved
a final bill of quantities (BOQ) is derived. The BOQ is a final list of all equipment, software and other
infrastructure components with their respective quantities that need to be supplied and installed
on the IFMIS project. The BOQ is formally signed off by the client and supplier and constitutes an
important milestone in the IFMIS project.
4.3.7.2 Supply
The process of supply involves importation or local sourcing of equipment, software and
components as per the final BOQ. Various factors affect the time taken for the supply and are
outlined below:
• Lead time – this is the time required by overseas suppliers before the order can be
shipped. For off-the-shelf items (readily available and stocked by vendors), the lead time
can be low (1 - 2 weeks), whereas for more complex equipment, it may be essential to
assemble the equipment based on orders received and lead times could be high (10 – 16
weeks).
• Transportation time – this is the time required for transporting the supplies from point of
loading to the destination. Bulky and heavy supplies (cables, UPS, printers..) are normally
transported by sea and take the longest time whereas some high value electronic
equipment (central computers, storage devices, PC’s, routers, switches…) can be sent via
air taking shorter time. Software on the other hand is normally delivered by courier and is
the fastest.
• Export Licensing – some high end computer and network systems require special export
licensing procedures to be undertaken with governments of country of origin. This adds to
the overall time required for processing supplies.
• Customs & Clearing – procedures for importation vary from country to country. Since
supplies for IFMIS projects are normally tax exempt in most cases, the necessary clearance
procedures need to be undertaken jointly between the government (the client), the
supplier and the respective customs & tax authority.

4.3.7.3 Delivery
All supplies need to be delivered to an agreed upon destination point. The process entails:
• Documenting all equipment, software and components with their respective quantities
(and serial numbers – where relevant).
• Inspection and testing (as required) by the client of the delivered equipment. Any testing
at this stage is restricted to ensuring the supplies are as per specifications agreed upon in
the BOQ. Operational testing is carried out later during installation and commissioning
phase.
• Sign off of the deliveries by the client.
4.3.7.4 Installation
The installation process commences with moving of equipment, software and various components
from the central storage where delivery occurred to the respective operations sites. The term
installation applies differently to various components of infrastructure.
Installation of a cable based local area network implies the task of laying the cable trunks, pulling
of cables from specific central locations to various termination points, installation of termination
points and testing the performance of all cables so installed.
Installation of routers or switches would mean configuration of the devices and connecting of
various cables including labeling of cables for ease of maintenance.
Installation of computers could mean placement on racks, connecting independent units to central
switches and installation & configuration of operating system software.
Likewise installation of other equipment like personal computers, printers, UPS and scanners
would mean placement at specific location, interconnection as relevant and configuring the units
for operations.
The outcome of the installation activity all equipment and component are operational and ready
for testing.
4.3.7.5 Infrastructure Testing
The infrastructure needs to be tested prior to commencing operations to ensure that it performs as
required. In order to enable this specific tests need to be defined for all devices (individually) and
for the system as a whole (interaction of various devices).
Initial tests include ensuring that each device meets the specifications of the tender. Second stage
tests include measuring performance of the device under operational conditions and ensuring that
the performance meets tender specifications.
The third stage of testing includes testing of all devices working together as part of the
infrastructure resulting in required behavior. This should include testing of various security
features of the system.

The final stage of testing includes testing of the system under stress to verify its capability and
resilience under high load conditions. This should include testing of disaster recovery capability.
The tests and expected outcomes are defined in the Infrastructure Test Criteria document
beforehand and are used as basis for the testing process.
All deviations are recorded as issues and are graded:
• Issues that must be resolved before further progress can be made (critical issues). These
issues must be resolved before go-live.
• Issues that do not stop progress or go-live but must be fixed within the shortest possible
time.
• Issues that do not stop progress or go-live and can be fixed with the next routine
maintenance of the infrastructure.
All critical issues need to be resolved before going live and once fixed are re-tested to ensure that
the no critical issues remain.
On completion of tests, a decision needs to be made for implementation and go-live. Essentially the
client is required to sign off the infrastructure operational certificate which is a major milestone in
the project.
4.3.8 Acceptance Testing
Acceptance testing is the last stage in the solution build / implementation preparation stage. The
process involves the testing by the client of the application solution. At the time of compiling the
requirements validation document the test criteria and expected outcomes are also compiled and
agreed upon for use during acceptance testing.
The process starts with compilation of test plan which defines the steps in which the testing will be
carried out. Setup data and transactions for testing are compiled to ensure all test cases are
considered. The application system with all customizations is installed on central computer systems
from where it can be accessed anywhere on the network.
The testing commences with setting up the basic data (compiled based on the Data Definition and
Compilation Document). The next stage is to processes various transactions through the system and
the outcomes are verified. Simultaneously reports are tested (operational and analytical). All tests
and outcomes are recorded. This is compared against expected outcomes and deviations if any are
recorded.
All deviations are recorded as issues and are graded:
• Issues that must be resolved before further progress can be made (critical issues). These
issues must be resolved before go-live.
• Issues that do not stop progress or go-live but must be fixed within the shortest possible
time.
• Issues that do not stop progress or go-live and can be fixed with the next routine update of
the system.

All critical issues need to be resolved before going live and once fixed are re-tested to ensure that
the no critical issues remain.
On completion of tests, a decision needs to be made for implementation and go-live. Essentially the
client sign off the application solution and it constitutes a major milestone in the IFMIS project
implementation.

4.4 Implementation
Implementation is the process of commencing configuration of the system, loading all initial data and
commencing operations live on the new system.
For this stage to be reached, it is essential that the both the infrastructure and application solution
must be tested and certified (signed off) by the client.
4.4.1 Systems Configuration
All work done so far is on the Test System i.e. a specific set of computers are setup, configured and
used for testing. The final implementation however is expected to take place on a different set of
computers generally referred to as Production System. The two systems are always maintained
separate for the life of the systems. The reason for doing this is so that any future changes are first
made on the test system and only after certification are the changes moved to the production
system. This ensures that untested changes do not adversely affect the production system.
The first task in commencing implementation is to setup and configure the production system and
these are documented in the Configuration Parameterization Document.
All application solutions have hundreds of “parameters” that need to be set. Unlike data (which is
used as reference and is processed by the application system), parameters control the behavior
(operations) of the application systems. Varying the parameters allows users to vary the systems
response and behavior. Highly flexible systems support a large number of parameters which can be
used in various combinations to modify system behavior based on requirements. Less flexible
systems have fewer parameters and most of the behavior is predetermined (is fixed).
Typical examples of parameters for configuration are:

• Creation of Chart of accounts;
• Setting up General Ledger control accounts;
• Setting up default posting accounts in various modules (procurement, inventory, assets,
accounts payable, accounts receivable …);
• Defining workflow;
• Setting up authorization rules;
• Setting up various allowance / deduction parameters (payroll);
The parameters would have been setup during the testing phase and can be used again but normally
at the testing stage such setups may not have been carried out for all ministries / entities. The
process is tedious and time consuming as it requires detailed work that needs to be verified.
4.4.2 Data Take On / Migration
Once the system is configured and the configurations have been verified to be in line with the
Configuration Parameterization Document the next step is to setup data required for the systems
operation. Data must not be confused with parameters. Parameters determine the behavior of the
system and only change when modified by an external user whereas data is processed (input,
referenced, stored, computed, updated, deleted, output ..) by the system as part of its routine
operations.

Data has a unique aspect associated with it and that is its validity at a particular period of time. Data
generally changes with time. For this reason data is further differentiated as static and variable data.
Data is seen as static if it changes infrequently or changes over a long period of time whereas it is
considered as variable if it changes frequently or in a short period of time.
Some examples of static data and variable data:
Module Static Data Variable Data
Accounts Payable Supplier Name & Address Pending Invoices

Outstanding balance
Accounts Receivable Staff Name & Address Outstanding Imprest
General Ledger Account Code & Description Available Budget Amount
Commitment Control Account Code & Description Available Amount
Payroll Name, Address and Personal Current allowances and

Particulars Deductions
Outstanding Loans
Inventory Stock ID and Description Quantity in Stock
The data required by the system to enable operation and the approach to compiling the same is
documented in the Data Definition and Compilation Manual.
Compilation of data is again a tedious task due to the volume involved and the need to have data
verified and valid as at a particular date.
Static data can be compiled in advance and verified as it does not change frequently. Variable data
on the other hand have to be available as at particular dates and this imposes a major challenge in
many governments. The issue gains further importance in instances where the system is expected to
go live in the middle of a financial year which requires balances to be available as at a particular
date. Considering that in many instances the government accounting is lagging by months, this
becomes nearly impossible. For this reason implementing IFMIS to go-live at the beginning the
financial year is recommended as it allows commencing with a new budget, new bank accounts etc.
There are two general methods in which data can be entered onto the new IFMIS system namely
date takeon (or entry) and migration.
The term migration is widely used wherein data is already available on an existing computer based
system and can therefore be transferred across electronically to the new system. It normally is not
straight forward task due to a number of issues outlines below:
• Not all data required in new system is available on the old system;
• Not all data available on the old system is required on the new system;
• The format of data (manner in which it is stored including various data types like numbers,
text, date, time etc.) will most likely vary between the new and old systems;

• The structure of the data (the various fields available e.g. name, physical address, city,
country, telephone no’s etc.) will most likely vary between the new and the old systems;
• The operating environments of the new and the old systems are different e.g. Windows and
Unix.
• The medium in which the data is available or required is different e.g. files on tapes versus
database on disks.
• Availability of knowledge of the structure and format of data in old system is normally a
problem. This happens when the systems are very old, poorly documented and the
knowledge resides with one or two individuals.
Due to the various issues in migration, the actual process of transferring data from the old to the
new system requires considerable data conversion effort. The objectives of the conversion are as
follows:
• Analyze data available in the old system and establish the content, structure and format of
the data;
• Analyze the data requirement of the new system;
• Map the data available on the old system to the new system and identify any missing data
(required but not available) and redundant data (available but not required);
• Define strategy for compiling missing data;
• Develop computer programs to convert data from old system to the structure and format of
the new system on the required medium. This step is relatively simple if the operating
environment is the same e.g. both systems operate on Windows operating environment. On
the other hand if the operating environments are different the complexity increases and in
certain instances it may not be feasible at all;
• Convert the data from the old system to the new system;
Once converted, the data is available for uploading to and verification on the new IFMIS system and
this completes the migration process.
The term data take-on or entry is generally used when data has to be sourced from paper based
documents and need to be physically entered onto the new system. This is a manual process, prone
to errors and requires more time. Following are common issues associated with data take-on / entry:
• Required data can be spread over various documents making it difficult to collate;
• Not all data required in new IFMIS system is available;
• Not all data available is required on the new IFMIS system;
• The structure of the data (the various fields available e.g. name, physical address, city,
country, telephone numbers etc.) may not match the requirements of the IFMIS system;
• Key documents are missing, untraceable or unreadable;

• Volume of data is large;
In order to facilitate data take-on from manual documents, it is advisable to design specific forms
that contain information in the structure and format required by the new IFMIS Systems. Users are
then required to fill the forms (from various sources if necessary). The information on the form is
verified and entered onto the computer. After entry, reports can be printed from the IFMIS system
to enable another round of verification to ensure there are no transcription errors (errors that arise
when data is read from a manual form and entered onto a computer).
4.4.3 System Cut-Over
Once the system infrastructure and application solution are tested, parameters have been set &
verified and the data has been migrated / entered, the stage is set for commencing live operations
on the IFMIS system.
Just before the cut over date, all variable data, valid and verified as at the day before cut-over date
needs to be entered onto the system. Since is not easy, it is recommended to have a freeze of
transactions and changes for 5 days prior to cut-over date. This allows enough time to compute
variable data and enter the same on the IFMIS system.
At the set cut over date, all processes should be carried out on the IFMIS system (e.g. requisitions,
purchase orders, payments, and receipts). In essence the IFMIS system replaces the relevant manual
or old system processes.
The first few days are most difficult as users cope with the new system and its processes. Though by
this stage training has been provided to the users, functioning in a real environment is a major
change and hence users need considerable support. It is recommended that a few days prior to the
cut-over date, the change management team should assemble all stake-holders (in groups as
necessary) and make presentations on expected IFMIS operations, changes that will occur, how
assistance will be provided and generally use the opportunity for answers questions. This is very
helpful in setting the stage for the cut-over as users anticipate the changes, know who to call for
assistance and are mentally prepared of the change on operations.
4.4.4 Parallel runs
Parallel runs imply that after cut-over the client runs two independent systems namely the new
IFMIS system and the existing manual or automated systems. All transactions are processed twice
i.e. in the old system and the new IFMIS system. The objectives of this having a parallel run are:
• Safe guard against potential failure of the new IFMIS system by enabling a fallback position;
• Compare the output of the new IFMIS system against the old system and ensure it is correct;
The objectives make good sense if existing systems are performing reasonably well and the new
IFMIS is being implemented as an improvement on existing systems.
If however the existing systems are in a poor state (lack of controls, inadequate information,
accounts lagging behind by months / years, no reconciliation, limited or poor reporting etc.) then a
parallel run is of little significance for the following reasons:
• Technically there is no system to fall back to even if there are initial problems with the IFMIS
system;

• It is not possible to compare output from IFMIS with existing system as reports of existing
systems are normally lagging behind by months / years;
• If existing personnel are unable to work with one system (i.e. existing system), the chances
of working with two systems and coping is almost nil;
• By allowing the systems to run in parallel, those opposed to the IFMIS (for their own
reasons) gain an opportunity to continue with existing poor systems with the objective of
finding ways to cause the IFMIS to fail. This may sound unrealistic but is actually a cause of
failure for many systems implementations as vested interests do everything possible to stop
the new system from gaining momentum.
Parallel runs in certain situations may be helpful but care must be taken to ensure that they do not
lead to the failure of the IFMIS initiative. If a parallel run is considered necessary then it should be
limited to a specific period e.g. 3 – 4 months only with a very clear indication to all concerned about
the way ahead.
4.4.5 Report Production
Once the IFMIS system in operational, the key target is to produce and review the wide range of
reports that are normally delivered with the system. There is generally a high and immediate
demand for operational reports as these are required for routine operations. On the other hand
requests for analytical reports are few as they are not an operational requirement but can provide a
wealth of information for management and planning.
Users need to be encouraged to review both operational and analytical reports and this can be a
very effective approach to demonstrate success. Immediate access to details of transactions,
account balances, bank balances, availability of funds, commitments to date, performance against
budget etc. provide a powerful tool to accountants and managers for control and planning purposes
and form one of the key benefits of implementing a IFMIS system.
Monthly or quarterly reports provide an effective internal management and reporting capability. Key
stakeholders must be provided access to the reports as part of building the system’s credibility and
also to demonstrate a key benefit of investment in the IFMIS. While this would be a logical approach,
it is not uncommon to find that information and reports are closely guarded and stakeholders have
limited or no access to information. This leads to complaints from stakeholders that the IFMIS has
made little impact and the investment has not led to any benefits. In the desire to with-hold
information from stakeholders it is common to find officials stating that the system does not
produce the required information!
Production and review of reports also forms a major part of analyzing system performance. Various
factors need to be considered such as validity and accuracy of processing rules / workflow,
computation accuracy, validity and accuracy of data in database, appropriate status of various
transactions (e.g. reconciled vs. un-reconciled), correct grouping / consolidation of information
(example when information is grouped by department / ministry / sector …).
In addition to online access to information and ability to produce reports in printed format, most
modern systems allow extraction of data from the IFMIS system for loading onto spreadsheets or
other databases for further processing and analysis. This provides a very effective mechanism for:
• Conducting non standard analysis;
• Producing one-off non standard reports;

• Presentation of information in a manner not supported by the available IFMIS system

reports;
Reports and online access to information provides a major means for auditors to evaluate
performance, analyze outcomes and gauge compliance to regulations. Internal and external auditors
should therefore be encouraged to use the systems capability to provide information online, in print
form or even as raw data (required for many audit packages) for their audit work. Approval by
auditors is a major success milestone that the IFMIS implementation must strive for.
4.4.6 Key Stage Review
The go-live stage of the systems is the single most critical phase in an IFMIS implementation and
forms a major project review stage. In case of projects planned for in phases, the review of this stage
forms the basis for decision to go ahead with other phases or not. Generally the review should
consider the following key areas:
• Infrastructure performance – this should include review of all supply procedures,

specifications, site works, installation issues, performance etc.;
• Capacity Building – this should include review of adherence to plan, training programs,
training material, attendance, feedback received and performance of trained personnel;
• Application solution – should include review of features, reports, performance, benefits

realized, users feedback etc.;
• Change Management – the review should include effectiveness of change initiatives and
communications and user feedback on changes;
• Quality Assurance – the review should consider effectiveness of quality assurance activities
and a review of project quality reports;
• Project Management – should include review of project management activities,

performance against plan, decision making process and quality of project documents;
In all cases the review should include:
• Outcomes against objectives and deviations if any;
• Key issues and approach adopted for their resolution (unless still outstanding);
The review report should then outline the following:
• Summary of project activities and key milestones;
• Assessment of project objectives and actual outcomes;
• Positive and negative lessons learned;
• Changes necessary for future implementation work;
4.5 Post Implementation Support

Once systems go-live and within a period of 3 months thereafter, a final acceptance process is
normally carried out. This objective of the final acceptance test is to ensure that all issues outstanding
as at go-live have been resolved and all deliveries are completed.
The final acceptance stage marks the transition from implementation to support i.e. at this stage the
client’s support team and users are expected to take full responsibility for all operations of the IFMIS
with the suppliers team forming a 2nd line of support on a need basis.
4.5.1 Transfer of Key Roles to Client Teams
The client’s technical, application, capacity building and change management teams are involved in
the entire implementation process immediately on completion of the extensive training program
specifically designed for the teams at the onset of the project.
The involvement of the client’s teams takes place at various stages throughout the implementation
process e.g. review of all documents, participation in all presentations, participation in (& leading) all
infrastructure & software installations, data gathering & take-on activities, change management
communications & sensitization session, acceptance testing, implementation and provision of
training.
The participation assists the team to practice whatever was covered in training and also helps in
gaining confidence necessary to carry out activities independent of the supplier’s team. The process
is generally referred to skills transfer and is a key measure of project success.
In order to ensure successful skills transfer it is essential that during the implementation process all
key activities must be carried out by the members of the client’s team under guidance from the
members of the supplier’s team. This eliminates possibility of reluctance by members of the
supplier’s team to transfer skills and the approach must be clearly articulated in the project charter
as part of the implementation strategy.
Just as there may be reluctance on the supplier’s part to transfer skills, there are instances of
reluctance by members of client’s team to accept responsibility associated with the transfer of skills
and it normally manifests itself in terms of endless requests for additional training or clarifications
from the supplier’s team members. The project management team has to be aware of this and
should take necessary action to avoid a prolonged period of dependence on supplier’s team.
Some of the key roles & responsibilities are:
• Operation and management of infrastructure;
• Operation and management of application system;
• Operation and management of help desk;
• Provision of training;
• Management and execution of change management activities;
• Liaison with suppliers team;
4.5.2 Infrastructure Support

Infrastructure (as outlined earlier) consists of central data centers (primary & backup), local area
networks, wide area networks, computer / printers / scanners at various locations, generators, UPS
and various system software components (operating systems, management software, databases..).
Support for infrastructure entails the following key tasks:
• Regular maintenance of all equipment. The activities carried out will depend on the
equipment type based on manufacturer’s recommendations. Typical tasks include cleaning
& running tests. Regular maintenance is normally carried out at fixed intervals e.g. once
every 3 months and the objectives are:
o To ensure that all components are in operational condition;
o Apply device software upgrades (where relevant);
o Replace consumable items (due to normal wear & tear);
o Identify potential problems for immediate resolution;
o Track usage and ensure appropriate use based on usage policy;
o Identify components due for retirement and replacement;
• Regular update & upgrade of all system software. From time to time manufacturers of
software provide updates (resolutions to problems) and upgrades (modified / additional
functionality). These need to be applied to various types of software used in the
infrastructure e.g. operating systems, anti-virus software, database software, network
management software. It is important however that a detailed review is conducted of all
such updates and upgrades to ensure compatibility and hence the updates & upgrades are
never applied to the main production systems at first. The recommended approach is to first
review the documentation accompanying the updates / upgrades for any notes on
compatibility. Based on the information, an impact assessment is carried out to establish
risks of applying the updates / upgrades. If compatibility is a issue that such updates /
upgrades should ot be applied without resolution of the compatibility issues first.
If the updates / upgrades are approved, then this is followed by applying the updates /
upgrades onto the test system at the primary and backup data centers and conducting all
relevant tests carried out at the acceptance stage. If the tests result in problems then these
must be resolved prior to applying the updates / upgrades onto the production system. If all
tests prove to be clear, then the updates / upgrades can be applied to the main production
system.
• Repair of faulty components. Unlike routine maintenance, this type of support entails
responding to calls for diagnosing and repairing faulty components. The response required
depends on the component and its criticality in the infrastructure. Generally four levels of
response are defined:
o Level 1 – means the component is very critical to the operations of the infrastructure
and needs an immediate response and resolution.
o Level 2 – means the component is very important to the operations of the
infrastructure but operations may continue and resolution would be require within 1
– 7 days.
o Level 3 - means the component is of local significance (e.g. PC’s, printers, scanners)
but operations can continue with alternative approaches and resolution would be
require with 7 - 14 days.

o Level 4 – means the component is of local significance and the issue can be resolved
during the next schedule of regular maintenance.
Please do note that alternative classifications are also possible. These levels are agreed
upon as part of the maintenance contract.
The following possible approaches can be adapted in order to ensure that repairs of
equipment are carried out in good time thus avoiding infrastructure downtime:
 Stock spares for all critical components. This allows for rapid resolution
especially in countries where such spares are not available and lead times
for ordering are very high.
 Stock complete components units as spares (standby equipment). This
allows for rapid replacement of faulty equipment which can then be
repaired.
While the both the options of stocking spares or complete units helps overcome the
problem of time taken to repair faulty equipment, both the options increase
maintenance costs as they require investment in spares and complete units.
In an IFMIS contract, it must be remembered that all equipment is supplied with warranty (normally
1 – 3 years) and normally warranty provides for free replacement of faulty equipment but is subject
to certain conditions. Warranty is only valid for equipment that fails due to manufacturing defects.
Equipment failures due to other causes such as poor power supply, physical damage, mishandling,
usage in a manner not compliant with manufacturer recommendations etc. is not covered under
warranty and will normally be charged for based on cost of replacement.
Normally all warranty provisions are on return to supplier basis i.e. a supplier will replace a faulty
equipment only after it has been returned to them. The cost associated with return of faulty
equipment to supplier is payable by the client whereas the cost of return to client is payable by the
supplier. All costs associated with configuration and installation of repaired equipment is the client’s
responsibility.
For a government to deal with various hardware vendors is difficult and hence warranty
arrangements are normally included in a maintenance contract.
A maintenance contract is entered into between the government and the supplier immediately after
the provisional acceptance stage. The maintenance contract defines how various infrastructure
activities are to be carried out and managed. The major aspects covered under a maintenance
contract are:
• Manner in which routine maintenance services will be carried out. This includes detailed of
all sites and equipment at each site, the schedule for services, tasks to be carried out for
each equipment during every service visit, manner of recording & reporting services carried
out, manner of reporting and resolution of problems, manner of reporting any usage
violations and manner of reporting special cases e.g. need to replace ageing equipment.
• Manner in which calls reporting problems will be handled. This includes definition of
criticality of calls, required response time, required resolution time, policy & requirements
for spares holding, policy & requirements for replacement of faulty equipment with standby
equipment and processing of faulty equipment which is under warranty. Additional aspects
include reporting of all calls (closed / open), resolutions, usage violations and need to
replace ageing equipment.

• Manner in which system software updates / upgrades will be provided and applied. This
includes schedule of provision of updates / upgrades, review of updates & upgrades, impact
assessment, approach to application on testing system and testing procedures, approach to
application on production systems and maintenance of all records of updates and upgrades
to the systems.
The maintenance contract will also include payment due, terms of payments and various other
legal clauses related to client & supplier responsibilities, communication, resolution of disputes etc.
The maintenance contract is normally managed and coordinated by the clients Technical Support
Team.
4.5.3 Application Support
Application solution consists of all software modules and manual procedures of the IFMIS System.
While the application software is part of the infrastructure, the support requirements are different
as they tend to be both domain related as well as technical in nature. The ability to support users
requires an in depth understanding of:
• Application domain (e.g. budgeting, accounting, financial reporting, material management);
• Application software (various modules);
• Configuration for client’s operations;
• Manual processes surrounding the automated system;
Most reported problems tend to be related to operational issues rather than problems with the
system itself. Typically 90% of the calls will be related to data entry, use of various codes, sequence
of execution of tasks, on line queries, production of reports and interpretation of online & printed
reports. About 10% of calls are related to errors in the system or inability to execute certain tasks.
The first level of support should be provided by the client’s Application Support Team (who have
been trained and have actively participated in the various implementation tasks). Only when an issue
cannot be resolved by the Application Support team, it is escalated to the suppliers support team.
With the period of time, the number of issues escalated should reduce as the Application Support
team gains experience thus reducing dependence on the suppliers team.
Support for application solution entails the following key tasks:
• Regular update & upgrade of all application software. From time to time manufacturers of
software provide updates (resolutions to problems) and upgrades (modified / additional
functionality). These need to be applied to the application solution, after conducting a
detailed review of all such updates and upgrades to ensure compatibility and hence the
updates & upgrades are never applied to the main production systems at first. The
recommended approach is to first review the documentation accompanying the updates /
upgrades for any notes on compatibility. Based on the information, an impact assessment is
carried out to establish risks of applying the updates / upgrades. If compatibility is an issue
that such updates / upgrades should not be applied without resolution of the compatibility
issues first.
If the updates / upgrades are approved, then this is followed by applying the updates /
upgrades onto the test system at the primary and backup data centers and conducting all
relevant tests carried out at the acceptance stage. If the tests result in problems then these
must be resolved prior to applying the updates / upgrades onto the production system. If all

tests prove to be clear, then the updates / upgrades can be applied to the main production
system.
• Resolution of reported problems. This type of support entails responding to calls for
diagnosing and resolving reported problems. The response required depends on the
component and its criticality in the application solution. Generally four levels of response are
defined:
o Level 1 – means the component is very critical to the operations of the application
solution and needs an immediate response and resolution.
o Level 2 – means the component is very important to the operations of the
application solution but operations may continue and resolution would be require
within 1 – 7 days.
o Level 3 - means the component is of local significance but operations can continue
with alternative approaches and resolution would be required with 7 - 14 days.
o Level 4 – means the component is of local significance and the issue can be resolved
during the next schedule of updates / upgrades.
Please do note that alternative classifications are also possible. These levels are agreed
upon as part of the maintenance contract.
A maintenance contract is entered into between the government and the supplier immediately after
the provisional acceptance stage. The maintenance contract defines how various application solution
support activities are to be carried out and managed. The major aspects covered under a
maintenance contract are:
• Manner in which calls reporting problems will be handled. This includes definition of
criticality of calls, required response time and required resolution time. Additional aspects
include reporting of all calls (closed / open), resolutions, usage violations and need to review
components for major changes.
• Manner in which system software updates / upgrades will be provided and applied. This
includes schedule of provision of updates / upgrades, review of updates & upgrades, impact
assessment, approach to application on testing system and testing procedures, approach to
application on production systems and maintenance of all records of updates and upgrades
to the systems.
The maintenance contract will also include payment due, terms of payments and various other legal
clauses related to client & supplier responsibilities, communication, resolution of disputes etc. The
maintenance contract is normally managed and coordinated by the client’s Application Support
Team.
4.5.4 On-Going Training
In any project, a substantial number of personnel are provided training as part of the project
implementation process but there is always a need for additional training. Various reasons for such a
need arising:
• Not all participants selected for training are able to attend planned training and hence a
separate training program needs to organized for them. It should be noted that failure by
selected participants to attend is a major loss for the client as the capacity is wasted and
every effort should be made to reduce this to a minimum;

• Replacements for personnel who are transferred, promoted, resign etc. need to be trained;
• Trained users need further training on application solution;
• New sites / entities are brought onto the system and need training;
On most projects training is required on an on-going basis for the lifetime of the project and should
be delivered by the Application Support Team unless it is for new modules of the application
solution. Provision of training requires access to fully equipped classrooms and it is recommended
that client should either setup such facilities or make arrangements with the supplier for access to
such facilities.

4.6 Project Total Cost of Ownership
IFMIS projects are expensive and require a long term financial commitments to ensure sustainability.
It is essential to compute the Total Cost of Ownership (TCO) for a period of not less than 5 – 7 years
for each technically viable proposal. Solutions that seem low cost to procure may have many hidden
costs and eventually result in far greater costs when in comparison to a solution that appears
expensive initially.
4.6.1 Key Cost Components
Following are the key cost components at various stages of an IFMIS project.
Project Formulation
No Cost Component One-Off Recurrent Comment
1. Project Team Costs  Lifetime of project.
2. Consultancy Services  For compilation of

requirements specifications.
3. Project Team Study Tours to countries /  Depends on team size,

clients with IFMIS implementations number of days and number
of sites to be visited.
Project Procurement
2. Consultancy Services  For compilation of Tenders

and assistance in evaluation
3. Project Team Travel for tender related  Depends on team size,

tasks. number of days and number
Project Implementation
2. Consultancy Services  For implementation support

on client side.
3. Project Team Travel for tender  Depends on team size,

implementation related tasks number of days and number

4. Site Works (civil works, electrical works,  Depends on outcome of site

climate control systems and security survey reports and number of
systems) sites.
5. Infrastructure Supply (computers,  Depends on the final design,

storage devices, network components, specifications, quantities and
printers, scanners, UPS, generators, number & location of sites.
system software licenses)
6. Application Software Licenses  Depends on number of users

and licensing approach of
manufacturer.
7. Capacity Building  Depends on number of

personnel to be trained,
number of training courses
and durations.
8. Consultancy Services  Supplier’s consultancy team.
9. Engineering Services  Supplier’s engineering team

for installation, testing and
commissioning.
10. Change Management Activities  Depends on communication

channels, number of activities
and number of personnel to
be involved in the activities.
Project Post Implementation Support
2. Site Maintenance (for electrical, climate  Lifetime of project.

control and security systems).
3. Infrastructure Maintenance  Lifetime of project.
4. Application Software Maintenance  Lifetime of project.
5. Capacity Building  Lifetime of project.
6. Change Management Activities  Lifetime of project.

4.6.2 Computing Total Cost of Ownership
Comparison of otherwise technically compliant options should be based on the total cost of
ownership (TCO) of a solution. In many instances tenders are compared merely on the basis of initial
costs leading to major problems with cost escalation at a later stage.
The TCO should be computed over a period of 5 -7 years which is about the time when hardware
components become due for replacement and software requires major upgrades. All costs outlined
in section 4.6.1 should be considered and totaled for all phases of the project.
Total Cost of ownership (TCO) = Formulation Costs + Procurement Costs + Implementation Costs +
Post Implementation Support Costs (for all phases of the project).
4.6.3 Key Issues in Project Costing
Computing project costs requires an in-depth understanding of requirements (what needs to be

done), design (how it will be done), implementation (actual execution) and support (maintenance).
Some problems with project costing are outlined below:
• Lack of clarity in requirements leading to key aspects being missed or misunderstood;

• Inadequate planning leading to poor estimation of time, missed tasks and incorrect
sequencing (essential for cash flow planning);
• Inadequate information for proper costing leading to use of estimates which could be
misleading;
• Poor tender evaluation leading to acceptance of bids with hidden costs;
• Inadequate emphasis on support requirements leading to poor sustainability;
• Fluctuations in currency exchange rates, especially for imported components leading to
significant cost escalation;
• Higher then project inflation, leading to significant cost escalation;
• Uncontrolled changes to the core project, leading to major cost escalation due to change in
scope, supplies and effort;
• Poor project management, leading to significant cost escalation due to extended effort
requirements;

4.7 Audit
Audit is both prudent and mandatory in the financial management. It is prudent as it helps evaluate:
• Operational adherence to policies and procedures;
• Effectiveness of controls;
• Validity and accuracy of reports;
• Value for money;
On the other audit hand is mandatory as government is answerable to the parliament, citizens of the
country and other stakeholders.
Audit therefore is an integral part of financial management and should also therefore be an integral
part of an IFMIS project. This however is not simple due to the administrative separation of Financial
Management and Audit functions in a government. In most instances the IFMIS project is managed by
the office of the Accountant General and the audit functions are managed by the Auditor General. It is
not unusual to find that there is little or no involvement by the audit team in an IFMIS project due to
lack of coordination or organizational issues.
In order to ensure that the audit team is involved in the project from the onset, the Accountant
General’s department must make every effort to include the audit team and the Auditor General’s
department must extend appropriate cooperation.
One aspect which is important to mention for any IFMIS project is the general sense of skepticism
within the audit function towards such a project. In almost all cases the audit team’s experience of
financial management in governments is based on the huge backlogs, missing documents, poor
adherence to policies & regulations and lack of skills. This experience makes auditors very skeptical of
the accounting function’s ability to achieve the objectives of an IFMIS project and hence it is very
important that the audit team is involved from the onset which assists in gaining valuable feedback
from auditors (essential for the design phase) while building confidence of the audit team as a major
stakeholder in the IFMIS project.
4.7.1 Audit of Computer Based Systems
Implementation of an IFMIS has a major impact on the audit function as it is a major shift from
manual procedures to a combination of manual and automated processes with major changes in
documentation, storage of data, security, application of controls and roles & responsibilities.
Training the audit team on the IFMIS system and on general concepts of auditing computer based
systems is critical and forms an important part of capacity building component. It is important to
note that an IFMIS does not change the principles or concepts of audit but merely the method and
manner in which audit work is carried out.
Audit of computer based systems is carried out in two major ways i.e. audit around the computer
and audit through the computer.
Auditing around the computer involves reviewing inputs to and outputs from the IFMIS system.
Inputs include documents, interface data, data entered and user actions whereas outputs involve
operational documents, printed reports, online reports, interface data to other systems and
extracted data. A major change from manual systems is that auditors can have instant access to a
wide range of reports (printed or online) which greatly enhances their work.

Auditing through the computer system is very similar to level of testing carried out during
acceptance testing of the IFMIS system. It involves auditors formulating extensive sets of test data
and applying the test data through each and every IFMIS process and reviewing outcomes. The
objective is to conduct an independent test of the system at a very detailed level. Variations are
flagged as compliance issues for review & resolution.
An increasingly popular development in the field of audit is the use of tools that enable auditors to
access a database independent of the application system. This enables auditors to review all input
data and data computed or manipulated by the application system. The tools allow production of
lists and wide range of analysis. The outcomes from such tools can then be compared with the
output from the application system thereby enabling the auditors to establish the integrity of the
system.
4.7.2 Proactive Audit
An IFMIS system enables auditors to review all system operations online and this can be achieved by
providing “read only access” i.e. auditors can review all information but cannot enter, modify or
delete any data nor can they execute any operations functions.
Further the IFMIS system can be setup in a manner that sends alerts to any designated system user
for any pre-defined event. Examples of events are:
• Transactions exceeding specified amounts;
• Transactions in specific accounts;
• Transactions specific to procurement of specific items;
• Transactions with specific suppliers;
The system automatically generates e-mail alerts which can be sent to designated personnel either
for awareness or for action.
The combined use of online read only access and alerts is a powerful approach to pro-active audit
i.e. review actions when they are happening in contrast to the conventional after-the-fact audit. This
capability can make a significant change to internal audit functions and the most important aspect is
that the same can be achieved by auditors working online from their offices.

5 Legal Framework - Guiding Principles for the Formulation of an Act for

the Management of Public Finances
This entire section is an extract from the work done by ESAAG Committee on COA and PFM.
The ESSAG committee recommends that the principles listed below should underpin the
development of any legislation governing or regulating public finances.
The Act should:
1. Provide for the development of an economic and fiscal policy framework. In this regard the Act
should provide for the following:
• Preparation, presentation and approval of budget

• Medium Term Expenditure Framework issues
• Regulation of supplementary budget
• Virement issues
• Fiscal responsibility issues
2. Regulate the financial management of government. This will include the following issues:
• Issue of regulations or instructions by the Minister or authorized public officers
• Authority to receive grants
• Management of funds
• Management of bank accounts
3. Prescribe the responsibilities of persons entrusted with financial management in government

such as:
• Responsibilities and powers of the Minister
• Responsibilities and powers of Secretary to the Treasury / financial Secretary
• Responsibilities and powers of the Accountant General
• Responsibilities and powers of the Accounting Officer
4. Regulate the borrowing of money by government such as:

• Borrowing powers
• Power to give guarantees
• Signing of loan agreements
• Application of loan proceeds
• Debt servicing issues
5. Provide for the audit of government, state enterprises and other authorities of the state. This
should include the following:
• Establishment of audit committees
• Establishment of internal audit office
• Audit of the Auditor General’s Office
6. Modernize the system of financial management such as:

• Powers to change / modify accounting system
7. Eliminate waste and corruption in the use of public assets.

• Offences & Penalties

8. Provide accompanying accountability and transparency arrangements together with compliance

with those arrangements. This will include the following:
• Preparation of financial statements
• Tabling of periodic reports
9. Require the government to produce statements of proposed budget policy.
10. Make better provisions for the more effective control, management, and regulation of the
collection and use of finances.
11. Enhance parliamentary control and supervision of public funds and resources.

The table below summarizes the current legal provisions contained in the various legislation relating to the management of public finances of seven
member countries.
Component COUNTRY
Lesotho Malawi Mauritius Mozambique Tanzania Uganda* Zimbabwe
Preliminary
Interpretation √ √ √ √ √ √ √
Short title √ √ √ √ √ √ √
Objects of the act √ √ √ √ √ √ √
Application √ √ √ √ √ √ √
Control and management
Duties and Power of the Minister and the
Treasury
Responsibilities and powers of the Minister √ √ √ √ √ √ √
Responsibilities and powers of Secretary to √ √ √ √ √ √ √
the Treasury
Responsibilities and powers of the AG X √ √ √ √ √ √
Responsibilities and powers of the √ √ √ √ √ √
Accounting Officer √
Consolidated Fund and other Public funds
Consolidated Fund √ √ √ √ √ √ √
Special/Other funds √ √ √ √ √ √ √
Investment of Moneys in the CF √ √ √ √ √ √ √
Moneys raised or received to excl deposits √ √ √ √ √ √ √
or trust funds
Bank accounts √ √ √ √ √ √ √
Issues from the CF √ √ √ √ √ √ √
Accountant General's/Minister's Warrants √ √ √ √ √ √ √
Estimates of Revenue and Exp √ √ √ √ √ √ √
Advances by Treasury √ √ √ √ √ √ √

Component COUNTRY
Loans, Guarantees & Grants
Borrowing powers √ √ √ √ √ √ √
All borrowings paid into the CF √ √ √ √ √ √ √
Power to give guarantees √ √ √ √ √ √ √
Signing of loan agreements √ √ √ √ √ √ √
Sinking Funds X X X X X X √
Authority to receive grants √ √ √ √ √ √ √
Estimates of Revenue and Expenditure
Submission to Parliament of estimates √ √ √ √ √ √ √
Excess Expenditure √ √ √ √ √ √ √
Supplementary Budget √ √ √ √ √ √ √
Virement √ √ √ √ X √ X
Preparation of financial statements

Annual financial statements √ √ √ √ √ √ √
Submission of the accounts √ √ √ √ √ √ √
Content/structure of the financial √ √ √ √ √ √ √
statements
Audit and Examination of Accounts
Duties and powers of the Auditor General √ √ √ √ √ √ √
VFM Audit √ √ √ √ √ √ √
Audit of public authorities and other bodies √ √ √ √ √ √ √
Audit Report √ √ √ √ √ √ √
Control of the finances of state
enterprises/Statutory bodies
Classification of public X X X X X X √
enterprises/Statutory bodies
Fiduciary duties of accounting officers √ X X X X X √

Component COUNTRY
Corporate Governance X X X X X X √
Annual reports and financial statements √ √ √ √ √ √ √
Finances and Audit of the Auditor General's
office
Funds for the Auditor General √ √ X √ √ √ √
Accountability √ √ X √ √ √ √
Audit of the Accounts of the Auditor √ √ X √ √ √
General X
Procurement
Procurement √ √ √ √ √ √ √
Local Authorities
Council fund √ √ √ √ √ √ √
Appointment of council chief accounting √ √ √ √ √ √ √
officers
Activities requiring approval √ √ √ √ √ √ √
Integration with the government budget √ √ √ √ √ √ √
process
Reports and presentation to parliament √ √ √ √ √ √ √
Information systems √ √ √ √ √ √ √
Bank accounts and written instructions √ √ √ √ √ √ √
Accounting Standards Board
Establishment of the ASB X X X X X X √
Miscellaneous
Amendment of the act √ √ √ √ √ √ √
Offences & Penalties √ √ √ √ √ √ √
Exemptions √ √ √ √ √ √ √
Repeals √ √ √ √ √ √ √
Transitional provisions √ √ √ √ √ √ √

Component COUNTRY
Abandonment of claims √ √ √ √ √ √ √
Write-offs √ √ √ √ √ √ √
Precedence √ √ √ √ √ √ √
Regulations/instructions to be issued under √ √ √ √ √ √ √
the Act

References
1. ESAAG Committee On COA and PFM - Guidelines on the Formulation of a Chart of Accounts and
Public Financial Management Act – for the Section on Legal Framework.

A Guide To IFMIS Project Implementation v1

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

A Guide To IFMIS Project Implementation v1

Hochgeladen von

Copyright:

Verfügbare Formate

A Guide to IFMIS Project Implementation

A Guide to IFMIS Project Implementation

Harish R Bhatt Soft-Tech Consultants Ltd. Page | 1

Harish R Bhatt Soft-Tech Consultants Ltd. Page | 2

3.4.3 Risk Assessment and Management ............................................................................................42

Harish R Bhatt Soft-Tech Consultants Ltd. Page | 3

4.1.9 Key issues in Planning and Requirements Specifications ...........................................................70

Harish R Bhatt Soft-Tech Consultants Ltd. Page | 4

Harish R Bhatt Soft-Tech Consultants Ltd. Page | 5

• Communicating and ensuring compliance to policies, guidelines / regulations and operational

• Managing large volumes of data;

• Lack of skilled manpower;

• Problems with overall management of critical processes;

2.2 Objectives of IFMIS

Harish R Bhatt Soft-Tech Consultants Ltd. Page | 6

No Objective Strategy Challenge Addressed

Enable reporting of non- Recognition of non-

Enable rapid access to data Poor access data stored in

Loss of data and documents

Manipulation of data and

Inability to audit due to loss

Harish R Bhatt Soft-Tech Consultants Ltd. Page | 7

No Objective Strategy Challenge Addressed

Poor morale associated with

Lack of skills in managing

5. Improve Management of Enable production of Inability to produce a wide

6. Improve confidence of all Provide timely information to Inability to provide

• Subscribing to best practices in planning and financial management. Implementing an IFMIS

Harish R Bhatt Soft-Tech Consultants Ltd. Page | 8

• Harmonizing initiatives. Most governments have a multitude of reform programs in process

2.3 Functional Areas to Consider for IFMIS Implementation

Harish R Bhatt Soft-Tech Consultants Ltd. Page | 9

• Payment Accounting. The area focuses on processing of procurement and non-procurement

• Asset Maintenance. Typically asset maintenance management is essential for vehicles,

• Public Debt Management. Public debt forms a substantial component of government’s

2.4 Why IFMIS?

Harish R Bhatt Soft-Tech Consultants Ltd. Page | 10

• lack of compliance to procedures by automating majority of processes;

Harish R Bhatt Soft-Tech Consultants Ltd. Page | 11

3 Components of IFMIS Project

In the following sections is a brief overview of aspects to be considered in relation to Application

3.1.1 Package Solutions

Package Solutions offer the following key benefits:

• The solution providers provide warranty and support services;

Some perceived disadvantages of packaged solutions are:

Harish R Bhatt Soft-Tech Consultants Ltd. Page | 12

3.1.2 In-house Development

Harish R Bhatt Soft-Tech Consultants Ltd. Page | 13

Some perceived benefits of in-house development are:

3.1.3 Potential Solutions

Harish R Bhatt Soft-Tech Consultants Ltd. Page | 14

Harish R Bhatt Soft-Tech Consultants Ltd. Page | 15

• Public Debt Management Module: Public debt forms a substantial component of a

Harish R Bhatt Soft-Tech Consultants Ltd. Page | 16

3.1.5 Updates & upgrades

Harish R Bhatt Soft-Tech Consultants Ltd. Page | 17

• need to upgrade operating system and database software;

3.1.6 Support & Maintenance

Harish R Bhatt Soft-Tech Consultants Ltd. Page | 18

3.2.1 Determinants for Infrastructure Design

• Application Software and Modules to be implemented. This assists in determining a number

o Transaction volumes (directly related to target areas to be covered based on

o Deployment Approach – this will depend on supported technologies such as client –