How to Plan an ERP Project Before You Write a Line of Code

An ERP project is rarely lost during development. It is lost earlier, in the weeks when nobody wrote down what the system was supposed to do, who would use it and which parts of the business it would actually replace. By the time the first module is demonstrated, the expensive decisions have already been made silently.

This article describes the planning work that should happen before a single screen is designed. None of it requires a technical background. All of it reduces the probability of an abandoned system, and most of it remains useful whether you build custom software, adopt a package or decide to do neither.

Why ERP projects fail

The failure patterns are consistent across industries and company sizes. They are almost never about the programming language, the database or the framework. They are about clarity, sequencing and ownership.

• The scope was described as a list of features instead of a set of business processes.
• The people who do the daily work were not consulted, so the system models management’s assumption of the process rather than the process.
• Everything was declared essential, so nothing could be delivered early enough to learn from.
• Data migration was treated as a final step instead of a design constraint.
• No single person inside the business owned the project, so decisions waited for meetings.
• Success was never defined, so the project could not be judged complete.

Start with operations, not features

A feature list is a description of software. A process map is a description of your business. Software should be derived from the second, not the first. Before evaluating any system, document how work actually moves today, including the parts nobody is proud of.

For each core process, write down the trigger, the sequence of steps, the person responsible for each step, the document or record produced, and what happens when something goes wrong. That last point matters more than people expect: exception handling is where generic systems usually break down.

Questions that produce useful answers

• What has to happen between a customer request and money in the bank?
• Where does the same information get entered more than once?
• Which numbers do two departments calculate differently?
• What decision is regularly delayed because the information is not available?
• Which step depends entirely on one person’s memory?
• What breaks when that person is on leave?

Interview the people who perform the work, not only the managers who describe it. The gap between the two versions is usually where the real requirements live.

Define the first release honestly

The most valuable planning output is not the full requirement document. It is the agreed boundary of the first release: the smallest scope that changes daily operations enough to be worth using, while being small enough to deliver and adopt.

A good first release usually covers one complete cycle end to end rather than fragments of several. Half of inventory plus half of sales is not usable. All of inventory, delivered on its own, can be.

1. List every candidate module or process area.
2. Mark each one as blocking, valuable or deferrable for daily operations.
3. Keep only the blocking items in release one.
4. Write the deferred items into a visible roadmap so nobody feels they were forgotten.
5. Agree in writing that the deferred list will not quietly re-enter release one.

Scope that is never written down is scope that expands until the budget stops it.

Map your data before your screens

Screens can be redesigned in an afternoon. A wrong data model is expensive for the entire life of the system. Before discussing interfaces, agree on the core entities the business relies on and the rules that connect them.

• What is a product, and does a product with two units of measure count as one record or two?
• What identifies a customer uniquely, and what happens when the same person buys under two company names?
• Can a document be modified after it is posted, or only reversed by another document?
• Which values must be calculated from records rather than typed by a user?
• What must never be deleted, and what may be archived?

These questions sound administrative. They determine whether your reports will be trustworthy in year three. A system whose totals are typed by users rather than derived from records will eventually produce two different answers to the same question, and staff will return to spreadsheets to resolve the conflict.

Plan integration and migration as design constraints

Migration is not a task at the end of the project. It is a constraint on the design, because the shape of your existing data determines what the new system can accept without manual cleanup.

For migration

• Decide which historical data genuinely needs to move and which can stay accessible in the old system as a read-only archive.
• Assess data quality early: duplicated customers, inconsistent item codes and missing values are discovered during migration, not before it.
• Assign someone from the business, not the development team, to own data cleanup decisions.
• Plan a trial migration well before go-live so the real problems appear while there is still time.

For integration

• List every external system the ERP must exchange data with and in which direction.
• Confirm that each of those systems actually has an interface you are permitted to use.
• Decide what happens when an integration is unavailable: queue, retry, or block the operation.
• Treat any integration without a documented interface as a project risk with a cost attached.

Define roles, permissions and accountability

Permissions are usually discussed too late, as a configuration step. In practice they encode how the business distributes trust, and they change how the software must be built.

Decide who may change a price, approve a discount, adjust stock, cancel a posted document, view margins and export data. Then decide whether each of those actions should be blocked, allowed with approval, or allowed but recorded. Recording is often the right answer: it preserves speed while making behaviour visible.

Budget time, money and internal people

The development cost is the most visible number and rarely the most decisive one. Three other costs determine whether the project succeeds, and all three are usually underestimated.

• Internal time: your staff must be available for discovery sessions, review and acceptance testing. If nobody has time, the project will be built on assumptions.
• Data preparation: cleaning existing records is business work, not development work, and it cannot be outsourced entirely.
• Adoption: training, parallel running and the temporary productivity dip while people learn the new system.

Also budget for the period after launch. An ERP is not finished on go-live day; it stabilizes over the following weeks as real usage exposes gaps. Plan for that support window explicitly instead of discovering it as an unbudgeted surprise.

Choosing a delivery partner

Evaluate how a vendor thinks, not only what they have built. A demonstration shows a finished surface; the questions they ask reveal how they will handle your specific situation.

• Do they ask about your processes before proposing modules?
• Can they explain their architecture in plain language, including what it will not do?
• Will you receive documentation, or only a running system?
• Who owns the source code and the data?
• What happens if you want a different team to maintain it in two years?
• Are they willing to say that part of your request is unnecessary?

A vendor who never disagrees with you during planning will not protect the project during delivery.

A practical pre-project checklist

If you complete only one thing from this article, complete this list. It is the minimum documentation set that allows different vendors to be compared fairly and prevents the scope from being invented during development.

1. A written description of the three to five core processes, with steps, owners and exceptions.
2. A named internal project owner with authority to make decisions.
3. An agreed first-release scope and an explicit out-of-scope list.
4. A list of core entities and the rules that govern them.
5. An inventory of existing data, its location and its quality.
6. A list of required integrations and their documented interfaces.
7. A role and permission matrix for sensitive operations.
8. A definition of success that can be evaluated three months after launch.
9. A budget that includes internal time, data preparation and post-launch support.

What a well-planned project looks like

In a well-planned ERP project, the first demonstration contains no surprises, because everyone already agreed what would be in it. Disagreements happen over documents rather than over delivered software. The deferred list is visible, so nobody argues about whether a module was forgotten or postponed. And when the first release goes live, it replaces something specific rather than existing alongside it.

None of this guarantees success. It does mean that when problems appear, they are visible early, described in business terms and small enough to correct. That is the realistic goal of planning: not certainty, but early visibility while change is still inexpensive.