Abstract
This technical note is the third of three addressing information technology (IT) themes and issues relevant to tax administrations. This note focuses on implementation of a commercial-off-the-shelf (COTS) system in a developing country tax administration. The first note covers the use of IT in tax administrations and how to develop an information technology strategic plan (ITSP). The second note addresses how to select a suitable information technology system for core tax administration functions. These technical notes are primarily tax administrations that have no technology to manage their core tax processes, or their technology is limited and outdated. These notes focus on core tax functions and do not address other business systems (e.g., payroll, finance, document, and asset management systems).
This technical note is the third of three addressing information technology themes and issues relevant to tax administrations. This note focuses on implementation of a commercial-off-the-shelf (COTS) system in a developing country tax administration. The first note covers the use of information technology (IT) in tax administrations and how to develop an information technology strategic plan (ITSP) and is intended for developing country tax administrations that are largely manual or have outdated legacy IT systems. The second note addresses how to select a suitable information technology system for core tax administration functions. Ideally, the notes would be read in order but a tax administration that already has an ITSP may choose to go to note two to determine the type of system most suited to its circumstances or straight to note three if the preferred system has already been selected. The content of these technical notes reflects the themes and issues the IMF Revenue Administration Divisions are frequently called upon to assist member countries with.
These technical notes are primarily for use by tax administrations that have no technology to manage their core tax processes, or their technology is limited and outdated. The notes may however, also be of interest to more advanced administrations. These notes focus on core tax functions and do not address other business systems (e.g., payroll, finance, document, and asset management systems). For advanced IT tax administrations, there is a wealth of other information available including the OECD Forum on Tax Administration publication: Technologies for Better Tax Administration. A Practical Guide for Revenue Bodies, May, 2016.1
This technical note and manual (TNM) addresses the following questions:
What is involved in implementing a COTS Core System?
What are the steps involved in setting up a program management structure?
What are the roles and responsibilities in a program management structure?
What is the significance of vendor roles and relationships?
What business process considerations exist?
What are the implementation considerations?
How is data conversion/migration managed?
What security issues are present?
How is the product tested?
How is the change to the new system managed?
What are the common pitfalls?
What are the effects on business-as-usual systems operation?
I. What is involved in implementing a COTS Core System?
The replacement of existing processing systems within a tax administration with an integrated Commercial-Off-The-Shelf (COTS) system is a collection of major pieces of work which will test even the most mature and competent administration.
Obtaining a replacement IT system is not just a case of procuring a firm to provide the system, even if user needs are clearly defined, agreed and understood. Many methodologies describe the components of an organization as an inter-relationship of people, processes, and systems. It is clear that changing one of the components has effects on the others. That is why a major change to the IT systems supporting the organization is likely to cause or require changes to both people and processes.
The collection of inter-dependent activities (projects) needed to bring about this level of change can be assembled to form an overarching program of work. This program needs to be carefully guided, monitored, and coordinated during the process to ensure each project is able to deliver its outcomes as and when described in the overall delivery plan of the program. The projects within the program need to be monitored by a central program management office regardless of whether or not they are business or IT related projects.
Different types of projects need to be conducted in concert to achieve a successful overall outcome—they can include projects such as:
|
|
|
|
|
|
|
|
A high level “mock-up” of the interrelationship between these projects and their potential sequencing is shown in Figure 1. A more detailed view is shown in Appendix 1.
Example of Linkages Between Different Projects in a COTS Implementation
Citation: Technical Notes and Manuals 2017, 003; 10.5089/9781475583984.005.A001
Example of Linkages Between Different Projects in a COTS Implementation
Citation: Technical Notes and Manuals 2017, 003; 10.5089/9781475583984.005.A001
Example of Linkages Between Different Projects in a COTS Implementation
Citation: Technical Notes and Manuals 2017, 003; 10.5089/9781475583984.005.A001
All aspects of change must be actively managed. It is critical that a strong program management and supporting change capability is in place. It is rare for such a capability to exist within an organization which does not have this sort of activity as its core business—tax administrations have capabilities and structures that enable them to run a tax system, but large-scale change management requires a different set of skills and capabilities. The level of difference in these areas is often underestimated in developments such as these, and must not be discounted.
II. What are the Steps Involved in Setting up a Program Management Structure?
It is essential to establish a management structure for the program that identifies the specific personnel, their respective roles and accountabilities, and the interaction between them for the life of the program. This arrangement must be tailored specifically for the program and does not necessarily need to reflect existing operational line management structures. Figure 2 illustrates a typical program management structure which comprises: (1) a program sponsor; (2) a steering committee; (3) a program manager and a support team (project management office); and (4) project teams. Because the program will involve substantial re-engineering of existing business processes, provision for expert user reference groups needs to be made. Consultants and contractors are also likely to need to be engaged to provide advice or services not available from within the organization.
Standard Program Management Structure
Citation: Technical Notes and Manuals 2017, 003; 10.5089/9781475583984.005.A001
Standard Program Management Structure
Citation: Technical Notes and Manuals 2017, 003; 10.5089/9781475583984.005.A001
Standard Program Management Structure
Citation: Technical Notes and Manuals 2017, 003; 10.5089/9781475583984.005.A001
III. What are the Roles and Responsibilities in a Program Management Structure?
Overlaying program management arrangements across the general management structure of the organization can cause conflict within an organization in regard to accountability and reporting. It must therefore be made very clear to all concerned how the program governance structure (accountabilities and reporting arrangements) will operate within the general management structure of the organization. The roles and responsibilities of the entities in the program management structure are described below.
Program sponsor (usually the Commissioner/Director General/CEO):
1. Delivers a successful program to the Minister.
2. Ensures the governance structure is appropriately staffed.
3. Chairs the business of the reform steering committee.
4. Solicits and obtains funding for the program.
Independent assuror (a highly experienced professional engaged by the sponsor to provide direct advice on any program feature), particularly:
1. Vendor performance.
2. General progress at either program or project level.
3. Specific guidance on issues resolution.
Steering committee (project sponsor, project owners, director/head of reform program office, external representatives):
1. Provides strategic direction to all project teams.
2. Ensures from the start that a project’s scope aligns with the program plan and requirements of the target stakeholder groups.
3. Assesses project feasibility in terms of resource commitments vis-à-vis the benefits or outcomes.
4. Allocates resources to projects and provides timely and objective decisions on prioritization of initiatives.
5. Monitors project scope and keep it under control as seemingly small emergent issues can force a departure from plan.
6. Deals with issues and risks that have implications for the projects.
7. Makes binding decisions on cross-cutting issues across projects in order to balance conflicting priorities against available resources.
8. Checks adherence of project activities to standards of best practice, both within the organization and in a wider context.
9. Takes necessary steps to secure policy decisions or legislative amendments needed to achieve program objectives.
Central program management office (full time, director/head of reform program, project counterparts):
1. Kick-starts the implementation of approved projects.
2. Guides the preparation of the project plans.
3. Manages vendor contract(s).
4. Consolidates periodic project status reports for presentation to steering committee.
5. Provides secretarial services to the steering committees.
6. Monitors all aspects of the project components.
7. Oversees day-to-day project implementation and provides advice and technical project management support to the project teams.
8. Disseminates and applies good practices for effective project management.
9. Ensures corrective measures are taken whenever institutional plans are modified and when project milestones and deliverables are behind schedule or not meeting set standards.
10. Ensures that the set standards for project monitoring and evaluation are met, including arranging for quality assurance services based on need.
11. Coordinates the resolution of complex cross-cutting issues among projects.
Project sponsor (often the head of the business area/sector):
1. Delivers a successful project to the Director General/CEO.
2. Prepares the project owner’s brief to the steering committee.
3. Provides the project’s strategic direction and overview.
4. Appoints an appropriate project manager.
5. Presents the project business case/justification to the steering committee.
6. Approves the project plan and any material change requests.
7. Monitors progress against the project’s objectives.
8. Ensures risk is effectively identified and managed.
9. Signs off completed project.
Project manager (full time, appointed by the project owner):
1. Delivers a quality project on time and within budget to the project sponsor.
2. Establishes the project in the project administration system through a formal registration action.
3. Prepares a project justification or business case to be considered by the steering committee before approval.
4. Prepares, implements and updates the project plan.
5. Manages the project according to the project plan.
a. Leads the team proactively, providing guidance necessary to ensure the project meets the agreed objectives.
b. Encourages team members to take ownership and accountability for their identified responsibilities.
c. Promotes a team approach and provide timely feedback to team members.
d. Seeks (constructive) feedback throughout the project.
5. Communication—the project manager must:
a. Promote the project and its benefits at every opportunity.
b. Identify any resistance to proposed changes and sensitize affected staff and stakeholders in a timely manner.
c. Build and maintain key stakeholder relationships.
d. Share experiences with other Project Managers.
e. Communicate change management initiatives at every stage.
6. Vendor/supplier management—the project manager must:
a. Ensure vendor progress complies with the contractual obligations.
b. Assign a suitable contract manager to work with the vendor.
c. Ensure vendors comply with their quality plans.
d. Adequately check all key deliverables before acceptance.
e. Meet the vendor expectations in regard to timelines, counterpart support, and quality of revenue agency inputs.
Project team (full time, appointed by project sponsor in consultation with project manager):
1. Work with the project manager and vendors to develop the detailed project plan.
2. Prepare the project work plan allocating time and resources to tasks.
3. Carry out the day-to-day project activities specified in the work plan.
4. Plan for implementation of project initiatives, including decisions on pilots, development of specification documents, etc.
5. Monitor and evaluate implementation of activities in the project plan.
6. Prepare/update and submit progress reports including issues and risk assessments to project manager.
7. Develop messages to be communicated to different categories of stakeholders.
Business owner(s): The business owner is the person who will be responsible for managing the project outputs after the closure of the project—and is accountable to the project sponsor for the realization of the project outcomes/benefits in the post-project environment. They are continuously involved from the early conceptual stages of the project through to the testing and acceptance of the completed outputs. There may be one or more business owners, at a number of managerial levels, depending on the size of the project. The business owner’s responsibilities include:
1. Provide assurance that the project will deliver all of the outputs necessary to realize the expected outcomes/benefits.
2. Contribute subject-matter expert resources to the project in order to ensure that the outputs are developed satisfactorily.
3. Ensure that the project outputs (i.e., products and services) are “fit-for-purpose.”
4. Ensure that appropriate change management planning is in place to integrate the project outputs into the regular business operations when the project closes.
Reference groups: These are groups that are convened as needed to address particular facets of the project. A reference group is made up of a small representative group of clients/users from areas that will be affected by the project’s work. They may comprise staff from business units impacted by the project; or taxpayers, tax advisors, or intermediaries in the tax system that will be required to use the outputs of the project; or a combination of these groups. Participants are selected on the basis of experience and/or special expertise in the activities/processes under review, and the reference groups are convened to focus their collective technical expertise and business experience to reach consensus solutions to operational issues that arise in the project. This level of engagement with internal and external users promotes “ownership” of the project outcomes more broadly across the organization and within the community. Reference group members also help disseminate information about the scope and outcomes/benefits of the project throughout their business areas and peer groups.
Consultants and contractors: Consultants and/or contractors from outside the organization may be engaged by the project manager or by the steering committee to provide specialist expertise or services not available from internal resources. Typical examples of external providers include:
Business analysts;
IT specialists;
Legal advisors;
Probity advisors;
Training experts;
Communication experts; and
Quality assurors.
IV. What is the Significance of Vendor Roles and Relationships?
Purchasing a COTS product creates a long-term arrangement with the vendor. As with any long-term relationship, care must be taken to manage the arrangement and any issues which develop need to be resolved, both quickly and effectively. The abilities of and relationships with vendor-supplied experts are essential to a successful outcome. Equally, the project teams gain most from vendor input if they act in a cooperative manner and assimilate vendor representatives into the team. Failure to do so engenders an “us versus them” environment and can lead to protracted issues and even program failure.
The way the product vendor interacts with individual project teams (or replaces them) depends on the terms of their engagement and their expected length of engagement. Where vendors are engaged to provide long-term support to a product in addition to installing/configuring it, it is common that they will take a leadership role in some or all projects and provide staff for the majority of project roles. In this way they become integrated into the fabric of the administration.
Where engagement is for a shorter defined term, e.g., just to install and configure the product after which the administration will take responsibility for maintenance, a vendor needs to be used in a more consultant-type role—explaining and teaching administration staff to manage the product.
It is important to note the vendor’s experience in previous installations/configurations as they can often explain how particular issues have been successfully handled in other administrations.
V. What Business Process Considerations Exist?
The introduction of a new system provides options for business process re-engineering (BPR). COTS products can accommodate many different processes within their overall design. There are many tools and methodologies available to assist in the BPR process. It would be good practice for an administration to engage professionals who specialize in BPR such as Lean Six Sigma3 and design disciplines such as Rapid Application Design, Agile4 methodologies, etc. to facilitate the work of reference groups in this area.
User expectations of what a COTS product will do for them need to be carefully managed. When a new core system is installed, it is often after years of user frustration with the shortcomings of the previous system and enormous expectations of the new system often exist. Although usually configurable to a large extent, it is common for COTS products to have some level of business process built in to them which need to be respected and evaluated properly. It should be noted that the design of the COTS product is the outcome of research done by the vendor on general needs of tax administrations and therefore typically represents a reasonable way of fulfilling core functions. Before insisting on changes to the way the product is configured, existing or envisaged processes should be thoroughly explored and evaluated.
Business owners as well as IT officials must be central to any assessment, design and implementation activity. Care must be taken however, that opportunities for improvement suggested by vendors or others in the design process are not discarded on the pretext that it is not in accord with current practices. Adoption of such an attitude will simply result in a newer version of the current system, which would perpetuate existing weaknesses and bad practices. The challenge for business and IT owners is to ask the question: can I do my business with the existing COTS design, and if not, why not?
At the other extreme, a COTS product may provide a dazzling array of new possibilities, especially in areas such as workflow, review points, supervision opportunities, reports, etc. It is common for an administration faced with these options to over-specify functions both in terms of range and complexity. This results in complicated and inefficient outcomes which adversely affect the user experience.
Because the many options available for using the system are easily configurable with COTS systems, opportunities exist for prototyping proposed processes before they are committed to in a final deployment. Instead of reference groups designing processes from a “blank sheet,” developing and exposing these prototypes to the reference groups for them to see operating and then review can result in a much more efficient and successful design process.
Even when an administration is satisfied with the design they decide on, once in production, further/different requirements will emerge. Any implementation should plan for at least one extra production release to address these issues. This release would normally occur approximately 12 months after the first production release.
VI. What are the Implementation Considerations?
One of the early decisions facing the program is how the system will be delivered—whether a “big-bang” approach will be used to deliver all functionality to all users at the same time, or whether a more gradual approach will be adopted by deploying by tax-type, by office segment, geographic regions, or functional module, etc.
Each option has its own advantages and disadvantages. These can relate to risk profile, practicality (e.g., country infrastructure including internet coverage and electricity supply), staff or taxpayer impact, technical issues such as data migration/conversion/interface requirements, etc., duration of the program, cost and capability availability. For example, a “big-bang” approach entails moving all users for all tax-types to the new system at the same time and then decommissioning the old system. This approach often has no way back if the new system fails, so is heavily dependent on very thorough testing. It has the advantage that data migration is likely to be simpler—there is no need to separate different types of data according to geography or tax type, and because all users and tax-types move at once, there is no need for interfaces between new and old systems. On the downside, all users will have to be trained virtually at the same time, settling-in inefficiencies will affect the whole administration at once and any defects which surface will affect the whole organization and all taxpayers.
From this general description, it can be seen that for an entire system, the risk of a big-bang implementation is higher than if the system were introduced in stages, but whilst the risks are higher, the process may be simpler, quicker and less expensive. All these issues must be weighed up to decide on an implementation approach.
VII. How Is Data Conversion/Migration Managed?
The effort required from administration staff in the data conversion process should not be underestimated.
As soon as new data structures are known, a specialized project focused on conversion should commence. In many cases, automated processes can be employed to transfer data from the legacy system to the new one, but typically, some portions or aspects of data holdings in old systems have become corrupt, meaningless or simply incorrect. Intense effort from business areas is often needed to manually inspect and correct this data prior to conversion. Where administrations have no electronic records, it is likely that existing manual data holdings will need to be entered into the system either by manual entry, or by requiring taxpayers to re-register using the new facilities provided by the system. It would be common in these cases for only registration data to be brought to the new environment, with historical accounting data kept in its manual state.
VIII. What Security Issues Are Present?
Introducing a new core system will require a review of security arrangements for its operation both in a physical sense, but also in respect of unauthorized access. It is an ideal opportunity to refresh existing security arrangements. Matters such as physical security protection—from access to the computer center all the way to how well the system is locked-down end-to-end (even including features such as disabling USB ports on office computers); access management; information security; penetration prevention measures; audit logging; and identity and authentication processes—all need to be addressed.
Data security is a key component affecting the reputation of a tax administration and a good reputation can be easily lost if a tax administration’s IT system is hacked or there is a breach of secrecy. Tax administrations need to pay close attention to security risks posed by internet access and staff wrongdoing arising from unrestricted access to data. Tax administrations need to ensure appropriate security policies and inbuilt security protections are in place, reviewed, and updated regularly.
IX. How Is the Product Tested?
As with any IT implementation, a thorough testing regime must be in place. It should be assumed that testing of the “clean” installation of the product (before any configuration/customization) will be executed by the vendor using their own test cases. This testing should also provide a baseline for environment needs and performance expectations.
Once configuration commences, due to the high level of functional integration5 which exists in modern systems, test cases for higher-level testing need to be developed which cover the full range of end-to-end processes expected of the system. Automated execution6 of these cases then occurs throughout the configuration/implementation process.
The process for User Acceptance Testing (UAT) is critical to any implementation. A common issue experienced at this stage is that when confronted with the product that has been specified and built, UAT staff express dissatisfaction with some facets of the implementation and reject the test simply because they do not like it, resulting in the system not being implemented. UAT teams need to be properly briefed when going about their work—their job is to confirm that the system has been delivered as designed and will allow them to do their jobs, not whether a screen is the wrong color, or that they dislike having an extra approval stage built into a process. This is typically mitigated by developing and documenting the UAT test scenarios based on the system design and establishing the test success factors as early as possible.
X. How Is the Change to the New System Managed?
Effective change management is essential to the success of a COTS implementation. The system change will heavily impact tax administration staff, as well as potentially impact users of the wider tax system—taxpayers, tax professionals, etc. To ensure that the change is embraced, a comprehensive change management process is required. Early communication of the reason for change is essential, as it allows for a rational presentation of the case for change. During introduction of the changes, emotions can run high and it is difficult to rationalize the case for change in retrospect. Features of such a change process are listed in Box 1.
Features of Major Change Processes
Leadership – provide a very strong statement of direction accompanied by a persuasive argument for its need. This is a layered communication. For management levels, as well as being informative, it is also an instruction. For operative levels, it should be delivered as an aspirational statement.
Planning – present a clear description of what is happening and when it is likely to impact the audience. This must be tailored to specific audiences, especially if some areas are threatened by issues such as redundancy or by a significant change in role, e.g., assessment officers being changed into desk auditors.
Governance – a description of how the change is being managed and that things will happen in an orderly fashion. Confidence in the outcome is critical to the acceptance of the change.
Information – clear, consistent and regular information about what is happening is essential to acceptance. Active countering of rumors is also an essential feature.
Explanation – explanation about why this is necessary and why the change is good for the administration and the audience. Staff need to understand why their world is being changed.
Certainty – staff need to know what will happen to them. They need to be confident that they will be adequately informed, trained and equipped for the new environment.
Value – the base knowledge that staff have about taxpayers and the overall tax system will not be altered by whatever structure they work in. This point should be used to reinforce the value of the staff to the administration.
Opportunity – staff should be made aware of the additional opportunities the new arrangements present for them in terms of better job satisfaction, etc.
Settling-in period – staff need to understand that they will be given time to become proficient within the new arrangements.
Be prepared – have the capability to respond quickly to any issues arising especially with the application. Unfixed errors cause loss of user confidence in the system.
Care must also be taken to closely manage existing IT staff. Although they may not be directly involved with the project, the existing systems must be kept running for its duration. Particular expertise with existing or old systems, known as legacy systems, will also be needed in the data migration process. In many instances of systems replacement, long-serving staff with deep expertise in the current system feel disenfranchised and de-skilled and consequently look for alternative employment. However, these staff are assets not only because of their systems knowledge, but also because of their developed understanding of the operation of the business and its needs. Their value needs to reinforced and used well in the replacement process. Whatever level of support is provided by the vendor, a continuing business and IT design capability needs to retained by the administration. In many cases, the existing staff are ideal to form part of that capability.
There is a similar challenge with middle managers within the business units. Many of these need to champion the change, but they have generally advanced to their level based on their knowledge of the existing system and business processes. As they are pivotal to the change, it needs to be recognized that they can feel threatened by the change itself.
XI. What are the Common Pitfalls?
It is devastating but not uncommon for large IT-based programs or projects to fail. Common causes are listed in Box 2.
Common Causes of Program Failure
Insufficient commitment by the senior executive body.
Program inputs and outputs (i.e., products and services) are not “owned” on an ongoing basis by the client business units.
Roles and accountabilities are not well defined, agreed, and accepted.
Program scope, objectives, and goals are not properly defined and agreed.
Program scope is not controlled (scope creep).
Program schedule and cost are poorly estimated.
Planning and coordination of resources is inadequate.
Outcomes/benefits are not properly defined in measurable terms.
Communication and change management issues are not properly addressed.
Stakeholder management (internal and external) is overlooked or not properly addressed.
It is critical that risk registers exist at both program and project levels that identify, assess, provide mitigation strategies and treat risks. These registers should be actively used and updated regularly throughout the life of the program.
Assessment and ranking of risks can be assisted by using a matrix combining likelihood and consequence as in Figure 3:
Risk Assessment Matrix Example
Citation: Technical Notes and Manuals 2017, 003; 10.5089/9781475583984.005.A001
Risk Assessment Matrix Example
Citation: Technical Notes and Manuals 2017, 003; 10.5089/9781475583984.005.A001
Risk Assessment Matrix Example
Citation: Technical Notes and Manuals 2017, 003; 10.5089/9781475583984.005.A001
Large programs involving many layers of integration and dependency are not typically very tolerant of shocks—for instance a small delay in a single project or the sudden loss of key personnel can cause chaotic effects to the program as a whole. Wherever possible, risk tolerance measures should be built into the program structure. These can include contingency plans, succession plans, in-built delay tolerance measures such as the inclusion of schedule “slack” in plans, etc. These are effectively a business-continuity plan for the program.
Large, long-running programs also usually incorporate stage gates—review processes positioned at critical stages of the program. These review points usually present three options: Continue as planned; continue with a modified plan; or stop the program. The first option is self-explanatory. The second can result in major changes to delivery times and/or costs but still provide the envisaged outcomes. But because of the size of the investment and potential impact of non-delivery, a decision to stop a program can be very difficult to make. Responses to questions such as those below need to be incorporated into the risk management system:
Does the administration still need the outputs that were originally envisaged?
Have changes to business operations occurred during the program which need to be restored to previous states? E.g., widespread pilot operations, external interfaces, etc.
Can the old system be kept running until a new solution is found?
What will be the wider impact of cessation—political/funding, etc.?
What caused the problem and how can it be rectified before it recurs?
What are the next steps?
That said, if a program is not going to meet its desired outcomes, there is no point in continuing to spend time and money on it. Administrations need to take a realistic view of progress and options and be prepared to pursue other alternatives if needed. Figure 4 provides a storyboard graphic of these stage gates.
IT Modernization Road Map with Stage Gates
Citation: Technical Notes and Manuals 2017, 003; 10.5089/9781475583984.005.A001
IT Modernization Road Map with Stage Gates
Citation: Technical Notes and Manuals 2017, 003; 10.5089/9781475583984.005.A001
IT Modernization Road Map with Stage Gates
Citation: Technical Notes and Manuals 2017, 003; 10.5089/9781475583984.005.A001
XII. What are the Effects on Business-as-Usual Systems Operation?
A typical COTS systems replacement program will usually take a minimum of three years. This period can be shortened by various techniques, but given the need for a thorough procurement process, it would be extremely unlikely to be achieved in less than two years, even if there was an existing clear articulation of requirements and design.
Pressure on staff in “expert” areas during the replacement period is often extreme. The same people who are relied upon to resolve day-to-day issues and problems are also the ones who are turned to by designers for solutions to their issues. Wherever possible, expert staff should be seconded from their full-time jobs to a particular activity (usually design) on the modernization program, and replaced for that period. This can be an excellent opportunity to try new staff in more challenging jobs. In many cases, a new level of future executives can emerge as they “step up” to the challenge of temporarily replacing more senior officers.
Overall agency costs typically increase for the period of the redevelopment processes. Replacement of seconded executives, increased hardware and multiple operating environments for build and testing, the need for expert business staff to work on design and data conversion, the need to resource the Project Management Office with in-house staff, and the increased need for fast agency-wide corporate decision-making all combine to put pressure on the operating budget. Adequate provision needs to be made in forward plans to cater for this pressure.
Because of these pressures, “optional” IT work must be kept to a minimum in this period. As mentioned in Note 1 of this series, a strictly enforced prioritization process is the key for management of workload and resource commitment to enable such restraint. Where IT development is unavoidable, e.g., because of law changes, care needs to be taken to minimize work which will be redundant when the new system is implemented. Every effort should be made to re-use existing legacy functionality where possible, or to build new features so they can be re-used by the new system. An approach to the relevant law-makers to explain the program and effects which changes can have on it may also be useful.
Appendix 1. Expanded Example of Linkages Between Different Projects in a COTS Implementation
Margaret Cotton is a Senior Economist in the Fiscal Affairs Department of the IMF. Gregory Dark is a member of the IMF’s roster of fiscal experts.
Common business process engineering methodology
Methodologies which use iterative steps rather than consecutive steps to design and build a system
COTS systems have many interconnections in-built—for instance, a change of registration details to include an extra tax-type can automatically include the creation of a new account, create new expectations for filing of a specific form, include that information in data analytics etc.
As test cases are developed, they can be stored and run automatically in future iterations of the system build to ensure functionality has not been altered.
