How to prioritize business transformation initiatives

Each initiative arrives with an advocate, a plausible benefit, and a reason it cannot wait. None of those is unreasonable, and together they produce a portfolio that exceeds what the organisation can absorb. The usual response is to add governance: a steering group, a scoring model, a benefits tracker.

Prioritisation is a decision about sequence, and sequence implies refusal. A ranking that leaves every item funded has not prioritised anything; it has described the queue.

1. Dependency. What has to exist first? A costed pricing change needs reliable margin data; a new CRM stage model needs agreed definitions. Ranking an initiative before its dependency guarantees a rework cycle.
2. What it changes. Distinguish work that changes a system from work that changes how people behave. Both are real, and the second usually takes longer and needs different support.
3. Reversibility. A pilot in one team can be stopped quietly; a migration across the business cannot. Cheap-to-reverse items can be run in parallel with larger work precisely because the downside is limited.
4. Who has to be involved. Where several initiatives need the same two people, they are competing for the same capacity. That constraint is more binding than the budget in most mid-sized businesses.

A weighted score produces an order that looks objective and hides judgment about dependencies. A simpler approach is to sort into three groups: items that unlock others, items that stand alone and can be reversed, and items that are large commitments. Take one large commitment at a time, fill the space around it with standalone work, and settle the unlocking items first even where their own return is modest.

Where an item is hard to place, ask what would have to be true for it to be obvious. The answer is usually a dependency that has not yet been named.

• Name the people each initiative needs, by role, for each phase.
• Check the total against a normal week, not an ideal one.
• Identify what will not happen while this runs, and say so explicitly.
• Set a review point where the initiative's assumptions are checked, not only its milestones.

The most useful output of this step is a short list of what the business is deliberately not doing this period. Without it, capacity is quietly borrowed from operations, and the cost appears as service problems somewhere unrelated.

Initiatives tend to accumulate consensus ownership, which in practice means nobody is accountable when a decision is needed in week six. One named person per initiative, with the authority to make scope calls and the obligation to report honestly, is more useful than a steering group that meets monthly. The steering group's role is to change the portfolio, not to run the work.

Where decisions keep returning to the group, the underlying problem is usually unclear decision rights rather than insufficient governance. The notes on decision rights and delegation cover how to settle that.

The example below is hypothetical and describes a pattern rather than a client engagement.

• Sequencing slows visible progress. Deferring a high-profile initiative in favour of unglamorous prerequisites requires explaining, and the explanation is easier when the dependency is documented.
• Dependencies are estimated. Some turn out not to be real, and some emerge later. Quarterly review limits the cost of being wrong.
• Capacity estimates are political. Teams understate the room they have when they want to avoid work and overstate it when they want to start something. Comparing estimates against the last period's actuals is the check.
• Some initiatives are not optional. Regulatory or contractual work sits outside the ranking and has to be slotted in as a fixed constraint.

Prioritising and sequencing transformation work is the substance of the Strategy & Transformation capability. Where the ranking produces a portfolio that needs someone to run it, the notes on the first 90 days of a fractional engagement cover how that work usually starts.