You’ve set out your tax technology strategy, planned your roadmap, and appointed a head of tax technology to make it happen. You’ve identified your technical requirements; and been through a vendor selection process if buying a product.
Now it’s time for the sharp end of the journey: deploying your tax technology solution. How you go about managing that will be crucial to whether your investment proves worthwhile.
Big bang – or bit by bit?
1. Waterfall – building the entire solution, then going live at the end of the project in a single, ‘big-bang’ release.
Waterfall is the traditional way of running tech deployments, and the one most of your stakeholders will be used to. It’s best suited to specific scenarios such as if the product is needed ahead of a regulatory deadline, if the requirement is fixed and unlikely to change, or for relatively short or quick projects.
2. Agile – generating ongoing value, by releasing incremental versions of the solution early and often.
The agile approach starts by creating a minimum viable product (MVP), which meets only some of the project’s requirements. Once that’s live, the development team builds the solution up through cycles of user-testing and iteration, which continue until there’s minimal value left to be delivered.
Since its introduction around twenty years ago, agile has become the more common approach, as it’s well adapted to the demands of technology installations. These tend to be lengthy projects, which evolve as they go along. They’ll often start with a set objective, which then changes during the implementation. The agile method allows you to adapt what you’re developing as and when the goalposts move.
Agile also releases value as you go along, so should your budget get pulled mid-project, you’ll have something to show for the money spent so far.
The challenge with agile is that it’s likely to be unfamiliar to most people working on the implementation.
The development team will almost certainly be accustomed to it; but your wider stakeholder group might expect waterfall-style delivery, with a definite end date. They may need educating, to understand why they keep testing an incomplete product, which doesn’t meet all their requirements.
A note of caution: don’t fall into the trap of ‘wagile’ project management. A hybrid waterfall-agile method never works. It just frustrates stakeholders who don’t understand the benefits of agile, without actually delivering them.
The five steps to implementation
Once you’ve decided your management approach, there are five key stages to a technology implementation.
1. Project charter
Start by laying down the ground rules: who’s accountable for, and involved in, developing the solution? What are your success factors and metrics? If you’re buying the product, who’s responsible for the relationship with the vendor?
I’d recommend creating a project charter, setting out ten fundamental elements of the project:
The charter provides vital clarity over who’s doing what, why, and how the various teams and stakeholders should work together. It’s crucial to help establish a collaborative culture among them from the outset.
2. Solution development
With the charter in place, implementation can begin in earnest.
This phase will be different depending on which approach you’ve opted for. On a waterfall project, it requires a detailed plan, against which progress is continuously monitored, and regularly reported to stakeholders, by the project management office.
With agile development, only the MVP is defined at the start, and a list is compiled of all the tasks required to develop it. User groups are then brought together to test the MVP, and the development team reprioritises and replans in response to their feedback.
This cycle repeats in a series of two-week ‘sprints’, until the solution is delivering the desired value.
3. User acceptance testing (waterfall only)
On waterfall projects, once the product has been built and released, you need to verify with users that it’s working as it should.
There are four steps to user acceptance testing:
start by defining the scenarios you wish to test
prepare scripts to take users through these scenarios
record users’ feedback on: the steps taken to complete the scenarios, whether the tool achieves the desired outcomes, whether it meets the non-functional requirements, how user-friendly it is
address any issues with the solution that your users point out
4. Change management
Once the first release is developed and tested, you can release it across the tax function.
This takes your project into an essential change management phase. New technology can significantly alter how people do their jobs – which may lead to anxiety, disengagement and even resistance.
Overcoming these reactions means educating affected employees about the solution. It’s important to communicate why it’s being implemented, how to use it, and where to get support if needed.
Appointing champions for the new tool should be part of your change management strategy. You might also want to start with a period of intensive ‘hyper-care’, over and above the usual level of tech support available to staff.
5. Project closure
Once the solution is bedded in, all that remains is to assess that it’s delivering the intended value; and document any lessons learned for future implementations.
Then you can move onto the next milestone on your roadmap.
Find out more
KPMG’s tax technology team has deep experience of both waterfall and agile solution development – and can help you avoid the ‘wagile’ trap.
Our proven processes and ready-made templates will accelerate your implementation, and take the formulaic work off your team so they can focus on delivering value.
We can also support your stakeholder engagement and education, and your post-release change management activity.
Please get in touch to see how we can help manage your tax technology implementation.
