Is Your ERP Deployment Strategy Set for Failure?
On ERP implementation projects, one of the most common deployment strategies businesses start with is attempting to release everything in a single “big-bang” go-live. Big-bangs are exciting concepts to present in boardrooms as they depict a vision where all business users have their needs met in the not-so-distant future. While the “big-bang” approach can sometimes work for smaller projects, our experience with high-stakes ERP deployments has shown that for programs involving many users and requirements, big-bang plans rarely deliver smooth outcomes. Let’s examine a real-life situation where a project opting for a big-bang strategy began to capsize and how the leadership teams were able to save things by pivoting to a better deployment strategy: the iterative release.
The History
One of our clients had a multi-billion-dollar wing of their business that had outgrown its IT infrastructure. To survive their success and keep growing, the client needed to consolidate their disparate tools and platforms into a centralized contract management system. The acutely painful problem spurring the program was that the current state IT architecture had no source of truth for the contracts. Various components of the contract were owned by separate teams, and their respective data was stored piecemeal across tools with the most important data being housed in spreadsheets. As a result, every modification to the contract (a common occurrence), would lead to a cascade of manual updates to data across systems and Excel spreadsheets with several groups responsible for or relying on various portions of updates, and each representing a point of fallout. As the business grew, so did the volume of data passing through the systems of record, compounding manual errors and slowness of updates. Key events such as contract commencement and modifications were often delayed and manually managed across several sources, leading to challenges around revenue recognition and sales compensation.
As the business kept growing, the overhead and rework for several teams became unbearable. All of these factors led client leadership to demand a solution, and they wanted it delivered as quickly as possible. With the program kicking off, our product managers began working with the business leads on the core requirements. Together, we produced a set of epics and models encapsulating requirements the solution would need to satisfy. Using the scope of requirements and capabilities, the program leaders consulted top-tier enterprise architects and debated several solution options. They eventually greenlit deploying a popular lease system along with necessary customizations as their centralized contract repository. With their architectural vision in hand, the program’s board of executives also issued a clear message: they wanted the go-live to span all types of contracts in the multi-billion-dollar portfolio, AND they wanted the system to service all regions globally.
The What, When, and How Don’t Always Agree
A global solution comprehensive of all products in one big-bang… it sounded great in theory, and the business teams all nodded in agreement in the workshop conference room, but the IT leads who would have to go build it were a mix of stoic and stunned. Large ERP deployments often create friction between business and IT. Business goals are often conceptualized by executives as being delivered in one fell swoop, while the safest and often fastest method for bringing the goal to life on the technical side is through iterative deployment. This program ended up becoming a textbook case of why ERP deployments must define success in terms of a prioritized set of MVP requirements, leaving room for iterative learning and improvement in further deployments.
What Happened
As they got into the details, the program uncovered that a global solution would take 3-5 years to build despite the call to jam that work into 1 year of development. With every sprint it became increasingly evident that if the business was going to receive value in the near term, the program needed to start thinking in terms of a prioritized MVP. Moreover, the harder the teams fought to have everything ready in time, the more dire things became as the requirements backlog swelled beyond development and testing capacities with little prioritization. Meanwhile, the program runway was evaporating with little to demonstrate except for incomplete epics driving program lead readouts increasingly amber. IT and Business leads convened and eventually settled on an MVP that targeted the most important product offerings for the two largest regions of service (a vast reduction from all products and 42 regions). This goal was deliverable in a year and would provide immediate value to more than a billion dollars of contracts and customers.
Better still, launching for the most financially critical regions first would provide learnings that could be applied for fast-follow deployments targeting the 40 other regions of service. Had the program staunchly adhered to one big-bang, retrospective learning from deployments would not have been possible, making easily preventable problems compound within a single launch. Another reason why a prioritized MVP was the better deployment approach was that while not all regions would provide the same business value, many of the 40 additional regions were more complicated to solve for due to their disproportionately complex tax and accounting requirements driven by international laws.
Key Takeaways for ERP Deployment
In essence, business leads define what they want, and IT leads define how to deliver it. The when tends to be the shared territory that creates conflicts between the two teams’ planning. The best practice for ERP deployments is to define a when that is the intersection of the most ambitious release scope and timing for the business with a timeframe that still leaves IT able to execute a proper, iterative software deployment strategy. Setting this line on scope correctly is incredibly difficult, and businesses often tend to ask for everything all at once (after all, they are incentivized to do so), which most often leads to rushed work, tech debt, gaps in development, missed deadlines, and eventually a cut in scope to deliver value sooner.
The time lost in setting deployment scope correctly is typically a hefty programmatic cost on ERP deployments. The sooner the program arrives at a feasible scope and deployment strategy, the less cost it incurs, not only by reducing time spent reworking plans, scrapping workshop outputs, and pushing back work that is eventually descoped, but also in terms of minimizing the strains put on teams that start with too much to solve and too little time to do it. Product Management experts are in a unique position to help identify the most efficient and value-driven when as they have a close relationship with the business and IT; this relationship enables product managers to clearly navigate each side’s needs to define strategies that perform best for all.
As executives consult with advisors to land on a deployment target and strategy, it is critical to partner with requirements experts who can bridge the what and the how to arrive at the best when; as countless programs have illustrated, failing to set the when for the what correctly results in churn and millions of dollars lost in inefficiencies when unrealistic plans are forced into considerable revision late into the game, large portions of all-hands workshops are descoped, and the business loses ground on gaining access to the benefits of working code.
