When I have taken over troubled EAM programmes, the most difficult part is often not the technology. It is the atmosphere around the project. Payments may be withheld, vendors may be reluctant to deliver additional scope, and relationships between the customer, system integrator and product principal may have deteriorated to the point where communication becomes defensive. Warning letters appear, legal teams are consulted, and senior management is left trying to decide whose version of events can be trusted.
At that stage, spending too much time reopening every historical dispute can make recovery even harder. My first objective is therefore not to prove who was right or wrong. It is to establish why the programme existed in the first place and what business outcome it was expected to deliver.
Start With the Original Business Objective
The first engagement should be with senior management to reconfirm the purpose of the programme. What operational problem was the organisation trying to solve? Which maintenance or asset-performance KPIs were expected to improve? What would success have looked like if the project had gone according to plan?
The next step is to validate that understanding with the customer project team and then with the system integrator. This creates a practical recovery blueprint covering business KPIs, maintenance practices, technical requirements, acceptance criteria and what has actually been delivered.
The original RFP remains useful, but troubled programmes need a simpler working document. Contractual language, optional requirements and historical discussions can make an RFP too noisy for recovery. The recovery blueprint should focus only on what is required to regain control and deliver measurable value.
Reset the Team Dynamics
Team dynamics are often as important as system configuration. In a damaged programme, the customer may ask for a fresh delivery team. That is understandable, but replacing everyone can also remove valuable project knowledge.
I normally identify which existing team members still have the customer’s confidence and retain them where appropriate, while introducing new people into customer-facing or critical delivery roles. Previous team members can continue supporting from the background because their knowledge of earlier decisions, configuration and unresolved issues is still valuable.
The purpose is not to assign blame. It is to reset the working environment so that both the delivery and acceptance teams can operate with clearer ownership and less accumulated tension.
Prioritise What Matters in the First 90 Days
Once the blueprint and team are reset, the next challenge is prioritisation. A recovery programme cannot treat every requirement as equally urgent.
I use four practical levels. Essential Modules are the capabilities required to stabilise core maintenance operations. In the recovery framework, these include corrective work orders, priority and status workflows, failure codes and approval controls—capabilities needed to restore operational control quickly. Supporting Modules strengthen early recovery through inventory and spares, purchasing and receipts, standard dashboards and KPIs, contractor management and basic mobile enablement. Extended Modules add value once the foundation is stable, for example HSE and permit-to-work functions, advanced mobile inspections, condition monitoring, document management and calibration. Future Expansion covers extensible capabilities such as digital twins, AI and predictive analytics, advanced APM and other enhancements that can be added later without putting the recovery at risk.
The central principle is that the first 90 days should concentrate on the common operational core. That prevents the recovery programme from being overwhelmed by features that may be useful but are not essential to restoring confidence and business continuity.
Architecture, Integration and Data Readiness Are Non-Negotiable
Even when delivery is incremental, architecture, integration and data readiness must be considered from the beginning. An EAM rarely operates in isolation. It may exchange information with SCADA, ERP, HR, data platforms, operational systems and other enterprise applications.
If these dependencies are ignored during the first release, the organisation may achieve a temporary demonstration but still fail when the solution is scaled. Master data is particularly important. Asset hierarchies, locations, equipment records, maintenance plans, materials and other core data should support realistic testing of both the EAM modules and the interfaces between systems.
Recovery should therefore validate not only screens and workflows, but also how information moves across the wider architecture.
Recover Through Measurable Releases
Each release should have a clearly defined scope, acceptance criteria and ownership. Where appropriate, I prefer formal milestone acceptance that links agreed deliverables to the corresponding commercial milestone. This reduces ambiguity between what the delivery team believes is complete and what the customer believes has been accepted.
A management demonstration led by members of the customer project team can also be a powerful exit criterion. When customer representatives can demonstrate the process themselves, confidence begins to shift from the vendor’s promises to the organisation’s own understanding of the solution.
A Focused 90-Day Recovery Window
The initial recovery phase should normally be designed around a focused 90-day window, with the objective of restoring control, confidence and measurable delivery. I structure this around four stages: Reset and Initialisation, Configuration & Validation, Cross-Functional Verification, and Module-Level Rollout.
During the reset stage, roles, priorities, scope and acceptance responsibilities are agreed. Configuration and validation then confirm that the core solution works against the recovery blueprint. Cross-functional verification tests the dependencies between business processes, data and integrations. Module-level rollout moves the stabilised capabilities into controlled operational use.
Not every feature needs to be completed during this period. The objective is to prove that the programme is moving again, that essential capabilities can be accepted, and that both sides can work to a common delivery model.
Restore Confidence Before Expanding Scope
After departments begin adopting the stabilised system, the programme can revisit features that were deliberately deprioritised. This is the right time to assess the next phase, including additional modules, broader rollout and more advanced capabilities.
By then, the discussion is very different. Instead of debating a troubled history, management can evaluate future investment against demonstrated progress, clearer risks and a working operational baseline.
That is ultimately what EAM recovery should achieve. It is not simply a technical rescue. It is a controlled reset of priorities, people, architecture and delivery discipline so that confidence can be rebuilt through evidence rather than promises.