MSP Foundation study materials
MSP Foundation study resources

MSP Foundation: MSP Principles - the seven enduring behaviours of a programme

MSP Foundation · Work through your exam, one topic at a time.

All guide sections

MSP Principles - the seven enduring behaviours of a programme

The principles are the guiding rules of behaviour for everyone involved in a programme. They are not processes, documents or stages, and they do not produce deliverables - they shape how the programme's work is done, from the first mandate conversation to closure. In the current MSP edition there are seven, and a candidate should be able to match each to a scenario:

  • Lead with purpose - a clear, compelling reason for the programme that people can commit to.
  • Collaborate across boundaries - working beyond project, function, supplier and organisational silos.
  • Deal with ambiguity - making sound decisions with incomplete information rather than waiting for certainty.
  • Align with organisational priorities - the programme serves the wider strategy, not its own momentum.
  • Deploy diverse skills - assembling varied capability, background and perspective.
  • Deliver measurable real benefits - benefits must be defined, owned and evidenced, not assumed.
  • Bring pace and value early - incremental value, learning and momentum rather than one big-bang delivery.

Traps in questions

  1. Principles vs. processes. If an answer option describes a document, a review gate or a role, it is unlikely to be a principle.
  2. Principles vs. themes/practices. Governance, risk and benefits management are practices; the principles are the behaviours underpinning them.
  3. Near-miss distractors. "Focus on deliverables" sounds plausible but is not a principle - MSP principle language centres on benefits and purpose.
  4. Situational matching. Questions describe a behaviour and ask which principle it illustrates; read for the action taken, not the topic.

Rule of thumb

Ask: does this describe a way of behaving, or a thing to produce? Behaviour → principle. Product → practice or document. Worked example: two projects in a programme are duplicating a customer-data build because they sit in different divisions. The Programme Manager brokers a joint design forum and a shared standard. That demonstrates collaborate across boundaries. The distractor answer "deal with ambiguity" would only fit if the issue were a decision taken without complete data.