Project Management Concepts practice questions

Project

Why it fails: A project is a single temporary endeavor; this grouping includes multiple projects.

Operations

Why it fails: Operations are ongoing activities, not temporary projects.

Portfolio

Why it fails: A portfolio is a collection of projects, programs, and operations managed as a group to achieve strategic objectives; it may include unrelated initiatives.

Full authority; team members report only to the PM

Why it fails: Full authority and sole reporting is projectized.

Limited authority; functional managers control resources

Why it fails: That describes weak matrix.

No authority; the steering committee makes all decisions

Why it fails: Steering committee provides oversight, but PM has authority.

Agile sprint planning

Why it fails: Sprint planning is for agile, not for sequential dependency modeling.

Gantt chart

Why it fails: Gantt charts show schedule bars, not necessarily logical dependencies as nodes.

Work breakdown structure (WBS)

Why it fails: WBS decomposes scope hierarchically, not sequencing.

Functional manager

Why it fails: Functional manager is an organizational role, not a project-specific role.

Stakeholder

Why it fails: Stakeholder is a broad category, not a specific role.

Stakeholder satisfaction

Why it fails: Stakeholder satisfaction is a project objective or success criterion, not a constraint; the triple constraint comprises scope, time and cost (with quality often added). It is tempting because unsatisfied stakeholders can limit options, but that pressure is a consequence, not a fixed boundary the project must operate within.

Team morale

Why it fails: Team morale is a project health indicator, not a constraint; the recognised constraints are scope, schedule, cost and quality. It is tempting because low morale can throttle delivery, yet morale fluctuates and is managed, whereas a constraint is a fixed limit imposed on the project.

Risk

Why it fails: Risk is a project uncertainty or threat, not a fixed boundary; the triple constraint comprises scope, time, and cost, with quality often added. It is tempting because risk management consumes budget and schedule, so it feels limiting. Constraints are imposed limits the project must operate within, whereas risk is an event that may or may not occur.

Cost-benefit analysis

Why it fails: Cost-benefit analysis compares costs and benefits but is broader.

Internal Rate of Return (IRR)

Why it fails: IRR is a discount rate, not a direct profitability measure.

Payback period

Why it fails: Payback period measures time to recover investment, not profitability.

A set of ongoing, repetitive operations to sustain the business.

Why it fails: This describes operations, not a project.

A collection of projects and programs aligned to strategic objectives.

Why it fails: This defines a portfolio.

A group of related projects managed in a coordinated way.

Why it fails: This defines a program, not a project.

Project Sponsor

Why it fails: The sponsor provides resources but does not manage daily priority changes.

Development Team

Why it fails: The team implements changes but does not manage priorities.

Steering Committee

Why it fails: Steering committee provides governance but not daily priority decisions.

Scope, because the regulatory directive adds new compliance requirements that must be satisfied by the project team.

Why it fails: The directive changes how the product must be verified rather than what the product must do. The features, deliverables, and boundaries of the product remain as originally agreed, so the product scope baseline is untouched. Treating every compliance obligation as a scope change would drive unnecessary change control requests and could confuse the team about whether the charter still applies.

Cost, because additional verification activities always require additional labor hours and therefore consume contingency reserve.

Why it fails: Additional verification does consume effort, but the scenario gives no indication of budget impact, no approved change request, and no reserve drawdown. Assuming cost is automatically the affected constraint ignores the fact that verification effort can often be absorbed within planned testing windows. The question asks which constraint the directive itself affects, not which one might incidentally feel pressure.

Schedule, because the new verification activities must be completed before the release date and therefore extend the critical path.

Why it fails: The delivery date is explicitly unchanged and the scenario never states that verification activities extend the critical path. Verification work can frequently run in parallel with development or fit inside existing test phases. Declaring the schedule the affected constraint without evidence of float consumption or a missed milestone substitutes an assumption for the facts given in the scenario.

Negotiate a new contract amendment with the vendor

Why it fails: Negotiating contract amendments happens during execution when scope or terms change, not during closure of an accepted project. At closure the focus is on verifying completion, settling final invoices, and closing out procurement, not creating new contractual commitments that would reopen scope.

Perform a root cause analysis on the critical path

Why it fails: Root cause analysis on the critical path is a scheduling or problem-solving technique used during planning or execution when delays occur. It is not a closure activity, and applying it to a fully accepted project would not contribute to formally closing the project or transferring knowledge.

Release project resources and reassign team members to other work

Why it fails: Releasing team members is a valid closure step, but the stem already states that formal customer acceptance has been received, and the question asks for activities performed as part of closing. Releasing resources is a real closure action, yet the strongest paired answer focuses on acceptance documentation and lessons learned; resource release is more of an administrative follow-on once closure is confirmed.

The business case justification

Why it fails: The business case explains the economic or strategic rationale for the investment and supports the decision to proceed. It is an input that justifies the project but does not itself confer authority. A compelling business case with no sponsor sign-off leaves the project manager unable to direct staff or budget, so it cannot be the binding element.

The high-level milestone list

Why it fails: The milestone list describes major checkpoints such as go-live or design sign-off. It is planning content that helps sequence and communicate progress, but it carries no authority. A milestone list can exist in an unapproved draft and still be accurate, so it cannot be the element that grants the project manager the right to expend organizational resources.

The list of key stakeholders

Why it fails: Stakeholder identification is valuable for engagement planning, and the charter may name the sponsor and other key parties. However, listing people does not grant the project manager any power over them. A roster of names can be compiled before approval, so it cannot be what makes the charter formally binding on the organization.

A responsibility assignment matrix

Why it fails: A responsibility assignment matrix maps work packages or activities to the people accountable for them. It answers who does what, not what is finished and when. It contains no completion status or planned dates, so it cannot show the sponsor which deliverables are done, in progress, or not started, and would misdirect the conversation away from schedule status.

A work breakdown structure

Why it fails: The work breakdown structure decomposes the total scope into deliverables and work packages in a hierarchy. It defines what must be delivered but deliberately excludes sequencing, durations, and status. Presenting a WBS to the sponsor would show scope decomposition only, leaving the completion and date questions entirely unanswered.

A resource histogram

Why it fails: A resource histogram displays the quantity of resources, usually labor hours, assigned over time. It reveals over-allocation and peaks in demand, which is useful for capacity planning. It says nothing about deliverable completion or planned milestone dates, so it would not answer the sponsor's status question.

Quality

Why it fails: Quality is a performance attribute degraded by cutting testing or review, not the constraint directly altered by adding unplanned features; scope changes first, then cost or schedule absorb the impact. Quality is tempting because rushed delivery often suffers, making it correct when the team compresses verification to meet a fixed date.

Schedule

Why it fails: Adding unplanned features consumes extra effort, but the stem already fixes the budget and deadline, so the immediate constraint hit is scope, not time; schedule shifts only once the added work is estimated and re-baselined. Schedule is the tempting answer because extra features usually extend duration, making it correct when the deadline is flexible.

Cost

Why it fails: Cost rises only after the added features are estimated and resourced; the request itself changes scope, and with a fixed budget the manager must negotiate trade-offs rather than assume new funding. Cost is tempting because extra work consumes money, making it correct when the budget is flexible and scope is fixed.

Difficulty in obtaining dedicated funding for the project

Why it fails: Funding allocation sits with the project sponsor and governance process, not the functional managers, so a weak matrix does not restrict it. The genuine weak-matrix constraint is that functional managers control team members' assignments and priorities, leaving the project manager little authority to secure or direct staff.

Team members reporting directly to the project manager

Why it fails: In a weak matrix, functional managers retain authority over assignments and priorities, so team members report to them rather than to the project manager. It is tempting because strong matrix structures do place team members under project manager direction, but that inverted reporting is precisely what this structure prevents.

High project manager authority over team members

Why it fails: Weak matrix structures grant the project manager limited authority, with functional managers controlling resources and priorities, so high authority over team members does not occur. It is tempting because strong matrix structures concentrate that authority in the project manager role, but here the challenge is the opposite: negotiating resources without direct control.

Project A because it has a longer payback period

Why it fails: Payback period measures how quickly investment is recovered, not total value created; policy mandates highest NPV, and Project A already wins on that $50,000 figure. Selecting it for a longer payback period inverts the stated criterion. Payback period is decisive only when liquidity or risk-recovery speed is the governing constraint.

Project B because it has a shorter payback period

Why it fails: The payback period measures how quickly investment is recovered, but the policy explicitly ranks projects by NPV. Project B's $40,000 NPV is below Project A's $50,000, so it fails the stated criterion. Project B would be correct only if the selection policy used payback period.

Project B because it has a lower NPV

Why it fails: Project B's NPV is $40,000, lower than Project A's $50,000, so selecting it contradicts the stated policy of choosing the highest NPV. The shorter payback period is irrelevant under that policy. Project B would be correct if the organisation prioritised fastest capital recovery instead.

Scope creep

Why it fails: Scope creep is unauthorised additions to the agreed scope baseline, whereas this describes gold plating: extra features delivered voluntarily without a change request. Scope creep is tempting because both involve unapproved work, and it is correct when stakeholders gradually expand requirements beyond what was baselined.

Value analysis

Why it fails: Value analysis examines whether a component's function justifies its cost, typically during design or procurement reviews; it does not describe unauthorised additions to a deliverable. It is tempting because added features appear to increase value, and it would be correct when assessing whether a function's benefit warrants its expense.

Progressive elaboration

Why it fails: Progressive elaboration is the iterative refinement of project and product detail as understanding improves, which is planned and sanctioned; it does not cover unapproved additions beyond agreed requirements. It is tempting because both involve changing detail during execution, and it would be correct when requirements are legitimately detailed further through successive iterations.

Agile

Why it fails: Agile delivers work in short iterations with continuous requirement reprioritisation, which suits evolving or unclear scope. Here the requirements are fixed and well-defined, so iterative re-planning adds overhead without benefit. Agile would be the right choice for a project where customer needs emerge during delivery.

Hybrid

Why it fails: Hybrid blends predictive and adaptive approaches, adding iterative elements that suit evolving or uncertain requirements; stable, well-defined construction requirements gain nothing from that overhead. It is tempting when organisations already practise Agile, but a predictive waterfall methodology fits fixed scope, sequential phases and change-controlled delivery.

Scrum

Why it fails: Scrum is an Agile framework built on short sprints and a product backlog that absorbs changing requirements. With requirements already well-defined and unlikely to change, sprint-based replanning provides no advantage. Scrum would be correct for complex product development where scope evolves through frequent stakeholder feedback.

Project management plan

Why it fails: A project management plan describes how the project will be executed, monitored and controlled; it does not authorise the project or assign the project manager. It is tempting because it also covers scope, budget and schedule, but as baselines rather than high-level estimates. It would be correct once planning is complete, consolidating subsidiary plans.

Scope statement

Why it fails: A scope statement details deliverables and boundaries; it neither authorises the project nor assigns the project manager. It is produced during planning to control change. The charter is the authorising document described in the stem.

Business case

Why it fails: A business case justifies the investment through costs, benefits and options analysis; it does not formally authorise the project or name the project manager. It precedes the charter and informs the sponsor's decision to proceed.

Net Present Value (NPV)

Why it fails: NPV discounts all future cash flows to present value and sums them, indicating absolute value created rather than the duration of recovery. It is the right method when ranking projects by value added, but the stem asks how long until cumulative inflows repay the initial outlay, which payback period reports.

Internal Rate of Return (IRR)

Why it fails: IRR calculates the discount rate at which a project's net present value equals zero, expressing percentage return rather than elapsed time. It is the correct selection method when comparing projects on profitability relative to cost of capital, but the stem asks for the period until cumulative cash inflows repay the initial outlay.

Cost-benefit analysis

Why it fails: Cost-benefit analysis compares total expected costs against total expected benefits, producing a net value or ratio rather than a duration. It suits go/no-go decisions on financial viability, yet the stem requires the elapsed period until cumulative inflows equal the initial investment, which payback period measures.

Predictive life cycle

Why it fails: A predictive life cycle plans scope, schedule and cost upfront and delivers in a single sequential pass, so it cannot accommodate the two-week iterative sprints described. It is tempting because the fixed budget, high-level schedule and sequential hardware procurement look plan-driven, but the iterative software work rules it out.

Iterative life cycle

Why it fails: A hybrid life cycle combines predictive and iterative elements; the stem's sequential hardware procurement alongside two-week sprints defines hybrid, not purely iterative. Iterative life cycles repeat phases without a fixed sequential track, so they would be correct only if all deliverables, including hardware, were refined through repeated cycles.

Adaptive life cycle

Why it fails: An adaptive life cycle delivers in short iterations with scope defined and refined per iteration, so it cannot support the fixed overall budget, high-level schedule and sequential hardware procurement described. It is tempting because of the two-week sprints, but the hybrid mix of predictive and iterative elements is the distinguishing factor.