The conversation usually goes like this. Leadership has been handed a deadline they don't like, they want it shorter, and they ask the partner: can we do this in six months? The partner says yes, the project starts, and twelve months later everyone is wondering what happened.
The honest answer is that a six-month ERP implementation is absolutely possible. But it's not a compressed twelve-month project. It's a different operating model with a different set of preconditions, and if any of those preconditions are missing on day one, the timeline is already dead — you just don't know it yet.
These are the five we keep coming back to.
A reliable internal team that can actually decide
The thing that kills timelines isn't ERP configuration. It's decisions sitting in inboxes for three weeks while seventeen internal meetings get scheduled. A six-month implementation is, in practice, a six-month decision-making exercise. If your team can't keep that pace — or won't, because they see the project as a side gig to their day job — you don't have a six-month project.
The team you need isn't necessarily the department heads. It's whoever knows the most and refuses to let the project fail. Sometimes that's the head of operations. Sometimes it's the analyst two layers down. Identify those people and put them on the team, with permission from leadership to make decisions in the room rather than escalate every one of them.
And if the team can't decide on their own, leadership needs to be there too. There's nothing worse than a go-live where someone senior suddenly asks "but what about…" three days after cutover, and the team has to say: you never mentioned that.
A genuinely simple business operation
Not every business is a candidate for six months, and pretending otherwise is dishonest. If you're multi-entity, multi-currency, heavily compliance-driven, with fifteen manufacturing sites and EDI to every customer, the answer is no. That's a twelve-to-eighteen month project, and that's fine — it's the right length.
What makes a business actually simple isn't the absence of complex Excel sheets. It's the absence of structural complexity: special pricing rules, weird customer-specific workflows, three integrations that all have to land on go-live day, and a different process for every product family. An ERP can replace a mountain of spreadsheets and still go live in six months. It cannot absorb structural complexity in that timeframe — that has to be designed out first, in phase zero, before the implementation clock starts.
Integrations are the silent killer. Every integration is a mini-project. If it's not absolutely required on day one, it shouldn't be in phase one — even if that means living with an Excel export for sixty days post-go-live.
A willingness to go standard with a clear MVP
Customisation tolerance should be near zero. The only things that should survive are regulatory requirements and genuine competitive advantage. Everything else is no.
The honest test for what belongs in phase one is whether you already have it. If you're currently running raw material planning in Excel, you can keep running it in Excel for the first sixty days post-go-live. You don't need to configure the system to replace it on day one. That's a phase two problem — and you'll make better decisions about it once the business is live and you actually know how the new system behaves.
The implementation should change the business more than the business changes the ERP. That's the orientation. The moment a customer tells the partner "just for this one part, can we…", the implementation has already started to drift. One customisation announces to the rest of the business that the rules are flexible, and the requests pile up from there.
The pattern that catches people out: every project starts with "we want to go generic". By month three, the reports are different, the workflows are different, and the timeline has moved.
A VAR who will challenge you, not nod along
You're not buying a consultant who builds whatever you describe. You're buying a partner who has seen this play out a hundred times and will tell you when you're about to make a mistake.
The tell during the sales process is who's doing the talking. If the partner is doing 80% of the talking, showing you logos and feature decks and not asking probing questions about how your business actually runs, that's the relationship you'll have for the rest of the project too. The partner you want will listen, take it back to their team, strategise, and come back with a perspective — sometimes one you don't want to hear.
You also have to be willing to lose some of the arguments. The partner has seen more implementations than you have. When they push back on a customisation request, they're usually right. If your project lead can't take that pushback, swap them out. There's no version of this where an "everyone agrees with me" project leader produces a six-month outcome.
The right ERP for the timeline you want
Some ERPs are built for rapid deployment. Some are not. F&SCM, SAP S/4HANA, IFS — these are not six-month implementations under any normal definition. Pick the wrong product and the other four conditions don't matter.
Conversely, some businesses get oversold a tier-one ERP when a mid-market product would have served them better, gone live faster, and cost a fraction of the subscription. The question isn't "what's the best ERP". It's "what's the best ERP for our timeline and our complexity". There's no best. There's only fit.
You're looking for something that gets you to a 70–80% fit out of the box. That last 20% is where the partner earns their fee — through process change, third-party add-ons where appropriate, and the occasional pragmatic customisation. If a product needs heavy customisation to reach 70% fit for your business, it's the wrong product.
What this actually means in practice
The five conditions exist on day one or they don't. You cannot manufacture them halfway through the project.
If your implementation is currently slipping, the question isn't "should we throw more bodies at it". The question is which of the five conditions you didn't have, and whether you can still get it. Sometimes you can. Sometimes the answer is to acknowledge the timeline was never six months in the first place and reset expectations honestly.
The counter-intuitive bit is that an eighteen-month project is often riskier than a six-month one. ERP risk compounds with time. Eighteen months gives the business three times longer to lose its nerve, change leadership, decide it wants three new features, fatigue out of training, and watch key people leave. Six months — when the conditions are right — is the lower-risk option, not the higher-risk one.
If you're staring at a six-month deadline right now and trying to work out whether it's realistic, the five conditions above are the checklist. Run yourself against them honestly. If you can tick all five, you have a real chance. If you can't, the deadline doesn't change physics.
This is from episode S4E11 of The ABCs of ERP & Beyond
Questions? Drop me a line: info@petenicholson.co.uk
