A new CFO, a new IT Director, or simply someone newly assigned ownership of an already-struggling Business Central project faces a specific, disorienting problem: everyone around them has an opinion about what's wrong, the previous owner's decisions are only partly documented, and there's real pressure to show progress immediately. The instinct to start fixing things in the first week is understandable. It's also usually premature.
First: Get an Honest Picture, Not a Fast One
Before changing anything, the priority is understanding what's actually true about the project's current state — not what various stakeholders believe is true, which often conflicts. This means reviewing the actual configuration, the actual data quality, and the actual gap between documented requirements and what's been built, rather than relying on secondhand accounts from people who each have their own version of what went wrong.
This diagnostic step feels slow when everyone wants visible progress immediately. It's also the only way to avoid the common failure of inheriting a project, making confident changes based on incomplete information, and discovering weeks later that the "fix" targeted the wrong problem.
Second: Separate People Problems From System Problems
Failing implementations often involve both — a genuinely flawed technical approach and genuine communication or trust breakdowns between teams. These require different responses, and conflating them leads to either a technical fix that doesn't repair damaged trust, or a relationship reset that doesn't address a real underlying configuration problem. Diagnose both separately before deciding what to prioritize.
Third: Resist the Urge to Assign Blame Before Understanding the Full Picture
It's tempting, and often politically expected, to identify whose decisions caused the current state. Resist doing this publicly before you genuinely understand the full context — decisions that look clearly wrong in hindsight were often reasonable given what was known at the time, and premature blame damages your ability to get honest cooperation from the people who actually know where the bodies are buried in the current configuration.
Fourth: Get One Independent, Specific Assessment
Rather than relying entirely on internal accounts — inevitably colored by whoever's telling them — a genuine outside assessment, focused specifically on the data model, configuration logic, and gap-to-requirements, gives you a foundation to make decisions from that isn't filtered through internal politics. This is exactly the kind of diagnostic covered in more depth elsewhere on this site, and it's worth prioritizing early rather than after you've already made public commitments about next steps.
Fifth: Communicate a Realistic Plan, Not a Reassuring One
Once you have an honest picture, resist the pressure to present an overly optimistic recovery timeline just to relieve immediate stakeholder anxiety. A realistic plan that undersells slightly and delivers on time rebuilds trust. An optimistic plan that slips again compounds the exact problem you were brought in to fix.
The Pattern Underneath All of This
Every step above trades short-term pressure for long-term accuracy. Inheriting a failing project creates enormous pressure to move fast and visibly. The actual path to fixing it runs through moving deliberately and accurately first — which feels slower in week one and is almost always faster by month three.