A Priority ERP Implementation: What Actually Happens and Where It Stalls

A Priority implementation is not an installation. It is a series of decisions about how your business works, written into a system. The project moves at the speed you make decisions and run tests - not at the speed the partner works. That single fact explains why similar projects take wildly different amounts of time.

Who does what

Priority is sold and implemented largely through implementation partners. That shapes the project: the vendor supplies the product, the partner performs configuration and customisation, and you supply the decisions and the people.

The third row is the least measured and causes the most delay.

The stages as they actually run

1. Analysis. Map the current processes and decide what changes. Everything is set here.
2. Configuration. Build the company structure, items, permissions and documents.
3. Data preparation. Clean, map, export from the previous system.
4. Customisations and interfaces. Screens, reports and connections that are needed and not off the shelf.
5. Acceptance testing. You run a real end-to-end process - not the partner.
6. Training. By role, not one session for everyone.
7. Go-live. Opening balances, freeze the old system, close support.
8. Stabilisation. A month of fixing what only real usage reveals.

Stage 5 is the one skipped when the date is under pressure, and it always resurfaces in stage 8 at a much higher price.

Where do projects stall?

• Data. An item list with duplicates and free-text descriptions is a month of work nobody scheduled.
• An unagreed process. Two managers describe the same process differently and configuration halts until someone decides.
• Testing. "We don't have time to test" is the sentence that produces the hard month after go-live.
• Scope creep. Every small request looks reasonable; twenty of them are a second project.
• One person who knows everything and takes leave at exactly the wrong moment.

What it demands from your team

The question usually gets asked too late. In practice you need:

• A project owner on your side with authority to decide between departments.
• A subject expert per area - finance, inventory, sales - available for questions.
• Someone to clean data, and it is usually not who you assumed.
• Testers who run real scenarios and record what failed.
• Time in the calendar, not "when we get a chance".

How do you know you can go live?

Not by the date. By five conditions you can tick:

1. A full sales process runs end to end on real data, including the document and the collection.
2. Opening balances are reconciled and agreed with bookkeeping.
3. Every live interface has been tested in both directions, including a failure case.
4. Every role has a screen they can work in without asking.
5. There is a written procedure for what to do when something breaks on day one, and someone available.

Missing one of them, postponing a week beats running a month of corrections in front of real customers.

The first month after

What genuinely happens: work slows down, because people are hunting for where things live. That is normal and it passes. What is not normal and needs immediate attention: documents created manually outside the system, a new side spreadsheet appearing, or a process people are routing around. All three mean the configuration missed something real, and they are worth fixing in the first fortnight rather than next quarter - otherwise they become the way the company works.

What to prepare before the project starts

Most of this preparation costs nothing and shortens the project more than anything else. Two weeks before the first meeting, these should be on the table:

• A list of your processes, in your names rather than the system's names.
• A list of the systems that stay alive, with a named contact for each.
• An export of customers and items exactly as they are today, dirty or not.
• The five reports management genuinely opens.
• A list of the exceptions - the customer on different terms, the item priced differently, the order that takes a special route.

That last list is the surprise: exceptions decide whether a configured process gets used or routed around. A partner who receives them at the start designs around them; a partner who discovers them the week before go-live produces urgent, expensive customisations.

What a well-run project looks like

There are three signs you can see from outside, without understanding the system. A decisions log exists and is current - every process decision recorded with a date and who made it. An open-gaps list that shrinks week over week rather than growing. And testing performed by people from the business, not only the implementer, recording what failed.

When one of those three is missing, a project can look like it is progressing while it is stuck: everything is "in progress", nothing is marked done, and the date slips a week every week. That is a reliable signal to stop for an hour and close all three before continuing - the highest return on an hour available anywhere in a project like this.

How to choose the partner

In practice you will work with the implementation partner far more than with the software vendor, which makes that choice weightier than it is usually treated. Three questions separate them: have they implemented in your sector - not to know the product but to know the exceptions; who actually attends meetings - the person who sold or the person who will deliver; and how they answer an out-of-scope request - a good answer prices it separately and says what it defers, rather than "we'll sort that out later".

It is also worth asking for two existing customers and speaking to them, with one focused question: what surprised you after go-live. That answer is worth more than any reference list.

Sources

• Priority Software - implementation and partners
• Integrating Priority through its API