Five questions to settle before an ERP project starts

An ERP project rarely fails because of the software. More often the organization starts without answers to a few plain questions and finds them later, when each answer costs more. Here are the five we ask before the first workshop.

What is in scope?

"The whole company" is not a scope. A scope is a written list: which processes, which legal entities, which sites, which reports, and what is left for later stages. The list protects the budget better than any contract clause, because every later request can be checked against it.

A useful test: can the first stage be described on one page, and can somebody outside the project understand from that page what will work on the first day?

Who owns the result?

A project needs one manager on the client side with the authority to decide and to free the time of key people. Without that person decisions wait for meetings, departments defend their own way of working, and the supplier ends up choosing between them.

The owner does not have to know the system. The owner has to know the business, answer within days and be present when stages are accepted.

What state is the data in?

Master data that nobody has cleaned does not become clean after migration. Duplicate customers, items without units of measure and contracts without dates move into the new system and spoil its reports from the first day.

Look at the data before the estimate is made. Count the items, the counterparties and the open documents, and take a sample to see how many are usable. Cleaning takes the client's people, not the supplier's, and it should be in the plan with names and dates.

Which processes change?

Automating a process exactly as it runs today keeps its problems and adds the cost of software. For each process in scope decide in advance: does it stay as it is, does it follow the standard process of the product, or is it redesigned?

The second option is the cheapest more often than people expect. A standard product carries the practice of many companies, and a deviation from it should have a reason that can be put in numbers.

How is the result accepted?

An opinion at the end is a poor acceptance test. Scenarios and figures agreed at the start work better: the month is closed in the system, the cost of an order is calculated, the consolidated report matches the reports of the companies.

Write the scenarios when the specification is written. They become the test plan, the training material and the basis of the acceptance document.

What this changes

Answering these questions takes days, not months. It changes the estimate, the team and the schedule of everything that follows, and it shows early whether the organization is ready to start.