The keys to a successful EPM solution: start small, end big
· EPM
EPM projects rarely fail at go-live - they fail in month three, quietly, one offline spreadsheet at a time. The delivery playbook that prevents it: a small first slice, a strong client-side lead, change management woven through, and scaling on patterns.
Most EPM projects do not fail at go-live. They fail a few months later, as planners drift back to offline spreadsheets.
I have written about preparing for an EPM project - the readiness work before anything is built. This post is the other half: the keys that make the delivery itself succeed. The idea is simple to state and hard to stick to: start from something small, and end with the big parts. Most projects do it backwards - they start with the big parts (platform, all processes, all entities) and never get small enough to work.
Think big, start small, scale fast - in that order
The order matters. Sketch the target architecture first: the dimension backbone, the data hub, the security model, the module map. One page. Then deliberately build only one thin slice of it.
The one-page big picture is what stops your MVP becoming a dead-end prototype - shared dimensions, naming conventions and the integration layer get designed for the end state even if only one cube uses them today. Teams that skip the big picture end up with three incompatible pilots. Teams that skip the small start end up with an eighteen-month waterfall nobody has seen working. You can ship one planning process in ten weeks, or shelf-ware in eighteen months; those are usually the actual options.
My rule: if you cannot draw the end state on one page, you are not ready to start the small piece. Mark the MVP slice on that page in highlighter, and go.
Pick the first slice by pain, not by ease
The right MVP is the process that hurts the most people most visibly - typically cost centre expense planning, a single-entity P&L forecast, or workforce planning. It must touch real data, real planners and a real decision cycle; otherwise it is a demo, not an MVP.
Resist the technically easiest module. An easy win nobody cares about buys you nothing at the steering committee. Score candidate scopes on two axes - hours of manual Excel pain eliminated per month, and number of senior stakeholders who personally feel that pain - and build the top-right quadrant first.
Then bank a quick win early. Within the first 30 days, show something running on the client's own numbers, live, no slides allowed in the meeting - even if it is one dimension loaded and one report rendering. Trust in an EPM programme is built almost entirely on demonstrated working software. Every early win extends your licence to make harder architectural decisions later without being second-guessed. The first release should be small and clearly useful.
Iterate with real users, and keep the model boring
Run one-to-two-week build cycles that each end with named business users clicking through the actual model. I hold a standing fortnightly "show and steer" with the same five to eight users, and every piece of feedback becomes a visible backlog item with a decision - do, defer or decline - within a week. Waterfall EPM fails in a predictable way: the spec was signed eight months ago by people who never saw a screen, and UAT becomes a renegotiation. The blend that works: fix the milestones and the dimension backbone waterfall-style, keep forms, reports and workflow agile inside those rails.
And keep the model boring early. Premature sophistication kills more EPM projects than missing features do. Phase one gets fewer dimensions than you think you need, driver-based logic instead of a replica of every Excel line item, and no clever rule where a simple form calculation will do. My threshold: no allocations, no exotic dimensions, no complex rules until the base model has survived two real planning cycles with live users. Complexity added to a trusted model is cheap; complexity removed from a distrusted one is nearly impossible, because someone always defends every attribute.
The people spine: project lead, sponsor, champions
Delivery-side success depends on a few key people, and each of these roles matters.
A strong client-side project lead is the single best predictor of success. One named person - usually a senior FP&A manager, not IT - who owns the backlog, makes scope decisions in days not weeks, and has the credibility to tell a department head "no, not in phase one". When the consultant plays proxy product owner, every decision becomes a negotiation and the client never develops ownership of their own model. The role costs 30-50% of that person's time during the build; get it agreed and backfilled up front, in writing. If the client cannot name this person, that is the project's biggest risk, and it belongs in the risk log by name.
Sponsorship is a delivery activity, not a kickoff slide. The sponsor's job does not end when the SOW is signed - it is to clear cross-departmental blockers (data access, IT priorities, reluctant department heads) all the way through. I put the sponsor on a monthly 15-minute cadence with three fixed agenda items: one win to communicate, one blocker to remove, one decision to make. Two consecutive empty agendas means the project is drifting - escalate.
Change management is woven through the build, never bolted on. It is not a training deck in the last two weeks; it is users co-building from week one. Recruit a named champion per department before the build starts and give them early access to every iteration - planners trust a colleague who says "this works" far more than any consultant. Every user who sits in a show-and-steer session has already accepted the change by the time you go live. Then train around real tasks at real timing, and sit next to users during the first live cycle, because that is where "trained" becomes "able".
And expect the master data fight. The tool is rarely the problem - the cost centre hierarchy nobody owns is the problem. An EPM project forces the organisation to agree, often for the first time, on a single entity structure and account hierarchy, and projects stall not on platform skills but on whose hierarchy wins. Name a business owner per shared dimension early, with a change process and an SLA, and budget real calendar time for the argument.
Go-live is the midpoint
The first live planning cycle always surfaces what no UAT can: real deadline pressure, real volumes, real users doing unexpected things. Plan for it instead of being surprised by it:
- Hypercare: two to four weeks with the build team on standby and same-day fixes.
- A funded release 1.1, four to eight weeks after go-live, batching the inevitable "now that I use it daily" requests. Put it in the original SOW, not a hoped-for change order. Projects that hard-stop at go-live teach users that feedback is pointless, and they quietly drift back to Excel.
- Adoption metrics from day one. Excel is your real competitor, and adoption numbers are your early-warning radar for a shadow-spreadsheet relapse. I track: active planners versus licensed users, share of plan input entered directly versus uploaded from offline files, forecast cycle time versus baseline, and the count of known offline workbooks still feeding the process. Put two of those numbers in the steering deck every month for the first year.
Delivering cubes is output. The outcome that matters is spreadsheets being retired.
End big: governance, a centre of excellence, a roadmap
The small start earns you the right to build the big organisational pieces - and they are what keep the platform alive after the consultants leave.
- Scale on patterns, not heroics. Before module two, hold a refactor gate: list what in the MVP was expedient versus what is a keeper pattern, and pay down that debt while it is one cube's worth. Each new module - sales, HR, capex, consolidation - should be cheaper and faster than the last; if module three costs the same as module one, you are rebuilding instead of reusing, and that is an architecture smell.
- Stand up lightweight governance: who owns each dimension, who approves model changes, what the release cadence is. (This is also where the custom register lives.)
- Grow a centre of excellence. A CoE is not a team you hire - it is the project team you already grew, formalised. Train the internal admin during the build, not after: in the final phase, run a skills-transfer audit and confirm a named internal person has performed every recurring task (loads, dimension maintenance, new reports, security changes) unassisted at least twice.
- Keep a living 12-18 month roadmap that steering reviews quarterly. The end state is not a bigger model - it is an organisation that can keep evolving its own model.
The whole arc
Prepare properly (the readiness post). Run a discovery that decides the design, and design small, clean cubes. Make the standard-versus-custom call per requirement. Then deliver it this way: think big on one page, start embarrassingly small, show working software in 30 days, iterate with real users, keep the model boring, hold the people spine tight - project lead, sponsor, champions - treat go-live as the midpoint, and end big with governance, a CoE and a roadmap.
Users do not adopt an architecture. They adopt a screen that saves them time - and once that happens, module by module, the architecture gets adopted too.