Select Two (Multi-Select) Questions

Work breakdown structure

Why it fails: The WBS is created during the planning process group.

Project management plan

Why it fails: The PM plan is developed during planning.

It always includes the project milestone

Why it fails: Milestones are zero-duration markers that may sit on any branch, and the critical path is defined solely by the longest chain of dependent activities. A milestone would be guaranteed on the critical path only if it marks project completion, which not every milestone does.

It is the path with the most resources assigned

Why it fails: Critical path duration is determined by the longest sequence of dependent activities, independent of how many resources each activity consumes. Resource counts matter for resource levelling and cost estimation, so this statement would fit a question about resource allocation rather than critical path identification.

It is the shortest path through the network

Why it fails: The critical path is the longest duration path through the network, since that total determines the project's minimum completion time. The shortest path carries float and can be delayed without affecting the finish date, so this describes a non-critical path instead.

Overhead costs

Why it fails: Overhead costs such as rent, utilities and administrative salaries are indirect: they cannot be attributed to a single project deliverable. Direct costs, like labour billed to the project or dedicated materials, trace to specific work. Overhead is tempting because projects do incur it, but it is shared across the organisation.

Training costs

Why it fails: Training is a recurring operational expense, not a direct project cost tied to a specific deliverable, so it fails the direct-cost criterion. It tempts because training often appears in project budgets, and it would qualify as an indirect or overhead cost when allocated across multiple projects rather than charged to one.

Ignore

Why it fails: Ignore is not a recognized response strategy.

Enhance

Why it fails: Enhance is for positive risks (opportunities).

Increase the project scope to justify the shorter timeline.

Why it fails: Increasing scope would extend the schedule, not shorten it.

Reduce the quality standards to speed up work.

Why it fails: Reducing quality is not acceptable and may cause rework.

Switch color

Why it fails: Switch colour has no bearing on network function or the upgrade's requirements. It is tempting only where aesthetic or rack-labelling conventions exist, which is not a technical selection factor. Port density, speed and PoE budget determine whether the switch meets the project's needs.

Warranty period

Why it fails: Warranty period is a commercial consideration, not a factor determining whether the switch meets the upgrade's technical requirements. It is tempting because warranty reduces lifecycle cost and risk, and would matter when comparing otherwise equivalent vendors. Port count, throughput and PoE capability are the deciding factors.

Brand name

Why it fails: Brand name does not determine whether a switch meets the upgrade's technical requirements. It is tempting because a reputable vendor can imply reliability and support, and brand would matter where standardisation or existing support contracts apply. Port count, throughput and PoE capability are the relevant selection factors.

Create the project charter

Why it fails: Creating the project charter happens during initiation, authorising the project before planning starts, so it is not a closure activity. It is tempting because closure produces final documentation, but the charter is an input created at the outset, whereas closure yields lessons learned and formal acceptance.

Update the risk register

Why it fails: Updating the risk register is a monitoring and controlling activity performed throughout execution, not a closure task. It is tempting because residual risks are reviewed at closure, but that review closes risks rather than updating them; closure instead covers final reports, archives and resource release.

Develop the project schedule

Why it fails: Developing the project schedule occurs during planning, before execution begins, so it cannot belong to closure. It is tempting because closure does involve schedule review, yet building the baseline schedule is the planning-phase activity; closure instead covers final performance reporting and resource release.

Providing project funding

Why it fails: Funding is approved by the sponsor or executive committee, who own the business case and budget; the PM only tracks and reports spend against it. It is tempting because the PM manages the budget day to day, and would be correct for controlling costs within the approved baseline.

Defining the company's strategic goals

Why it fails: Strategic goals are set by executive leadership, and the PM aligns the project to them rather than defining them. It is tempting because the PM does translate strategy into scope, schedule and deliverables, and would be correct for defining project objectives derived from that strategy.

Resolving escalated issues above the PM's authority

Why it fails: Escalated issues sit above the project manager's authority, so the PM routes them to the sponsor or steering committee rather than resolving them. It is tempting because the PM does own issue resolution within their authority, and would handle risks and blockers at that level.

Communication

Why it fails: Not a core constraint.

Risk

Why it fails: Risk is an uncertain event.

Team member salaries

Why it fails: Team member salaries belong to HR or finance records, not the communication plan, which specifies what information is shared, with whom, when, and through which channel. It is tempting because personnel data can inform stakeholder analysis, and salary bands would be relevant when building a resourcing or budget plan rather than a communications matrix.

Personal contact information for all stakeholders

Why it fails: A communication plan defines who receives what, when, how and through which channel; individual contact details belong in a stakeholder register. Contact information is appropriate for a directory or escalation list, not the plan's core elements.

Vendor performance

Why it fails: Vendor performance measures supplier delivery against contracts, not how a stakeholder prefers to receive project information. It is tempting because procurement reporting genuinely belongs in communications planning when external suppliers are stakeholders, yet the stem asks for per-stakeholder factors such as influence, interest, and preferred channel.

Budget constraints

Why it fails: Budget constraints are a project-level consideration, not a per-stakeholder factor; the communication plan addresses each stakeholder's information needs, influence and preferred method and frequency. It is tempting because cost shapes overall communication channels, and would be correct when selecting enterprise-wide tools rather than planning individual engagement.

Risk tolerance

Why it fails: Risk tolerance describes how much uncertainty an organisation or individual accepts, governing contingency and escalation thresholds rather than communication needs. It is tempting because risk appetite is recorded in stakeholder registers, but the communication plan requires each stakeholder's interest, influence, and preferred format, channel, and frequency.

The project has the shortest payback period

Why it fails: The stem already states this project has the longest payback period, so claiming the shortest contradicts the given data and cannot be a factor. Payback period measures how quickly cumulative cash inflows recover the initial outlay, making it relevant when comparing proposals with similar NPVs or when liquidity constraints dominate.

The project has the lowest initial cost

Why it fails: Initial cost is not the deciding factor here; NPV already discounts all future cash flows against that outlay, so a low initial cost can still yield poor value. Initial cost matters when capital budgets are tightly capped and proposals must fit within a fixed funding envelope.

The project requires minimal resources

Why it fails: Minimal resource requirements address execution capacity, not the financial trade-off between NPV and payback period that the stem asks the manager to weigh. Resource minimisation is the right consideration when skilled staff or infrastructure are the binding constraint on which projects can proceed.

Testing

Why it fails: Testing is a phase within Executing, not a process group.

Designing

Why it fails: Designing is a phase, not a process group.

The extra features are necessary for regulatory compliance

Why it fails: Regulatory compliance is mandatory work, not optional scope, so it would never be a discretionary add-on funded from leftover budget. It tempts because compliance features do consume budget and must be delivered, but here all required features are already complete, making this irrelevant to the decision.

The extra features will improve customer satisfaction

Why it fails: Improving customer satisfaction is a benefit, not an issue, so it cannot be one of the two problems the project manager must weigh. It tempts because scope additions genuinely can raise satisfaction when budget and schedule allow, but the stem asks for risks of gold-plating under a tight budget.

The extra features are part of the original scope

Why it fails: Features already delivered within the approved scope cannot be "extra"; adding them is not scope creep, so this is not a valid concern. It is tempting because scope language appears relevant, and would be correct if the sponsor proposed functionality never baselined in the original requirements.

Encourage gold plating

Why it fails: Gold plating adds unrequested features beyond the agreed scope, directly worsening scope creep rather than controlling it. It is tempting because extra functionality can appear to add value, but it is only defensible when formally approved through change control as a documented scope change.

Remove the project sponsor

Why it fails: Removing the sponsor eliminates the person who authorises the project charter and resolves escalated scope decisions, which would stall change approval rather than control it. The sponsor's role is to champion the project and arbitrate on scope at governance level, so this action is relevant only when a sponsor is actively undermining the project, not when uncontrolled additions are arriving from stakeholders.

Fast track project activities

Why it fails: Fast tracking overlaps activities to compress the schedule; it addresses time, not scope, and can increase rework and risk. It is tempting as a recovery technique when deadlines slip, making it correct for schedule compression rather than for controlling unauthorised scope additions.

SWOT analysis

Why it fails: SWOT analysis examines internal strengths and weaknesses against external opportunities and threats, producing strategic context rather than numerical risk estimates. It is tempting because it is a recognised risk-identification technique, and it would be correct when framing strategy or identifying risks, but it yields no quantified probability or impact data.

Probability and impact matrix

Why it fails: The probability and impact matrix is a qualitative risk analysis tool, plotting likelihood against consequence to rank risks. It is tempting because it also uses probability and impact data, but it assigns ordinal ratings rather than the numerical probability distributions, EMV or Monte Carlo simulation that quantitative analysis requires.

The project is on schedule.

Why it fails: On schedule would have SPI = 1.

The project is under budget.

Why it fails: Under budget would have CPI > 1.

The project is behind schedule.

Why it fails: Behind schedule would have SPI < 1.

SWOT analysis

Why it fails: SWOT analysis assesses internal strengths and weaknesses against external opportunities and threats, producing no monetary figures such as ROI, NPV or payback period. It is tempting because it is a recognised project selection technique, but it belongs to the strategic, non-financial category, where it would be the right tool for comparing alignment with organisational capability.

Expert judgment

Why it fails: Expert judgment draws on specialist experience and opinion rather than calculating monetary returns, so it cannot rank initiatives by ROI, NPV or payback period. It is tempting because it is a legitimate selection input, and it would be the correct choice when scoring qualitative criteria such as regulatory risk or technical feasibility that resist financial quantification.

Requirements gathering

Why it fails: Requirements gathering is a scope and elicitation technique, producing no monetary figures for comparing candidate projects. It is tempting because it precedes selection and shapes the business case, and it would be correct when defining what a chosen project must deliver, not when ranking projects financially.

Lessons learned register

Why it fails: The lessons learned register is an organisational process asset updated throughout and after the project, not a component of the project management plan itself. It is tempting because lessons learned management is planned, but the register is a separate repository. The plan contains baselines and subsidiary plans such as scope, schedule and risk.

Actual cost reports

Why it fails: Actual cost reports record incurred expenditure during execution, so they are project performance data rather than a planning component. They are tempting because cost management features in the plan, but the reports themselves are produced by monitoring and controlling processes. A cost baseline, not actuals, belongs in the plan.

Project charter

Why it fails: The project charter authorises the project and precedes the project management plan; it is an input to developing that plan, not a component within it. It is tempting because both documents are foundational and approved by the sponsor. The plan comprises baselines and subsidiary management plans instead.

Issue log

Why it fails: An issue log tracks problems and their resolution status during the project; it is an input that informs lessons learned rather than a document used to capture them. It is tempting because resolved issues often yield lessons, and it would be correct when tracking open issues requiring active management attention.

Change log

Why it fails: A change log records change requests, approvals and implementation status; it does not capture the reflective lessons drawn from project experience. It is tempting because changes frequently generate lessons, and it would be correct when the goal is tracing change history, approvals and configuration baselines.

Risk register

Why it fails: A risk register documents identified risks, their analysis, owners and planned responses; it is an input to lessons learned, not a capture document. It is tempting because realised risks produce valuable lessons, and it would be correct when tracking and managing live project risks.