Question 3 of 8: Risk Activities, and a Testing-Team-Attrition Scenario

Question 3: Risk Activities, and a Testing-Team-Attrition Scenario (10 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Part a) — risk mitigation, monitoring, and management. Risk mitigation comprises the proactive activities carried out before a risk materialises, aimed at reducing its probability or its impact (e.g. cross-training staff, adding redundancy, choosing a proven technology over an untested one). Risk monitoring is the ongoing activity of tracking known risk factors and their leading indicators throughout the project (e.g. watching staff-satisfaction surveys or defect trends), so that a risk's probability of occurring can be re-assessed and escalated in time to act. Risk management (and contingency planning) covers the reactive activities carried out if and when a risk actually occurs — executing a pre-prepared contingency plan to contain the damage and keep the project moving, rather than improvising a response under pressure (Pressman Ch. 23, the "RMMM" — Risk Mitigation, Monitoring and Management — plan).

Part b) — managing 50% testing-team attrition after implementation. As project manager, the immediate response follows the RMMM contingency plan that should already exist for "key staff loss" (a routinely identified risk on any project, per Part a): (1) Contain the knowledge loss — conduct exit interviews and rapid knowledge-transfer sessions with the departing testers before they leave, capturing test plans, known-tricky areas of the system, and any tacit knowledge not already in the test documentation. (2) Re-baseline the schedule and scope — with half the testing capacity gone right as testing is about to ramp up, either extend the testing schedule, reduce scope via risk-based test prioritisation (spend the remaining capacity on the highest-risk/highest-usage functionality first, per Question 1's risk-management umbrella activity), or both; silently absorbing the loss without adjusting the plan is the single biggest mistake a PM can make here. (3) Reallocate and backfill — temporarily cross-train available developers to execute (not design) test cases, bring in contract testers, and begin recruiting permanent replacements immediately given the lead time involved. (4) Increase automation — if not already in place, prioritise automating the highest-value regression test cases so the remaining, smaller team's manual effort concentrates on new, exploratory and high-risk testing rather than repetitive regression runs.

Would agile help manage this risk? Partially, yes, but it is not a complete answer. In an agile process, testing is continuous and embedded within every sprint rather than concentrated into one large phase at the end (as the question's Waterfall-style "upon completion of the implementation phase" phrasing implies), so a mid-project departure loses less already-accumulated, un-executed test-case backlog, because most functionality delivered so far has already been tested as part of its own sprint. Test automation, a first-class practice in most agile methods (continuous integration, TDD/XP), also reduces reliance on a large manual-testing headcount in the first place. However, agile does not eliminate the risk: a small agile team still depends on the tacit domain and system knowledge of its testers, and losing half of them mid-project still shrinks the team's sustainable velocity and forces the same re-planning (re-prioritise the backlog, replan future sprints) that a Waterfall project would need — agile changes when the loss is felt and how gracefully the team absorbs it, not whether the loss is a real problem.