Approval is premature until the business can govern the project
A Business Central project can look ready long before the organisation is ready to run it.
The software may fit. The budget may appear affordable. The preferred partner may have presented a credible plan. Yet approval is still risky when leaders cannot state what the project must improve, who owns the key decisions or where the project boundaries sit.
A Business Central project is ready to approve only when its business outcomes, internal owners, decision rights, delivery boundaries, organisational demands, partner evidence and success gates are explicit. Until those points are clear, approval commits money and management attention without giving leaders enough control over what happens next.
The real approval question is not simply, “Can Business Central support our requirements?”
It is: “Can we govern this project well enough to protect the expected value?”
Use the TRUST Readiness Test before committing
The TRUST Readiness Test gives leaders a practical way to assess that position:
- Target outcomes: What measurable business changes must the project deliver?
- Responsible owners: Who owns decisions, data, processes, testing and adoption?
- Underlying readiness: Can the business provide the time, skills and attention required?
- Supplier evidence: Has the proposed partner proved it can handle comparable complexity?
- Terms of commitment: Are scope, dependencies, phase gates and success measures understood?
The first two tests should be settled before detailed configuration begins.
Broad goals such as “better visibility” or “less manual work” are too weak to govern a Business Central implementation. Leaders need observable outcomes: a shorter month-end close, fewer manual purchase-document steps, improved stock accuracy, faster order-status reporting or a reduction in spreadsheet-based reconciliation.
These outcomes give the steering group a basis for prioritising scope and judging trade-offs. Without them, every requested report, integration or extension can be presented as important.
Ownership needs the same precision. An executive sponsor may support the project, but support alone does not resolve process disputes, approve scope changes or confirm that migrated data is fit for use. Each critical decision area needs a named owner with authority, available time and a clear escalation route.
| Weak project input | Likely business risk | Evidence required before approval |
| Vague business outcomes | Spend cannot be tied to value | Agreed measures and baselines |
| No named data owner | Migration delays and weak trust | Accountable owner and data plan |
| Unclear scope authority | Cost growth and delivery drift | Change-control decision rights |
| Part-time process ownership | Slow design and testing decisions | Confirmed capacity and backfill |
| Undefined success criteria | Go-live becomes the only measure | Operational and adoption targets |
This is where project confidence begins. Not with a polished demonstration, but with a business foundation strong enough to support difficult decisions once delivery starts.
Readiness is a commercial commitment, not an IT checklist
Business Central implementation readiness is not proved by a requirements document or a licence estimate. It is proved when the organisation understands the full cost of change and has the capacity to carry its share of the work.
That distinction matters because many ERP budgets account for software and partner fees while underestimating internal effort. Finance teams still need to validate processes. Operational leaders still need to resolve exceptions. IT still needs to support integrations, environments and access. Users still need time for testing and training.
A project can be technically viable and commercially weak if those demands are not funded, owned and scheduled.
What should a realistic Business Central budget include?
A sound budget should cover more than licences and configuration. Leaders should consider:
- implementation and advisory fees
- internal project time and backfill
- data cleansing and migration
- integrations and extensions
- user acceptance testing
- training and change support
- go-live cover and hypercare
- ongoing support and improvement
This does not mean every cost can be fixed at the outset. It means the main cost drivers, assumptions and exclusions should be visible before approval.
Expected value needs the same discipline. Benefits such as faster reporting, lower administration or better stock control should be linked to the processes in scope. A broad benefit claim is difficult to defend if the project plan does not show which workflows, teams or controls will change.
Internal capacity is often the hidden constraint
Business Central projects depend on client-side decisions. A partner can propose a future process, but the business must confirm whether it is workable. A consultant can prepare migration files, but an internal owner must decide which records are trusted. A test script can be written, but users must validate real transactions and exceptions.
Job titles are not evidence of capacity. Readiness requires named people, protected time and cover for business-as-usual responsibilities.
One practical example is the finance lead who is expected to own design workshops, cleanse supplier data, approve posting rules and run month-end at the same time. Without backfill or reprioritisation, decisions slow down and testing is compressed. The risk appears later, but the cause exists before the project starts.
Use a readiness scorecard before setting the start date
Rate each area as ready, conditional or unresolved:
| Readiness area | What leaders should verify |
| Outcomes | Measures and baselines are agreed |
| Ownership | Decision-makers have authority and time |
| Data | Quality issues and responsibilities are understood |
| Processes | Priority workflows and exceptions are documented |
| Scope | Go-live needs are separated from later improvements |
| Adoption | Training, communications and support are planned |
| Dependencies | Integrations, resources and external constraints are visible |
An unresolved rating is not automatically a reason to cancel. It is a reason to complete discovery, narrow scope or strengthen resourcing before committing to delivery.
The safer question is not whether the organisation wants Business Central. It is whether the business is prepared to do what a successful Business Central project requires.
Partner credentials matter only when they predict delivery behaviour
A strong Business Central implementation partner should be able to prove more than product knowledge. Leaders need evidence that the proposed team can manage comparable process complexity, data conditions, integrations, organisational constraints and delivery risk.
A long customer list may show experience. It does not show whether the partner has handled a project like yours, with similar pressure on finance, operations, data and internal resources.
How should you assess a Business Central implementation partner?
Start with comparable conditions, not logos.
A useful reference is one where the operating model, project scope and delivery risks resemble your own. That may mean multi-entity finance, complex stock movements, manufacturing processes, legacy NAV data, third-party integrations or limited internal project capacity.
The closer the comparison, the more useful the evidence.
| Area to test | Credible evidence | What a weak answer may conceal |
| Discovery | Clear method for defining processes, outcomes and exclusions | Scope built around assumptions |
| Delivery team | Named roles, relevant experience and expected availability | Senior people sell; junior people deliver |
| Data migration | Cleansing rules, ownership, trial loads and reconciliation | Data risk deferred until late in the project |
| Testing | Business-led scenarios, entry criteria and defect control | Testing treated as a final-stage formality |
| Training | Role-based preparation and internal super-user support | Generic handover with weak adoption planning |
| Change control | Written impact assessment for cost, time and testing | Scope additions accepted without full consequence |
| Support | Defined hypercare, escalation and ongoing support model | Responsibility becomes unclear after go-live |
Test how the partner behaves when the project becomes difficult
Most proposals describe the intended delivery process. Fewer explain what happens when assumptions fail.
Ask how the team would respond if:
- source data is late or incomplete
- a key process owner becomes unavailable
- an integration proves more complex than expected
- user acceptance testing exposes a material design issue
- a requested extension threatens the go-live date
- the business is not ready to approve cutover
The value lies in the reasoning behind the answer. A dependable partner should explain the options, business consequences, escalation route and decision needed. Reassurance without trade-offs is not evidence of control.
Business Central delivery works best when discovery, process design, data migration, configuration, testing, training, cutover and post-go-live support are treated as one connected programme. Buying these activities as separate technical tasks can leave gaps between what was scoped, what users expected and what the business is ready to operate.
GO ERP’s role in this stage is not to make every uncertainty disappear. It is to make the uncertainties visible early enough to govern. That means challenging weak assumptions, protecting the agreed scope and giving leaders clear evidence for each material decision.
The right partner should not simply make approval easier. It should make delivery more predictable.
A safe commitment is conditional, visible and measurable
Leaders should approve a Business Central project only when the plan, trade-offs, dependencies and success measures are understood well enough to govern.
That does not require every detail to be fixed. It does require the material uncertainties to be visible, assigned and controlled.
What should be in the commitment pack?
Before approval, the steering group should have a shared view of:
- agreed business outcomes and baselines
- go-live scope and deferred improvements
- named owners and decision rights
- delivery phases and approval gates
- data, integration and resource dependencies
- testing and user acceptance responsibilities
- training and adoption requirements
- go-live and rollback criteria
- hypercare and ongoing support
- operational and value measures
This pack turns Business Central project planning into a management discipline. It gives the CEO a clearer view of value and accountability, while giving the CIO firmer control over scope, risk and delivery expectations.
Approval is not always a simple yes or no
A sound readiness review should lead to one of three decisions:
- Approve. The project has clear outcomes, adequate ownership, controlled scope and credible delivery evidence.
- Approve with conditions. The direction is sound, but named actions must be completed before a specific phase or spend commitment begins.
- Pause for validation. Material questions around data, scope, internal capacity, process design or partner fit remain unresolved.
A pause is not failure. It is often cheaper than discovering the same weakness during migration, testing or cutover.
Business Central implementation FAQs
When is a Business Central project ready to start?
When outcomes, scope, owners, internal capacity, delivery evidence and approval gates are clear enough to control cost, risk and decision-making.
Who should own the project internally?
An executive sponsor should provide authority, supported by named process, data, testing and adoption owners with enough time to make decisions.
What evidence should a Business Central partner provide?
Comparable references, a named delivery team, a clear discovery method, a data and testing approach, change-control rules and a defined support model.
When is a readiness assessment worthwhile?
When the business case is broad, the scope is still moving, internal effort is uncertain or partner proposals are difficult to compare.
The final decision should not rest on whether the platform can be configured. Microsoft Dynamics 365 Business Central is capable of supporting a wide range of finance and operational needs. The harder question is whether the business and its delivery partner are prepared to convert that capability into controlled, usable change.
Where one or more TRUST criteria remain unresolved, a Business Central readiness and scoping review can test the business outcomes, project boundaries, internal workload, delivery assumptions and approval conditions before major spend begins.
That is the point of readiness: not to remove every risk, but to make the remaining risks clear enough to manage.
