Is Your Business Ready for an ERP Project? Check authority, staffing, processes, data and competing work.
An ERP readiness review should end with a precise authorization: which work may begin, under what conditions, and what evidence is still required before the next commitment. A reassuring overall score cannot answer those questions.
Readiness is specific to the decision in front of the organization. A business can be ready to investigate options while remaining unready to sign a major delivery commitment. It can be ready to design a process while remaining unready to convert production data. Asking whether the organization is simply “ready for ERP” hides these distinctions.
CuriousRubik proposes treating readiness as a set of evidence-backed entry conditions. The practical test is whether the organization can fulfill the obligations created by its next decision. This article develops that test for the point before a substantial implementation commitment, when unresolved questions can still change scope, staffing, and timing.
Name the commitment before assessing readiness
Write a short gate statement describing what a positive decision will authorize. For example: “Approve detailed design and its associated staffing commitment for the first operating release.” Include the expected outputs, expenditure authority, participating functions, and decisions that remain outside the gate.
Then ask what must already be true for that work to be worthwhile. Detailed design may require agreed process ownership, representative scenarios, access to relevant data, and protected participation from the people who can approve operating changes. It does not require finished training materials for every end user.
This distinction protects against two opposite mistakes. One is starting work with missing foundations. The other is demanding evidence that cannot reasonably exist until the authorized work has been completed. A readiness gate should expose dependencies without turning uncertainty into a reason for indefinite delay.
The sponsor owns the commitment decision. A program lead assembles the evidence, while each functional owner remains accountable for the conditions within their control. Someone other than the person closing a gap should check material evidence where practical. An owner declaring “complete” is a status update; verified proof supports a decision.
Examine five conditions independently
Use a matrix with five rows: authority, capacity, process, data, and change load. For every row, record the required condition, current evidence, evidence date, accountable owner, unresolved gap, and effect on the proposed commitment. These dimensions are a proposed working structure, not a universal maturity standard.
Authority
Can the organization make and sustain the decisions the next phase will demand? Evidence includes named process owners, delegated limits, a route for cross-functional disagreements, and acceptance of those responsibilities by the people involved.
Test the arrangement with a realistic disagreement. If two departments want different rules for releasing an order, who makes the decision and which consequences require sponsor approval? A steering committee listed in a charter is insufficient if nobody can explain how it resolves this case.
Capacity
Can named people perform the project work while maintaining essential operations? Ask for a role-by-week view that includes reviews, preparation, decisions, and known operational peaks. The evidence should show what work has been removed, reassigned, or deferred to create availability.
An allocation expressed as “twenty percent of the team” may conceal that the only qualified approver is unavailable during the critical period. Assess the required skills and authority, not just aggregate hours. A manager's commitment should identify the operational coverage that makes the allocation credible.
Process
Does the team understand enough of the operating problem to make design decisions? Evidence may include agreed process boundaries, representative business events, material exceptions, and unresolved policy questions. Existing process diagrams help only if people doing the work recognize them.
Perfection is unnecessary at this gate. The requirement is to distinguish what the project must discover from what the business must decide beforehand. If departments disagree about who may approve a customer concession, configuration workshops cannot substitute for an authorized policy decision.
Data
Can the project access, interpret, and take responsibility for the information needed for the next phase? Seek named data owners, a verified route to representative extracts, initial profiling results where needed, and a process for resolving conflicting definitions.
“Data cleanup is planned” leaves the essential questions unanswered. Who decides which record is authoritative? Can the team see the population it will need to migrate? Are restrictions on access understood? The required depth should match the commitment: a design gate may need representative evidence, while a conversion gate needs much stronger proof of completeness and reconciliation.
Change load
Can affected teams absorb the proposed change alongside other initiatives and operating obligations? Gather a calendar of competing changes, role impacts, peak business periods, and the managers responsible for preparing their teams.
Listen to objections as information. Concern about a new workflow may reveal a missing control, a customer obligation, or an unstaffed task. Labeling it “resistance” before investigating can remove the very evidence the gate needs. The condition to prove is a credible plan for the affected work and people, not universal enthusiasm.
Make critical conditions impossible to average away
Assign a state to each condition: proven, conditional, or unproven. Define these states in operational terms for the particular gate.
“Proven” means the specified evidence exists and an appropriate reviewer accepts it. “Conditional” means a gap remains, but a bounded portion of work can proceed without relying on the missing condition. “Unproven” means the necessary evidence is missing, contradictory, or insufficient for the requested commitment.
A critical blocker is a missing condition whose absence makes the proposed next step unsafe, unworkable, or likely to produce unusable work. A lack of decision authority may block cross-functional design. Inability to access representative data may block conversion planning. The same gap may not block unrelated process discovery.
Do not turn the states into an average that can obscure such a blocker. Four strong dimensions cannot compensate for the absence of the person authorized to accept the fifth. If leaders still choose to proceed, the record should describe the exception, consequences, and explicit authority for accepting them. Applicable legal or control obligations cannot be waived by a project score.
What conditional approval actually permits
Conditional approval is useful only when its boundary can be enforced. Document the permitted work, prohibited dependent work, the gap owner, evidence needed for release, deadline, and consequence of a missed condition.
For instance, a team might proceed with common purchasing-process workshops while holding location-specific design until the site appoints an authorized owner. The program lead must ensure that the held work does not enter the schedule through informal decisions or partner assumptions.
A vague promise to “resolve before it becomes a problem” is not a condition. Neither is a deadline with no effect on the work. If the condition expires, the dependent activity should pause automatically for review. The sponsor can then authorize a revised scope, date, or remediation plan using the new evidence.
Conditional approval also creates coordination overhead. Too many exceptions can make a project harder to manage than a brief, focused pause. Use it when the allowed work is genuinely separable and the dependency can be tracked reliably.
A hypothetical gate with a mixed decision
Imagine a manufacturer preparing detailed design for two sites. This is an illustrative scenario, not a client account. The sponsor wants both sites included so that the team can establish common processes before configuration.
The authority review finds an accepted enterprise process owner and a clear escalation route. Process evidence includes representative production and purchasing scenarios from both sites. Those conditions support proceeding.
The capacity review finds that the second site's sole inventory specialist is scheduled for a physical count during the design workshops. The site manager has approved project participation but has not assigned count coverage. The data review also finds that the two sites use different definitions of available stock, with no agreed interpretation for certain held items.
A single readiness score could bury both issues. The evidence-based gate instead distinguishes their effects. Common process workshops may begin. Inventory availability design for the second site remains on hold because both a qualified participant and an agreed definition are missing.
The site manager owns the staffing gap. Closure requires a named replacement for the operational duties, confirmed by that person's manager, and a revised calendar accepted by the inventory specialist. The enterprise inventory owner owns the definition gap. Closure requires a documented decision tested against representative held-stock scenarios from both sites.
The program lead records which workshops can proceed and which design decisions cannot be finalized. An independent functional reviewer verifies the two closure records before releasing the held work. If the conditions remain open at the agreed checkpoint, the sponsor must change timing or scope rather than letting the design proceed by assumption.
This decision preserves useful momentum while making its limits visible. If the common workshops turn out to depend on the unresolved inventory rules, the separation no longer holds. That new dependency sends the decision back to the gate.
Keep the gap register small enough to govern
A readiness register should contain decision-relevant gaps, not every task in the project plan. For each gap, capture the missing condition, blocked commitment, closure action, owner, due date, evidence required, verifier, and escalation consequence.
Choose evidence that demonstrates the condition. For a capacity gap, a revised allocation is stronger when it also identifies the work being removed. For a data gap, a completed meeting is weaker than an agreed definition applied successfully to the relevant records. For an authority gap, a signed role description matters less if the first real disagreement still has no decision-maker.
Keep closed gaps with their evidence dates. Readiness can expire: staff leave, scope expands, extracts change, or another initiative consumes the promised capacity. Specify which events trigger a reassessment so that an old approval does not become permanent permission for a materially different commitment.
Run the gate as a decision meeting
Distribute the evidence before the meeting and focus the discussion on disputed conditions, material gaps, and the proposed authorization. End with one of three recorded outcomes: proceed within the stated boundary, proceed with enforceable conditions, or hold the commitment pending specified evidence.
A hold should include useful next work, responsible owners, and a retest condition. It should not become an indefinite status that leaves people preparing for a start date nobody believes. Equally, proceeding should create a clear handover from readiness remediation to phase delivery.
For the next review, take the largest upcoming commitment and ask each functional owner for one piece of evidence that proves they can fulfill their part. Where the answer is a promise, turn it into a bounded closure action. That simple exercise makes the readiness conversation more honest and gives leadership a decision it can actually enforce.