Free Project Management Professional (PMP) practice test: 30 questions with answers

Schedule compression, through crashing or fast-tracking, shortens the critical path, and comparing each option's added cost and risk lets the sponsor choose. Portfolio-level earned value does not show schedule options for this project. Levelling smooths resources without shortening the path, and re-baselining without analysis hides the cause.

Scrum teams manage sprint risk together, and re-scoping items while keeping the goal visible is the team's own decision. Extending the sprint breaks the timebox, and adding people mid-sprint slows the team as they ramp up. Cancelling is reserved for cases where the goal has become invalid, not for a risk on day six.

A contingency response prepares the team to act if the low-probability event happens, which limits the damage to the launch. Ignoring a high-impact risk leaves the launch exposed, and removing the date is not a realistic response. Assigning the risk to one person and closing it does not plan a response at all.

Iterative delivery with short feedback cycles suits uncertain requirements, because each iteration produces evidence that shapes the next. A fixed scope and a single release assume the requirements are already known. Fixed-price contracts and complete upfront plans assume the same certainty.

Assessing impact and submitting the change to change control gives the decision makers the information needed to approve or reject it. An informal agreement bypasses the governance process. Rejecting without documentation and backlog additions without assessment both leave the baseline and its risks unmanaged.

A schedule performance index below 1.0 means earned value is lower than planned value, so the project is behind schedule. A cost performance index above 1.0 says nothing about schedule, and a zero variance at completion or an estimate equal to budget would indicate the project is on plan.

Three-point estimating uses optimistic, most likely and pessimistic values and weights them, which produces an expected value with a range. Analogous and parametric estimating use reference data rather than a range of values, and bottom-up estimating adds up detail without showing a range for each activity.

A product backlog ordered by value tracks the iterative workstream's work, and it fits within the predictive plan at the program level. A Gantt chart and a work breakdown structure without iterations do not track iterative work, and a risk register records threats rather than the work itself.

Peer reviews and inspections during development find defects while they are cheap to fix, which prevents them from reaching release. Final inspection, acceptance testing and warranty tracking all find defects later, when the cost of fixing them is higher.

Baselines change only through approved change control, which keeps changes visible and justified. Free changes remove the reference point for measuring performance, and baselines are reviewed and updated through governance rather than kept unchanged. Baselines exist for scope, schedule and cost, not for cost alone.

A private conversation reveals the cause, which could be workload, a technical blocker or a personal issue, before any action is taken. Reporting the developer to a manager skips the step that would reveal the cause. Reassigning work without discussion removes the person from the problem, and daily check-ins with the product owner add pressure without addressing what is going on.

A direct conversation explains the change process and shows the cost and schedule effect of each request, which addresses the behaviour while keeping the stakeholder engaged. Granting everything removes control of scope, and ignoring requests frustrates the stakeholder. Escalating immediately, without a conversation, damages the relationship before it has been tried.

Facilitating the discussion lets the team compare trade-offs against agreed criteria, which produces a decision the team owns. Imposing a design or using chance skips the reasoning. Escalating to the sponsor is appropriate only if the team cannot resolve the disagreement itself.

A short, planned onboarding with a buddy and clear first tasks limits the disruption and gets the new member productive sooner, and reassessing capacity keeps the plan realistic. Learning alone from documentation is slow, delaying onboarding leaves capacity idle, and no onboarding causes avoidable errors.

A communication plan records each stakeholder's needs, format and frequency, and it keeps the effort manageable while meeting the requirements. Sending the same update to everyone ignores differing needs, and updates only on problems leave stakeholders uninformed. Separate formats for each request create unmanageable work.

Coaching the team on decision-making techniques and giving members the chance to practise builds the team's capability, which lasts beyond the project. Making decisions for the team removes ownership, and removing meetings does not solve the problem. Replacing the lead is an extreme step that the scenario does not justify.

The dependency owner can agree a plan and a date directly, which resolves the block fastest. Escalating straight to the sponsor or the customer skips the people who can act, and procurement is relevant only if the dependency is bought.

A servant leader removes blockers that sit outside the team by coordinating with stakeholders, and facilitates retrospectives so the team improves its own ways of working. Assigning tasks and setting priorities without the product owner take ownership away from the team, and fixed reporting schedules add overhead without removing impediments.

Collaboration and problem-solving address the underlying needs and causes, which keeps the relationship healthy over time. Forcing ends the discussion without buy-in, withdrawing leaves the problem in place, and smoothing hides it until it returns.

Asking the team what changed and discussing it at the retrospective uncovers the real causes, such as new dependencies or unfamiliar roles, so the team can act on them. Raising the target ignores the cause, and replacing members or comparing with another team is premature and unfair.

An impact assessment shows which deliverables, dates and risks change, and it gives the sponsor the information needed to decide on scope and funding. Building before assessing risks wasted work, and ignoring or removing deliverables without consultation exposes the organisation to non-compliance.

Organisational change management with training, sponsor reinforcement and adoption metrics addresses the resistance that stops benefits from being realised. Closing at deployment leaves the benefit at risk. A mandate without support creates resentment, and delaying measurement hides whether the benefit is being achieved.

Reviewing the business case with the sponsor confirms whether the project still delivers its intended value in the changed market, which should drive any decision to change scope. Adding people or stopping the project react before the facts are known, and copying the competitor's features may not serve the business case.

The business case explains why the investment is worth making, in terms of benefits, costs and alignment with strategy, and it is revisited during the project. The project management plan describes execution, lessons learned records experience, and the resource breakdown structure lists resources.

An updated business case shows whether the expected benefits still justify the investment, which is the decision the board is making. Velocity, task lists and overtime describe activity and effort, not the value the investment will deliver.

Closing includes documenting lessons learned, releasing resources, and closing contracts and administrative records. Identifying stakeholders, defining scope and developing the schedule all happen during earlier processes.

Value depends on realising the expected benefits after delivery and on the project's outcomes supporting strategic objectives. Report design, meeting counts and team size do not determine whether the organisation gains value from the result.

Reviewing alignment with the sponsor and the portfolio board establishes whether the project still supports the strategy, which should drive any decision to continue, change or stop. Continuing unchanged ignores the strategic shift, and stopping or adding features before the review are decisions taken without the evidence.

Managing a portfolio prioritises investment and resources across projects against strategic objectives, so the organisation spends where it gains most. Independent tools and isolated management lose that coordination, and approving projects without priorities defeats the purpose of a portfolio.

Benefit realisation tracking compares the value the product delivers in use with the business case, which shows that the intended benefit is not being achieved. On-time and budget measures show delivery performance, and change requests count activity, so none of them show the value gap.