Expertise
Six areas where I have led delivery at global scale, inside a regulated, operationally critical environment.
Areas
- What does executive-level programme governance involve?
- How do you take a business-critical system from selection to stable operation?
- Why does technology adoption fail, and how is it fixed?
- How should a business process be improved before it is automated?
- What changes when systems run in a GxP-regulated environment?
- How do enterprise systems connect to the manufacturing floor?
What does executive-level programme governance involve?
Structured leadership of complex business and technology programmes, including ERP programme management and global rollouts, from initiation through post-delivery stabilisation. It means clear decision rights, individual ownership, and executive reporting that reflects the real position rather than the planned one.
In practice
- Programme governance design: decision rights, steering structure, escalation paths
- Milestone planning with individual ownership and accountability
- Stakeholder management across leadership, operations and external parties
- Vendor and supplier performance management
- Go-live governance and post-delivery hypercare
Where it applies: Multi-year transformations, multi-site rollouts, ERP and MES implementations, M&A technology integrations.
How do you take a business-critical system from selection to stable operation?
By owning the full lifecycle: requirements, vendor selection, delivery, go-live and the hypercare period. Most implementations go wrong in the weeks immediately after go-live, so the stabilisation structure is designed before go-live and exits on defined criteria, not calendar dates.
In practice
- Requirements defined in business language, not technical specification
- Vendor evaluation and selection
- Implementation governance and delivery oversight
- Integration and data readiness management
- Go-live governance, cutover planning and hypercare with defined exit criteria
Where it applies: Any organisation implementing or replacing a business-critical system, particularly where earlier implementations underdelivered.
Why does technology adoption fail, and how is it fixed?
Technology is adopted by people, not organisations. Adoption fails when the people most affected were not brought along, training happened once and stopped, and nobody owned adoption after go-live. Fixing it means addressing all three, including direct work with the people most resistant to the change.
In practice
- Stakeholder and change impact assessment
- Role-specific training built around real operational scenarios
- Super-user and champion networks
- Adoption tracking and follow-through for the first three months
- Direct engagement with resistant individuals and teams
Where it applies: Significant operational or technology change, especially in manufacturing, regulated industries, and organisations where previous change programmes did not land.
How should a business process be improved before it is automated?
Map how the organisation actually operates today, not how the procedure says it should. Identify where complexity and waste have accumulated, then redesign with the operational team. Automating a broken process only embeds it.
In practice
- Current state mapping, including workarounds and informal fixes
- Gap analysis of waste, duplication and structural complexity
- Redesigned processes co-developed with the operational team
- Documentation people can actually use
- A KPI framework to measure improvement over time
Where it applies: Organisations whose processes are not keeping pace with growth, and any organisation preparing for a system implementation.
What changes when systems run in a GxP-regulated environment?
Failure carries regulatory as well as commercial consequence, so compliance has to be designed into how programmes are structured and governed, not added at the end. My experience covers GxP, computerized system validation (CSV) and 21 CFR Part 11, across ERP, MES (Werum PAS-X), serialisation and regulatory submissions.
In practice
- Validation built into programme design and governance
- MES and ERP delivery in operationally critical, regulated sites
- Serialisation and identity governance
- Regulatory submissions supported by technology programmes
Where it applies: Pharmaceutical and other regulated manufacturing organisations.
How do enterprise systems connect to the manufacturing floor?
Through deliberate integration between operational technology and enterprise business systems, from MES to ERP and from the floor to management. The technical integration is the smaller part. The larger part is getting IT and operations to agree on shared data definitions.
In practice
- Mapping data flows between operational and enterprise systems
- Prioritising integration points by operational impact
- Aligning IT and operations on shared data standards
- Real-time data flows and executive visibility
Where it applies: Manufacturing and supply chain organisations making decisions on delayed or reconciled data. See the real-time visibility result.
How I work
Understand before proposing
The actual operational reality, not the problem as described in a brief: the history, the constraints, the people and the pressures that shaped how things work today.
Map what is actually happening
Including the workarounds, the informal fixes and the exceptions that have become the norm. The gap between the documented process and the real one is where the problems usually live.
Design the solution with the team
Designed with the operational team, in context, around real constraints. It takes more time at the front and produces significantly better adoption.
Implement with accountability
As an active participant accountable for the outcome: managing vendors, resolving blockers and holding the governance discipline that most programmes lose under delivery pressure.
Own the go-live and what follows
The hypercare structure is designed before launch, with engagement continuing until the organisation is genuinely stable.
Make the change last
Success is whether the organisation is still running on it six months later, and whether the people who use it have adopted the new way of working.
Principles
- Simplicity over complexity. Always.
- People adopt what they understand and trust.
- No system works if the process around it is broken.
- Change is only real when it holds after the project team leaves.
- The IT team and the business are both right. They need a translator.
Common questions
- Why do technology adoption projects fail?
- Technology adoption projects most commonly fail because the team was not involved in the decision, training was one-time and insufficient, the process around the tool was never redesigned, or the change was not supported for the people most affected by it.
- How do you handle resistance to change?
- Resistance to change is almost always rational once you understand what is behind it. The key is to talk to resistant people individually and address the specific concern, not the general resistance.
- When should you not automate a business process?
- Do not automate a broken process, a process that varies for good reasons, or one that is currently changing. Fix and stabilise first, then automate.
- What is the most important thing to do after go-live?
- Establish a clear issue management structure before go-live, not after. In the first 48 hours, you need a severity classification, named owners for issues, and a daily visibility mechanism.