GaneevEcoA simple effort-versus-impact framework
Score each candidate use case on two axes: how much time or cost it currently consumes across the organization (impact) and how straightforward it is to actually implement well given your current data and systems (effort). The best starting use cases are consistently high-impact, low-effort — not the most ambitious idea in the room, and not necessarily whichever executive happened to ask about it first in a leadership meeting.
This simple framework does something valuable beyond just producing a ranked list — it gives every department a fair, transparent way to see how their proposal was actually evaluated, which considerably reduces the perception that prioritization decisions are political or arbitrary. A department whose idea scored lower can at least see clearly why, on criteria that applied equally to everyone else's proposal too.
What skews this in practice
- The most vocal department isn't necessarily where the most time is actually being wasted — that's exactly what structured department interviews are for, rather than trusting whoever advocates most persuasively in a meeting.
- "Impressive to demo" and "valuable day to day" are frequently different use cases — prioritize the second over the first, even when the first would look more exciting in a leadership presentation.
- A small, well-executed first win builds more organizational trust than an ambitious one that stalls halfway through, however much more impressive the ambitious version would have sounded at the outset.
How to actually run this exercise with a group
The most productive version of this exercise involves the actual people closest to each candidate task, not just department heads working from secondhand descriptions. A frontline team member usually has a far more accurate sense of how much time a task genuinely costs and how disruptive a given solution would be to implement than a manager describing it at one remove, and involving them directly tends to surface a more honest, more useful scoring session.
It's worth running this as a live, facilitated session rather than a survey people fill out independently and submit. The back-and-forth discussion that happens when people compare their scoring of the same use case out loud often surfaces disagreements worth resolving directly, and those disagreements are frequently more informative than the final numeric scores themselves.
It's worth revisiting the prioritized list itself every quarter or so as circumstances change, rather than treating the initial ranking as fixed permanently. A use case that scored lower initially might become considerably more attractive once an adjacent piece of groundwork is completed, and a list that's periodically refreshed tends to stay genuinely useful for planning much longer than one frozen at a single point in time.
It's also worth keeping a visible record of use cases that scored well but weren't selected for the current phase, rather than letting them disappear once the initial prioritization exercise concludes. That record becomes valuable input for planning the next phase of the rollout, and it also reassures the department whose idea wasn't chosen first that their proposal was genuinely considered and remains on the table, not simply dismissed and forgotten.