The rush to build
Most ERP projects start the same way.
Week one: Requirements gathering. Two days of meetings. Stakeholders list what they want. IT writes it down.
Week two: Technical design. Architects draw boxes and arrows. Developers estimate hours.
Week three: Coding starts.
Six months later: Nobody can explain why half the features exist. The other half don't do what anyone needs. The project is over budget and behind schedule.
The problem wasn't execution. It was starting wrong.
What clarity actually means
Clarity isn't writing down what people say they want.
Clarity is understanding what problem you're actually solving.
When someone asks for a custom field to track "customer priority," the real question isn't how to build that field. It's why they need it.
Are sales reps fighting over which deals to close first? That's a compensation structure problem, not a software problem.
Is customer service routing tickets wrong? That's a process problem, not a field problem.
Is leadership trying to forecast revenue? That's a data quality problem, not a customization problem.
Same request. Three completely different root causes. Three completely different solutions.
If you start coding before you understand which problem you're solving, you'll build the wrong thing.
Why projects skip this step
Because clarity is uncomfortable.
Asking "why" five times exposes broken processes. Unclear ownership. Competing priorities. Things people would rather not talk about.
It's easier to just build what they asked for.
The consultant gets paid. The project stays on schedule. Everyone avoids the hard conversation.
Until six months later when the system goes live and nothing works the way anyone expected.
What clarity before code looks like
We don't start with requirements. We start with questions.
What's broken right now? Not what features you want. What's actually not working in your business today.
What happens if we do nothing? If the pain isn't worth fixing, we shouldn't build anything.
Who owns the outcome? If nobody will be accountable for whether this works, it won't work.
What does success look like? Specific, measurable, time-bound. If you can't define it, we can't build it.
What are we willing to kill? Every yes is a no to something else. What are you willing to not do.
These questions take time. They're uncomfortable. They surface problems people don't want to deal with.
That's the point.
Better to find out your process is broken in week one than in month six when you've already spent the budget.
The discovery phase
This is why we always start with discovery.
Fixed price. Fixed scope. Two to four weeks.
We audit the current system. Interview users. Map processes. Document actual workflows, not wished-for ones.
We find the gaps between what people say they do and what they actually do.
We identify what's a software problem and what's a people problem.
At the end, we deliver a plan. What's in scope. What's out. What it costs. How long it takes. What the risks are.
Then the client decides whether to proceed.
Sometimes they don't. The numbers don't work. The timing's wrong. The organization isn't ready for change.
That's fine. Better to know now than after you've burned six months and half a million euros.
What this prevents
Scope creep. Because everyone agreed upfront what we're building and why.
Rework. Because we understood the problem before we started coding.
Political battles. Because we surfaced the conflicts early when they're cheap to resolve.
Failed deployments. Because we know what success looks like and we can measure whether we're on track.
Technical debt. Because we're not building features nobody needs just because someone asked for them.
Why most consultants won't do this
Because it delays revenue.
If you spend three weeks on discovery, that's three weeks you're not billing implementation hours.
If the discovery reveals the project isn't ready, you might lose the deal entirely.
So most consultants skip discovery. They take the requirements at face value. They start building immediately.
They get paid faster. The project looks like it's moving.
And six months later when it falls apart, they're already gone.
What this means for you
If a consultant is willing to start coding on day one, run.
If they don't ask uncomfortable questions about your processes, your organization, your readiness for change - run.
If they take your requirements list and say "sure, we can build all of that" without challenging anything - run.
The best ERP projects start slow. With questions, not answers. With clarity, not code.
Because if you don't know what problem you're solving, it doesn't matter how well you write the code.