A green status report tells you what the program manager believed last Friday. It does not tell you what the defect log, the data load reconciliation or the attendance sheet shows. Seven measurable signs appear about two reporting quarters before the color changes: open defects rising while the RAG stays green, mock data loads slipping, signed-off designs being reopened, SI staff turning over above 20% in six months, steering committee meetings getting shorter, scope sliding into a "phase 2" with no budget line, and business process owners missing sessions. Each has a threshold you can check in one afternoon. If three or more trip, commission an independent review now, because a rescue later costs 30 to 50% of the original budget.
The status report is a lagging indicator
A RAG status is an opinion about a plan. The program manager, often an SI employee, judges whether the next milestone is still reachable. That judgment then passes through two or three layers that each have a reason to round up. By the time the color changes, the numbers underneath have usually been moving the wrong way for a quarter or two.
ERP Today made the same point in July 2026 when it treated the growth of SAP project rescue firms as a market signal. Programs "rarely fail all at once," the article said. They drift through weak governance, staffing gaps and data problems until they are too expensive to quietly reset. The same shape applies on Oracle Fusion Cloud ERP, Microsoft Dynamics 365 Finance and Supply Chain, Workday Financials, IFS Cloud, Infor CloudSuite or Epicor Kinetic. The governance is the variable, not the vendor.
The seven signs below are where the program's weekly records diverge from the report. The thresholds are the rules we recommend, with the reasoning in each section. They are judgment calls, not study findings, so scale them to your program.
| Sign | What the status report says | Threshold (recommended rule) | What to ask for |
|---|---|---|---|
| 1. Defects rise while the RAG stays green | "SIT cycle 2 at 68% execution, on track" | Open sev 1 and 2 defects rising for 3 consecutive weeks, or closed-to-opened ratio below 1.0 for 2 weeks | Weekly open sev 1 and 2 count for 8 weeks; first-time pass rate; defects downgraded last month |
| 2. Mock data loads slip | "Data migration 80% complete" | Fewer than 3 full-volume mocks planned; mock 2 below 95% clean load; no reconciled trial balance inside 9 months of go-live | Mock schedule and results; record load success rate; trial balance variance signed by the controller |
| 3. Signed-off designs reopened | "Design complete, build 60%, 14 CRs in review" | More than 5% of signed decisions reopened after build starts; any reopened in finance or order-to-cash within 90 days of go-live | Change requests that cite a signed design document, by process area; who signed the designs |
| 4. SI staff churn | "Resourcing: green" | More than 20% of named SI roles turned over in 6 months; any change of SI program manager, lead architect or data lead | Named staffing list in the SOW against today, with grades and start dates; SI attrition on your program by quarter |
| 5. Steering committee gets shorter | "Steering committee held, no escalations" | Under 45 minutes with no decision recorded at 2 consecutive meetings; sponsors sending delegates twice running | Decision log for the last 3 meetings; attendance by name; top 5 risks with date of entry |
| 6. Scope moved to phase 2 without a budget line | "Scope stable, 23 items deferred to phase 2 by agreement" | More than 10 deferred items with no owner, cost estimate or funding source; any deferred item that the business case counted | Phase 2 list against the business case, with benefit value, cost and who agreed |
| 7. Process owners stop attending | "Business participation strong, workshops complete" | Owner attendance below 75% at design and test sessions; owners with less than 50% time freed during those phases | Attendance record by named owner; who signed the design documents and the test results |
Sign 1: Defects rise while the RAG stays green
Open severity 1 and 2 defects rising for three consecutive weekly test cycles is the earliest hard signal a program keeps on record. A healthy integration test cycle opens many defects in week one and closes more than it opens by week three. A troubled cycle opens more than it closes, week after week, while the report shows percent of scripts executed. That number keeps climbing because a failed script still counts as executed.
The rule we recommend is a closed-to-opened ratio of at least 1.0 by the second week of any test cycle, and a hard stop if it stays below 1.0 for two weeks. A cycle that opens more than it closes cannot finish, so the next cycle inherits the backlog. Three weeks rules out a bad week and still leaves time to act.
Consider a 20-month S/4HANA program in month 14, with go-live in month 20 and two test cycles to go. The report reads "SIT cycle 2 at 68% execution, on track." The defect log for the last three weeks shows 92, 118 and 140 open sev 2 defects, with 60, 70 and 75 closed in the same weeks. The ratio is 0.65, 0.59 and 0.54. At that rate cycle 2 ends with roughly 200 open sev 2s and cycle 3, planned as a regression pass, becomes a repair cycle. The go-live date has already moved by six to eight weeks, and nobody has written that down.
Ask for three numbers: open sev 1 and 2 defects by week for the last eight weeks, the closed-to-opened ratio each week, and the first-time pass rate. Then ask who sets the severity. If the SI triages defects without the business in the room, severity drifts downward. A sev 2 that becomes a sev 3 leaves the executive view without being fixed. Ask how many defects were downgraded last month.
Sign 2: Mock data loads slip or shrink
Data migration needs at least three full-volume mock loads before cutover. The second should load at least 95% of records cleanly, with a trial balance variance the controller will sign. Those are the rules we recommend. The first load finds the mapping errors, the second proves the fixes, and the third rehearses cutover timing. The last 5% of records is the hard 5%, and it takes the remaining months to clear.
Panorama's warning-sign checklist, first published in 2010 and updated in 2022, flagged fewer than three rounds of integration testing as a sign of trouble. The same logic applies to loads, and Panorama's 2025 finding that data issues now lead schedule overruns says why.
Mock loads slip in two ways. The date moves, which at least shows up in the plan. Or the scope shrinks: mock 1 becomes "mock 1a" with master data only, and mock 2 becomes the first real test of what cutover depends on. The status report says "Data migration 80% complete" because 80% of the extraction and mapping objects are built. Built is not loaded, and loaded is not reconciled.
Take a $2B electric utility with 1,500 employees moving from SAP ECC to IFS Cloud, go-live in nine months. The plan shows mock 1 done and mock 2 next month. Mock 1 loaded 2.1 million of 2.4 million records, an 87.5% success rate. The 300,000 failures are mostly asset and work order history with missing location codes, and nobody has run a trial balance against the loaded general ledger. On that evidence the program needs several months of data cleanup by the utility's own asset and finance staff. Mock 2 will not clear 95% unless that work starts now. The report calls it 80% complete.
Ask how many full-volume mock loads are in the plan, how many have run, the record load success rate on the last one, and the variance between the legacy and loaded trial balances. If the answer to the last question is "we have not reconciled yet" and go-live is inside nine months, you have found your problem.
Sign 3: Signed-off designs get reopened
When more than 5% of signed-off design decisions are reopened after build starts, the design was not finished when it was signed. That is the rule we recommend. Design sign-off is where fixed-fee risk transfers from the SI to you, and anything reopened afterward is a change request the SI is right to charge for. A program with 400 signed decisions can absorb 20 reopened ones as normal discovery. Forty means the business was not in the room.
The design phase is 10 to 20% of implementation hours by ERP Research's cost breakdown. Compressing it is a common way a program buys an early milestone it later repays with interest.
Reopened designs hide well. The change log says "CR-114: adjust intercompany posting logic," not "we never agreed how intercompany works." Suppose a five-plant manufacturer at $500M is implementing Oracle Fusion Cloud ERP with 320 signed design decisions. The report says "Design complete, build 60%, 14 change requests in review." Sorted by source, nine of the 14 cite a signed design document, and six of those nine sit in order-to-cash and intercompany. That is 2.8% reopened overall, under the threshold, but six reopened decisions in the areas that touch revenue recognition are a different problem from a dozen cosmetic form changes. The threshold triggers the question; it does not answer it.
Ask how many change requests cite a signed-off design document and which process areas they cluster in. Then ask who signed. If the design documents carry an IT signature and no business process owner's name, the sign-off was procedural. That connects directly to sign 7.
Sign 4: SI staff turn over faster than 20% in six months
Turnover above 20% of named SI roles in six months means the program is being re-learned by people who did not make its decisions. So does any change of the SI's program manager, lead solution architect or data migration lead. We recommend 20% because a 25-person SI team losing five people in six months loses one a month. Each departure takes two to four weeks of handover the plan did not include. We could find no published benchmark, and SIs do not volunteer the number.
The report says "Resourcing: green" because the seats are filled. It does not say who filled them. The replacement is often a grade junior, and the design rationale leaves with the person.
Consider a Dynamics 365 program with a 30-person SI team in month 10 of 18. The statement of work named 12 key roles. Four of the 12 have changed, including the lead solution architect, who left in month 8 and was replaced by someone two grades junior. That is 33% churn in the named roles. Suppose the new architect spends eight weeks learning 200 design decisions while also running build, and reopens 5% of them. The program has lost two months of architect time and gained ten change requests, and none of that is in the plan.
Ask for the named staffing list in the statement of work against the list today, with start dates and grades. Ask for the SI's attrition on your program, by role, for the last two quarters.
Sign 5: The steering committee meeting gets shorter
A steering committee that runs under 45 minutes and records no decision at two consecutive meetings has stopped governing. The agenda has become a readout, and decisions that should have reached the committee, such as a scope cut, a date move or a contingency draw, are being made below it or not at all.
The rule we recommend is monthly meetings in the last twelve months before go-live, with a written decision log. Two meetings in a row that run short and decide nothing is the alarm. Forty-five minutes is the floor because a program spending $1M a month generates at least one decision a month that belongs above the program manager, and a decision with its options takes 15 minutes. Panorama's 2010 checklist called for executive review at least every two months. That is a fair minimum for a nine-month cloud program and too slow for a tier 1 program near cutover.
Take a Workday Financials program eight months from go-live. The last three steering meetings ran 40, 35 and 30 minutes, and the minutes record "no escalations" each time. In the same period the program manager approved a two-week slip to the integration test start and deferred the fixed asset module to phase 2. The program manager also drew $180,000 of the $1.2M contingency (15%) for extra data cleanup contractors. Each was a steering decision, made one level down and reported, if at all, as a line in the deck.
Ask for the decision log, the attendance record and the top five risks with their dates of entry. Sponsors sending delegates two meetings in a row is the same sign in a different form. A top-five risk unchanged for three months is a decision nobody wants to make.
Sign 6: Scope moves to phase 2 without a budget line
Any phase 2 list with more than ten items that have no owner, cost estimate or funding source is a scope cut dressed as a plan. If the list includes anything the business case counted on, your benefits have shrunk while your budget has not. Deferring scope is legitimate, and a good program team takes out everything not needed for go-live.
The rule we recommend is that every deferred item carries an owner, a cost estimate and a funding source before the deferral is approved. Ten unfunded items is the alarm because at that point the deferred list is a program in its own right, and nobody is running it.
Panorama's 2025 report found the top reason for budget overrun was the unexpected need for additional technology. Some of that is discovery, and some of it is phase 2 arriving. Suppose an Epicor Kinetic program at a $300M manufacturer has a $4.5M budget and a business case built on $1.8M a year of benefits. The report says "Scope stable, 23 items deferred to phase 2 by agreement." Matched against the business case, six of the 23 carry benefit value, among them shop floor data collection, the quality module and two EDI integrations. Together they account for $700,000 of the $1.8M, and none has a cost estimate. The program will go live on budget and deliver 61% of the case that funded it. The first anyone hears of the gap is the year-one benefits review.
Ask for the phase 2 list against the business case line by line, with each item's benefit value, estimated cost and funding source. Look especially for deferred integrations the go-live design assumes, because each one means a manual workaround at cutover. Panorama's checklist noted that over half of the manufacturing implementations it studied created operational disruption at go-live. Workarounds are where that disruption comes from.
Sign 7: Business process owners stop attending
Business process owner attendance below 75% at design and test sessions means the business is not making the decisions the system will enforce for the next fifteen years. The rule we recommend is that a process owner has at least half of their time freed during design and again during integration testing. Attendance is tracked by name and reported to the steering committee.
Seventy-five percent is the floor because design runs as a sequence. An owner who misses one session in four has missed a decision the next three build on. A program that does not backfill the owners' day jobs gets far less than that, because the day job wins every scheduling conflict.
Consider an Infor CloudSuite program at a $1B distributor with eight named process owners. The report says "Business participation strong, workshops complete." The attendance sheets for the 40 design workshops show the finance and procurement owners at 90%, the warehouse owner at 55%, and the sales order owner at 40%. A delegate from IT attended in the sales owner's place, and the order-to-cash design documents carry the delegate's signature. When integration testing reaches order-to-cash, the sales owner sees the design for the first time, and sign 3 begins.
Ask for the attendance record by named owner, who signed the design documents, and who signed the test results. A test signed by an SI consultant and an IT analyst, with no process owner's name, has not been accepted by the business. The fix costs less than any other on this list: backfill the owners' roles for the design and test windows.
Check your program in fifteen minutes
The Program health check asks the seven questions above, scores the answers against the thresholds, and tells you which records to pull first. It takes about fifteen minutes with the last status report in front of you.