The purpose of this piece is to set out five questions a board can put to management before approving a transformation, and to explain what each one is intended to reveal in terms of the eight capability domains and the three enterprise principles. I write it as a Graduate of the Australian Institute of Company Directors who has also worked on the delivery side of transformation, and I am conscious that those two vantage points do not always agree about how much detail a board should ask for.

It is a well-established principle that boards govern and management manages, and a board that asks for operational detail risks undermining the executives it has appointed. I would not dispute that, and nothing below is intended to. The argument here is that a board’s questions are also its principal instrument of oversight, and that a transformation is the kind of decision where the quality of the questions asked at approval largely determines what the board will be able to see once delivery has begun.

Why approval is the moment

Research by Deloitte and NACD, discussed in an article published in 2023, reported that 95 per cent of boards participate in early M&A strategy while 23 per cent stay involved in the later phases. The research comes from a United States body and concerns a particular kind of transformation, so I would not generalise from it too far. It points, though, to a pattern in which board attention is concentrated at the start and falls away as delivery begins. The Queensland Audit Office found something comparable in a public setting, reporting in its review of major infrastructure business cases that planned assurance activities were not consistently carried out and that three of the business cases lacked a log showing how reviewers' concerns had been addressed. Together these support, without proving, the view that the board's best opportunity to shape its own oversight is before the program starts.

The five questions

1. What problem is this solving, and how will we know it has been solved?

This question tests Purpose and Objectives and Data. A good answer describes a measurable change in how the organisation performs, and not only the delivery of a system or a structure, and it names who will own the benefit once the program has finished.

What to listen for

An outcome stated in terms of the organisation and not of the program; a baseline against which the change will be measured; and a named owner for the benefit after delivery.

2. Can this be traced to our strategy, and who holds the decision rights?

This question tests Enterprise Traceability and Governance. It asks whether the program serves a stated strategic objective, and who has the authority to resolve a conflict between the program and the day-to-day business when one arises, as it usually does. A short way to test traceability is set out in The traceability test.

What to listen for

A line from the strategy to the program that does not rely on the sponsor’s recollection, and a clear answer, in advance, on who decides when the program and the business compete for the same people.

3. What do we know about where the organisation is starting from?

This question tests Operating System Configuration. Proposals frequently rest on a description of the current state taken from documents, and the current state as it is actually run may differ from it, as described in What an operating system is.

What to listen for

A baseline across the capability domains drawn from evidence and not from assumption; an acknowledgement of what is not yet known; and an indication of whether anyone independent of the program has looked.

4. What else will change, and who owns the boundaries?

This question tests Capability Interaction Design, and it covers the interface between the program and the business that has to keep running while it is delivered. The method is described in What else will change?

What to listen for

Named flow-on effects in the domains other than the one primarily changing; an honest estimate of the business’s capacity to absorb the change; and an owner for the boundary between the program and business as usual.

5. Who will tell us the truth between milestones?

This question tests Information Flow and the independence of what reaches the board. Program reporting is usually produced by the people running the program, who have understandable reasons to present it favourably, and a report that has been green for several months is uncomfortable to turn amber.

What to listen for

A line of sight to the program that is independent of its own reporting; a description of how bad news is expected to travel; and what the board will see each month beyond a summary status.

Two views on how far a board should go

Some directors will regard these as too probing for a board, and would prefer to rely on the executive and on the audit and risk committee. That view has real force, because a board that inspects work can displace management's accountability for it. The other view is that a board approving a transformation carries accountability for the decision and cannot discharge it from summaries alone. I think the two can be reconciled by asking of management's information systems and not of the work itself, so that the board asks management to show how it would know, and not to show the work.

What to ask management to bring to the next meeting
  1. A one-page baseline of the operating system across the eight capability domains, with its evidence base and its known gaps.
  2. A line from the strategic objective to the program and its measures.
  3. A register of the flow-on effects identified, with an owner for each boundary.
  4. The name of the independent reviewer, and how often the board will hear from them.
  5. A description of what the board will see in the third month, other than the program’s own status report.

If a board's best opportunity to shape what it will see during a transformation is at the moment of approval, and if the questions it asks then determine whether the information it receives afterwards is independent, traceable and measured against a baseline, would it not be prudent to treat the quality of those questions as seriously as the quality of the business case they are asked about?

Continue reading
  1. The traceability test: five decisions, one question
  2. What else will change? Designing for flow-on effects
  3. Six symptoms that program risk has become an issue
Sources Referenced
Aaron Thomas
Principal, Systemic Advisory  ·  Enterprise Capability Integration  ·  Brisbane, Australia

Approving, or already inside, a transformation?

The Enterprise System Health Check is a two-day on-site assessment across eight capability domains, and it is one practical way to find out where to look.

Start a conversation