I.1 — Develop a Common Vision

I.1 · Last updated: 11/10/2026

Why the People domain opens with a vision

I.1 — Develop a Common Vision is the task that opens the People domain of the 2026 ECO. The domain carries 33% of the exam and holds eight tasks, and its list starts neither with the team nor with conflict or stakeholders. It starts with the vision.

The ECO gives this task four enablers:

• Help ensure a shared vision with key stakeholders
• Promote the shared vision
• Keep the vision current
• Break down situations to identify the root cause of a misunderstanding of the vision

All four rest on the same assumption about what a vision is. The ECO treats it as an alignment that has to be looked after for as long as the project runs, so a sentence written once and pinned to the wall would satisfy none of them.

An old "I.1" question is about something else

Domain I came down to eight tasks in 2026, while the numbering in older material ran to at least I.12. With that much compression very few numbers could stay where they were, and I.1 is one of those that moved.

In 2021, I.1 was conflict management, a topic that now lives in I.2 — Manage Conflicts. In 2026, I.1 is developing a common vision. An older question tagged "I.1" is therefore far more likely to be about conflict than about vision.

Assuming that everything simply slid down one place would also mislead you, because the shift is irregular. I.3 took over at least five separate 2021 numbers on its own, while I.7 and I.8 inherited numbers whose topics had left for other domains. When you map older material, go by the title. The wider picture of the numbering trap is in what changed in the 2026 PMP exam.

PMBOK starts a project with a picture of the end state

Putting the vision first fits what PMBOK says about how a project should begin. When the Guide relates the focus areas to governance, it sums up initiating in a single line: successful projects begin with a clear description of the desired end state. A clearly articulated business case enables stakeholder alignment on priorities and constraints, and it gives team members a broader context that informs their work (PMBOK® 8, Guide p.10).

Each part of that passage matches one of the enablers. The clear end state is the vision itself, stakeholder alignment is the shared vision, and the context handed to the team is what promoting the vision produces.

On the exam this task often turns up in disguise. When a team knows what it has to do but not why, the scenario can look like a communication breakdown, although the question is really testing this task.

The vision is what you measure a decision against

When the Guide lists the common aspects of project team development, the first item is vision and objectives. They are communicated throughout the project and give the team its basis for a shared understanding, and that communication includes referencing the intended outcomes when the team makes decisions and solves problems (PMBOK® 8, Guide p.84).

The practical core of the task sits in that last clause. A vision earns its keep when it is laid on the table as the yardstick for a decision, which is exactly what the enabler about promoting the vision asks for. Once the vision has become the reason people give for their choices, it has been promoted in the sense the ECO means.

The other four items on that list (roles and responsibilities, team operations, guidance, and growth) are covered under I.3 — Lead the Project Team.

A shared vision grows out of the culture

One of the six principles in The Standard overlaps directly with this task. The Build an Empowered Culture principle asks for a culture that fosters proactive collaboration and promotes unity in shared objectives, built through stakeholders and teams with diverse skills, knowledge, and experience (PMBOK® 8, Standard p.53).

The principle also states its precondition. For such a culture to take hold, the project environment should promote mutual trust among stakeholders and team members, and there should be full clarity on individual roles, responsibilities, team agreements, and guiding processes (PMBOK® 8, Standard p.53).

"Unity in shared objectives" and the ECO's "shared vision" are two names for one thing. The book does not handle it as something to announce. It sees it as the result of a culture built on trust and clarity, which is a slower and more demanding job than writing a memo.

A vision needs upkeep

The third enabler says something most study material passes over, namely that a vision can change.

The reason is that a project depends on the world outside it. When The Standard lists the ways a project can come to an end, one of them is that, because of changes in strategy, priorities, or the external environment, the need for the project no longer exists (PMBOK® 8, Standard p.7).

Losing the need altogether is the extreme case. The forces that cause it usually work more quietly and only nudge the vision off course. Tracking changes in the external business environment is a separate task; see III.8 — Evaluate External Business Environment Changes.

That is why an answer option saying the vision was settled at the start and the matter is closed counts as wrong on the exam.

From product vision down to the iteration

In an agile setting the vision has a concrete counterpart, and the Guide builds the chain from the top down. One of its figures shows the typical relationship among the product vision, the product roadmap, release planning, and iteration planning (PMBOK® 8, Guide p.146).

The release plan in the middle of that chain draws on the roadmap and the product vision to give a high-level summary timeline for the release, typically 3-6 months, and it fixes how many iterations the release will contain. With it the product owner and the team determine the development scope, the timelines, and a releasable product, factoring in business goals, dependencies, impediments, and resource availability (PMBOK® 8, Guide p.146).

The vision therefore sits at the top and breaks down into a roadmap, then releases, then iterations. On the predictive side the equivalent is the scope structure; see II.2 — Develop and Manage Project Scope.

Finding out why the vision was misread

The fourth enabler names a method outright: break situations down to identify the root cause.

The book's matching tool is the after-action review (AAR), a simple, structured process for analyzing what happened, why it happened, and how it could be done better (PMBOK® 8, Guide p.145).

Applied to a vision, this means that repeating the vision more loudly is the wrong first move when the team has misunderstood it. You first need to learn why it was misread. The cause might be an ambiguous phrase, stakeholders sending messages that contradict each other, or a priority that changed without anyone being told.

It also explains why "lack of communication" so often turns out to be a shallow answer on the exam. The option the question is looking for is the one that points to the source of the problem, while the weaker options only describe its symptom.

About the citations

Every page number above refers to the PMBOK® Guide, Eighth Edition (PMBOK® 8); references to the 2026 ECO are marked "ECO" separately.

⚠️ PMBOK® 8 contains two separate books in one volume, and their page numbering is independent:

• The Standard for Project Management — cited as Standard p. X
• A Guide to the Project Management Body of Knowledge — cited as Guide p. X

This page cites both books; which number belongs to which book is stated in every citation. The numbers are the books' printed page numbers.

This page describes the book; it does not replace it.