Who Makes the Decisions in an ERP Project? Assign a decision-maker, a deadline and a way to resolve delays.
An ERP decision can be overdue before it appears late on the program plan. The configuration team is waiting for a policy choice. Testers are preparing two versions of the same scenario. A regional lead assumes the current practice will continue. Everyone remains busy, but their work depends on an answer nobody has authority to give.
Treat that answer as a deliverable. It needs a defined question, an accountable decider, a date derived from downstream work, and a route for resolving disagreement. The practical objective is to prevent uncertainty from quietly becoming design.
This article proposes a decision-rights register for that purpose. It is a working approach to adapt to your organization's authority and control requirements, rather than a universal governance model. Start with the decisions that can block or invalidate work. You do not need to register every routine conversation.
Find the decision inside the discussion
“Agree the customer model” is too broad to route or finish. “Decide whether a shared customer account may place orders for more than one legal entity” is specific enough to identify affected processes, needed evidence, and an authority boundary.
A useful decision question presents a choice somebody can actually make. It also states what has already been settled. Otherwise contributors may reopen the business case, operating model, and implementation scope while the team needs a narrower answer.
Collect pending choices from design workshops, unresolved test assumptions, open policy questions, and repeated requests for clarification. Look especially for deliverables labeled “draft pending confirmation.” The assumption behind that label is often the decision that needs an owner.
For each candidate, ask three questions:
- What action becomes possible when the answer exists?
- Whose work or obligations could change because of the answer?
- What happens if nobody decides before that work starts?
If the answer affects only one team's reversible working method, the team lead may have sufficient authority. If it changes another function's controls, a customer's promise, or an approved program boundary, the route needs to include the relevant accountable authority.
Assign authority at the lowest responsible level
Assign one accountable decider wherever the organization's rules permit it. This person owns the answer and its rationale. They do not acquire unlimited discretion, nor do they replace specialist approval obligations.
Distinguish three roles. Contributors supply evidence and explain consequences. Required approvers protect defined obligations, such as an accounting policy or an access-control requirement. The decider resolves the choice within those boundaries. Where formal joint approval is required, name the approval sequence and the person responsible for obtaining a complete decision.
This distinction prevents two common governance problems. Broad consultation can turn into an implied veto for every attendee. Conversely, a named “owner” can be held accountable for a choice they cannot legitimately authorize. Both leave the team waiting.
Write delegated limits in plain language. A process owner might select a workflow within the approved control model and existing staffing capacity. A change that removes a required review, adds recurring operating cost, or moves work between functions may exceed that delegation. The exact limits belong to your organization; the register makes them visible.
Work backward from the first dependent activity
A due date chosen because the next committee meets on Thursday may already be too late. Begin with the earliest activity that needs a stable answer. Then allow time to communicate the choice, update the design, and resolve any resulting inconsistencies.
In a hypothetical program, an order-approval rule affects test data, training examples, and user access. Integrated testing starts in three weeks. The decision is needed sooner because the teams must prepare those inputs and verify that they agree. The decision deadline should reflect that preparation, not merely precede the test milestone.
Record a “latest useful decision date” and the assumptions behind it. If dependent work moves, revisit the date. If the choice cannot be made in time, ask the decider to authorize a specific interim approach or stop the affected work. An undocumented assumption should not become the default simply because the calendar advanced.
Be explicit about the cost of delay without inventing precision. “Two training modules would need revision” is useful when verified. “This will cost a large amount” is weak evidence. Where estimates are uncertain, give the range, the person who estimated it, and what would make it change.
Build the decision-rights register
Use a shared register that can be read without attending the meeting where an issue first appeared. Keep supporting analysis elsewhere and link it from the record.
Each material decision should contain:
- Decision ID and the exact question to resolve.
- Business outcome and boundaries already agreed.
- Accountable decider, contributors, and required approvals.
- Delegated limits and the next escalation authority.
- Options, recommendation, and material uncertainties.
- Latest useful decision date and the work it protects.
- Evidence owner and date when the evidence will be ready.
- Escalation trigger, response expectation, and interim authority.
- Final choice, rationale, conditions, and communication recipients.
- Reversal conditions and links to affected deliverables.
Avoid using a single “owner” column for the decider, the analyst preparing the options, and the person implementing the answer. These are different responsibilities. A coordinator can maintain the register while the business retains decision authority.
The register should also distinguish “awaiting evidence” from “awaiting decision.” The first requires research or clarification. The second requires an authorized person to choose among sufficiently understood options. Calling both “in progress” hides what needs to happen next.
Make escalation a clocked action
An escalation route is incomplete if it merely names the sponsor. Specify the condition that starts it and the time available for a response. The trigger might be an unresolved cross-functional conflict, missing mandatory approval, an approaching dependency date, or a consequence beyond the decider's delegated authority.
Use timing appropriate to the decision. A recoverable reporting-layout choice can follow a normal review cycle. A choice that could invalidate the next rehearsal may need a faster route. Urgency should come from consequences, not from how forcefully somebody asks.
The escalation packet should state the question, options, disputed point, consequence of delay, and recommendation. Passing a long conversation upward simply transfers the ambiguity. The higher authority should receive the smallest complete set of information needed to act.
Do not let escalation suspend responsibility. The original decider remains responsible for making the choice usable unless authority is explicitly reassigned. The coordinator checks that the escalation was received, tracks its response date, and flags any missed commitment. If no answer arrives, the team follows the previously authorized hold or interim arrangement.
Record what would justify changing the answer
A decision made with incomplete information can still be responsible. The record should identify the uncertainty, its possible impact, and the evidence that would trigger reconsideration.
For the hypothetical order-approval rule, the team might approve a common workflow subject to an operational capacity test. If that test shows that the designated reviewers cannot handle the expected workload, the decision returns to the process owner before training is finalized. The condition is observable, and the review point is attached to actual work.
Separate a legitimate revisit from a preference change. A new control requirement, failed assumption, or verified operational constraint may justify reopening. A stakeholder encountering the answer late does not automatically invalidate it. They should bring the evidence or consequence that warrants review.
Version the record when the answer changes. Preserve the previous rationale and identify which designs, scripts, roles, and communications must be updated. Otherwise two valid-looking answers can circulate at once.
Review waiting time before reporting progress
At a regular program review, inspect decisions that are approaching their latest useful date, waiting on unavailable evidence, or repeatedly returning for reconsideration. Look across workstreams. Several modest decisions may depend on the same person or unresolved policy.
Measure selectively. Decision age, missed dependency dates, and the amount of work proceeding on assumptions can reveal governance friction. Avoid rewarding a high number of closed decisions: a quickly recorded answer that lacks approval or cannot be implemented is not meaningful progress.
Check a sample of completed decisions too. Can the delivery team find the answer? Were affected people informed? Did the choice reach requirements, configuration, tests, and training? Closure in the register should follow usable communication, not simply a meeting vote.
For your next review, choose five live decisions and write their exact questions, deciders, latest useful dates, and escalation triggers. Resolve any authority gaps before adding more fields or reports. A compact register with real authority will do more useful work than a comprehensive register that merely documents waiting.
