What is project management?
Project management assessment skills involve defining outcomes, understanding dependencies, managing uncertainty and changes, and making delivery status and decisions clear under the supplied governance and constraints. The worked questions cover a dependency and the critical path, a risk or an issue?, a scope change, acceptance criteria, reading earned-value indicators, an unresolved dependency. Use the explained answers to check your method, then practise applying the same principles to fresh facts instead of memorising an answer sequence.
Why this skill matters
Activity completion, accepted output and achieved outcome are different states. A plan also depends on assumptions that can change, so its baseline and forecast should remain distinguishable. The worked questions connect network calculations with risks, scope, acceptance and stakeholder decisions. They show why accurate reporting and an explicit owner can matter as much as choosing the correct numerical formula.
A subject-specific method
Step 1
Define the required outcome and acceptance criteria, distinguishing completion of an activity from evidence that the promised deliverable is accepted.
Step 2
Map dependencies and assumptions before calculating dates, identifying which sequence controls completion under the resource and calendar rules the question supplies.
Step 3
Assign owners and responses to uncertainties, distinguishing a possible future risk from an issue that has already occurred and needs present action.
Step 4
Assess a proposed change across scope, schedule, cost, quality and dependencies before seeking the appropriate decision instead of silently changing the baseline.
Step 5
Report status, impact and next decisions clearly, preserving the difference between an approved baseline, a current forecast and an unverified recovery promise.
Original worked scenario
Scenario: A launch depends on a security review that is running five days late. Task: Choose the best supported response or conclusion. Worked answer: Assess the critical path, update stakeholders, explore mitigation and avoid bypassing required security controls. Why this works: The late security review is a dependency whose schedule impact must be assessed, rather than automatically assuming a five-day final delay. Stakeholders need the impact, options and owner. Any mitigation must respect required assurance; an approaching launch date does not authorise silently removing a prerequisite control. Common trap: A deadline does not justify removing essential assurance steps.
How to prepare effectively
Draw small dependency networks and calculate the finish date under explicit assumptions. Check parallel branches before adding durations. Then change one task duration and see whether the controlling path changes. This makes the critical-path idea concrete and prevents the shortcut of assuming that the longest individual task always determines the project's finish. For risk practice, write an uncertain event, its potential effect, an owner and a response. Separately record conditions that have already happened as issues. A contingency trigger is useful only if someone knows when to act. Do not treat listing a risk as equivalent to reducing or managing it. For scope scenarios, prepare an impact note that explains the requested change and its consequences. Include assumptions and alternatives where relevant, such as deferring a lower-priority feature or changing a date. A change process should support informed decisions, not automatically reject improvement or conceal additional work behind an unchanged commitment. Use acceptance exercises to distinguish developed, tested, reviewed and accepted. The relevant criteria may differ by deliverable, but a status label should reflect the agreed definition. Ask what evidence would let another person verify the claim. This is especially important when a dashboard percentage could otherwise hide unfinished review or user validation. In progress reporting, state what changed, what the effect is and which decision or action is needed. The recipient should understand the dependency and its owner without reading a large narrative. During assessment preparation, practise calculations and judgement separately, then combine them. In the formal attempt, use the framework, value definitions and governance rules actually supplied rather than importing assumptions from another project.
Mistakes that reduce scores
Do not add parallel task durations as though they were sequential, label an existing failure only as a future risk or call a deliverable accepted before its criteria are met. Changing a forecast does not authorise rewriting the baseline. Report the impact and decision needed rather than hiding the variance.
Frequently asked questions
Why not add every task duration?
Tasks may run in parallel. Calculate dependencies and the controlling path under the resource and calendar assumptions supplied.
How does a risk differ from an issue?
A risk is uncertain; an issue has already occurred. Their ownership and actions should reflect that difference.
Does development finished mean accepted?
Only if the agreed acceptance conditions are met. Testing or user review can remain outstanding under the stated criteria.
Does changing a forecast change the baseline?
No. Keep the original commitment, current expectation and approved changes distinguishable so that variance remains visible.
Project management: make objectives, dependencies and decisions visible
A project management assessment can test scope, schedules, risk, stakeholders, change control and delivery decisions. Start with the intended outcome and acceptance criteria. Completing many activities does not establish that the required result has been achieved. A project that delivers the wrong capability on time still has an outcome problem. Distinguish a plan from a guarantee. Estimates depend on assumptions, resources and uncertainty. A useful plan makes dependencies and decision points visible so that changes can be assessed. It does not hide a missed milestone by moving dates without explaining the consequence. The strongest assessment answer often identifies the next decision and who is authorised to make it. The following simplified exercises state the scheduling and financial assumptions needed for their calculations. Real projects may include calendars, resource constraints, overlapping work, probabilistic estimates and contractual rules. Do not apply a simple model beyond its assumptions or use one performance measure as a complete verdict on the project.
Question 1: A dependency and the critical path
Tasks B and C both begin after A. A takes 3 days, B takes 4 and C takes 6. D takes 2 days and begins only after both B and C finish. With unlimited resources and no other constraints, what is the shortest completion time? Answer: Eleven days: 3 for A, 6 for the longer parallel branch C and 2 for D. The A-C-D path controls completion under these assumptions. Adding every duration gives 15 and incorrectly treats B and C as sequential. The shorter B branch has two days of scheduling flexibility relative to C in this simplified network. Resource limits or different dependency rules could change the result, so identify those assumptions before generalising.
Question 2: A risk or an issue?
A supplier might deliver a component late next month. A different component has already failed its acceptance test today. How should the two matters be distinguished in the project record? Answer: The possible late delivery is a risk; the failed test is an existing issue. Both need owners and proportionate actions, but the uncertainty differs. A risk response may reduce likelihood or impact and define a contingency trigger. An issue requires management of a condition that has already occurred. Calling an existing failure only a future risk can delay action, while treating every possibility as an actual failure can distort the project's current status.
Question 3: A scope change
A stakeholder requests an additional report after the delivery baseline is agreed. The team believes it will add five days of work. What should happen before the team commits to the request? Answer: Clarify the requirement, assess effects on scope, time, cost, quality and dependencies, then obtain the appropriate change decision. Do not silently add the work while continuing to promise the unchanged baseline. Equally, do not reject every change merely because a plan exists. Change control provides an informed decision process. The right outcome could be approval, deferral, substitution or rejection depending on value, constraints and authority.
Question 4: Acceptance criteria
A team reports that a software feature is complete because development has finished. The agreed acceptance criteria also require a verified export and user review, neither of which has occurred. Is the feature accepted under those criteria? Answer: No. Development completion is not the same as satisfying the full acceptance conditions. Report the actual state and arrange the remaining verification and review. Do not redefine complete after the fact merely to improve the progress figure. The scenario does not imply that every project needs the same review steps; it states that these steps were agreed here. Trace the status to the governing criteria rather than a convenient activity milestone.
Question 5: Reading earned-value indicators
A simplified project report gives earned value of 80, planned value of 100 and actual cost of 90, in consistent units. What are its cost performance index and schedule performance index? Answer: CPI is 80 divided by 90, approximately 0.89; SPI is 80 divided by 100 = 0.80. Under the supplied definitions, earned value is below both actual cost and planned value. These are warning indicators, not a complete forecast or a precise number of days late. Check how progress and value were measured before relying on the ratios. A forecast needs appropriate assumptions about remaining work and future performance.
Question 6: An unresolved dependency
A project team cannot test until another department provides approved data. The promised delivery date has passed. What is a stronger status update than simply reporting testing delayed? Answer: Identify the dependency, its owner, the current consequence, the decision or action needed and the next review point. Propose realistic alternatives where available, such as testing unaffected components, without claiming those alternatives remove the dependency completely. A useful update supports action. It should not conceal uncertainty, assign blame without evidence or promise a recovery date that the responsible parties have not agreed and cannot support.
Preparing with a decision-focused project log
For each scenario, record the objective, constraint, owner, evidence and next action. A schedule question needs dependency logic; a change question needs impact and authority; an acceptance question needs criteria and evidence. This keeps a familiar project-management term from becoming a substitute for reasoning about the actual situation. Practise small networks by hand and check the path that controls the finish date. Then change one duration and see whether the critical path changes. For risk scenarios, distinguish prevention, contingency and issue resolution. For stakeholder questions, tailor the information to the decision rather than sending everyone a large undifferentiated report. During a formal assessment, apply its specified framework and definitions, since organisations can use different terminology and governance arrangements for similar work.
Continue with the matching discipline
Explore the Project Management assessment, using the production skill name shown on that page. Review the assessment format, current access terms and account requirements before starting. A skills assessment does not guarantee employment or a particular result.
A final practical check
When updating a plan, preserve the distinction between the original baseline, current forecast and approved change. Moving a forecast date is useful information; silently rewriting the baseline can hide the very variance stakeholders need to understand.