Tax professionals are largely aware of the technologies available to supplement their departments’ operations—technologies designed to directly support tax functions, such as tax engines, return preparation programs, and certificate management applications as well as general-purpose technologies that can be leveraged for tax, like data enrichment platforms, robotic process automation (RPA), and visualization and analytics tools.
In the authors’ experience, most tax professionals can readily identify at least one process in their department that would be an ideal candidate for technology enhancement. Why then is it so difficult for technology initiatives to gain a foothold in tax departments? In many cases, the reason is that the process of bringing a new tax technology to production is an exercise in information technology engineering. And many tax departments may not have tax technology fluency at the level appropriate to have meaningful conversations with IT departments and vendors.
This article examines the process of implementing or upgrading a tax technology solution through an IT lens by using the “phase-gate” approach. The phase-gate approach, a project management model commonly used for IT projects, includes the phases of ideation, scoping, building a business case, development, testing, and production and postproduction assessment. This article covers the critical tasks a tax department should complete during each phase in order to select and implement a technology solution that delivers the expected benefits on time and on budget, which should help lay the groundwork for subsequent technology enhancements and overall departmental efficiency and improvement.
Although other technology implementation methods exist, this linear approach may demonstrate more clearly the process and considerations in the implementation life cycle. It is important to note that other methodologies, such as an “agile” approach, can be incorporated into certain phases to allow for some flexibility throughout the course of tax technology projects as evolving dynamics arise, because business needs, the economic environment, and certain resources may change after inception.
Phase 0: Ideation and Groundwork
The phase-gate approach is a front-loaded project management model, making early planning and ideation necessary for success in later phases. In ideation, the tax team candidly and transparently discusses challenges and other issues the tax department faces that may warrant technology upgrades. The organization must be confident that its brainstorming process is comprehensive before it can begin to scope the project.
Whiteboard With Outsiders
The capabilities, accessibility, and costs of technology change constantly; therefore, even sophisticated tax departments are likely to have certain technology blind spots. Organizations that move forward with a technology implementation without first uncovering these blind spots risk implementing a suboptimal solution or identifying a better-suited solution only after advancing down the implementation path, requiring the team to double back unnecessarily.
The best way to shine a light on technological blind spots is not only by getting as many internal stakeholders involved early for fact-finding and needs assessment, but also by talking with outsiders. Industry peers are a potential resource to gauge what other tax departments are doing, but competitors aren’t always open to sharing, and organizations should avoid selecting any technology just to keep up with the Joneses. Even similarly situated organizations have different goals, priorities, and challenges.
Holding whiteboarding sessions with tax and technology advisors is an ideal way to get a 360-degree view of the current tax technology landscape and to learn what works for organizations across different industries and geographies. Leadership should signal its support for transparent feedback throughout the whiteboarding process by ensuring that all team members can participate and by providing breakout discussions to ensure that all perspectives are shared. A perspective of this breadth and depth will ensure that the ideation process has been comprehensive, laying a solid foundation for decisions to come.
Select a Strategic Partner
As the tax department devotes time to exploring new technology, its daily responsibilities remain, creating inevitable time constraints on stakeholders. To get the most out of time set aside for whiteboarding, as well as time spent on implementation, the organization must be deliberate in selecting an advisor with which to partner. Technology qualifications are an obvious consideration in choosing an advisor, but the advisory team should also have tax technical knowledge and process improvement experience. Additionally, the organization should learn whether its whiteboarding advisors would be the same team to deliver the implementation. The teams don’t have to be identical to deliver a successful project, but the organization should vet the actual engagement resources to make sure the implementation team understands the organization’s objectives, is aligned with organization personnel, and is prepared to partner with the user team as owners of the results.
Become a Data Steward
All tax technology solutions are rooted in data. If the organization’s data is unstructured, unorganized, contained in multiple repositories, and inconsistent, then implementing a tax solution likely will be much more difficult, and the solution could have limited utility. Whether the organization decides to advance beyond the ideation gate-phase in the present, or if it decides to defer its pursuit of technology, now is the time to ensure that the organization’s data is in a usable form by capturing as many data fields as possible, ensuring accurate data entry and coding, and organizing and storing data in an orderly, intuitive fashion. Although many technology solutions improve data imperfections, it is much easier to address data issues early on.
If the department is undertaking a data digitization or modernization effort in response to recent work-from-home or virtual workplace challenges, this dynamic presents an opportunity to embark on the journey to strategically capture company data so as to maximize the benefit of future technology implementations for years to come. If these efforts are undertaken at the enterprise level, they offer an important opportunity to ensure that tax has a seat at the table.
Phase 1: Scoping the Project
In the scoping phase, the team has identified at least one potential technology solution, and the organization gathers additional research to outline the project scope. The primary challenge in this phase is to move toward a balanced scope—one that is not so big as to make the project unmanageable or prohibitively expensive, but not so small that no real benefits are realized or the new solution won’t integrate with existing processes.
Focus on a Small Project . . .
It is often best to implement as small a solution as will render a benefit, especially if the technology is new to the organization. A small quick win can actually be much more valuable than a moon shot end-to-end overhaul. For example, a tax department adopting RPA or automation technology may want to focus its first batch of automation on short, well-defined manual processes—think click-and-keystroke functions such as creating payment vouchers, printing and storing deliverables to a data warehouse, or preparing returns not supported by software. Automating these tasks may produce results in weeks, whereas sophisticated algorithms based on exception-based logic and large decision trees can take months or years to write, test, and implement.
In many instances, a quick win over a relatively small, isolated problem can pay long-term dividends by increasing confidence and morale, thereby gaining leadership’s buy-in. The opposite approach, an overambitious initial bet on technology, will take longer to generate benefits and can risk creating time and budget overages. Impatient stakeholders may be tempted to prematurely terminate such initiatives, and the stakeholders’ perception of a technology failure can result in fewer long-term investments in innovation and technology.
. . . But Always Think Big-Picture
Although smaller can often be better when scoping initial technology implementations, the scope for a technology implementation of any size must be assembled with the end-to-end tax function in mind. The new technology will affect and depend on existing ancillary components of the relevant tax function, and these existing components—data, systems, controls, people, etc.—influence whether and to what extent the new technology will generate desired benefits. Organizations that don’t consider surrounding processes are often disappointed when the new technology provides only a fraction of the anticipated benefit.
For example, the potential time savings to be gained from an automation tool (whether RPA or a data enrichment application) can be greatly restricted if the data being fed into the tool must be entered manually from different systems or sources. In such a scenario, the organization should explore whether revisions to the scope could increase the utility of the solution. Specifically, the organization could explore whether comparable tools can automate data imports (many can), or the organization may expand the scope to include an optical character recognition application to amplify the capabilities of the automation program if the solution requires data scraping from a document-intensive organization.
In addition to the impact of components directly connected to the new technology, the company should consider processes located further upstream and downstream from the new technology as well as interdependencies with other initiatives. For instance, a sales tax engine will enable the company to begin proper tax collection in many new jurisdictions, but is the organization registered in all of the new jurisdictions and equipped to prepare and file all of the new returns? If the end state isn’t considered, the organization could end up in a worse position than it was in before the implementation.
This is not to say that a tax department should aim to optimize its entire process in one project, but rather that it should consider whether its anticipated improvements are realistic given existing constraints elsewhere in the department. If other components or processes are likely to impede the new technology, the scoping phase is the time to reshape the focus of the current project or begin clearing the way for follow-up projects.
Draft a Detailed Work Plan
The work plan is more than the project scope from the scope of work; it is the project road map that dictates responsibilities and timelines and is continually referenced by users and the implementation team to chart progress. A proper work plan includes implementation phases and milestones, defines tasks and deliverables associated with each phase, assigns tasks to responsible preparer and reviewer resources, associates due dates with tasks, and requires sign-off for each task. Oversight at such a granular level may seem like micromanagement, but preplanning to this degree is needed to identify gaps that could stall the project mid-implementation. The work plan should be shared with the organization’s IT professionals early on to coordinate any required IT resources and to confirm that the implementation timeline does not conflict with scheduled system maintenance or other IT projects. This is also an ideal stage to reconfirm the time commitment that will be needed from end users and department personnel to ensure there are clear expectations of needs as well as support from leadership.
Phase 2: Building a Business Case
At its core, the business case phase is a simple equation: how does the anticipated outlay compare to the anticipated return, and how soon will the return be recognized? Although the equation is relatively straightforward, factors on both sides of this equation are commonly omitted from the business case.
Make a Realistic Budget
Business case budgets are often assembled with the goal of getting the project approved instead of estimating what the project will actually cost. These lean best-case budgets are often based on generous assumptions and omit possible upstream/downstream work (discussed above) that will be needed to get satisfactory results from the new technology. Approval-based budgets often result in either an on-budget technology implementation that falls short of expectations or scope creep that takes the project over budget to deliver expected results. Either result will undercut the case for future technology requests.
Make the Realistic Budget an Attainable One
To the extent that the realistic budget pushes the boundaries of approval, there are several ways to make project costs manageable. First, consider executing the project in phases. Executing a large project in phases can spread budget requests over multiple years. Second, assuming capacity exists, identify areas where company personnel can execute some project tasks to limit service provider fees. In fact, leveraging the organization’s personnel is not just a budgetary benefit but a best practice for development and testing as well. (More on this later.) In pragmatic terms, the department should use the budget process to reevaluate existing technology and license fees. Often companies pay for stale shelfware that could be freed up to provide funds for implementation.
Finally, pursuing a cash-generating project such as a refund claim can supplement the budget for technology implementation. In an ideal scenario the proposed technology can be leveraged to execute the cash-seeking project. For example, licensing tax automation or data transformation software on an ad hoc basis to identify refund opportunities serves as a good use case to include in the business case documentation.
Quantify the Entire ROI
While describing the return on investment for the technology (fewer hours spent, improved compliance, reduced audit assessments, reduced organizational risk, etc.) is relatively easy, quantifying that return can be a challenge. To capture all the value a technology creates, consider not just the immediate impact of the technology but also the pull-through advantages it creates. Take, for example, a use tax automation platform that is estimated to improve tax accuracy. Quantifying the immediate return is simple: take prior assessments on tax underpayments and reduce tax, interest, and penalty in an amount proportional to the anticipated increase in accuracy. But as a secondary impact, also consider tax overpayments. The increased accuracy from the automation platform will reduce the professional services fees the tax department regularly pays to recover refunds. A tertiary impact would be a reduction in resources and fees spent on compliance audit management; accurate tax results can cut the time spent on audits; and good audit results (especially net refund positions) have been known to reduce audit frequency.
Finally, in addition to tax impacts, the value of freeing up personnel hours to deploy on more important initiatives, especially those that generate returns themselves, should be considered when quantifying the project’s return. This factor cannot be understated when determining the overall ROI on a technology investment. For example, the income tax director at a very large retailer indicated that she deploys her master’s degree in tax accounting by spending seventy-five percent of her time (notwithstanding her large team) “manipulating spreadsheets” for multiple purposes, including reporting, estimates, and tax-provision-related tasks. She said that even though she is now an expert in Microsoft Excel, she feels as though she is losing her edge on the tax technical side due to daily time demands. Again, quantifying hours and organizational accuracy risk are big pieces of the overall puzzle.
Consider Alternatives
Explain in the business case document why comparable alternatives are not as optimal as the proposed solution. Occasionally, articulating the case against an alternative technology is harder than anticipated. Reducing the analysis to writing can uncover gaps in the comparison process. Maybe the reduced functionality of the low-cost alternative isn’t critical to the organization’s operations, warranting further consideration; or maybe the added functionality of the higher-cost alternative will generate exponential returns, making it a viable option. In this regard, building the business case is an extension of the scoping phase, representing the last step before development. If a trip back to the whiteboard is in order, it needs to be identified at this point.
Phase 3: Development
In the development phase, the provider, in close cooperation with the tax department, designs the software configuration and builds the system configurations to meet the company’s specifications. From this stage forward, the organization’s participation becomes paramount. During development there should be clear and detailed documentation of the requirements, including a full understanding of inputs and end-state outputs as well as desired exception reporting.
Generate User Buy-In
Change management and buy-in are necessary at both user and stakeholder/leadership levels. At the user level, buy-in is needed for quick adoption of the technology and a seamless entry into production. End users should be invited (or maybe strongly persuaded) to participate in software selection, process design, and implementation. Early user participation promotes collaboration and consensus and creates a sense of ownership of the project. The organization should also identify team members with strong software/technology interest and elevate these individuals’ roles as participants or leaders in the technology implementation to promote adoption by other users. Failure to generate buy-in at the user level is the primary reason that new tax technology becomes shelfware.
At the leadership level, buy-in is needed for a fair analysis of the project after the technology is in production. Stakeholders must articulate the objectives for the initiative, and leadership needs to sign off on the anticipated benefits of the project. Assessing the results of the implementation will be critical for making decisions about the next project, and an accurate, fair assessment can be made only if the picture of success is clearly defined and documented at the outset. Raising or lowering the standard of success post hoc can prevent the organization from making objective decisions about whether to pursue subsequent technology initiatives.
Formalize Project Management and User/Implementer Roles
For any complex implementation, a project manager should be formally designated. The project manager can be on the organization’s side or the provider’s side (or both in collaboration), but the project manager should have ownership over project plan management, status calls, issue resolution, milestone management, and budget updates. Centralizing these responsibilities is integral to delivering implementation on time and on budget. It’s also important to formally designate an executive-level project sponsor and often an IT liaison who can together ensure timely access to resources and systems required for the implementation.
The elevated roles of the user team should be formalized as well. Some technology providers place such importance on role assignments and responsibilities that they assign titles to different user roles. For example, many automation and data platforms structure specific technology teams by assigning titles like data specialists, technology users, maestros, administrators, and executive sponsors, among others.
Phase 4: Content and UA/UI Testing
In testing the technology content and user interface, user data is loaded into the system for user acceptance (UA) and user interface (UI) testing. System output results are compared to expected results, differences are identified and remediated, and calculations and reporting are tried out to validate the accuracy of the application’s configurations. If possible, test the implementation in parallel against the previous process or by recreating a previous output. This testing allows comparison to previously validated deliverables. If testing is completed against new data for which a previous output is unavailable, it is important to consider changes in underlying data and facts.
Ensure USER Participation in Implementation and Testing
The degree of user participation in the implementation and testing phase should equal or exceed the user participation in the development phase. Although a turnkey implementation requiring minimal tax department resources may sound efficient, a hands-off implementation often prevents an organization from becoming self-reliant with the new technology and drastically steepens the post-
cutover learning curve. To promote user participation, the project plan should assign to the user team and key stakeholders tasks that require assignees to provide input and to gain experience throughout implementation. To facilitate participation, some organizations engage short-term external resources to relieve key internal personnel of competing commitments during implementation and testing. Governance and controls should be considered throughout implementation, but testing should provide an opportunity to formalize these new processes and develop proper documentation.
Put a Fence Around Testing
Although many components of development and implementation can occur in parallel, testing must be a deliberately partitioned phase. When the development and testing phases overlap even slightly, users frequently assume that the bugs they encounter are simply unfinished development components—and the bugs go unreported. Users should also receive specific instructions on how to test. Ideally, the project work plan will contain or reference a testing checklist for users. Without a testing checklist, user testing devolves into user tinkering, which falls far short of the scrutiny required to move new technology into production.
Phase 5: Production and Postproduction Assessment
The heavy emphasis on planning during every phase prior to production is intended to reduce challenges during the production phase. With sufficient participation and detailed planning, the user team should be fairly familiar with the new technology by this point. Some training will still be in order, but the user team’s learning will not begin at the ground level.
Training Day(s)
Training details should not be an afterthought. The scope and work plan should specify the key aspects of training, including the timing and duration of training, which party will provide training (the implementer or the technology provider), what reference materials and project/technology documentation will be provided to the organization, and which user personnel will be trained (that is, the entire user group or a selection of trainers within the organization).
Production and Postproduction Support
Once the new technology is in production, what support and assistance are available? In some instances, a “training wheels” period is designated where the provider or implementer will be available to offer support. In others, post-cutover support is provided as ad hoc consulting or, increasingly commonly, as an external tax technology help desk approach. Either way, it is important to clarify expectations well in advance of going live with the new technology.
Conclusion
Tax technology implementations represent the convergence of some of tax’s and IT’s biggest challenges—which helps to explain why companies often neglect to prioritize tax technology upgrades, despite widespread consensus about their necessity and value. As with any multidisciplinary convergence, the methods and challenges familiar to one side may seem foreign and opaque to the other. Therefore, the tax departments that learn to “speak IT”—those that understand IT methods and best practices—are more likely to experience success with tax technology initiatives.
Rob Clarke is the national managing principal of Grant Thornton’s tax digital consulting practice, which comprises all aspects of tax technology, including tax engine implementations, data transformation, analytics and visualizations, robotic process automation, optical character recognition, custom applications, and tax function process improvement. Brian Howsare is a senior manager in Grant Thornton’s state and local tax practice, specializing in transaction taxes, tax function process improvement, use tax automation, data analytics, refunds, tax audits, and appeals. Lindsay Miller is a senior manager in Grant Thornton’s tax digital consulting practice, focusing on direct/income taxes, tax function process improvement, provisions for income taxes and associated technologies, data transformation, analytics and visualizations, and robotic process automation.
