Building a Project Brief That Works:

Most ERP projects don’t fail because the software is wrong.
They fail because the organisation never clearly agreed what success actually looks like in the first place.

Ask five stakeholders what they want from a new ERP system and you’ll often hear:

“Better reporting”
“More control”
“Automation”
“Something modern”
“What our competitors have”

None of these are wrong — but none of them are specific enough to deliver against.

That’s where a proper Project Brief comes in.

The Project Brief: Your Single Source of Truth

A Project Brief is not a formality and it’s not shelfware.
Done properly, it becomes the anchor document for the entire ERP programme.

It answers three critical questions:

Why are we doing this?
What does success look like?
How will we manage our progress?

Without clear answers, scope will drift, decisions will slow, and disagreements will multiply.

What a Good ERP Project Brief Must Contain

1. The Business Problem (Not the Technical One)

The brief must clearly articulate the business problem you are solving, not just the system you are replacing.

For example:

Are manual processes limiting growth?
Is poor data visibility affecting decision-making?
Are legacy systems creating operational risk?

If the problem statement is vague, the solution will be too.

2. Clear, Measurable Success Criteria

“Better” is not a metric.

Success criteria should be measurable and business-focused, such as:

Month-end close reduced from 6 days to 2
Inventory accuracy improved to 98%
Order to shipment cycle reduced by 20%

These measures become the yardstick against which the project is judged — not opinions or anecdotes.

3. Defined Scope (and Explicit Exclusions)

Scope is where most ERP projects quietly unravel.

Your brief must clearly define:

What processes are in scope
Which sites, divisions, or regions are included
What is explicitly out of scope

If exclusions are not written down, they will be challenged later — usually when time and budget are under pressure.

4. Roles, Ownership, and Accountability

A strong Project Brief identifies:

The Project Sponsor (from the business)
The Project Manager
Decision-making authority
Escalation paths

Ambiguity here leads to delays, rework, and political deadlock.

Someone must be accountable for decisions — and that must be clear from day one.

5. Risks, Assumptions, and Constraints

Every ERP project carries risk. Pretending otherwise doesn’t remove it — it just hides it.

The brief should openly acknowledge:

Known risks
Key assumptions
Timeline and any resource constraints

This sets a realistic tone and prevents surprises later.

When Should the Project Brief Be Written?

Ideally, before you speak to vendors.

Too many organisations let vendor demos define their ambition.
A good Project Brief ensures you control the narrative, not their sales process.

If you are already part-way through an ERP project, it is not too late.
Stopping to build or refresh a Project Brief now can prevent far more expensive mistakes later.

The Real Benefit of a Strong Project Brief

A good Project Brief:

Aligns stakeholders
Speeds up decision-making
Controls scope creep
Provides a reference point when pressure builds

Most importantly, it shifts the conversation from “What did we think we agreed?”
to “What does the brief say?”

That alone can save months.

Want Help Getting This Right?

I help organisations create clear, practical ERP Project Briefs that stand up to real-world pressure — not theoretical frameworks.

If you are about to start an ERP project, or you’re already in one and things feel unclear, a short conversation now can make a significant difference.

Get in touch to discuss your ERP project readiness.