An agile EPM approach reduces risk, gets to value faster, creates less waste, and is more likely to make your stakeholders happy. So why build your EPM system any other way?
When we listed in a recent blog article the top ten reasons why EPM projects fail, one of the reasons we listed was “scope creep” — and one of the reasons for listing it, we wrote, is that scope creep undermines agile. That might seem like a contradiction since both scope creep and agile are about doing things incrementally — which is true. But where agile is about doing one small piece of a project during a sprint (that lasts typically two to four weeks), scope creep is about taking on additional little pieces before the sprint is even over.
In other words, with scope creep it often becomes “let’s make it up as we go” project plan. But with agile, stakeholders know up front what they should get, project teams know up front what they should deliver, and the wait is short until the deliverable arrives — when both sides get to see what’s the difference. Differences might exist because people misunderstand each other or because stakeholders now realize they want something they did not originally request. But regardless of the reason, those differences become input for the next sprint’s deliverable. And the cycle continues until the entire EPM project is done.
Agile teams would rather see lots of these small course corrections over the project’s life than end up at the wrong destination after weeks or months of work. With agile, that’s not likely to happen and here’s why:
Greater Stakeholder Collaboration
The fact that stakeholders and project teams meet before the start of each sprint (and that there are lots of sprints), both to define the next deliverable and to assess progress on the one just completed, forces a high degree of collaboration between the two sides. That continuous collaboration makes stakeholders and project teams work more as partners, so they have a shared agenda and shared interests, which increases the likelihood of better outcomes.
Continuous Team Collaboration
What applies between stakeholders and project teams also applies to the various functional groups within a project team — i.e., there’s greater collaboration across the project value chain of project leaders, system designers, implementation consultants, and quality assurance specialists. Why is that so? It’s because each sprint, by definition, must deliver something that teams can show the client. It may be a small thing, but it’s got to be a complete thing — in other words, a complete report, a complete part of an interface, a complete function — that actually works. Business stakeholders are not going to want to inspect source code. And because there is more technical interdependence between team roles, there is also more day-to-day personal interaction and shared vision among team members — in other words, continuous collaboration.
All that collaboration, both between stakeholders and project teams, and between project team members themselves, helps explain other agile benefits.
Greater collaboration ensures greater accountability. On a daily basis each team member’s contribution (or lack thereof) is highly visible to colleagues — all of whom realize that their contribution (or lack thereof) will be highly visible to business stakeholders at the end of the sprint — just a few days away. That’s one reason why there will be less waste. Another reason is improved communication. By working more interactively within shorter work-assess-plan cycles, people have less opportunity to go off in the wrong direction before they are pulled back on course by the sprint’s feedback loop.
Because stakeholders judge progress based on what they see working — as in what you see is what you get (WYSIWYG) — they can provide meaningful feedback to the EPM project team. That way the problem of technical people (who speak technology) unable to communicate with business people (who speak business) is avoided. The customer can actually point to features and functions on screen and describe what they want with much greater clarity than if they had to rely on words alone. Of course, another way to enhance communication is to have actual functional experts on the project team working alongside technology experts — a cloud EPM consulting best practice.
Faster Time to Value
Continuous collaboration, less waste, and WYSIWYG communication add up to faster time to value, which translates:
- Fewer missed business opportunities
- Greater strategic use of capital
- Agile business decision making
In other words, faster time to value are the very reasons why organizations decide to implement enterprise performance management in the first place.
Ultimately, agile’s lesson is that how you implement your EPM system (and therefore whom you select as your EPM implementation team) is just as important as what EPM features and functionality you decide to implement. Choose agile, and many other project success factors will fall into place.
Strafford's breadth of skills has enabled us to provide consulting and EPM advisory services for small to medium sized operations as well as to larger Fortune 500 environments. With over a decade of experience guiding clients through strategic initiatives and supporting routine, day-to-day management, Strafford can help free up your IT resources and give finance more control over their own solutions.