Is Your IFS Cloud Project Off Track? 8 Signals

A project reports what its plan contains, and a plan can be complete on paper while the system underneath cannot yet carry the business. The vendor protects the relationship and the project manager protects the schedule.

Green status reports and red reality

A configuration task reaches 100% when the setup is entered, not when a user has pushed a purchase requisition, a customer order and a supplier invoice through it with correct accounting. The health check asks for a business scenario executed by a business user, on migrated data, in a named environment, with the result recorded.

Each signal below is checked against a document, a log or a roster, not an opinion. A scoring table follows the list.

The go-live date moved twice with no change in scope

A date that moves while the scope list stays identical shows that the original estimate was not built from the work. Compare the baseline plan, the current plan and the change log. Two date changes with no scope change beside them show that the dates were negotiated with the sponsor while the estimate behind them stayed the same.

The legacy system still runs in parallel because nobody trusts the new one

Parallel running with no end date means the business has not accepted the new system as the book of record. Check whether the legacy system still receives postings, whether finance still reconciles from it, and whether the condition for switching it off exists in writing.

Success metrics were never written down

Look in the business case and the acceptance document for statements such as “month-end close in N working days”. When the only targets are “system live” and “users trained”, go-live is a calendar event. The ERP ROI analysis covers the cost side of the same question.

Scope grows with no change-control record

Scope that enters through meetings and e-mail reaches neither the budget nor the schedule. Compare the requirements in the current design documents and the approved change requests with the kick-off scope. The difference is unfunded scope, and it can by itself explain the first signal.

Migration trials keep failing on the same data classes

A trial that fails on the same class each run, such as supplier bank details, open purchase order lines or inventory part attributes, points at an unowned rule or a source that cannot supply the field. Read the load logs of the last three trials side by side. The data governance phases and the data migration checklist show what ownership looks like.

Testers come from the project team, not from the business

Whoever configured a process follows the path that works, while a business user finds the one that does not. In the test execution log, count the scenarios executed by someone who had never seen the configuration. Rethinking test automation describes how to involve process owners without stalling their daily work.

Key people are single points of failure

Ask for a written, named deputy for the finance configuration lead, the data migration lead and the integration developer. Without deputies the schedule depends on holidays and resignations, and a vendor team with one named architect carries the same exposure.

Extensions grow faster than standard configuration

Track Custom Events, Custom Fields, customised reports and integrations against configured standard processes, release by release. Rising extensions beside flat configuration mean requirements are met by building around the standard, and each extension adds a test obligation at every release, as described in why ERP upgrades fail and upgrade preparation.

Score each signal 0 when the evidence is absent, 1 when it is present and owned, and 2 when it is present and nobody is addressing it.

A total of 0 to 5 calls for ordinary management attention. A total of 6 to 10 justifies an independent review. A total above 10 puts the repair-or-rebuild decision on the table. These thresholds are this practice’s working convention, not a published benchmark.

The health check is a fixed-length review that changes nothing in the project while it runs. Documents come first because they are cheap and show what the project says about itself. Scenarios come last because only they show what the system does.

Week 1: documents, interviews, environment and data review

Days one and two cover scope, solution design, plan history, change log, risk register, test results, migration trial logs and the vendor contract. The reviewer reads for contradictions, such as a design assuming a standard process while the interface list holds a custom build for the same process. Days three and four are interviews with the sponsor, project manager, vendor lead, process owners and end users who have tested, all answering the same questions so answers can be compared across roles. Day five inspects environments, installed extensions and a sample of migrated customers, suppliers, parts and open orders.

Week 2: scenario walkthroughs, risk register, finding session

Days six to eight run purchase-to-pay, order-to-cash and a period close with business users at the keyboard, on migrated data. A scenario that needs a consultant to touch the keyboard is recorded as failed, with the reason. Day nine re-rates the project’s own risk register against what the scenarios showed. Day ten is the finding session with the sponsor, where every finding arrives with its evidence.

The deliverable is a map of solution areas, each marked keep, repair or rebuild, plus a recovery plan. Areas follow business boundaries (finance, procurement, sales, inventory, manufacturing, interfaces), because one project can hold a sound finance design and an unusable interface layer.

• Keep - the scenario ran with business users, the data loaded with explainable rejections, and extensions cover only what standard could not. Work continues on the existing plan.
• Repair - the design is sound, but evidence is missing or a defined set of defects blocks a scenario. The plan lists the defects, the owner and the retest date.
• Rebuild - the area was designed against a requirement that no longer holds, or it uses extensions where standard functionality fits. The review states why rebuilding costs less than testing the area into shape.

The sponsor approves keep areas at once, funds repair areas against a defect list, and takes each rebuild decision with its cost in view.

A recovery gate is a dated decision with an owner, an entry condition and a stop rule that says what happens if the condition is not met, such as work halting or the date being recalculated. The plan described here uses four.

• Scope freeze - every requirement sits either in the signed list or in the change-control register. Stop rule: anything outside both is not built.
• Data - a migration trial loads the agreed data classes, and each rejection has a named owner. Stop rule: no cutover rehearsal until two consecutive trials pass.
• Business test - business users complete the agreed scenarios without consultant intervention. Stop rule: failed scenarios return to repair, and the go-live date is recalculated from the defect list.
• Go-live readiness - the written metrics from signal 3 are checked against rehearsal results, the legacy switch-off condition from signal 2 is on paper, and support after the start is staffed. That period is covered in IFS Cloud hypercare after go-live, and the first service update after the start belongs in the plan described in the IFS Cloud update calendar article.

Fix the missing success metrics first, because every other decision refers to them: write five to eight measurable targets with the sponsor and the process owners and put them into the acceptance document. Second, freeze scope until a change-control register exists. Third, put business users into testing, even for one order-to-cash scenario on migrated data. Extension growth and key-person risk come after these three, and the process honesty check shows how to keep the evidence honest. If the vendor reprices the remaining work, read the revised quote with the line-by-line quote guide.

A health check can show a sound design and a team that is the obstacle: named consultants replaced after signing, findings acknowledged and never fixed, or a contract with no acceptance criteria to enforce. The decision then belongs to the commercial side. Choosing an IFS Cloud implementation partner covers the clauses to check: named-team and key-person commitments, acceptance criteria, change control and the support model after go-live. They apply equally to a replacement, a second vendor for a rescued area, or a hybrid model in which the customer leads and a partner provides quality assurance.

The author runs an independent consulting practice and sells health checks, so every finding points to an artefact you can open yourself, and the recommendation can be to keep your current vendor.

Dariusz Myśliwiec: 18 years hands-on with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally through an independent practice.

Selected clients: Fugro · LGC · BVI Medical · Betafence · Barlinek · NGK Ceramics · Newag · Oleofarm.

IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.