The companion to our piece on why ERP projects fail. Seven things the projects that come in on time, on budget and actually used have in common, what the research adds, and the checklist I published in 2017 that still holds.
The companion piece went through nine well-documented ERP failures and the seven causes that keep coming back. This one is the other half: what the projects that come in on time, on budget and actually used have in common. It is a shorter list than you might expect, and nothing on it is expensive.
The sponsor is the managing director or the finance director, not the IT manager. They chair the steering group, they make the scope calls, and they say in public that the project matters. Prosci's 25 years of change management research finds the same top contributor to success in every edition: active and visible executive sponsorship. Projects with a highly effective sponsor meet their objectives roughly three times as often as those without one. Below the sponsor there is one named project manager on your side with the authority to say no.
Business Central's standard finance, sales, purchasing, stock, manufacturing and warehousing processes work for tens of thousands of companies. Successful projects start from "why would we do it differently?" rather than "make it work like the old system". The fit-gap in the Analysis phase is where those arguments are had, early and cheaply. Extensions are reserved for the handful of things that are specific to how you win business, and they are built to survive Microsoft's twice-yearly updates.
Customers, suppliers, items, bills of materials and the chart of accounts are cleaned in the old system by the people who know them, before anything is designed. History is kept to what is useful (opening balances, open items, a couple of years of transactions), not everything since 2009. The migration is rehearsed at least twice and reconciled to the penny each time: trial balance, debtors, creditors and stock. By go-live weekend it is a routine.
Unit testing by the developer on every extension and integration; system integration testing end to end with migrated data; user acceptance testing run by your own super users. Nobody opens the next gate until the last one is signed off. We wrote up where each gate sits in the lifecycle.
Super users are named in the Analysis phase, one or two per department. They sit in the design workshops, they see the sandbox as it is built, and they are trained on it as it takes shape, so by UAT they can run the system without us. They then deliver end-user training on the real configuration with real data a few weeks before go-live, and they become the first line of support afterwards. That is what makes hypercare short and the support contract cheap.
The date is chosen after the fit-gap, not before the sales meeting. Go-live is on the first working day of a quiet month, never the last day of a busy one. Manufacturing, advanced warehousing or complex integrations are given the extra time they need in Design, Development and Deployment rather than squeezed into a standard timeline. Phasing is treated as sensible, not as a failure: finance first, then operations, is how most mid-sized businesses should do it.
The people in the sales meeting are the people on the project. Risks are reported in plain words in the first five minutes of the steering meeting, not on page 40. And there is somebody on the customer's side who understands both the business and the technology well enough to challenge the partner. If the business does not have that person, that is exactly the gap a fractional CIO or CTO is meant to fill.
McKinsey and the University of Oxford, after studying more than 5,400 IT projects, boiled success down to four "value assurance" disciplines: manage strategy and stakeholders, not just budget and schedule; put a few people on the project who understand both the business and the technology; reward the team for the project outcome rather than their own workstream; and run a disciplined project office with short delivery cycles and strict quality gates. Microsoft's Sure Step methodology, which we use on every project, is the same idea with six named phases and a sign-off at the end of each. The lifecycle graphic shows where each gate falls.
In January 2017 I published a short piece on LinkedIn, What makes a successful Microsoft Dynamics NAV/Business Central project, after a run of implementations that had gone well and a couple that had not. Reading it back now, I would not change much. Here it is, lightly tidied.
A successful Dynamics NAV or Business Central project is one that meets the business requirements, is delivered and maintained on schedule, is delivered and maintained within budget, and delivers the expected business value and return on investment. Many factors contribute, but effective project management and governance are the critical ones.
Put the nine cases from the companion piece against those two lists and almost every one maps onto the first six items on the failure side. The software has changed a great deal since 2017; what makes a project succeed has not.
Once you have chosen Business Central (a good choice), vendor due diligence is paramount. You need to know that you are in safe hands for the whole journey. Like Goldilocks and the three bears, the partner should be:
Everyone wants the "just right" partner: one that meets the business requirement, delivers, and supports the critical systems that let you serve your customers and grow. Every project has its ups and downs, but if you surround yourself with the best people with the best skills, your projects will succeed time after time.
One last thing, when defining project tasks and goals: be SMART, and stay on the critical path.
If you are planning a Business Central project, the cheapest thing you can do is get the first three right before you sign anything: a sponsor who will show up, a decision to run standard wherever you can, and a look at the data. Our health check is one day of senior time to tell you where you stand on all seven. Or book a 30 minute call and we will talk it through.