III.8 — Evaluate External Business Environment Changes

III.8 · Last updated: 11/10/2026

Keeping watch on the world outside the project

III.8 — Evaluate External Business Environment Changes is the last task in the Business Environment domain of the 2026 ECO. The domain carries 26% of the exam and is made up of eight tasks. This one has three enablers:

• Survey changes to the external business environment (e.g., regulations, technology, geopolitical, market)
• Assess and prioritize the impact on project scope/backlog based on changes in the external business environment
• Continually review the external business environment for impacts on project scope/backlog

None of the three asks you to prevent a change, because the external environment is outside the project team's control. What the ECO expects is that you watch that environment regularly, pick out the changes that matter to the project, and carry their effects into the scope or the backlog.

🔴 The 2021 III.3 lives here now

In 2021 this task carried the number III.3, under the title of evaluating and addressing external business environment changes. In 2026 the number III.3 went to change control, III.3 — Manage and Control Changes. Since both topics have "change" in their names, a wrong match slips by easily. The simplest way to keep them apart is to look at the direction each one faces. III.3 decides on change requests coming into the project, and III.8 watches what happens in the world outside it. If an older source shows an external environment question tagged "III.3", it is using the 2021 numbering. The overall picture, including the other shifts in this domain, is in what changed in the 2026 PMP exam.

What the book calls the external environment

The PMBOK® 8 counterpart of the ECO's "external business environment" is enterprise environmental factors (EEFs). The Standard defines them as conditions the project team cannot directly influence that impact, constrain, or direct the project, and notes that they can sit inside or outside the organization. According to the book, EEFs are inputs to many processes, most planning processes in particular; they can widen or narrow the options open to project management, and they affect tailoring needs (PMBOK® 8, Standard p.18). The definition uses the verbs impact, constrain, and direct, and nowhere says the factors are controlled, which is where the ECO's choice of "evaluate" over "change" comes from.

The book gives nine examples of EEFs external to the organization (PMBOK® 8, Standard p.19):

Each of the four examples in the ECO's parentheses has a match in this table. Regulations correspond to legal restrictions and to standards, technology to emerging technologies, and market to marketplace conditions. Geopolitics is the odd one out, since the book gives it no heading of its own and lists it as an example of a constraint under physical environmental elements.

EEFs change while the project runs

This is the heart of the task. Most sources teach EEFs as inputs to planning, and they tend to be pictured as a backdrop that stays fixed for the life of the project. The Guide, however, talks separately about updating them. Enterprise environmental factor updates describe changes in the conditions that impact, constrain, or direct the project. The Guide says these conditions are outside the project team's control, that the updates can affect the project's options and outcome positively or negatively, and that understanding and updating EEFs is fundamental to effective project management (PMBOK® 8, Guide p.120).

EEFs therefore do more than feed planning once; they become information that is refreshed as the project moves forward, and the ECO's enabler about continual review rests on that idea. When a question contains a line such as "this regulation did not exist when the project started," treat it as a finding that calls for an assessment, since the exam will not accept it as an excuse.

The success measures of the Risk performance domain ask for the same awareness. One of the expected outcomes the Guide lists for that domain is awareness of the environment the project operates in, including its technical, social, political, market, and economic contexts. The check for it is whether the team takes environmental factors into account when it assesses uncertainty, risks, and responses (PMBOK® 8, Guide p.102).

Carrying the impact into scope or backlog

The second enabler also says where the impact should go, and by naming "scope/backlog" it covers both kinds of approach. The route differs between them. In a predictive project, once the scope baseline is in place, every change has to pass through the formal change process (PMBOK® 8, Guide p.29). In an adaptive project, the change enters the backlog as an item, its impact is analyzed, and its priority is set on the basis of that analysis (PMBOK® 8, Guide p.30). Both mechanisms are described in detail on the III.3 page.

This is also where the verb "prioritize" earns its place in the enabler. Not every development in the outside world concerns the project, and the task asks you to separate, from everything you survey, the changes that will actually affect it.

An external change can end the project

A change in the external environment seldom arrives as a ready-made scope change. It usually shows up first as uncertainty, which is why this task works closely with risk. Among the tailoring considerations for the Risk performance domain, the Guide lists preparing for major disruptions through scenario planning and keeping aligned with the organization's business continuity or emergency response plan (PMBOK® 8, Guide p.101). How external changes find their way into the risk register is covered in III.5 — Plan and Manage Risk.

The most extreme outcome the book describes shows how serious this link can be. When The Standard lists the situations in which a project ends, two of them are tied directly to the outside world. The need for the project can disappear because of changes in strategy, in priorities, or in the external environment, and the project can be terminated because of legal, regulatory, or compliance issues (PMBOK® 8, Standard p.7). An external change that nobody is watching can remove the very reason the project exists.

The eight Business Environment tasks as one sequence

This task closes the domain, and reading all eight tasks together reveals an order. The domain opens by building the framework the project will be run within (III.1) and continues with compliance with the rules that come from outside (III.2). Then come the things managed inside the project, namely changes (III.3), impediments and issues (III.4), and risks (III.5). The project hands what it has learned back to the organization (III.6) and supports the organization's own transformation (III.7), and the domain ends with noticing that the world outside has changed.

That order also offers a key for reading Business Environment questions. In this domain's scenarios, the option to "carry on with the project as planned" is seldom the right one. All eight tasks measure the same quality in a project manager, which is whether they look at the project's surroundings and act on what they see.

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.