PMP Business Environment: 55 practice questions

12 of the 55 Business Environment questions in the Certsqill PMP bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for PMP? Take the free 5-min readiness check →

1. Project success is not business success: What does this indicate about the project's relationship to organizat

1. Project success is not business success; realizing benefits requires management after close ✓

   Projects deliver outputs such as features and systems, but business benefits like cost savings and revenue depend on adoption, usage, and operational change after close — so benefits management extends beyond project completion.
2. The project failed outright, since on-time, on-budget delivery means nothing without benefits

   The project succeeded against its constraints of time, cost, and scope — the failure to realize benefits is primarily an organizational and operations challenge, even though the PM should have planned benefits tracking.
3. The sponsor's expectations were unrealistic, as real benefits take several years to appear

   Six months is a reasonable window for initial benefits to begin appearing, so dismissing the sponsor's concern is inappropriate — benefits realization should have been planned and tracked rather than assumed to be years away.
4. The project management plan was flawed because it excluded delivery of the business benefits

   Benefits realization is an organizational responsibility that extends beyond the project — the PM plan governs project deliverables, not post-project business outcomes, though a benefits realization plan should accompany the business case.

Project outputs ≠ business benefits. Projects deliver outputs; benefits (value) emerge from how those outputs are used. Benefits management requires planning and measurement beyond project close.

2. EEF: government regulations and market conditions; OPA: Which of these are Enterprise Environmental Factors (E

1. EEF: templates and historical databases; OPA: government regulations and market conditions

   This reverses the two categories — templates and historical databases are internal assets (OPAs), while government regulations and market conditions are external factors outside organizational control (EEFs).
2. EEF: government regulations and market conditions; OPA: templates, databases, lessons learned ✓

   EEFs are inputs outside the organization's control that affect performance — laws, market conditions, industry standards. OPAs are the organization's accumulated internal knowledge and tools — templates, databases, lessons learned, and policies.
3. Both are EEFs, since every external and internal input to planning is environmental in nature

   EEFs and OPAs are distinct input categories — OPAs are organization-owned assets accumulated over time, so templates, databases, and lessons learned are not EEFs even though some EEFs are internal (culture, infrastructure).
4. Both are OPAs, since the organization draws on all available information as its process assets

   External factors such as government regulations and market conditions lie outside the organization's control and are EEFs, not OPAs — an organization cannot own or modify external laws or market forces.

EEF = conditions influencing project (internal: culture, infrastructure; external: regulations, market). OPA = organization's accumulated knowledge assets (templates, lessons learned, processes).

3. Legal , Economic , and Social: Which PESTLE categories do these represent?

1. Political (GDPR), Economic (recession risk), and Social (cultural differences in behavior)

   GDPR is a specific law and therefore a Legal factor, not Political — Political factors cover government stability, trade policy, and political risk, whereas Legal factors are the specific laws and regulations themselves.
2. Legal (GDPR), Financial (recession risk), and Cultural (differences in customer behavior)

   'Financial' and 'Cultural' are not PESTLE categories — the correct labels are Economic (not Financial) for the recession and Social (not Cultural) for the behavior differences, even though the Legal label is right.
3. Legal (EU GDPR), Economic (recession risks), and Social (cultural differences in behavior) ✓

   PESTLE covers Political, Economic, Social, Technological, Legal, and Environmental factors. GDPR is a Legal regulation, recession risk is an Economic factor, and cultural differences are a Social factor — each maps to the correct dimension.
4. Regulatory (GDPR), Market (recession risk), and Demographic (cultural behavior differences)

   'Regulatory', 'Market', and 'Demographic' are not PESTLE categories — the framework specifically uses Political, Economic, Social, Technological, Legal, and Environmental.

PESTLE: Political, Economic, Social, Technological, Legal, Environmental. GDPR = Legal. Recession = Economic. Cultural behavior = Social.

4. Change management: What is missing from this approach?

1. Risk management — address the technical risks first, before turning to any people-side concerns

   Risk management is necessary but does not close the adoption gap — user resistance is itself a major risk that requires specific change management interventions, not simply documentation in the risk register.
2. Quality management — stronger testing of the system will raise user satisfaction and adoption

   Better testing improves system quality but does not address the behavioral and cultural change employees must make — adoption is a change management challenge, not a quality one.
3. Nothing is missing — technical delivery is the PM's job while HR owns the employee changes

   On modern projects the PM is responsible for the organizational-change aspects of the project — separating technical delivery from the people side is a formula for failure through poor adoption.
4. Change management — communication, training, and engagement to prepare staff for the system ✓

   Technical delivery without organizational change management leads to poor adoption. The PM must address the people side of change — communication plans, training, stakeholder engagement, and resistance management.

Technical delivery without change management = low adoption. PMs must plan and execute people-side change: communication, training, stakeholder engagement, resistance management.

5. Business case: Before a project is formally authorized, what document is used to justify the investment by doc

1. Business case — justifies the investment via benefits, costs, risks, and strategic alignment ✓

   The business case documents the justification for undertaking a project — expected benefits, estimated costs, feasibility, risks, and strategic alignment — and is the basis for the authorization decision.
2. Project charter — formally authorizes the project and names the project manager to lead it

   The project charter authorizes the project and the PM and is created after the business case is approved — it references the business case but is not itself the investment-justification document.
3. Project management plan — defines how the project will be executed, monitored, and controlled

   The project management plan describes how the project will be executed, monitored, and controlled — it is produced after authorization and does not serve to justify the investment beforehand.
4. Statement of work — describes the scope of work to be delivered under the resulting contract

   The SOW describes the work scope and is a procurement or planning artifact — it specifies what will be delivered but is not the document used to justify the investment decision.

Business case = pre-authorization investment justification document. Project charter = post-approval authorization document. Sequence: Business case → Approval → Project charter → Project plan.

6. Submit a change request to add the encryption requirement: What should the project manager do?

1. Defer the encryption work to a later phase to protect the current project's timeline and cost

   Deferring a mandatory compliance requirement exposes the organization to legal liability — regulatory obligations cannot be postponed for the convenience of the current schedule or budget.
2. Submit a change request to add the encryption requirement; compliance is mandatory regardless ✓

   Regulatory requirements are non-optional and must be implemented regardless of impact to cost, schedule, or scope — the PM submits a change request to formally add the requirement, update baselines, and meet the legal obligation.
3. Log the new regulation in the risk register and formally accept it as a project-level risk

   Regulatory compliance is not a risk to be accepted — non-compliance is a legal obligation to fulfill, not an uncertain event, so documenting and accepting it instead of implementing it is not acceptable.
4. Ask the sponsor to negotiate a government exemption from the encryption regulation instead

   While exceptions may theoretically exist, seeking an exemption from a federal healthcare data-protection regulation is neither realistic nor acceptable — the requirement must be implemented.

Regulatory requirements are mandatory regardless of project constraints. Submit a change request, update baselines, and implement. Compliance cannot be deferred or accepted as risk.

7. Program — related projects managed together for benefits: What is the correct description of this structure?

1. Portfolio — a collection of projects and programs aligned to strategic objectives across the org

   A portfolio groups projects, programs, and operations aligned to strategy and may contain unrelated initiatives — these five are specifically related and benefit from coordinated management, which makes them a program.
2. Five independent projects — each best run separately under its own dedicated project manager

   Although each project may have its own PM, running them independently ignores their interdependencies and forfeits the coordinated benefits that a program structure is designed to deliver.
3. Program — related projects managed together for benefits unavailable from managing separately ✓

   A program is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually — all five share the strategic goal of improving customer experience and have interdependencies.
4. Operations — the ongoing, repetitive activities of managing the customer experience function

   These are time-bounded initiatives with specific deliverables, which makes them projects — operations are ongoing, repetitive activities and do not apply to this set of initiatives.

Program = related projects managed together for coordinated benefits. Portfolio = all projects/programs in an organization (may be unrelated). Related customer experience projects = program.

8. Lessons learned sessions and process audits held at each: What is the equivalent activity for the predictive w

1. Daily standup meetings to synchronize the team and surface impediments each working day

   Daily standups are coordination meetings for status and impediments, not process-improvement sessions — they do not fulfill the retrospective's purpose of reflecting on and improving team practices.
2. Risk reviews to reassess probability and impact and keep the risk register fully up to date

   Risk reviews monitor and update the risk register — they focus on managing risk exposure, not on reflecting on and improving how the team works.
3. Status reports to the sponsor summarizing progress, cost, and schedule performance to date

   Status reports communicate progress to stakeholders — they inform rather than drive team reflection on improving the way work is done, so they are not the equivalent of a retrospective.
4. Lessons learned sessions and process audits held at each phase gate and project milestone ✓

   In predictive projects, lessons learned sessions at phase gates and milestones, together with quality audits, serve the same purpose as agile retrospectives — reflecting on what worked and improving for subsequent phases.

Predictive equivalent of agile retrospective = lessons learned sessions at phase gates + quality process audits. Both aim to improve how the team works.

9. Project Alpha: Which project should be selected and why?

1. Project Beta — its higher ROI of 200% versus Alpha's 150% means each invested dollar returns more, making it the more efficient use of the available capital

   ROI compares efficiency per dollar (Beta 200% versus Alpha 150%), but PMI's preferred selection metric is NPV, which measures absolute value created. When budget allows, Alpha's higher NPV means more total value.
2. Project Beta — its smaller $100,000 initial investment ties up less capital and therefore reduces the organization's overall financial risk exposure on this decision

   A smaller investment does reduce cost exposure, but when budget is available for either project the criterion is value creation measured by NPV. Risk-tolerance adjustments are a separate consideration not raised in the scenario.
3. Both projects should first be re-evaluated using IRR, since the internal rate of return is the decisive financial metric to apply before any selection is finalized

   IRR is another valid financial metric, but it is not decisive once NPV has been calculated. PMI treats NPV as the primary financial tool for project selection, so re-evaluating with IRR first is unnecessary.
4. Project Alpha — its higher absolute NPV ($450,000 versus $200,000) indicates greater total value creation, and NPV is the preferred metric for project selection ✓

   NPV (Net Present Value) measures absolute value created above the investment cost. PMI recommends selecting the project with the highest NPV when budget allows. Project Alpha creates $150,000 more value than Beta. ROI% is not the primary selection criterion.

PMI prefers NPV for project selection — select the highest NPV project when budget allows. NPV measures absolute value creation. ROI% measures efficiency but doesn't capture total value. Alpha (NPV $450K) beats Beta (NPV $200K).

10. Weak matrix — functional managers hold primary authority: What type of organizational structure is this?

1. Weak matrix — functional managers hold primary authority over reviews and resources; the PM has only limited, influence-based coordinating power ✓

   In a weak matrix, functional managers retain most authority. The PM has limited power (coordinator role), team members are part-time on projects, and functional managers control performance reviews and resource allocation.
2. Strong matrix — the project manager holds significant authority, controls dedicated full-time resources, and outranks functional managers on the work

   In a strong matrix the PM's authority rivals the functional managers' and team members are mainly assigned to projects. Here the members spend only 25% of their time on the project and functional managers control reviews, which is a weak matrix.
3. Projectized — the project manager has full authority and the team members report directly to the PM rather than to their functional managers

   In a projectized organization team members report to the PM, who holds full authority over resources. In this scenario functional managers remain in control, so it is not projectized.
4. Balanced matrix — the project manager and functional managers share authority roughly equally over the team members and their daily assignments

   A balanced matrix splits authority roughly evenly between PM and functional managers. Here the functional managers clearly dominate, controlling performance reviews and most of the members' time, which indicates a weak matrix.

Weak matrix: functional managers have primary authority; PM is coordinator-level; team members are part-time on projects; functional managers control performance reviews. PM relies on influence, not authority.

11. Reinforcement: Which ADKAR element is the adoption gap?

1. Desire — the users do not genuinely want to change their way of working, and that missing personal motivation is the reason they keep reverting to spreadsheets

   The analysis states users believe the tool is beneficial, so Desire is present. The reversion is driven by managers not modeling or reinforcing the new behavior, which is a Reinforcement gap, not a Desire gap.
2. Reinforcement — without managerial modeling and consistent reinforcement of the new behavior, users revert to old habits despite having Awareness, Desire, Knowledge, and Ability ✓

   ADKAR: Awareness, Desire, Knowledge, Ability, Reinforcement. Users have awareness (understand the tool), desire (believe it's beneficial), knowledge (training completed), and ability (know how to use it). The gap is Reinforcement — managers are not modeling/reinforcing the behavior change.
3. Knowledge — the training was too shallow, so users still lack the practical know-how to operate the new tool effectively and therefore fall back on the old spreadsheet-based method

   Users report they understand how to use the tool, so Knowledge is present. Even with knowledge, the absence of managerial reinforcement causes them to revert, making this a Reinforcement issue rather than a training one.
4. Awareness — the users do not really understand why the change matters, and without grasping that reason they see no need to abandon the familiar old spreadsheets

   Users understand how to use the tool and see its value, so Awareness is present. The breakdown is at the Reinforcement stage, where managers fail to model and sustain the new behavior, not at awareness.

ADKAR: Awareness → Desire → Knowledge → Ability → Reinforcement. Adoption failure despite awareness, desire, knowledge, and ability = Reinforcement gap. Managers not modeling the new behavior prevents sustained adoption.

12. The business/sponsor owns post-project benefits: Who owns benefits realization, and what should have been done

1. The project manager owns benefits realization both throughout and long after delivery; the PM should have stayed engaged well past closure to drive user adoption, measure the 40% and 15% targets, and take corrective action

   Once the project closes and the PM is reassigned, the PM typically has no operational authority to drive benefits adoption. Benefits realization post-delivery is a business/operational responsibility, not a project management one.
2. The product owner owns benefits realization here; because the deliverable is a product, the PO should have tracked onboarding time and satisfaction and adjusted the backlog to close any remaining benefit gap

   The product owner maximizes product value during development — but the post-delivery business benefits (onboarding time, customer satisfaction) require operational changes that go beyond the product owner's role and authority.
3. Because neither benefit appeared within six months the initiative has failed, and ownership reverts to the sponsor to relaunch the project with a revised scope and a fresh delivery team

   Six months may not be sufficient for all benefits to materialize, depending on adoption rate and change depth. The appropriate response is measurement, diagnosis, and corrective action through the benefits realization plan — not an automatic relaunch.
4. The business/sponsor owns post-project benefits realization; a benefits realization plan should have been created before project closure, with assigned benefits owners, measurement mechanisms, and a tracking timeline ✓

   Benefits realization extends beyond project completion. The business (sponsor, operations) owns benefits post-delivery. A benefits realization plan assigns ownership, defines KPIs, sets measurement timelines, and ensures benefits are tracked and actions taken if targets are missed.

Business/sponsor owns post-project benefits realization. Benefits realization plan defines KPIs, measurement timeline, and assigned benefits owners. Project delivery ≠ benefits delivery.

Other PMP domains

• Process — 263 questions →
• People — 181 questions →
• All 499 PMP questions →