Your project went live. But was it successful?

Delivery is not the same as success

Projects are often defined by outputs: implement a new ERP, launch a portal, migrate data, build an application or integrate two systems. These outputs matter, but they do not explain why the organization is investing in the project. If the objective is to reduce invoice processing time, improve inventory visibility or eliminate duplicate data entry, success should be expressed in those terms. Otherwise the team can technically complete the implementation while the original business problem remains.

Create observable outcomes

A useful success criterion should be specific enough that stakeholders can recognize whether the project improved the situation. It may be quantitative, such as reducing processing time from two days to two hours, or qualitative but observable, such as giving managers one agreed source of operational information.

Not every benefit needs a perfect KPI. The important point is that the project sponsor and delivery team share the same picture of the desired future state.

Success guides decisions

Clear outcomes are useful throughout the project. When a new request appears, the team can ask whether it contributes to the agreed outcome. When time or budget becomes constrained, priorities can be evaluated against what matters most. A definition of success therefore does more than help at the end of the project. It improves decisions from the beginning.

Key takeaway: Define the business outcome before defining the project as a collection of deliverables.

Answer these questions before even looking for a new system and implementation partner

1. 1. Why are we considering a new ERP in the first place?
      What business problems are significant enough to justify the investment?
   2. What should be different after implementation? Describe the future business situation—not the software.
   3. Which processes specifically need to improve? For example: purchasing, month-end closing, inventory planning, order processing, production planning or financial reporting.
   4. How do those processes perform today? Establish a baseline. If invoice processing currently takes two days, for example, what should it take afterward?
   5. How will we recognize that each problem has actually been solved? Can success be measured quantitatively, or at least observed objectively
   6. What information should management have that it cannot reliably obtain today? Better reporting isn’t simply “we implemented Power BI.” What decisions should managers be able to make faster or with greater confidence?
   7. Which manual activities should disappear or decrease? Where are employees currently re-entering data, maintaining spreadsheets, performing reconciliations or creating workarounds?
   8. Which existing problems must not simply be recreated in the new ERP? A new ERP should not become an expensive reproduction of the old way of working.
   9. Who determines whether the implementation was successful? Finance, Operations, IT, management and end users may have very different definitions of success. 
   10. Do the project sponsor and implementation partner share the same definition of success? If the customer expects “better inventory control” while the implementation team is focused on “getting inventory functionality live,” there is already a potential disconnect.
   11. When a new requirement appears, how will we decide whether it belongs in the project? Does it contribute materially to one of the agreed business outcomes?
   12. If budget or time becomes constrained, what outcomes are we unwilling to compromise? This converts the definition of success into a practical prioritization mechanism.