Business Central implementation resources: scope the right delivery team

Scope business outcomes before allocating people

An implementation scope that lists finance, sales, purchase and inventory is incomplete. Each module contains decisions about policies, transactions, controls, reporting and exception handling. Describe the operating outcomes: who creates a purchase request, what approvals apply, how goods are received, how invoices are matched and how balances are reviewed.

Use process boundaries rather than department names alone. Order-to-cash crosses sales, warehouse and finance; a production order can involve planning, stores, shop-floor reporting and costing. If these boundaries are ignored, separate consultants may complete their own setup while the end-to-end process remains untested.

Create a scope register with the process, business owner, expected result, standard configuration assumption, known gaps and acceptance scenario. It becomes the basis for resource planning. When requesting Business Central implementation specialists, share this register or a shorter version. It helps distinguish genuine capacity shortages from decisions that the business has not yet made.

Name the internal roles that cannot be outsourced

External specialists can advise and deliver, but the business must own its policies, priorities and acceptance. Name an executive sponsor who resolves cross-department conflicts and a process owner for each major workstream. Give those owners time to attend workshops, review data and test outcomes.

A data owner should decide which records are valid, resolve duplicates and approve mappings. A consultant can provide templates and checks, but cannot reliably infer commercial intent from years of inconsistent customer or item records. Likewise, finance must approve opening balances and reporting definitions rather than delegate sign-off to the person who loaded them.

Treat business availability as a project dependency. If a purchasing manager can attend only one hour each week, the design schedule must reflect that. Adding more external consultants will not eliminate a decision bottleneck. Make escalation rules explicit so unresolved questions do not silently become assumptions embedded in configuration or code.

Build a role map with deliverable ownership

A functional lead maintains process consistency and coordinates configuration decisions. Specialist consultants add depth where manufacturing, warehouse operations or finance requires it. Developers implement approved gaps. Data specialists manage mapping and loading mechanics, while testers structure evidence and help ensure coverage.

The same person may hold more than one responsibility on a small project, but the responsibilities should remain visible. A delivery lead should know who authors, reviews and accepts each output. This is particularly important when several suppliers or a customer’s internal IT team are involved.

Use the table as a starting point, then assign names. Titles alone do not prevent gaps. A solution architect may advise periodically rather than remain full time, while a data lead may need intensive involvement before every migration rehearsal. Plan capacity around these peaks instead of assigning everyone uniformly across the calendar.

Separate configuration from application gaps

Business Central includes operational functions that can be configured, while development supports requirements beyond the agreed standard approach. Microsoft’s developer documentation describes the AL application layer; the hiring decision should follow a fit assessment rather than a blanket assumption that every existing spreadsheet deserves an extension.

For each gap, record the requirement, standard option considered, reason it is insufficient, alternative approaches and maintenance implications. Some requests are better handled by changing a process or using an existing report. Others represent a genuine differentiating business need and justify development.

Use Business Central functional consultants to clarify process fit before sending ambiguous requests into a development queue. Where several modules or applications interact, obtain architectural review. Keep unresolved gaps visible in the plan because they affect resource demand, testing and training. A scope labelled “standard implementation” can still require significant effort if the underlying processes and data are poorly understood.

Make data preparation a staffed workstream

A common planning mistake is assigning data migration to whichever consultant has spare time near go-live. Instead, inventory the data categories early: customers, vendors, items, account structure, dimensions, outstanding transactions and other scope-specific records. Assign ownership and define how each set will be checked.

Build a mapping workbook that records the source, target meaning, transformation, mandatory information and validation rule. Test representative difficult records before attempting a full load. A clean sample should include awkward cases, such as missing classifications or inconsistent units, rather than only the easiest records.

If an existing Business Central or NAV estate is involved, Microsoft’s migration planning guidance emphasizes understanding versions, companies, database size and extension data. Those inputs also affect staffing. A Business Central migration specialist may be needed for the technical path, while business owners remain responsible for data meaning and reconciliation. Do not confuse successful import messages with accepted operational data.

Schedule testing around complete business journeys

Testing should show that a person can complete meaningful work with the proposed configuration, data and permissions. Build scenarios from the scope register: a normal sale, a return, a partial receipt, a disputed invoice, a production exception or another relevant journey. Include the reports and controls used to review the result.

Make the business owner’s expected outcome explicit before running the test. Record inputs, results, defects and decisions. When a defect is corrected, retest the affected flow and assess whether another process could be impacted. The purpose is confidence in operations, not a large spreadsheet of unexplained pass marks.

Reserve user time and consultant support together. A test cycle cannot succeed when users are available but the configuration owner is absent, or when specialists are present but test data is missing. In multinational projects, schedule cross-functional sessions around actual time zones and language needs, especially where the same process is interpreted differently by local teams.

Use engagement models at workstream level

Hourly Model is useful for periodic architecture review, a specific configuration question or specialist support to an established team. Define the questions and expected output so advice can be acted upon. It is less useful when nobody owns the overall workstream and hourly sessions become disconnected conversations.

Project Based can suit a clearly bounded implementation workstream with agreed deliverables, dependencies and acceptance. Describe what the client must supply, such as clean master data or available testers. Changes to scope should be assessed openly rather than hidden inside a growing list of tasks.

Dedicated Resource fits sustained functional, development or project coordination demand. It provides continuity, but does not automatically establish delivery accountability across all suppliers. A hybrid team may use dedicated functional capacity, project-based integration work and hourly specialist review. Choose the combination that matches the workload rather than forcing every role into the same commercial arrangement.

Define readiness before the final deployment meeting

Go-live readiness should be assessed against evidence gathered throughout delivery. Confirm process acceptance, data reconciliation, user access, operational instructions and support ownership. Record unresolved items with their business impact and an accountable decision-maker. An open issue is not automatically a blocker, but its consequence must be understood.

Run a realistic rehearsal with timing and ownership for each activity. Include communications, data freeze arrangements, validation and the decision points for proceeding. Ask who can authorize changes during the transition and how users will report issues after launch.

Plan early-life support before the project team disperses. Identify which consultants remain available, what the internal team can resolve and how technical issues are escalated. For partners delivering across the United Kingdom, North America or continental Europe, agree coverage that matches the customer’s operating hours. The final handover should leave an operable service, not merely a completed configuration workbook.

• Accountable process owners and scheduled decision time.
• Representative data and complete acceptance journeys.
• Transition ownership and agreed early-life support coverage.