Project Life Cycle practice questions

Business case

Why it fails: A business case justifies the project’s existence by outlining costs, benefits, and risks, but it does not formally authorise work or assign a project manager. The correct document—the project charter—grants that formal authority and names the project manager. The business case is tempting because it precedes the charter in the project lifecycle and often contains the initial recommendation, yet it lacks the binding approval signature that triggers resource allocation.

Project scope statement

Why it fails: The project scope statement defines deliverables, boundaries, and acceptance criteria, but it does not contain the formal approval to commit organisational resources or assign the project manager. It is tempting because it is a foundational document created early in planning, yet it lacks the authorisation signature that a project charter provides. In a scenario where the question asked which document defines the work to be done, the scope statement would be correct.

Project plan

Why it fails: A project plan describes scope, schedule and execution approach; it grants no authority. The project charter is the document that formally authorises the project and names the project manager. The plan is tempting because it is the central artefact the manager owns and maintains throughout delivery, but it is created after authorisation.

Procurement contract

Why it fails: The contract includes legal terms, but the SOW has technical details.

Risk register

Why it fails: The risk register lists risks and responses, not specifications.

Project charter

Why it fails: The project charter authorises the project’s existence and names the project manager, but it does not contain the detailed technical or acceptance criteria for deliverables. The scenario requires a document that defines the specific product specifications, which only the SOW provides. This option is tempting because the charter is often consulted for high-level scope boundaries, and it would be the correct reference if the dispute involved whether the project itself was authorised or the manager’s authority was questioned.

Final project report

Why it fails: The final report is produced at closure.

Lessons learned

Why it fails: Lessons learned are created during closing, not used as input to change control.

Performance measurement baseline

Why it fails: The baseline is updated after approval, not an input to the change control process.

Project charter

Why it fails: The charter authorizes the project.

Scope statement

Why it fails: The scope statement defines what is included.

Lessons learned

Why it fails: Lessons learned capture knowledge.

2 days

Why it fails: 2 days is incorrect because it does not account for the dependency on Activity C. The late finish of B is constrained by C's start, not directly by the project end date.

1 day

Why it fails: 1 day is incorrect because the calculation ignores the critical path influence of B on C.

3 days

Why it fails: 3 days is incorrect as it would indicate excessive float not supported by the schedule constraints.

The activity is on the critical path.

Why it fails: Critical path has zero float.

The total float is -2 days.

Why it fails: Float cannot be negative if LS > ES.

The activity has free float of 2 days.

Why it fails: Free float may differ; total float is 2.

Inform the sponsor of the change

Why it fails: The sponsor may be informed, but the first step is to submit a change request.

Implement the change immediately

Why it fails: Changes must go through the change control process.

Update the project baseline

Why it fails: Baselines are updated only after approval.

Project charter

Why it fails: The project charter is produced during initiation, authorising the project and naming the sponsor and manager, so it cannot be a monitoring and controlling output. It is tempting because charters are revisited when scope changes, but monitoring and controlling instead yields work performance reports and change requests.

Risk register

Why it fails: A risk register is created during planning and updated as risks are identified and monitored, so it is an input and ongoing artefact rather than a distinct monitoring and controlling output. It is tempting because risk monitoring does occur in that group, but the outputs there are work performance reports and change requests.

Work breakdown structure

Why it fails: The work breakdown structure is created during planning, decomposing scope into deliverables, so it is not a monitoring and controlling output. It is tempting because the WBS is referenced when verifying scope, but that process instead produces work performance information, change requests and accepted deliverables.

1 day

Why it fails: Incorrect calculation.

2 days

Why it fails: 2 days is the float for activity B, not C.

5 days

Why it fails: 5 days is the duration of A, not float.

Ignore

Why it fails: Ignoring is not a valid risk response; acceptance is the appropriate passive strategy.

Enhance

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

Team members disengage as the project ends.

Why it fails: Disengagement as the project ends describes the adjourning stage, where the team disbands after delivery. It is tempting because it reflects a recognisable late-project behaviour, and would be correct when the work is complete and members are moving on.

Team members are polite and avoid conflict.

Why it fails: Politeness and conflict avoidance describe the forming stage, where members are cautious and orientating. It is tempting because it sounds like early team friction, and would be correct before storming begins, when roles and relationships are still being established.

Team members work collaboratively and efficiently.

Why it fails: Collaborative, efficient working describes the performing stage, where the team operates as a cohesive unit. It is tempting because it is the desired end state, and would be correct once storming and norming have been resolved and the team focuses on delivery.

Cost-reimbursable

Why it fails: Cost-reimbursable contracts pay the seller's actual allowable costs, so overruns are largely borne by the buyer, not the seller. It is tempting because it suits uncertain scope where costs cannot be estimated reliably, but the seller's profit is protected rather than exposed.

Time and materials (T&M)

Why it fails: Time and materials pays the seller for hours worked plus materials, so the buyer bears cost growth when effort expands. It is tempting for staff augmentation or undefined-duration work, but the seller recovers incurred labour rather than absorbing overrun risk itself.

Cost-plus-fixed-fee

Why it fails: Cost-plus-fixed-fee reimburses allowable costs and adds a fixed profit, so the buyer absorbs cost overruns while the seller's fee stays constant. It is tempting for research or development work with undefined scope, but it caps the seller's exposure rather than maximising it.

21 days

Why it fails: Incorrect addition.

20 days

Why it fails: The delay extends the critical path.

23 days

Why it fails: Incorrect.

Ignore

Why it fails: Ignoring is not a proactive response.

Enhance

Why it fails: Enhance is for opportunities, not threats.

Escalate

Why it fails: Escalate is not a standard response; it's for when risk is beyond PM authority.

The project is over budget and behind schedule.

Why it fails: CPI of 1.2 means earned value exceeds actual cost, so the project is under budget, not over. The schedule half is correct. It is tempting because SPI below 1.0 does indicate behind schedule, so the accurate second clause lends false credibility to the inverted cost claim.

The project is over budget and ahead of schedule.

Why it fails: CPI of 1.2 means earned value exceeds actual cost, so the project is under budget, not over. The option inverts the cost index. It is tempting when a learner reads any index above 1.0 as unfavourable, but CPI and SPI both measure favourability above 1.0, making this pairing internally inconsistent.

The project is under budget and ahead of schedule.

Why it fails: SPI of 0.9 means earned value lags planned value, so the project is behind schedule, not ahead. The cost half is right, the schedule half is inverted. It is tempting because CPI above 1.0 genuinely signals under budget, so half the statement reads correctly and masks the schedule error.

Exploit

Why it fails: Exploit is a strategy for positive risks, not negative risks.

Accept

Why it fails: Accept is a valid strategy but is passive; the question asked for three proactive strategies, so it is not included.

Actual start and end dates

Why it fails: Actual dates are recorded during execution, not part of baseline.

Resource assignments

Why it fails: Resource assignments are part of resource management, not necessarily schedule baseline.

Team members are polite but unsure of their roles.

Why it fails: This describes Forming stage behavior.

Team members resolve conflicts openly and constructively.

Why it fails: This is more characteristic of the Norming stage, where ground rules are established and conflicts are resolved.

Team members are independent and rely on the project manager for guidance.

Why it fails: This is characteristic of the Forming stage, not Performing.

Medium power, medium interest

Why it fails: Incorrect. This quadrant is not standard in the power/interest grid; typical quadrants are high/low power and high/low interest. Even if considered, it would not be 'Manage Closely' as power is medium.

High power, low interest

Why it fails: High power, low interest stakeholders are kept satisfied, since they can block the project but need not be consulted on detail. Manage Closely applies to high power, high interest stakeholders, who require active engagement and regular communication. The quadrant determines the engagement strategy, not the stakeholder's authority alone.

Low power, low interest

Why it fails: Stakeholders in the low-power, low-interest quadrant require only monitoring, not close management, because they lack influence to affect the project and are unlikely to engage. The 'Manage Closely' strategy is reserved for high-power, high-interest stakeholders, whose active support is critical. This option is tempting because low-power, low-interest stakeholders are often numerous and easy to overlook, but a project manager would correctly apply 'Monitor' here, not 'Manage Closely'.

Low power, high interest

Why it fails: Incorrect. Low power, high interest stakeholders should be kept informed but not managed closely.

The project manager's preferred communication style

Why it fails: The plan should address stakeholder preferences, not the manager's style.

The number of project team members

Why it fails: Team size may influence communication but is not a primary factor for individual stakeholder needs.