Free Certified Associate in Project Management (CAPM) practice test: 30 questions with answers

A predictive approach works best when requirements are stable and well understood, because the plan can be built up front and changed through formal control. Unclear or changing requirements, frequent feedback needs and domain learning all favour adaptive approaches.

Estimating activity durations assigns a time to each activity, using techniques such as analogous, parametric and three-point estimation. Sequencing sets the order, controlling monitors progress, and developing the schedule combines durations and logic into dates.

Expected monetary value multiplies the probability by the impact, so 0.30 times 50,000 gives 15,000. Subtracting or adding the probability to the impact does not measure exposure, and ignoring probability overstates the risk.

Mitigation reduces the probability or the impact of a threat, for example by adding testing or a second supplier. Acceptance does not reduce the threat, transfer moves the risk to another party such as an insurer, and escalation changes who manages it without addressing it.

The critical path method identifies the longest sequence of dependent activities, which determines the shortest possible duration. Pareto analysis, the responsibility matrix and fishbone diagrams are useful tools for quality, roles and root cause analysis but do not calculate the schedule network.

The risk register records identified risks, their causes and planned responses, and it is updated throughout the project. It is not closed at charter signing, it does not replace the issue log, and it should be shared with the team that manages the risks.

The schedule performance index is earned value divided by planned value, here 80,000 over 100,000, which gives 0.80. An index below 1 means the project is behind schedule. Dividing the other way gives 1.25, and the variance of minus 20,000 is an amount, not an index.

A request for proposal invites suppliers to propose a solution, approach and price for a defined need, so the buyer can compare them. A purchase order authorises payment, a service-level agreement sets performance standards after a contract is signed, and a bill of materials lists components.

The Product Owner is accountable for the product backlog, including ordering items to maximise value. The Scrum Master coaches the process, the sponsor funds the work, and the development team selects work from the backlog but does not own its order.

The Daily Scrum is a 15-minute event where developers inspect progress toward the sprint goal and plan the next 24 hours. The sprint review, retrospective and sprint planning are different events with different purposes and timeboxes.

A work-in-progress limit on the testing column stops more work entering it than can be handled, which makes the bottleneck visible and forces the team to resolve it. Adding work worsens the queue, removing testing hides the problem, and assigning work to the sponsor does not improve flow.

The sprint backlog holds the sprint goal, the selected items and the plan the developers use to deliver the increment. The product backlog is the wider list of desired work, the increment is the output, and the burndown chart is an information radiator.

A minimum viable product or prototype gives the customer something to try early, so feedback can shape the rest of the work. A detailed document before coding, delayed demonstrations and testing after delivery all delay the learning the customer needs.

The sprint review, the Daily Scrum and the sprint retrospective are Scrum events. The project steering committee and the change control board are governance bodies from predictive project management, not Scrum events.

The Scrum Master is accountable for the framework being understood and followed, and for removing impediments. The Product Owner manages value and the backlog, the development team owns the technical approach, and stakeholders provide input rather than approving every change.

Velocity is the average amount of work the team completes per sprint, and it helps forecast how much fits in future sprints. Burnout, lead time and escape rate measure other things and are not forecasting measures for story points.

A project is temporary, with a defined beginning and end, and it produces a unique product, service or result. Operations are ongoing and repeat outputs, so the reversed statement is wrong. Budget and scope do not define the difference, and operations do not end at delivery.

The business case explains why the organisation should invest, what benefits are expected and whether the work is worth doing. The project charter authorises the work, and the stakeholder and risk registers track people and uncertainty rather than the justification for funding.

A stakeholder with high power and low interest should be kept satisfied, with concise updates that focus on what they need to decide. Monitoring alone risks surprising a powerful person, and daily meetings overload someone who has little interest in the detail.

Perform integrated change control is the process that reviews each change request, assesses its impact across the project and decides whether to approve it. Planning how scope is managed, accepting deliverables and closing work are different processes.

Schedule variance equals earned value minus planned value, so a negative result means the project is behind schedule. Actual cost minus earned value is cost variance, dividing planned value by earned value inverts the schedule performance index, and the last calculation is the expected final variance.

A work breakdown structure is a hierarchical decomposition of the project's deliverables into smaller components, which makes the full scope visible. Critical path analysis, risk breakdowns and resource histograms are useful tools, but none of them decomposes the scope of work.

The project charter formally authorises the project, gives the project manager authority and summarises the high-level requirements and objectives. The management plan is developed afterwards, the WBS follows from the scope, and the lessons learned register is maintained throughout the project rather than created as an authorisation.

Observation, often called job shadowing, reveals how work is really done, including workarounds that users may not mention in an interview. Benchmarking, brainstorming and document analysis are useful elicitation or analysis techniques, but none of them observes the user at work.

A requirements traceability matrix links each requirement to its design, tests and delivered features, which shows coverage and the impact of a change. The engagement plan, issue log and risk burndown each track a different kind of information.

Decision analysis compares options against agreed, weighted criteria to support a choice that can be explained to stakeholders. Elicitation gathers needs rather than choosing among options, risk identification lists threats, and schedule compression is a schedule technique.

The financial analysis in a business case sets out costs, benefits and return over time so the investment can be judged. A team charter, change log and review notes are project documents that support delivery rather than justify the investment.

Non-functional requirements set quality attributes such as performance, security and availability, while functional requirements describe behaviour. Transition requirements cover the move to the new solution, and business rules define logic rather than quality conditions.

A facilitated workshop brings the affected stakeholders together to understand the conflict, weigh the options and agree on a decision that is recorded. Picking the senior person's view skips the analysis, dropping both leaves a real need unmet, and deferring to testing wastes time.

Interviews and facilitated workshops are two of the most common ways to elicit requirements from stakeholders. Earned value, critical path analysis and Monte Carlo schedule simulation are planning and analysis techniques used in other areas.