3. The programme starts without clear outcomes

Some transformation programmes focus heavily on implementing a new platform without clearly defining what business problems the technology is expected to solve. 

The organisation may want to “improve procurement” or “increase automation”, but these ambitions are too broad to guide design decisions or measure success. 

Clear outcomes might include increasing purchase order compliance, reducing manual invoice handling, improving spend visibility, shortening sourcing cycles or strengthening contract controls. Each objective should have an agreed baseline, target, owner and measurement approach. 

Without this clarity, teams risk recreating existing processes inside a more expensive system. A successful transformation should simplify work and improve outcomes—not merely digitise unnecessary complexity.

4. Change management begins too late 

Change management is often underestimated or reduced to training and communications shortly before go-live. By this stage, many important stakeholder opinions have already formed. 

Senior stakeholders who were not brought along during the design process can become significant procurement change barriers as implementation approaches. They may challenge the new process, object to approval requirements or argue that the solution does not reflect how their function operates. 

These concerns can result in late design changes, delayed sign-off and reduced adoption. 

Effective change management should begin during programme mobilisation. Stakeholders need to understand why the transformation is happening, how it will affect them and what decisions they will be expected to support. 

Engagement should continue throughout design, testing, deployment and stabilisation. It is much easier to resolve concerns gradually than to overcome organised resistance immediately before launch.

5. Poor data is treated as a technical problem

A new procurement system will not automatically correct inaccurate supplier records, duplicate data, inconsistent classifications or incomplete contract information. 

Data quality is frequently discovered as a major source of procurement risk late in the programme. When ownership is unclear, teams may underestimate how long cleansing, validation and migration will take. 

Poor data can undermine reporting, prevent transactions from processing correctly and reduce trust in the new platform. It can also create operational and compliance risks if supplier, banking, tax or approval information is incorrect. 

Data should therefore be treated as a dedicated workstream with clear owners, quality standards and validation controls. The business—not only the technology team—must take responsibility for confirming that migrated data is accurate and usable. 

6. Governance and decision-making are too slow

Procurement transformations generate hundreds of decisions covering processes, controls, integrations, roles, data and exceptions. 

When decision rights are unclear, minor questions can remain unresolved for weeks. Project teams continue working with assumptions, only to discover later that stakeholders disagree with the chosen approach. 

A clear governance model should define who can approve process designs, who owns specific risks and where unresolved issues should be escalated. Decision logs, regular governance meetings and visible action tracking help prevent delays from becoming embedded in the programme. 

Good governance does not mean adding unnecessary bureaucracy. Its purpose is to help the programme make timely, accountable decisions.

7. Technology is expected to solve process and behaviour problems

Technology is an enabler, but it cannot compensate for unclear policies, unnecessary approvals or a lack of accountability. 

Automating a poorly designed process often makes the same problems occur faster. Before configuring the system, teams should challenge existing ways of working and identify where processes can be simplified, standardised or removed. 

The selected solution must also reflect how users genuinely work. Excessively complex buying channels, approval structures or data requirements can push employees towards workarounds and reduce compliance. 

Design decisions should balance control with usability. A process that looks perfect on paper but is avoided by users will not deliver the intended return.

8. Go-live is treated as the finish line 

Getting the system live is an important milestone, but it is not the end of the transformation. 

The weeks and months after launch are critical. Users need support, data issues emerge and processes that worked during testing may behave differently at scale. Without sufficient stabilisation support, confidence in the new system can decline quickly. 

Organisations should plan for hypercare, issue resolution, adoption monitoring and continued stakeholder communication. They should also track whether transactions are moving through the intended processes and whether users are reverting to spreadsheets, email or legacy systems. 

Embedding is equally important. New roles, controls and responsibilities must become part of normal operations. Training may need to be repeated, guidance improved and processes adjusted using real user feedback. 

Ultimately, the expected return on investment is not achieved when the platform goes live. It is achieved when people consistently use the new processes and the organisation begins to realise measurable improvements.