The most important part of any EPM project is getting great stakeholder support — because getting great enterprise performance is the job of everyone who works there.
If you’ve ever sponsored or led an IT project for people who don’t care then you’ve felt the pain of what we’re talking about. First, there’s shock at the sheer illogic of people not caring who should. Then there is the day-to-day frustration of dealing with people who blow off meetings, don’t answer emails, or won’t provide timely or careful reviews of work to date.
Of course when stakeholders don’t care it’s not only you (an internal project sponsor or lead) who suffers but so will all these other stakeholders who would otherwise benefit. For EPM projects this can potentially include almost anyone — finance, line of business managers, the executive team, supply chain partners, the firm’s customers — system users and data consumers alike. When stakeholders don’t care, EPM projects waste money, are late, and are misaligned with stakeholder needs, which makes stakeholders even less willing to engage on future projects. If allowed to continue, the most likely outcome of this vicious cycle is the removal of the person at its center, i.e., you.
Getting stakeholders to care is always a key priority even if logically it shouldn’t have to be. It requires understanding why stakeholders should want to care, the reasons they might not, and what you can do about it.
Why Stakeholders Should Want to Care
Of course the most obvious reason stakeholders should care is because they benefit; in fact, that’s why they fund EPM projects. So if you ask them, they would probably say that, yes, of course, they care. But as other areas of life, there is caring and then there is wanting to care. And here actions speak louder than words (and money). Two other things project teams need are knowledge and access. Stakeholders in finance know the most about finance. Stakeholders who run lines of business know the most about those lines of business. Stakeholders on the executive team know most about corporate policies and direction — and so on. Non-IT stakeholders can’t expect IT to have their same level of subject matter expertise. (However, when you engage outside EPM consultants, something you should expect is relevant subject matter expertise — especially in finance.)
So, if non-IT stakeholders want the EPM projects they commission to succeed, they will want to share relevant subject matter knowle dge with EPM project teams. That obviously includes providing access to those who possess that knowledge when project teams are looking for direction and feedback.
And Why They Might Not Care
Giving someone some of your budget is one thing. Giving them some of your time — for project direction and feedback, for example — is another. That shows real commitment. To get that commitment, project sponsors and leads need to compete with other checkboxes on stakeholders’ priorities list. But in that contest IT may face some hurdles:
· IT sees the project in a technical context while stakeholders see it in a functional or business context
· Instead of seeing digitalization as a business imperative, stakeholders see IT as a support function
· IT doesn’t know what they could give stakeholders that they might want, while stakeholders don’t know what they might want that is technically possible
· Stakeholders’ constituents resist change
Given all the time pressures stakeholders are under, it’s a lot to ask for them to overcome these hurdles on IT’s behalf. Then again, if these hurdles come with the territory then it’s reasonable to expect IT to have the skills to overcome them.
What You Can Do About It
We’ve written before about the importance of an agile approach when tackling EPM projects. And if you do know the agile methodology, then you already have many of the skills for getting stakeholders to really care about EPM projects. Top among them are:
Show vs. tell. There is nothing better for getting stakeholders on your side than showing them working code. It’s also a great conversation starter.
Fast iterative deliverables. If what you want is frequent stakeholder access, and showing working code is a great way to get people to talk to you, than dividing projects up into small chunks is a great way to get the frequent access you crave.
In addition to agile we would also suggest that caring is a two-way street. If you want stakeholders to care about your priorities, which is to deliver a great EPM project, then you have to show them that you care about theirs. Don’t wait for an EPM project to come along to engage with your colleagues to learn more about what they do and their concerns. If you’re a more receptive listener, you may find that they are too.