Free ERP project risk assessment covering the seven red-flag criteria. Score your programme health and find out if your ERP is on track or heading for distress.
An ERP implementation risk assessment is a structured review of the conditions most likely to cause your programme to overrun, fail to deliver the intended benefits, or disrupt the business at go-live. It examines scope control, budget governance, schedule confidence, data migration readiness, user adoption, technical integration, and vendor performance. Most ERP failures are not caused by the software itself but by weaknesses in one or more of these areas that go undetected until they are expensive or disruptive to fix. A formal assessment gives the board an objective view of programme health and identifies specific actions to reduce risk before it is too late to act.
The most frequently cited causes of ERP failure are uncontrolled scope growth, underestimated data quality problems, insufficient end-user training and change management, incomplete integration testing, and weak vendor governance. Underpinning many of these is a lack of senior leadership ownership of the programme as a business transformation rather than an IT project. When the board delegates accountability entirely to IT or the vendor without maintaining rigorous oversight, warning signs are routinely missed until the programme is in serious difficulty.
The early warning signs are typically subtle: go-live dates that shift repeatedly by small amounts rather than one large reset; cost forecasts that remain optimistic despite scope growth; vendor reports that are consistently more positive than the observations of internal staff; and change management activity that focuses on communications rather than genuine readiness assessment. A formal programme health check conducted by someone independent of the delivery team is the most reliable way to surface these signals before they become crises.
A health check is valuable at any stage but is most impactful at three points: before the detailed design phase begins, to confirm that the foundations are sound; six months before the planned go-live date, when there is still time to intervene on readiness gaps; and immediately after a major concern surfaces, such as a significant budget overrun, a schedule slip, or a change of implementation partner. Conducting a health check at the final weeks before go-live still has value but leaves very limited time to act on the findings.
A programme assurance review focuses on the conditions for future success rather than on historical compliance with process. A standard audit checks whether defined procedures were followed; a programme assurance review asks whether the programme is likely to deliver what the business needs, on time and within budget. Assurance looks forward rather than backward and produces actionable recommendations rather than audit findings. For a board or steering committee, assurance is the more useful lens because it enables preventive action rather than after-the-fact accountability.
The board's role is to set clear accountability, receive objective and independent reporting, make timely decisions at defined gates, and remove obstacles that the programme team cannot resolve. This means insisting on a monthly report prepared or reviewed by someone independent of the delivery team, defining the conditions under which they would authorise or withhold go-live, and ensuring a named executive sponsor has the authority and time to act on escalations within days rather than weeks. Micro-management is rarely the risk; under-governance is far more common and far more damaging.
The seven questions that consistently reveal programme health are: what has slipped since last month and what is the recovery plan; what is the current cost-to-complete and how has it changed; what is the status of data migration rehearsals; what percentage of users have completed training and passed competency checks; are there any open disputes with the vendor and how are they being managed; what would cause us to delay go-live and how close are we to those conditions; and what does the independent assurance lead believe the board should know that is not in the main report?
Contingency sizing should be based on a formal risk quantification exercise rather than a rule of thumb, but programmes that have not yet completed technical build and testing typically require contingency of at least ten to fifteen per cent of remaining budget to absorb realistic adverse scenarios. Contingency should be held by the programme sponsor or CFO rather than included in workstream budgets, and drawdown should require a formal request with a documented justification. Contingency that is embedded in workstream budgets tends to be consumed without being tracked against specific risks.
Effective contracts define deliverables with objective acceptance criteria rather than relying on the partner's own assessment of completion, include fixed-price milestones for major phases wherever possible, specify the process and notice period for replacing key personnel, and contain a structured dispute resolution process with defined timescales. Retention arrangements, where a proportion of each milestone payment is held until satisfactory delivery is confirmed, are a practical lever for maintaining vendor focus. Contracts that are primarily time-and-materials with vaguely defined deliverables significantly increase the commercial risk to the client.
The cutover plan is the detailed sequence of activities required to stop using the old system, migrate data, configure the new system for production, and start live operations. It is high-risk because it must be executed correctly within a finite window, often over a weekend or a short planned maintenance period, with no tolerance for unresolved problems. Cutover plans that have not been rehearsed, that assume more internal resource than is actually available during the go-live period, or that have no formally tested rollback procedure are among the most common causes of go-live failure. A credible cutover plan is a pre-requisite for go-live authorisation, not a document produced in the final week.