MSP Foundation common mistakes
MSP Foundation · Understand the traps and how to avoid them.
Reciting the principles as a sequential lifecycle - for example, picking an option that says 'lead with purpose' must be completed before 'collaborate across boundaries' can start, or that a principle is satisfied at a single gate.
The principles are presented as a short list, so candidates mentally map them onto a stage model and look for 'first/then' answers.
What to do instead
Treat each principle as a continual lens applied across every tranche and activity. Test each option by asking whether it describes ongoing behaviour rather than a phase that can be completed.
Defining a programme as 'a very large project' or simply 'a group of related projects', and choosing answers that emphasise size, duration or project output over benefits and tranches.
In many workplaces 'programme' is used informally for any big project, so everyday language overrides the framework definition.
What to do instead
Anchor every definition on the MSP idea of a temporary, flexible organisation created to coordinate, direct and oversee related projects and activities in order to deliver benefits. Reject options that define a programme only by scale or by a list of projects.
Treating tranches as project phases or fixed calendar periods, and selecting answers that say a tranche ends when a phase is complete rather than at a tranche review.
Phase and stage models are more familiar, and 'tranche' is an unusual word, so candidates substitute the phase model they already know.
What to do instead
Remember that a tranche is a grouping of projects and activities managed together to deliver a defined set of benefits, and that it concludes with a tranche review that assesses benefits achieved and readiness to proceed.
Mixing up the Senior Responsible Owner and the programme manager - for example, saying the programme manager owns the business case and is accountable for benefits realisation.
Both roles are senior and the titles vary between organisations, so candidates assign accountability to whichever role sounds more 'hands-on'.
What to do instead
Keep the accountability split clear: the SRO is accountable for the programme and its business case, including benefits realisation; the programme manager leads the programme day to day, manages the team and coordinates delivery of the blueprint.
Treating stakeholder engagement as one-way communication and choosing 'produce a communications plan' as the main response to an engagement question.
Engagement sounds like communications, and many organisations conflate the two in practice.
What to do instead
Look for two-way, relationship-based answers: identifying stakeholders, understanding their impact and concerns, involving them in design and benefits realisation, and adapting engagement to their influence and interest.
Assuming that leading change is solely the programme manager's responsibility, and ignoring the roles of business change managers and operational managers in embedding change.
Candidates focus on delivery roles and forget that benefits are realised in the business after projects deliver outputs.
What to do instead
Distribute leadership of change: the SRO sponsors, business change managers prepare and support the business, operational managers embed the change, and the programme manager coordinates. Select answers that involve the business, not only the programme team.
Confusing the vision with the blueprint - for example, choosing 'the vision describes the target operating model and the blueprint is the inspiring statement'.
Both describe the future, and exam options deliberately swap their characteristics.
What to do instead
Separate them by purpose and form: the vision is a short, inspiring statement of the future state; the blueprint is the structured model of the future capabilities, processes, information, organisation and technology needed to achieve it.
Treating the blueprint as only a target-state model and overlooking the current state and the gap between current and target.
Design documents in practice usually focus on the future, so candidates assume the blueprint is only a 'to-be' picture.
What to do instead
Remember that the blueprint covers the current state, the target state and the gap, and that it is used both to design the programme and to define what benefits depend on.
Answering business case questions as if the business case were only a financial justification produced once at the start to obtain funding.
In many organisations the business case is an approval document, so candidates do not associate it with ongoing benefits and tranche reviews.
What to do instead
Treat the business case as a living document covering benefits, costs, risks and timescales, updated as the programme progresses and reviewed at tranche boundaries alongside the benefits profile.
Confusing programme risk with project risk - for example, selecting 'the programme risk register contains all project risks' or 'every project risk must be escalated to the programme'.
The programme-project hierarchy suggests that risks should simply aggregate upwards.
What to do instead
Keep risk ownership at the right level: projects manage risks to their own objectives, while the programme manages risks to benefits, the blueprint and tranches. Escalation should be threshold-based, not automatic for every risk.