Why these projects go wrong.
WHAT THE COMMON CAUSES ARE
Scope larger than the organisation could absorb Requirements not understood before selection Data migrated without cleaning Insufficient training Process not changed to match the system Customisation to preserve old ways of working Leadership disengaged Go-live forced by a date
WHY DATES CAUSE FAILURE
Testing and training are compressed, and problems reach production.
WHAT THE VISIBLE SYMPTOMS ARE
Staff maintaining spreadsheets alongside the system Reports nobody trusts Transactions entered late or not at all Workarounds becoming standard practice
WHAT THOSE INDICATE
The system is not actually in use.
WHAT PARTIAL ADOPTION PRODUCES
Incomplete data, which makes the system worse than none.
WHY WORSE
The old process is gone, and the new one is not trusted.
WHAT PREVENTS THIS
Scope limited to what can be absorbed Data cleaned before migration Training before and after go-live Leadership visibly committed Process redesign accepted
WHAT TO DO IF A PROJECT IS FAILING
Stop, and establish why, before continuing.
WHAT NOT TO DO
Add resources to an approach that is not working.
WHAT TO ACCEPT
That abandoning is sometimes cheaper than continuing.
