MSP Foundation study materials
MSP Foundation study resources

Releasing Half a Capability Early

MSP Foundation · Put your knowledge to work in context.

All case studies

Releasing Half a Capability Early

A bank's programme to create a single customer view has a blueprint covering five target operating-model areas. The change team is under pressure to release the new data warehouse to marketing eight weeks early, in tranche 2, because marketing has a contractual campaign commitment. Testing shows the customer-matching logic works for individual retail customers but produces duplicate records for joint accounts, roughly 11% of the customer base. The blueprint's definition of a single customer view explicitly includes joint accounts. Marketing argues duplicates are acceptable because the campaign targets individual retail customers. The programme's £14m benefit comes from reduced mailings and improved cross-sell - both of which depend on deduplication.

1. Should the programme manager approve the early release? Give your reasoning.

Read the worked answer

Conditionally, and only if the release is a coherent subset rather than a known-defective whole.

The deciding question is not 'are duplicates acceptable to marketing?' but 'does this release create a capability, or create a debt?' Three tests:

  1. Can the defect be excluded at source? If the marketing extract is restricted to individual retail customers and joint accounts are filtered out before load, no duplicate leaves the building. That is a subset of the blueprint capability and is defensible. If duplicates go out and marketing simply promises not to mind, it is not.
  2. Does the benefit survive? The £14m depends on deduplication. Releasing a warehouse with an 11% duplicate rate into the base may entrench a figure that later undermines cross-sell modelling - and re-keying customer records after the fact is far more expensive than waiting eight weeks.
  3. Is this a defect or a design flaw? If matching joint accounts is genuinely hard and unsolved, the blueprint's definition may be wrong, and that is a board decision, not a project one.

Conditions if approved: joint accounts excluded at source; the deviation logged with a named owner and a fix date; the fix funded and scheduled, not hoped for; campaign restricted in writing; benefit measurement scoped to the clean base. Approved on those terms, an eight-week early release is good value. Approved without them, the programme has converted a marketing deadline into a permanent exception.

2. Who should decide, and what does the programme manager owe the decision-maker?

Read the worked answer

The decision belongs to the programme board (or the blueprint owner acting under delegated authority), because it is a deviation from an approved blueprint with a benefit implication. The programme manager's job is to make it decidable.

What is owed to the board:

  • A clear statement of what is being varied - the 'single customer view' as defined includes joint accounts; the proposal delivers a narrower view.
  • Options with consequences: release restricted; release unrestricted; hold to the blueprint date; change the blueprint definition permanently.
  • The benefit arithmetic, showing whether £14m is at risk, delayed, or unaffected under each option.
  • A recommendation with a reason.

What the programme manager must avoid is a quiet project-level waiver. Deviations from a blueprint that are agreed informally tend to reappear two tranches later as 'the way things are', at which point the blueprint no longer describes the organisation and the benefits case has no referent. The value of logging the deviation is not bureaucracy - it is that it forces someone senior to own the exception and gives the programme a trigger for closing it.