Business Environment practice questions

Organizational process assets (OPAs) are the plans, policies, procedures, templates and knowledge bases of the performing organization, and they are the basis for establishing project governance.

Governance is described and established through the organization's process assets. An established PMO almost certainly owns reporting templates, approval policies and document control procedures, so the project manager reviews and tailors those rather than inventing new ones or borrowing rules from elsewhere.

1. Recognise that reporting, approval and document control rules are governance.
2. Ask what the organization already provides for them.
3. Start from the organization's process assets.
4. Tailor them to the project once they are understood.

Exam tip: Establish governance from the organization's process assets, then tailor.

Organizational process assets are the organization's own plans, policies, procedures, templates and knowledge bases; enterprise environmental factors are conditions, internal or external, that constrain or influence the project.

The budget-change policy and the lessons learned repository belong to the organization and can be used and updated by the project, so they are process assets. Regulations and market rates are external environmental factors, and culture is an internal environmental factor. Culture is the tempting one because it is internal, but being internal does not make something a process asset.

1. For each item, ask whether the organization owns and can update it as a policy, procedure, template or knowledge base.
2. Policies and lessons learned qualify.
3. Laws and market conditions are external environmental factors.
4. Culture and structure are internal environmental factors.

Exam tip: Process assets are what the organization owns and documents; environmental factors are conditions it works within.

Organizational process assets are tailored to the project through the route the organization defines, rather than ignored or followed rigidly.

Two options would give the sponsor more frequent insight: swapping in the team board and adding iteration summaries. The board swap skips the PMO approval that the procedure requires, and the extra summaries add overhead the sponsor ruled out. Only a tailored approach approved through the PMO meets both the governance rule and the constraint.

1. Note what the procedure allows: tailoring with PMO approval.
2. Note the sponsor's constraint: more frequent insight, no extra overhead.
3. Eliminate options that bypass the PMO approval route.
4. Eliminate options that add team overhead.
5. Choose the tailoring proposal that goes through the PMO.

Exam tip: Tailor process assets through the organization's own approval route; don't ignore them or pile on extra work.

The sponsor is the governance role that champions the project, provides resources and funding, owns the business case and resolves issues beyond the project manager's authority.

Accountability for the business case and funding, plus being the first escalation point above the project manager, defines the sponsor. The PMO director is the tempting alternative because the PMO is part of governance, but it supports and standardizes rather than funding and owning a specific project.

1. List what the role must own: business case, funding, escalation.
2. Match those duties to the sponsor.
3. Rule out roles that manage resources or standards but not funding.

Exam tip: The sponsor funds the project, owns its business case and is the first escalation above the project manager.

Clear decision rights mean each type of decision has one agreed owner; in agile and hybrid work, backlog ordering belongs to the product owner.

The stakeholder asked the wrong person. The governance names the product owner as the decision owner for priority, so the project manager connects the stakeholder with the product owner. Moving the item and informing the product owner afterwards looks cooperative but still takes a decision the project manager does not hold.

1. Identify the decision requested: backlog priority.
2. Check the governance: the product owner owns backlog ordering.
3. Route the request to the decision owner.
4. Avoid acting on the decision yourself, even with notice afterwards.

Exam tip: Route a decision to the role governance assigns it to, even when you could make it yourself.

Effective governance assigns exactly one accountable decision maker per decision type, with others consulted or informed, as a responsibility assignment matrix does.

Joint approval and the seniority rule are both workable governance designs, but each breaks one of the sponsor's conditions: joint approval is slow, and the seniority rule removes one director's influence. Assigning a single accountable approver per decision type, for example clinical workflow to the clinical director and technical architecture to the IT director, with the other consulted, meets both conditions and removes the root cause.

1. Identify the root cause: two people believe they hold the same decision right.
2. Recall the rule: one accountable role per decision.
3. Test each option against speed and against both directors keeping influence.
4. Choose single accountability by decision type with consultation.

Exam tip: One decision, one accountable owner; give others a consulted role rather than a second veto.