The decision is made. The contract is signed. The ERP project has officially kicked off. For the first 100 days, every status report shows green across the board — until, several months later, the project manager announces a three-month slip and a 40% budget overrun.
That overrun did not come out of nowhere. It was built, silently, between day 1 and day 60, while steering committee reports reassured everyone.
This guide gives you six measurable indicators you can track from day one, with alert thresholds and the responses they should trigger. These KPIs apply to the scoping and design phase — the 100 days before intensive configuration begins — not the post-go-live hypercare phase, which follows a different logic.
Why the First 100 Days Are Critical in an ERP Project
The Window Where Bad Trajectories Take Shape
An ERP project does not derail at go-live. It derails during the scoping phase, and the consequences accumulate quietly until they become impossible to hide. Experienced programme management firms consistently observe the same pattern: the vast majority of budget overruns and schedule slippages are detectable, with the right indicators, by day forty-five.
The reasons are structural. During the start-up phase, scope decisions are still reversible — or at least correctable at a reasonable cost. A poorly scoped process at D+30 can be corrected. The same problem discovered at D+180, deep in configuration, means rework, emergency meetings, and contractual renegotiation with the implementation partner.
The Difference Between a “Green” Project and a “Green Going Red” Project
The RAG reporting trap is well known. A project can show green on every standard management indicator — deliverable progress, workshop attendance, response times — while accumulating fragilities that only reveal themselves in phase 2.
The reason: standard indicators measure activity, not trajectory. A workshop “held” is not a workshop “concluded.” A milestone “validated” does not mean the underlying design decisions were actually made. The six KPIs described here are trajectory indicators, not activity indicators. They measure whether the project is going where it needs to go, not just whether it is moving.
KPI 1 — Validated Scope Coverage Rate
How to Measure
During scoping, the implementation partner and client agree on a number of processes to be covered. Count the number of processes for which scoping workshops resulted in a signed design sheet, divided by the total number of processes specified in the contract.
Formula: scoped and signed processes / processes specified in contract (as %)
Alert Threshold: Below 80% at D+45
A rate below 80% at the midpoint of the scoping phase signals that the validation pace is insufficient to meet the design schedule. In practice, this indicates either insufficient availability of business process owners, unresolved scope decisions, or workshops held but not concluded — all three situations can coexist.
What it reveals: processes not scoped by D+45 are processes that will consume design budget at a time when that budget was earmarked for configuration.
KPI 2 — Key Decision-Maker Availability Rate
Cancelled or Postponed Workshops: An Underestimated Signal
The workshop schedule is the backbone of the scoping phase. When a workshop is cancelled, it generates three effects: loss of a billed consultant slot, deferral of design decisions, and progressive demobilisation of the project team.
How to measure: keep a simple log of workshops planned / held / postponed / cancelled. The rate is calculated as workshops held over workshops scheduled for the period.
Alert Threshold: More Than 2 Consecutive Cancellations on the Same Workshop
The same workshop rescheduled twice in a row is not a diary problem. It signals that the subject has no sponsor available to make a decision. Letting this pattern take hold creates a queue of unmade decisions that will cascade into the configuration phase as emergencies.
What it reveals: project governance is insufficient, or the executive sponsor is not adequately protecting business process owner availability against operational pressures.
KPI 3 — Client-Provided Configuration Data Completeness Rate
Chart of Accounts, Master Data, Cost Centres
Configuring an ERP requires source data provided by the client: chart of accounts, third-party master data (customers, suppliers), cost centres and cost accounting structures, units of measure, bills of materials, payment terms. This data rarely arrives as a clean, structured package.
How to measure: the implementation partner maintains a data request log. The rate is calculated as the number of files or datasets delivered within the agreed deadline versus the number requested.
Alert Threshold: Below 70% at D+30
A rate below 70% at D+30 foreshadows a delay in the configuration phase. Configuration cannot begin on incomplete master data: either it starts on dummy data (with a data migration risk) or it waits for the data (with a schedule slip).
What it reveals: the IT department and finance function have not allocated the resources needed for data preparation, or the organisation’s data governance is in worse shape than expected.
KPI 4 — Change Resistance Index (Proxy: Business Workshop Participation Rate)
Weak Signal Number One
Change resistance does not announce itself. It shows up in behaviours: absences from workshops, delegation to stand-ins without decision-making authority, questions about “what we’ll lose” rather than “what we’ll gain,” silence during mockup sign-offs.
How to measure: compare the list of expected participants (decision-makers) against actual attendees at each workshop. If the expected business process owner systematically sends a representative without decision-making authority, the workshop counts no better than a cancelled one for that process.
Alert Threshold: Below 60% Decision-Maker Participation on Key Business Workshops
A rate below 60% on key business workshops is a red flag for change management. This is not a scheduling problem — it is a meaning problem. The people who should be driving the project do not yet see its value for them.
What it reveals: the change management work has not adequately accompanied the upstream project phase. The communication on expected benefits reached management without reaching the operational process owners.
KPI 5 — Design Decision Velocity (Design Decisions Backlog)
The Backlog of Unmade Decisions
Each workshop produces design decisions — or open questions. Measuring the ratio between open questions and closed decisions, per two-week sprint, gives a reliable picture of the organisation’s capacity to move forward.
How to measure: the implementation partner maintains a design log with open / in progress / decided status. Velocity is calculated as the number of items closed per fortnight.
Alert Threshold: Backlog Above 15 Open Items at D+60
A growing backlog is an indicator of insufficient governance. Open items accumulate either because they are technically complex (acceptable), because no one has authority to decide them (governance problem), or because the organisation is deliberately avoiding resolution (disguised resistance).
What it reveals: when the backlog exceeds 15 open items at D+60, field experience suggests that half of those items will not be resolved in the design phase — they will be handled as emergencies during configuration, at the highest cost point in the project cycle.
KPI 6 — Early Budget Tension (Spend Rate vs Forecast)
Budget Consumption at D+30 vs Initial Forecast
This KPI is the most direct, and yet the least monitored in the early weeks. The reason: the start-up phase is expected to “ramp up,” and initial under-consumption is often read as a positive sign. It rarely is.
How to measure: compare billed consultant days consumed at D+30 against the planned load curve in the project plan. An overrun of more than 15% at D+30 — before configuration has even begun — signals insufficient initial scoping.
Early Overrun = Insufficient Scoping
When consultants consume start-up budget to re-scope processes that should have been clear from signing, it means the initial scoping document (statement of work, contract, functional specification) lacked precision. This re-scoping cost is rarely budgeted, and it draws down the project’s contingency reserve.
What it reveals: the maturity of the upstream scoping. A project whose D+30 budget is already in overrun is one where the pre-contractual phase underestimated complexity or scope.
How to Build the 100-Day Dashboard
A Deliberately Simple Format
The 100-day dashboard must not be a 20-page report. It must fit on one page, be readable in five minutes, and trigger decisions — not discussions about calculation methodology.
Recommended format:
| KPI | Week N value | Alert threshold | Trend | Status |
|---|---|---|---|---|
| Scope coverage | 82% | < 80% at D+45 | Stable | Green |
| Decision-maker availability | 71% | < 2 consec. cancellations | Degrading | Amber |
| Data completeness | 64% | < 70% at D+30 | Insufficient | Red |
| Workshop participation | 67% | < 60% | Stable | Green |
| Decision velocity | 8 closed / fortnight | Backlog < 15 | Stable | Green |
| Spend rate vs forecast | +8% | < +15% | Stable | Green |
Frequency: weekly. Not twice weekly, not monthly — signals move fast at project start.
Recipients: executive sponsor, CIO, client project manager, implementation partner project manager. Not the business units on a wide distribution — that turns the dashboard into a communication tool rather than a decision tool.
The Double-Red Rule
Any KPI in red for two consecutive weeks triggers a mandatory crisis meeting within five business days. “Crisis” does not mean confrontation: it means a dedicated meeting, with the sponsor and the relevant parties, to analyse the root cause and decide on a concrete corrective action within the following ten days.
Week-One Mini Checklist
Before the end of the first project week, the following must be formalised:
- In-scope process list validated and signed by both parties
- Steering committee scheduled at a fixed cadence for the next 12 weeks
- Business process owners identified by name for each process (not “the procurement department” — a first name, last name, and title)
- Design decision log open and shared between client and implementation partner
- Configuration data delivery deadline confirmed
If any of these five items is not formalised by D+7, the project has not truly started yet.
The 3 Common Reactions (and the Wrong Ones) to a Red KPI
Reaction 1: “We’ll Catch Up in the Next Sprint”
This is the most common reaction, and the most dangerous. A red KPI is not a one-off delay — it is a systemic signal. “Catching up” means either accelerating (by compressing quality), reducing scope (without explicitly acknowledging it), or deferring the problem to the next phase.
Experience shows that quality debt created in the design phase is repaid with interest during configuration and user acceptance testing.
Reaction 2: Rebaselining Without Causal Analysis
Revising milestones without understanding why they slipped is a guarantee they will slip again. A sound rebaseline answers the question “what has changed in the initial assumptions?” — not “how do we make the schedule look presentable?”
The Right Reaction: Structured Escalation Within Five Days
Faced with a persistent red KPI, a structured response involves three steps:
- Identify the root cause (not the symptoms) within 48 hours: unavailability of a specific resource? A poorly defined scope decision? Missing data for an identifiable reason?
- Formulate a remediation plan with a named owner: not “the team will handle it,” but “First Name LAST NAME is responsible for action X by [date].”
- Verify the plan’s effect after 10 days: if the KPI is still red after remediation, the plan has not worked — change the plan, do not simply wait.
Escalation is not an admission of failure. On an ERP project, a signal addressed at D+45 costs ten times less than the same signal addressed at D+120.
These six indicators will not replace a skilled project manager and an engaged executive sponsor. They give those two actors the factual basis to justify their decisions — and to resist pressure from those who prefer a comfortable green over an actionable amber.
To go further, read our article on ERP change management: the 8-step adoption plan and our guide to ERP project team roles and the RACI matrix. For the KPIs that take over after go-live, see our article on detecting silent rejection post go-live and our guide to ERP post-deployment governance.
