Align Stakeholder Expectations

Introduction

This lesson covers Task 1.5 of the People domain of the July 2026 PMP Examination Content Outline (ECO), a domain that carries 33% of the scored questions. Lesson 4 showed how to identify and engage stakeholders. This lesson focuses on a narrower and very practical problem: different stakeholders expect different things from the same project, and many of those expectations are never written down. Expectations that are not discovered and aligned early appear later as disputes at acceptance, as scope creep, or as disappointment about a result that technically meets the requirements. The exam describes such situations and asks how a project manager categorises stakeholders, finds out their expectations, facilitates alignment and uses mentoring to develop people.

After this lesson you will be able to categorise stakeholders, identify expectations explicitly, run alignment discussions and workshops, and organise and act on mentoring opportunities.

Learning objectives

• Categorise stakeholders in ways that support the alignment effort.
• Elicit stated, unstated and conflicting expectations using several techniques.
• Prepare and facilitate an alignment discussion or workshop that ends in documented agreements.
• Distinguish expectations, requirements and objectives, and treat each properly.
• Organise mentoring opportunities for team members and stakeholders and act on what they reveal.
• Recognise when misaligned expectations must go through change control or escalation.

1. Categorise stakeholders

Categorising stakeholders turns a long list into groups that can be handled with the same approach. The categories used for alignment are different from the power/interest grid alone, although they build on it:

Categorisation is useful because it makes visible where conflicts of expectation are likely. For instance, the finance department (cost-focused) and the product team (feature-focused) are different on the dimension "type of expectation"; the sponsor and the operations director may differ in "impact of the project" if the project moves budget and staff between them. The project manager can then arrange the alignment sessions by pair of groups that disagree, rather than lumping everyone into a long general meeting.

2. Identify stakeholder expectations

An expectation is what a stakeholder believes will be true when the project is done: features, quality, timeline, cost, ways of working, even the amount of involvement they will have. There are three kinds:

• Stated expectations: written in the contract, charter or requirements.
• Unstated expectations: obvious to the stakeholder, never said ("of course the new app works offline", "of course the old data is migrated").
• Assumed or conflicting expectations: held by two stakeholders who do not know that they disagree.

Unstated expectations are the greatest danger because they surface at acceptance. Techniques to bring them out:

Expectations should be recorded in a form that can be traced: the stakeholder, the expectation, its priority, whether it is already a requirement, and its status (agreed, to negotiate, rejected, out of scope). This record may sit in the stakeholder register, the requirements documentation or the backlog.

Example: a hidden expectation found with a prototype

An insurance company commissions a claims portal. The requirements say "customers can submit a claim online". During a clickable-prototype session, a claims handler asks, "Where do I see the photos at the same time as the form?" Nobody had written that the handlers expected a split screen with the customer's photos. The prototype brought out an unstated expectation, which the team converts into a requirement and a user story before development. Finding it in week six cost two days; finding it at acceptance would have cost several weeks.

3. Facilitate alignment discussions and workshops

When expectations differ, the project manager (or a neutral facilitator) leads a structured discussion. A good alignment session has five parts.

1. Prepare. Define the purpose ("agree on the release-1 scope and success measures"), invite the right people (those with decision rights and those affected), share a short pre-read, and gather the known expectations in advance. Meet very senior or sensitive stakeholders beforehand to avoid surprises.
2. Open. Restate the objective of the project and the purpose of the session, set ground rules (listen, speak about interests, decisions recorded), and agree how decisions will be made.
3. Surface. Ask each group to state its expectations and success criteria, and make them visible: sticky notes, a shared board, a table. Ask for the reasons ("Why is that important?"), because positions hide interests.
4. Align. Group the expectations, find overlaps and conflicts, and compare with the objectives, the constraints (budget, time, regulation) and the business value. Use prioritisation methods such as MoSCoW (must, should, could, won't), weighted scoring, or voting with dots. For conflicts, search for options that satisfy both interests; if impossible, apply agreed criteria or escalate to the person with decision rights.
5. Close. Summarise the agreements and open points, assign owners and dates, send minutes within a day, and obtain confirmation in writing from the decision makers.

Facilitation skills the exam values: staying neutral, managing dominant speakers, drawing out quiet participants, keeping time, reframing blame as problems to solve and testing for understanding ("Can you tell me what you heard?").

Worked example: aligning expectations for a release

Scenario. A software company builds a subscription-billing platform for a telecom client. The sponsor wants go-live in four months to catch the sales season. The finance director expects automatic tax calculation in 12 countries. The customer-care head expects a self-service portal. The development lead says the three cannot all fit in four months. Each stakeholder has said privately that their item is "essential", and each assumes the others will give way.

Step 1 - Prepare. The project manager collects estimates, categorises the expectations (time, functional/finance, functional/service), and checks the contract and charter: the contract mentions billing and tax for 3 countries, and a "customer portal" without detail. He meets the sponsor beforehand to confirm that the deadline is a business target and to learn what is flexible.

Step 2 - Run the workshop. All three attend with the development lead. The facilitator asks each stakeholder to explain what happens if their item is absent at go-live. Findings: tax calculation in the three contracted countries is needed for the first invoices; the remaining nine countries start billing only in month nine. The self-service portal is needed to reduce call volume, but a basic version (view invoice, update address) covers 70% of the expected calls.

Step 3 - Align. The group uses MoSCoW: must have = billing for the 3 countries and invoice viewing; should have = address update; could have = remaining features of the portal; later release = tax for nine other countries. Capacity estimate: the plan fits within four months with a 15% buffer.

Step 4 - Close. Minutes are issued the same day, the scope baseline and backlog are updated through change control (the contract only required three countries), and the sponsor confirms by email. A review is set for the end of month two.

Why not other choices? Letting the sponsor decide alone would have ignored legitimate needs and probably produced complaints later. Promising everything and relying on overtime would have created risk of failure and quality issues. Negotiating privately with each stakeholder would have kept the conflicts hidden. The workshop exposed the interests behind the demands and led to a documented compromise.

4. Expectations, requirements and objectives

These three terms are tested together and are often confused:

An expectation that is not a requirement is a risk for satisfaction. The project manager can convert it into a requirement (if it is valuable and affordable, through change control), adjust it (explain the limits, show alternatives), or decline it (with reasons, documented). Silence is never a strategy: a stakeholder who is not told that an expectation will not be met will assume it will be.

Also separate expectations about the product from expectations about the project: for example, how often a stakeholder wants to be consulted, how decisions are communicated, how quickly issues are escalated. These process expectations belong in the communication and stakeholder engagement plans and in the team agreement.

5. Organise and act on mentoring opportunities

Mentoring is a relationship in which a more experienced person shares knowledge, perspective and encouragement with a less experienced one. It differs from coaching (focused on a skill or performance goal, usually shorter) and from training (structured instruction). In a project, mentoring has three practical roles related to alignment:

• Developing team members. An experienced engineer mentors a junior colleague on design decisions; a senior analyst mentors a new analyst on how to elicit requirements. The result is better quality and fewer misunderstandings about what stakeholders want.
• Building stakeholder understanding. The project manager or a senior team member explains the project approach to a stakeholder who is new to it: an executive new to agile, a user group unfamiliar with iterative delivery. Better understanding leads to more realistic expectations.
• Developing the project manager. Seeking a mentor, or being one, increases the leader's perspective and contacts.

To organise mentoring: identify needs (skills matrix, performance conversations, retrospective topics), match mentor and mentee on experience and style, agree on goals, frequency (for example 45 minutes every two weeks) and confidentiality, review progress, and recognise the mentor's time in the plan. To act on mentoring, use what emerges: a mentee may reveal that a stakeholder's request is misunderstood, that the team lacks a skill, or that a rule of the working agreement is unclear. The project manager follows up on such points, with the permission of the people involved and without breaking confidentiality.

Example: mentoring that changes an expectation

A new product owner from the business side expects the team to deliver every item of her 80-item wish list in the next quarter. Her mentor, a senior product owner from another unit, meets her every fortnight and shows her how to order a backlog by value and how to read the team's velocity chart. After a month she presents a prioritised list of 22 items with outcome measures to the stakeholders and explains why the rest will wait. The expectations of the stakeholders drop to a realistic level because the person representing them has learned how the system works.

6. Common pitfalls and exam tips

Pitfalls

• Assuming that a signed requirements document contains all expectations.
• Holding separate private conversations and never bringing opposing stakeholders together.
• Letting the loudest or most senior person define the expectation of the whole group.
• Agreeing in the meeting and not documenting or confirming.
• Accepting expectations beyond the scope informally.
• Treating mentoring as optional "nice to have" or confusing it with performance management.
• Giving stakeholders good news only, to keep expectations high.

Exam tips

• When the scenario reveals two stakeholders with conflicting expectations, the best answer usually brings them together in a facilitated session using objective criteria.
• If an expectation was not part of the approved scope, assess it and route it through change control.
• A prototype, a demo or an example is often the best tool to discover unstated expectations.
• When a stakeholder is new to the approach (for example, agile), explaining and mentoring is usually better than imposing.
• Always confirm the outcomes of an alignment session in writing.
• Distinguish a stakeholder who disagrees with the objective (escalate to governance) from one who disagrees with the way to reach it (negotiate and align).

7. Mini case study

Situation. You are managing a project to build a new e-learning platform for a university. The academic dean (sponsor) expects the platform to be ready by the start of the autumn term, which is in 7 months. The IT department expects to host it on the university's existing servers and to approve all design decisions. The faculty representatives expect to upload their own existing videos and tests without changes. Students' association members, interviewed for the first time in month two, say that they assume the platform will work well on phones and with low-bandwidth connections. The requirements document does not mention mobile use or hosting. The team estimates that adding full mobile support would add six weeks.

Question. What should you do?

Model solution.

1. Categorise. Sponsor (decision rights on scope and date), IT (constraint owner and approver of technical decisions), faculty (users and content owners), students (users and the largest group). Note the types of expectation: schedule, technical, functional, experience.
2. Record the unstated expectations (mobile and low-bandwidth use, hosting on existing servers, reuse of existing content) in the register, with the stakeholder and a proposed priority.
3. Prepare data. Estimate options: responsive web design for essential functions (two weeks), a native app (eight weeks), content conversion effort and the hosting constraints. Find out from the sponsor what is fixed (the date, the budget) and what can flex.
4. Facilitate an alignment workshop with the four groups. Ask each group about the consequences of not having its expectation met, use MoSCoW, and compare against the charter's objectives (improve access for students). Likely agreement: responsive design for the main functions in release 1 (should-have because it meets the objective), a native app later, existing content accepted in standard formats with a conversion service for the rest, hosting decision based on a short technical assessment by IT with the team.
5. Process changes. Update the scope, schedule and cost baselines through change control, because mobile responsiveness is new. If the sponsor cannot accept the delay, agree on what leaves the scope.
6. Document and confirm. Send minutes, obtain written approval from the sponsor and IT, and update the stakeholder register and communication plan. Schedule a review in six weeks and a demo with student representatives.
7. Support understanding. Pair the faculty representatives with a team member (mentor) who explains how content formats affect the platform.

Why this is best. It brings hidden expectations to the surface, aligns the conflicting ones with the facts and the project objective, and uses the formal process for changes. Quietly adding mobile support would break the schedule. Telling students that mobile use is out of scope without discussion would risk the project's main objective.

Key terms

• Expectation: a stakeholder's belief about what the project will deliver or how it will run.
• Unstated expectation: an expectation that is obvious to the stakeholder and was never communicated.
• MoSCoW: a prioritisation method (must, should, could, won't have).
• Alignment workshop: a facilitated session where stakeholders agree on expectations and priorities.
• Pre-mortem: an exercise that imagines a failure to find its causes in advance.
• Mentoring: a relationship in which an experienced person guides the development of another.
• Change control: the process that reviews and approves changes to baselines.
• Success criteria: measurable conditions that show that an expectation has been met.

Summary checklist

• I can categorise stakeholders by role, decision rights, attitude and type of expectation.
• I look for unstated and conflicting expectations with interviews, prototypes, observation and pre-mortems.
• I prepare, run and close an alignment workshop with documented, confirmed agreements.
• I distinguish objectives, requirements and expectations and handle each properly.
• I send expectations outside the approved scope through change control.
• I organise mentoring, match mentor and mentee, and act on what it reveals.
• I tell stakeholders early when an expectation will not be met.

Official sources

• PMI, PMP Examination Content Outline (July 2026): https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf (opens in a new tab)
• PMI, the new PMP exam: https://www.pmi.org/certifications/project-management-pmp/new-exam (opens in a new tab)
• PMI, Code of Ethics and Professional Conduct: https://www.pmi.org/about/ethics/code (opens in a new tab)