This article is #4 of a 5-part series on the value of ERP PMO. You can access the whole series here
.
"Getting an idea from A to B is as important as getting an idea". This was the ad copy for a fax machine, back when the world was young and fax machines were A Thing. I don't remember the brand - Japanese, I think - and Google or CoPilot aren't any help. So: fax machines are gone, and my memory of the company details is gone, but the phrase is as fundamental as ever.
When you pull together an ERP programme team, ideas multiply. Some of those can be good news, some are not. Multiple, conflicting ideas definitely are not - even if they are well-intentioned. So, there are some key topics where we very much want everyone to share the same basic idea before they start generating improvement ideas, problem resolution ideas or risk mitigation ideas. However: simultaneously getting that same basic idea from one A to multiple Bs won't "just happen". So, here are three ways in which the ERP PMO can remove common root causes of significant ERP delay and cost through better communications.
- Start With Why. Nobody implements an ERP system because they want to be the proud owner of an ERP system. ?The system is only an enabler: the idea is that your team can now do things differently - better, faster, or cheaper. Their new capability gives you a business outcome that you can measure and confirm as better, faster or cheaper with KPIs or other metrics - those are your benefits. In an ideal world you could trace a line from organisational strategies through strategic objectives, departmental OKRs, right through to new capabilities evidenced as ERP benefits. Conversely, if your business & teams don’t know why you’re implementing ERP or how you’ll measure success, you’re on a Magical Mystery Tour, not a programme.
- Why it matters: “Keep your eyes on the prize”. At difficult points it is tempting to drop or add scope; to compress timings; to settle for a clunky user interface or workaround in the name of “delivering ERP”. But you are not there to deliver an ERP; you are there to deliver measurable benefits. it helps a lot to capture and describe the envisioned "to be" state - be it in a Vision Statement, a customer proposition, or a Target Operating Model. Build it into your Business Case or Charter Document or whatever will serve as a usable benchmark across multiple teams and governance bodies when making decisions about scope, risk or timing.
- Tip: Revalidate this “why” as the programme progresses. Ensure the organisation uses the latest approved version of WHY as their North Star when evaluating options to deal with the inevitable pressures that arise.
- Share The Roadmap. An ERP project is a long, complex slog with many subteams and moving parts. WHY is a good start, but people also need to know HOW and WHEN we are going to reach our goals, WHAT are the workstreams, WHO owns which tasks, WHERE we are on our journey – and WHETHER we are where we should be.
- Why it matters: “Plans are nothing; planning is everything”. One of the most powerful moments in an ERP programme is when the various teams come together to work out how & when their separate workstreams interlace. Understanding and communicating the relationship between the moving parts is more important than the actual timeline that emerges. The initial timeline will surely change; the shared sense of how the parts fit together helps the teams to respond to such changes appropriately.
- Tip: Invest in a good visualisation of the roadmap and use it to update folk regularly on where we are vs. where we said we should be. Consider a core visualisation of, say, business capability drops over time, with various "overlay" layers that can be superimposed or removed for specific stakeholder groups - customer/ supplier comms view, new IT support arrangements view, technology components view, etc.
- ERP Change Is People Change. When you “unpack” any ERP system, it is a tightly-aligned bundle of pre-configured business processes, assumed roles, defined data objects and standardised document templates. There is ZERO chance you can implement all that and not affect how people do their day-to-day work. There is a correspondingly BIG chance you will have to make changes in 3, 4 or all 5 of people, skills, jobs, organisation, and roles.
- Why it matters: ERP is often delayed when a busy business team suddenly understands in their own terms the full operational scope of the impending change – and realises they are not ready for it. Treat ERP as a full-on business change project. While you can - and indeed should - use internal folk as Change Agents, do consider hiring an external Change Manager with experience of guiding teams like yours through the specific ERP you are implementing. Talk to your people; show what’s coming and why; ask them what they need to succeed - and give it to them!
- Tip: Don't wait until you know everything before you start communicating anything. You can tell people you will support them before you know exactly how. You can tell people there will be training before you decide exactly what. In fact, you need to communicate at 2 levels simultaneously: high level for the whole shape of the programme, but detail only as needed for the immediate period ahead.
Throughout the life of an ERP programme we will need to keep on building trust, aligning stakeholders, listening to people. We will need to be transparent about status, timely with updates and escalations, credible in our risk assessments and responses. There will be a lot of communication, and I don't downplay any of it. But in terms of Communications that will do most to save you time, money and heartache, I think you'll find a North Star "WHY", a widely-understood Roadmap, and a Business Change approach with team buy-in are very hard to beat.
