5.2 Leadership in Projects
Key Takeaways
- PRINCE2 7 moves away from command-and-control toward persuading, influencing and co-creation, reflecting the same collaborative values found in agile.
- Co-creation means users and key influencers work together with the project team in product design, producing outputs people actually want to use.
- Leadership is earned through influence and relationship management; authority is granted by a role. They are different and a Project Manager needs both.
- Effective project leadership keeps the team aligned with objectives and manages the key relationships that determine whether the project is supported.
- Regular feedback is a leadership mechanism: it surfaces disagreement early and keeps collaboration grounded in what users actually experience.
From command and control to co-creation
A defining shift in PRINCE2 7 is the explicit move away from command and control — the "I tell, you do" model — toward persuading, influencing and co-creation. The method acknowledges that modern projects, especially those delivering digital or service outcomes, rarely succeed when a Project Manager simply issues instructions. People support what they help create.
This shift is heavily influenced by agile ways of working, which PRINCE2 7 integrates rather than treats as a separate world. Three agile-influenced behaviours run through the People element:
- Collaboration — working across roles and organisations rather than throwing deliverables over walls.
- Co-creation — users and key influencers work with the project team in product design, not just receiving the finished product for sign-off.
- Regular feedback — short, frequent loops that surface disagreement while it is still cheap to fix.
What co-creation looks like
Co-creation is more than "consultation." In consultation, the project asks users what they want and then disappears to build it. In co-creation, users and key influencers sit alongside the team during design — reviewing prototypes, challenging assumptions, adjusting direction. The output is something the users feel ownership of, which dramatically improves adoption at closure.
Exam angle: A scenario where the Project Manager runs a workshop with end users and a senior business representative to redesign a screen together is illustrating co-creation. A scenario where the Project Manager emails a finished design for comment is illustrating consultation, not co-creation.
Leadership versus authority
PRINCE2 7 draws a clear line between leadership and authority, and exam scenarios test whether you can tell them apart.
| Authority | Leadership | |
|---|---|---|
| Source | Granted by the role | Earned through influence |
| Example | A Project Board chair can approve a stage because the role gives that right | A Project Manager persuades a reluctant supplier to re-prioritise work |
| When it fails | People comply minimally or escalate | People commit beyond what the role requires |
A Project Manager has limited formal authority — they rarely line-manage the team. They rely on leadership: managing key relationships, keeping the team aligned with objectives, and influencing stakeholders whose support the project needs. A Project Board member, by contrast, has real authority over stage approval and direction, but still benefits from exercising leadership rather than simply wielding the role.
What project leadership actually involves
Leadership in a project context is not a generic "be inspiring" activity. PRINCE2 7 frames it as a set of concrete behaviours:
- Managing key relationships — identifying the few relationships that most affect the project and investing in them deliberately.
- Keeping the team aligned with objectives — restating the goal, connecting day-to-day work back to outcomes, and addressing drift early.
- Creating conditions for collaboration — removing blockers between teams, making information visible, protecting the team from noise.
- Using feedback as influence — letting evidence from users do the persuading instead of relying on the Project Manager's opinion.
A useful diagnostic for exam scenarios: if the Project Manager is dictating a solution, that is command and control. If they are bringing the right people together to shape the solution, that is leadership through co-creation.
When authority is still needed
The shift toward influence does not abolish authority. PRINCE2 7 still gives the Project Board real decision rights — stage approval, direction-setting, tolerance escalation — and the Project Manager still has authority over certain project management decisions. The point is that authority alone is insufficient for the people-dependent parts of a project: getting a reluctant operational manager to adopt a new process, persuading a supplier to share information they would rather hoard, encouraging a team to surface bad news early. These are leadership problems, and they are solved through relationships and influence, not through the organisational chart.
A healthy project uses authority for what it is good at (clear decisions, escalation, accountability) and leadership for what authority cannot reach (commitment, openness, willingness to change). Scenarios that show a Project Manager relying on authority where influence was needed — or, less commonly, relying on influence where a stage decision was actually required — are testing whether you can tell the two apart.
Leadership behaviours to recognise in scenarios
- Inviting users into design workshops rather than sending finished designs for comment.
- Sharing user feedback with the team and letting the evidence make the case.
- Naming a conflict explicitly and working it through rather than letting it fester.
- Protecting the team from stakeholder noise so they can focus on the objective.
- Restating the objective when the team drifts, rather than issuing new tasks.
The cost of getting this wrong
The Practitioner exam often frames leadership choices as trade-offs with visible consequences. A Project Manager who defaults to command and control will typically see three symptoms during the project: team members stop bringing problems forward, suppliers do the minimum the contract requires, and user representatives disengage from design. By the time these symptoms appear in a scenario, the leadership failure has already happened — usually at the point where the Project Manager chose to dictate rather than co-create. The correct exam answer is rarely to "escalate" or "re-issue instructions"; it is to change the leadership approach, bring the right people back into the room, and rebuild the collaboration that the dictating behaviour broke.
A Project Manager emails a finished process redesign to the operational team for written comments, then incorporates the comments into the next version. Which behaviour is this, and what would co-creation look like instead?
A Project Manager has no line-management authority over the supplier team but persuades them to re-prioritise a dependency by sharing user feedback and connecting the change back to the project objective. What does this illustrate?