Change management starts in the business case
Most change management fails before the project starts, at the moment the goal is written down. The trigger is often technical, an unsupported system or an expiring licence, but if the goal itself says “replace the software”, everyone, including the vendor, optimises for the technology and the way people work is left to sort itself out after go-live. Michal argues that change management belongs in the business case and tests the claim on two cases he is accountable for.
Inside BIQ Group, where as COO he leads the consolidation of five companies, the order was processes first, then the organisation that owns them, then one shared Jira, and only after two years the choice of a tool for P&L and capacity planning. At DPD SK, the first SAP S/4HANA Public Cloud implementation in Slovakia, the trigger was an unsupported ERP, but the goal was written as standardised processes and one source of truth, which is what later earned the SAP Quality Award for CEE. He closes with what a project definition has to contain so that the change has an owner from day one.