Target picture and boundaries
Target state, explicit non-goals, one to three verifiable benefit statements. Plus the question of who owns the target picture — one person, not a committee.
Program & Transformation
Setting up a transformation program that stays controllable.
Most programs do not become uncontrollable in delivery but during setup. Whatever is not decided in the first few weeks costs a multiple of that later.
TopicSetting up a program
Reading timeapprox. 8 minutes
For whomClients, program leadership, PMO
Last updatedJuly 2026
In brief
A program is controllable when four things are in writing.
First: the target picture, worded so that it is clear what does not belong. Second: the structure — which workstreams there are and who is accountable for each. Third: the decision paths — which body decides what, at what cadence, on what paper. Fourth: the dependencies on everything that lies outside the program.
If one of them is missing, what you get is not a program but a collection of projects with a shared name. The difference only shows once the first dates collide — and catching up then is expensive.
A target picture says what does not belong.
A target picture that only describes what is meant to get better is worthless, because nobody can disagree with it. It becomes usable only through the counter-check: which obvious expectation does this program expressly not meet? If that question is not answered during setup, everyone involved will answer it later, quietly, for themselves — and differently.
A simple format has proven itself in practice: one paragraph on the target state, one paragraph on non-goals, and for each non-goal a line on where that topic belongs instead. That takes the edge off the boundary, because it does not take anything away from anyone but places it somewhere.
The second part is the question of benefit: how will you tell in twelve months that it was worth it? Not as a catalogue of metrics, but as one to three verifiable statements. Anyone who cannot formulate those statements does not yet have a program but a budget.
The four building blocks of setup.
In this order, because each building block is a precondition for the next.
Structure and accountability
Which workstreams are there, what does each deliver, who owns it? A workstream without a named person is not a workstream. Better a few clearly cut workstreams than a fine-grained structure nobody can oversee.
Decision paths
Which body decides what — on what paper, at what cadence, and who may decide between meetings? The last point determines the pace of the program.
External dependencies
Everything the program needs but does not control itself: other initiatives, operations, procurement, service providers, the works council, regulatory deadlines. Each dependency with a contact and the state of the commitment.
The questions that have to be answered during setup.
This list is short, yet it is rarely answered in full. Every unanswered question comes back later as a conflict:
- Who decides when two workstreams want the same thing? Without that answer, the loudest voice decides.
- What happens if a workstream does not deliver? Do you wait, replan, or cut scope? Agreeing the rule beforehand is easier than doing it in a conflict.
- Who may decide between committee meetings, and up to what size?
- What is the smallest sensible first step? A program whose first visible benefit is eighteen months away loses support before it arrives.
- How do you tell that the target picture no longer holds? Programs run for years; target pictures rarely last that long. You need an agreed trigger for reviewing them.
- Who takes over operations at the end? That answer belongs in the setup, not in the rollout.
Governance does not mean more committees.
The most common reflex during setup is to create control through meetings: a steering committee, a program board, an architecture board, weekly alignment calls. The result is activity, not control. If a topic passes through three committees before anything is decided, the lead time of a decision is longer than the sprint waiting for it.
Usable governance answers three questions and nothing else: who decides what? How does this body know that it is able to decide — that is, what paper does it need? And what happens if it does not decide? The third point is almost always missing, and it is exactly what causes the quiet delays.
A rule of thumb from practice: for every body you set up, you should be able to name which decision was actually taken there in the past four weeks. If that is not possible, it is an information meeting — and then it can be a document instead.
Four mistakes when setting up.
Structure along the org chart
Workstreams are cut along departments instead of results. Then every dependency runs across an organisational boundary, and the program mainly administers itself.
Target picture without non-goals
Without explicit boundaries the scope grows invisibly, because everyone involved assumes their own topic is included. Scope creep rarely comes from decisions, mostly from assumptions.
Plan before commitments
A schedule that contains effort nobody has committed to is a wish list with dates on it. First the commitment, then the date.
Operations comes later
If you do not involve the future operating unit during setup, you build in requirements that will not hold up in operations. That surfaces at the end, when it is most expensive.
Are you setting up a new program?
Describe the target picture, the people involved and the intended role. You will get an assessment of which of the four building blocks are still open in your case.
Discuss your project