david boyd & associates focusing on cots integrated tax systems before the project starts...

David Boyd & Associates

Focusing on COTS Integrated Tax Systems

•Before the Project Starts

•Procurement

•During the Project

•After the Project

Presentation to the Federation of Tax Administrators IT Conference 2005


What Should an Agency Contemplating a COTS ITS Project Focus On?

Before the Project…

There are two broad reasons to be attentive and careful in the period prior to the project:

11 Many of the most important determinants of success are decided during this period:

•Objectives and Vision

•Project Definition

•Requirements

•Choice of Software

•Choice of Hardware

•Choice of Integrator

•Governance Model

•Selection of Key Team Members


Meeting Objectives/Achieving the Vision

• It pays to articulate measurable objectives and document a vision prior to starting the project

•The tools needed in the software for efficient processing and processing monitoring are available, BUT

•It takes time, effort, and executive involvement to significantly change the status quo




Understand What it Takes to Meet Your Objectives

Consolidate stove-piped systems

Streamline and automate high volume processes

Establish a consolidated view of taxpayer’s accounts

Manage a shifting mix of return and payment channels (More Electronic)

Increase overall maintainability and adaptability of the system

Improve reporting (especially performance and analysis driven reporting)

Improve compliance processing, reporting, and revenues

Better balance priorities and workload

Improve customer service

Decrease internal errors

Modernize the technology

Key Objectives Call for Specific RFP Content

Typical Integrated Tax System Project Objectives

Question 1: How good was your evaluation if you didn’t validate that your objectives could be met?

Question 2: How good is your contract, if there is no detail describing the software features needed, the processes to be implemented, and the outcomes required in relation to your objectives?




22 There isn’t adequate time for certain critical activities once the project begins:

•Organization and process design

•Data cleanup

•Clearing up backlogs of exceptions and review items

•Hard decisions requiring analysis and consensus


Phase I – 12 Months

Reason One: Once the project starts there may not be time.

2- 3 months


1 - 2 months

Example One: 1st Phase of 12 months

Example Two: 1st Phase of 8 months

Make the Hard Decisions Before the Project (if you can)

Time available to create and build consensus on new vision.

Time available to create and build consensus on new vision.

Normally, it takes several months to reach consensus on a vision or for re-engineered processes. This time is in addition to that needed for requirements elicitation


Design and Configuration Construction Testing


Training


Phase 2 – 12 Months

Training


Phase 3 – 12 Months

Training

When Do You Figure Out the End State?

Make the Hard Decisions Before the Project (if you can)

It is difficult to implement new department wide processes if you begin implementation phasing without knowing the design for those processes in advance.



During the Procurement…

11 Understand the marketplace for COTS ITS solutions and your state’s procurement regulations.

•Mandatory Requirements and the number of qualified bidders

•‘Apple and Orange’ offerings and the evaluation approach

•Cost vs other factors


Recognize the differences in a COTS Procurement

•Deal involves multiple agreements

•Services Agreement

•Software License & Maintenance Agreement (Through the Project and Beyond)

•Hardware purchase and Hardware Maintenance Agreement

•The Software Agreement runs beyond the end of the project. It codifies a long term relationship with the software vendor and is worth some advance thought.

•Key Ts and Cs in the Software license agreement relate to:•Term of the agreement•Escrow of source code•Rights and cost of new releases•Rights to new products or replacement products•Response time •Hours of operation•Cost of annual maintenance and ceilings on increases•Continuing support or lack thereof if you don’t upgrade•Actions that invalidate the support obligation•Obligations of the vendor to keep current with new releases of dbms and operating system software

22


During the Procurement…


22 Evaluating Functionality Can Be Harder than You Think

•Often most of the bidders will claim that all or nearly all requirements can be met

•The extent of functionality and how requirements are met are important to consider

•The following distinctions are useful

•Met out of the box

•Met with configuration

•Met with site specific code

•Met with modification to the base package




During the Project…

General Design

Preserving the Upgrade Path

Using Protected APIs

Understanding Configuration Options Used and Not Used

Acquiring Experience for Use After Implementation

Getting the Organization Ready for the Software

Balancing Exception/Review Workload with Staff

22

33

44

55

66

11

77




11 General Design

•In many cases, COTS integrators will install the system, demonstrate it for the user community and immediately engage in configuration, gap analysis, and site specific design.

•This approach is a very good thing in terms of achieving quick implementations and keeping down implementation costs.

•It does not lend itself to process and organization redesign.

•IF you do want such process and organization redesign during the project, you might want to include a general design deliverable that specifies new processes, roles, and a revised distribution of work across organizations. (As opposed to a ‘gap analysis’ type deliverable or just iterative configuration with heavily involved but not heavily empowered users.)



22


Preserving the Upgrade Path

•COTS solutions provide an upgrade path that can provide a stream of functional enhancements and provide protection against technological obsolescence.

•Modifications to the baseline package or extensive site specific additions make it harder to upgrade.

•The project governance structure needs to act as a brake on such site specific solutions where they unduly complicate or even prevent upgrades.

•It should also engage the software vendor (who may not be the integrator or even the prime contractor) as an integral part of this effort. This collaboration should extend to incorporating any absolutely needed changes to the base software into future releases.




33 Using Protected APIs

• Part of the effort to preserve the upgrade path involves use of ‘protected API’s’

• Protected API’s are Application Programming Interfaces that the software vendor agrees not to change from one release to the next.

• Use of these APIs in writing site specific code gives the agency some assurance that they will not have to completely rewrite site specific extensions to the base code.

• Agencies should work closely with the software vendor to understand which APIs can be safely used and which cannot. Also, the extent to which any APIs are ‘protected’.




44 Understanding Configuration Options Used and Not Used

• Much of the configuration will be done by the integrator and it is important that agency employees understand how the system was configured to achieved tested and approved functional outcomes.

• Less obvious is the need to understand configuration options not used, so that they can be used later as functional needs evolve.




55 Acquiring Experience for Use After Implementation

• Most tax and revenue agencies are aware of the need to leverage the project to train their people.

• Generally, a range of representative tasks are assigned to agency personnel so that they have exposure to the types of tasks they will perform once they take over maintenance responsibilities.

• This is generally not sufficient to train internal staff given the integrator’s extensive role in configuring and extending the system.

• One option that has been used on projects using two separate packages is to have agency personnel take responsibility for a full implementation phase (typically all tasks related to implementation of a specific tax). This generally takes place while the integrator is still on site to answer questions and deal with problems that cannot be handled easily by the internal staff.




66 Getting the Organization Ready for the Software

•Integrators naturally focus on getting the software ready for the organization.

•Notwithstanding the assistance they give related to training, they take little responsibility and spend little time getting the organization ready for the software.

•It is properly the agency’s role to make the organizational, procedural, and HR changes necessary to achieve efficient operations using the software.

•But that responsibility is rarely dealt with at the level of plans, activities, deliverables, status reporting, or deadlines. As a result, the preparation for software use is typically limited and less than fully effective.

•The set of tasks to prepare the organization should be formally recognized during the plan and monitored like other tasks.




77 Balancing Exception/Review Workload with Staff

•Workflow tools available with COTS solutions make it easy to establish a work list for exceptions, items requiring review, and other reasons.

•There is a tendency among agencies implementing new ITS software to overuse these features and to generate work items faster than they can be worked.

•If data conversion activities generate work items, then an agency can find itself with tens of thousands of work listed items in the first week of live operations.



After the Project…

11 The IT organization must be properly structured and sized

• When the COTS package become enterprise wide in its implementation, the impact on the IT organization can be significant.

• A number of factors act to reduce staffing needs

•The vendor is responsible for maintaining the base code. The in-house IT shop only maintains site specific code.

•Much of what would have been maintenance programming is done via configuration

•At some sites, configuration is done primarily by the business users rather than IT personnel.

• The functions of the maintenance organization change significantly.


Overall Management

Operations/Production

Environment

ITS Application Maintenance

ITSApplication

Administration

ProjectsVendor

Relationships/Contracts

• ITS service request log and prioritization

• ITS Configuration

• ITS Site Specific Programs

• ITS Reports

• ITS Correspondence

• ITS Interfaces

•Security

•Workflow

•Single Sign on

• Job scheduling and submission

• Backup and recovery

• Archiving and restoration

• Capacity Planning

• Production Environment Toolset

•Upgrades

•Implementation of remaining taxes

•Upgrades

•Implementation of remaining taxes

•Other large scale efforts

ITS Training

• New user training

• Project training

• Maintenance Training

• Documentation

•Planning

•Assignment

•Coordination

•Coordinate with business community

Sample COTS Based Maintenance Organization

•These functions are phased in as the project proceeds.


Conclusion

Concluding Comments

david boyd & associates focusing on cots integrated tax systems before the project starts...

Documents