Why Tax Technology Projects Fail

Technology projects often end in disappointment, and in some cases, they lead to significant financial losses for the companies that undertake them. The statistics are grim: according to Gartner, between 55% and 75% of ERP projects end in failure, and McKinsey reports that 70% of digital transformation initiatives fall short of their intended goals. Tax technology projects are no exception, and their intricate and cross-departmental nature makes them particularly prone to failure.

While we are well-acquainted with common causes of project failure, such as vague project objectives, inadequate resources, and limited budgets, there are some other often-overlooked factors that can spell disaster even when everything else seems ideal. This article aims to explore some of the less recognized factors contributing to tax technology project failures.

The missing link: understanding the current state

Tax technology projects often falter because they skip a crucial step – comprehensively understanding the current state of affairs. In the fast-paced environments of today, many projects skip this critical analysis phase in a rush to start the work. However, you can’t chart a clear path forward unless you know precisely where you stand. Projects, processes, and systems are often imbued with a complex history, especially in larger organizations where numerous systems and processes span multiple teams.

But what exactly does “the current state” mean? Let’s consider a practical example: if you’re planning to implement e-invoicing capabilities, understanding the current state involves delving into how data is currently extracted from your ERP, the formats in which it’s stored, and whether you rely on ERP-native solutions or middleware. Additionally, it’s essential to identify any missing e-invoicing-relevant data in your ERP and uncover any data enrichment occurring outside the ERP system. Frequently, these processes aren’t adequately documented, or the documentation fails to accurately represent how things are done in practice. This deficiency must be addressed before introducing any new technology that’s meant to integrate with existing systems.

A critical area of concern in the context of tax technology projects is system integration. Direct integration involves automating the transfer of data from one system to another, while indirect integration relies on manual manipulation by a user who extracts data from one system, makes adjustments in a spreadsheet, and imports it into another solution. The pitfall here is assuming that the integration is entirely automated, only to discover that it’s a manual process. Indirect integrations are challenging to detect because they’re often carried out by a small group of individuals without proper documentation or awareness from others using the system. It’s imperative to understand these integration points to safeguard data flows against future disruptions.

In addition to understanding the current state, it’s equally important to evaluate its effectiveness and efficiency. This becomes especially crucial if you’re contemplating the purchase of third-party software with customization options. It’s a common pitfall to insist on customizing software to fit existing processes without questioning if the process itself is a competitive advantage. Don’t customize software to your process unless the process is your competitive advantage.

Decisions and the dangers of committee decision-making

Every success and failure within a project can be traced back to a decision or a lack thereof. Therefore, identifying the individuals who possess decision-making authority is crucial. In many cases, decision-making becomes convoluted as committees make choices, leading to delays and ineffective compromises. Committee decisions often necessitate revisiting because they tend to involve parties who weren’t appropriately engaged from the project’s outset.

The solution is to initiate each project by clearly designating the decision-makers and endowing one person with ultimate ownership and accountability for the project’s decisions. Establishing a transparent decision-making process is essential. Various methods have been devised to clarify decision roles and responsibilities, such as the RAPID framework. The five letters in RAPID correspond to critical decision-making roles: Recommend, Agree, Perform, Input, and Decide.

Recommenders are responsible for formulating proposals, gathering input, and providing essential data and analysis to facilitate timely, sensible decisions. Those in the Agree role possess veto power, granting them the authority to approve or disapprove recommendations. If agreement is elusive, the issue can be escalated to the decision-maker. Individuals in the Input role are consulted for their insights into the decision. Their input isn’t binding, but it carries significant weight in the implementation process. The formal decision-maker in the Decide role holds accountability for the decision, along with the authority to resolve any impasses in the decision-making process. The Perform role entails the execution of decisions, which may be handled by the same people who recommended them.

The dangers of scope creep

Scope creep, the uncontrolled expansion of project features and functionalities without addressing the impact on time, costs, and resources, is a prevalent issue in tax technology projects. While changes to project plans are inevitable, excessive scope creep can be just as detrimental as its opposite, “scope kill,” where changes are strictly prohibited.

Scope creep manifests through various channels, often originating from a lack of robust project definition. In the realm of tax technology projects, this issue is particularly prevalent, where tax specialists may not have an in-depth grasp of the technology while engineers may not fully comprehend the intricacies of tax regulations to be integrated.

The absence of precise and well-articulated project requirements creates ambiguity and leaves room for interpretation. Team members and stakeholders may have varying understandings of what the project should entail, which can lead to the introduction of new elements or changes as the project progresses. Additionally, scope creep in the form of scope drift can materialize when there is a broadening of stakeholder involvement. This expansion can lead to a misinterpretation of the project’s overarching scope, resulting in deviations from the original intent.

To effectively stave off scope creep, it’s prudent to consider these preventative strategies. First and foremost, it’s crucial to define comprehensive and detailed requirements and ensure that they receive official approval. This approach establishes a robust foundation for the project. To maintain control over scope changes, establish a formal process for modifying requirements. This structured procedure should be rigorously followed to manage alterations effectively. Keeping projects focused and of shorter duration can be instrumental in minimizing the introduction of new ideas and changes to project requirements. Lastly, as scope creep remains an inevitable challenge, it’s wise to incorporate contingency measures into your project planning. These measures act as a safety net, allowing for necessary adjustments while safeguarding the project’s integrity.

Conclusion

While tax technology projects inherently carry risks, understanding the current state, clarifying decision-making roles, and managing scope changes are key steps to mitigate these risks and improve the odds of project success. Addressing these often-overlooked factors can greatly enhance the success rate and minimize the risk of failure, ultimately leading to more successful and cost-effective outcomes.

The opinions expressed in this article are those of the author and do not necessarily reflect the views of any organizations with which the author is affiliated.