This blog post is the first part about why implementations fail, and what you can do about it.
Flawed from the Start
Implementations fail 70%+ of the time because they are built on the assumptions that…
- Everyone involved is equally incentivized to succeed
- Your business requirements are static
- Your requirements are simple enough to be passed around without losing critical details
- The solution being built is future proof
The standard first 3 phases are a dead giveaway
Phase 1 - Commitment
There’s a financial commitment made by the FP&A team before an implementation even starts. Whether it’s a costly Statement of Work, or a commitment of internal resources, there’s a large commitment made in advance. Commitment (to anything you do) is important, but a financial commitment to an implementation is challenging because it implies you know the cost. Once a commitment is made, deviations in time and deliverables are viewed as failures - and often external resources make more money if the project goes sideways.
Phase 2 - Discovery & Design
Once an organization commits to implementing a new tool, the implementation team, which could be an internal or external team, begins documenting the “what” and “how” things are done today, and how they should be done in the future. This is often based on the false assumption that what we do today, and what we want the future to look like, is set in stone. IT IS NOT. During the discovery & design phase, implementation teams are essentially drawing a map to a fixed destination as described by the business. This map is often memorialized contractually in milestones. The problem is, business needs change and the map does not - at least not without significant cost.
Phase 3 - Development
During the development phase, teams are hard at work building & configuring based on the roadmap documented during the discovery and design phase. Typically, the development team is at least a few degrees removed from the user’s actual needs - and in FP&A, almost no development teams (the people that do the work) truly understand the finance team’s needs. Anybody who’s played the game “telephone” understands why this can be difficult with even simple phrases. Add complex FP&A use cases, organization-specific logic, multiple projects managed by the same development team, and competing priorities and it’s easy to see why this often doesn’t end well.
Failure is so common and widespread that there’s been cartoons circulating since at least the 1960’s.
So... What can we do about it?
Be Skeptical!
Microsoft creates some of the most powerful financial software in the world and doesn’t require an implementation - why does your FP&A platform? As an FP&A and Operations leader myself, and after many implementations of both ERP and point solutions, I believe implementations are simply a way of making the customer pay for product shortfalls.
Align Incentives
If the value you get from the software is contingent upon a successful implementation, then so should your commitment. Don’t sign long-term contracts, or pay upfront, for a solution that won’t work for months.
Reverse Implementations
If you have to do an implementation, do it in reverse order. Quickly add your data to the FP&A platform of choice, and focus your efforts on both offensive and defensive progress.
Offensive progress: Use your new platform to drive progress. By focusing on offense first, you can ensure that the software can deliver on the ideal outcome - progress!
Defensive progress: Use your new platform to automate and fix the manual and time consuming processes and issues, so you can spend more time on the goal - offensive progress!
Want to understand reverse implementations a bit more?
Email me and we can find some time to geek out on FP&A:
Oliver@AnalystIntelligence.com
