Project Risk Management
Project risk management is how a test manager keeps the testing of a release possible when the project around it goes wrong. A project risk is an uncertain event that, if it occurs, affects the project’s schedule, budget or scope rather than the quality of the product. For example, the payment provider’s shared sandbox (its test version of the service) may be down for days during the test window, blocking every payment test.
Managing it is a loop that runs for the whole release: describe each risk precisely, rate its likelihood and impact, choose a response, give it one owner and, where needed, a trigger, keep it in a risk log (also called a risk register), review it at fixed points, and report what is still open at the go/no-go meeting, where the release owners decide whether to ship.
Why it matters
When a project risk occurs and nobody planned for it, testing usually absorbs the damage. The environment arrives a week late, the release date does not move, and the test window quietly shrinks. The product risks that testing was meant to reduce are then tested less, and nobody decided that on purpose.
For the test manager, a risk log turns complaints into decisions: "we still have no test data" becomes a recorded risk with an owner, a deadline and a fallback, raised while there is time to act. At go/no-go the same log shows how project problems changed the testing, before anyone finds the gap in production.
Project risk and where it comes from
A recap from the Risk-Based Testing guide: ISTQB CTFL v4.0 separates product risks, ways the product could fail its users (a wrong total, a data leak), from project risks, ways the project could fail to deliver on time, on budget or in full. Testing reduces product risk directly, because a test can reveal the feared failure before users meet it; more test cases do not make a late environment arrive. Both kinds are rated by likelihood and impact, which give the risk level, and are kept in separate lists with separate owners.
Write each risk as cause, event and effect so that a response has something to act on: the payment sandbox is shared with other clients (cause), so it may be unavailable in our test window (event) and block the payment tests (effect). A certain event, such as a fixed go-live date, is not a risk but a constraint to plan around.
The syllabus groups project risks into organisational, people, technical and supplier issues. For testing they usually show up in four places:
- Environments: staging shared with another team, a test environment unlike production, a sandbox down during the test window.
- Staffing: the only person who knows an integration, a tester moved to another project, a test type nobody has done before.
- Suppliers: a third-party API late or changed without notice, an outsourced team that misses a delivery.
- Schedule: late builds, an estimate with no time for retesting, a fixed release date that makes the test window the buffer.
Choosing a response
Once a risk has been analysed, CTFL v4.0 (section 5.2.4) gives four examples of possible responses: risk mitigation by testing, risk acceptance, risk transfer and a contingency plan. That section is about product risks; for project risks the same options apply, but mitigation means management action rather than tests. General risk management practice adds a fifth option, avoidance.
Options combine, and a useful starting point links them to the rating: mitigate more as likelihood rises, add a contingency plan or a transfer as impact rises, and when both are high consider avoidance and escalate. In practice:
- Acceptance: the risk is small, or responding costs more than the damage. Record who accepted it and keep watching; acceptance is a named decision, not silence.
- Transfer: move the risk to a party better able to carry it, such as a specialist firm contracted to run the load test by a fixed date. The firm’s delivery then becomes a supplier risk in your log.
- Contingency plan: decide now what you will do if the risk occurs (test against a mock, borrow a tester, defer low-risk tests), and agree the trigger that starts it.
- Mitigation: act now to lower likelihood or impact: book the environment early, pair a second tester with the only expert, ask for smaller, earlier builds.
- Avoidance: remove the cause by changing the plan, such as moving a feature that depends on an unready supplier to the next release; it changes scope, so the product owner decides.
| Likelihood | Impact | ||
|---|---|---|---|
| Low | Medium | High | |
| High | Mitigate or acceptfrequent but small: mitigate if it is cheap | Mitigateact now to make it less likely | Avoid, or mitigate + contingency plan or transferescalate: date, scope or budget |
| Medium | Accept and monitorrecord who accepted it | Mitigate or contingency plancompare what each costs | Mitigate + contingency planagree the trigger in advance |
| Low | Acceptnote it in the log | Accept and monitorre-rate it at each review | Contingency plan or transferrare but severe: never just accept |
- Accept: record the decision and keep watching
- Respond if the cost is justified
- Respond now: act or prepare before it occurs
- Escalate: the decision is above the test team
- Low likelihood, high impact: plan for it even though it is rare
- The five responses
- Accept live with it by a recorded decision, naming who decided
- Transfer a better-placed party carries it, usually by contract
- Contingency plan prepared now, started only when its trigger fires
- Mitigate act now to lower the likelihood or the impact
- Avoid change the plan so that the cause disappears
A starting point, not a rule: the cost of each response and who is able to act also decide the choice.
Mitigation by testing
When a project risk lands on a product risk, for example a late build that cuts the time left for a high-risk feature, testing cannot bring the build sooner, but it decides where the remaining effort goes; what stays untested becomes residual risk to report. CTFL v4.0 lists these actions for mitigating product risks by testing:
- Select testers with the experience and skills the risk type needs.
- Apply the right level of independence: a high-risk area is tested by someone who did not build it.
- Conduct reviews and static analysis, which work before the environment is ready.
- Apply suitable test techniques and coverage levels, such as decision tables for pricing rules.
- Apply test types for the affected quality characteristics, such as performance tests for a capacity risk.
- Perform dynamic testing, including regression testing, so rushed fixes do not break what worked.
Try it: Risk-Based Test Generator Try it: Regression Scenario Generator
Triggers, owners and the risk log
A contingency trigger is an observable condition, agreed in advance, that starts the fallback, such as "the payment build is not in the test environment by the end of day 5". Without one, the team waits and hopes until there is no time left to use the fallback.
Each risk has one owner: a named person, not a team, who watches it, carries out the response and reports its status, often from outside QA (the development lead for builds, the operations lead for environments, the vendor manager for suppliers). Agree an escalation rule too: when a response needs a decision on date, scope or budget, the owner takes it to the project manager or product owner with options and a decision date.
Keep the log through the whole release:
- Raise risks at test planning, and add new ones on the day they appear.
- Review the log at fixed points: the weekly status meeting, the end of each test cycle and before go/no-go.
- Record changes with dates: re-ratings, triggers fired, decisions and who made them.
- When a risk occurs, mark it as an issue and track its effect on testing; close a risk only with evidence or a recorded acceptance.
Worked example: from risk log to go/no-go
A fictional clinic booking app, release 2.4, adds online payment through a third-party provider and SMS reminders; the test window is 15 working days and go-live is fixed. Two contingency triggers fired during the release. The log at the end of this section shows the five project risks at the go/no-go meeting.
At go/no-go the test manager does not read the log aloud. The project-risk part of the report answers three questions:
- What happened and what it did to testing: the sandbox outage (rated Low likelihood, but given a contingency plan because of its High impact) was covered by the mock and a retest of 8 key flows; the late build triggered the contingency plan.
- What it left untested: regression of the reports module, whose product risks are Low. The product owner accepted this in writing on day 7, and it is listed as residual risk.
- What the meeting must decide: confirm the release with that residual risk, and the deferred regression in the first week after release.
Project risk log - Clinic booking 2.4 - status at go/no-go (day 15)
PR1 Shared payment sandbox -> down in our window -> payment tests blocked
L Low | I High Contingency: test on the provider mock, retest later
Trigger: sandbox down > 4 working hours Owner: test lead
Day 6: TRIGGERED. Day 11: 8 key flows retested on the sandbox. CLOSED
PR2 Only Omar knows the SMS gateway -> he is away -> SMS tests stall
L Medium | I Medium Mitigation: Huda pairs with Omar on days 1 to 3
Owner: QA manager Day 3: test notes written. CLOSED
PR3 Payment build late -> test window shrinks -> regression cut
L High | I High Mitigation: two smaller drops
Contingency: defer Low-risk regression
Trigger: build not in test by end of day 5 Owner: test manager
Day 6: TRIGGERED, escalated. Day 7: product owner accepts deferring
the reports-module regression to week 1 after release. ISSUE, open
PR4 No load-test skills in the team -> peak-hour test not done
L High | I High Transfer: specialist firm, report due day 12
Owner: QA manager Day 12: report received. CLOSED
PR5 Insurer API has no test environment -> eligibility check untestable
L High | I High Avoidance: eligibility check moved to release 2.5
Owner: product owner Day 2: decided. CLOSEDCommon mistakes
- Mixing project and product risks in one list, or answering a late environment with more test cases.
- Logging certainties as risks: a fixed go-live date or a planned holiday is a constraint to plan around, not an uncertain event.
- Writing a contingency plan without a trigger, so nobody knows when to switch and the fallback starts too late.
- Naming a team ("Dev", "QA") or nobody as the owner, and having no rule for escalating decisions the test team cannot make.
- Absorbing a project risk silently by shrinking testing, so the go/no-go report hides the coverage that was lost.
- Writing the log at kick-off and never reviewing it, or closing risks without evidence or a recorded acceptance.
The QA perspective
Start the project risk list during test planning, in a short session with the project manager, the development lead, the product owner and whoever runs the environments. Ask two questions: what could stop testing from happening as planned, and what would we lose if it did? Record the answers as cause, event and effect, and agree the owners before the session ends.
Then keep the log alive: review it weekly, report a fired trigger the same day with what the fallback costs, and pass risks you cannot handle to the project manager’s log rather than keeping a private list. At go/no-go, link each project risk that occurred to the product risks it left less tested, so the release owner can accept residual risk knowingly.
Practice exercise
Build a project risk log for a registration portal
You are the test manager for the release below. From the planning notes, build a project risk log, then draft the project-risk part of the go/no-go report.
Student registration portal, release 3.1
Test window: 10 working days. Go-live is fixed: registration opens on 1 September.
Notes from the planning meeting:
1. The student information system (SIS) team will deliver the new course API
"around day 3"; their last two deliveries were late.
2. Only Rana has tested the fee-payment integration; she is on leave on days 7 and 8.
3. An external firm does the accessibility audit; it has not confirmed a start date.
4. Nobody on the team has load-tested registration-day traffic before.- Separate facts and constraints from risks; write each risk as cause, event and effect.
- Rate likelihood and impact as High, Medium or Low, and choose a response, combining options where needed.
- Give each contingency plan a checkable trigger, each risk one owner, and the most serious risk an escalation rule.
- Assume the course API arrives on day 6, and write the project-risk part of the go/no-go report in a few sentences.
Show the model answer
Not risks: the fixed go-live date and Rana’s leave are certain, so you plan around them. The fixed date means schedule risks will land on test scope.
R1: the course API may arrive after day 3 (the SIS team was late before), leaving too little time for course tests. L High, I High. Mitigate: get the API contract and an early partial drop. Contingency: test against a mock built from the contract; trigger: API not in the test environment by the end of day 3. It is the most serious risk because course registration is the core of the release and the date cannot move, so it gets the escalation rule: if the API is still missing at the end of day 5, the product owner chooses between deferring the feature and deferring low-risk regression. Owner: test lead.
R2: fee-payment fixes on days 7 and 8 cannot be retested by anyone who knows the integration. L High, I Medium. Mitigate: a second tester pairs with Rana on days 1 to 3 and they write test notes. Owner: QA manager. R3: the accessibility firm starts too late for an audit before go-live. L Medium, I High. Mitigate: a dated written booking. Contingency: an in-house checklist pass on the key flows; trigger: no start date by day 2. Owner: QA manager.
R4: without experience, the peak-traffic load test is done badly or not at all. L High, I High. Transfer it to a specialist firm with a report due on day 8, and log the firm’s delivery as a supplier risk. Owner: QA manager.
Go/no-go: "R1 occurred: the API arrived on day 6. The contingency started on day 4, so course tests ran on the mock, then on the real API on days 6 to 10. We escalated on day 5, and the product owner accepted deferring regression of the low-risk timetable pages, now listed as residual risk." Then state R2 to R4 the same way, each with its evidence, and the decision needed: release with that residual risk accepted.
Frequently asked questions
Is project risk the project manager’s job or the test manager’s?
Both. The project manager owns the project’s risk log. The test manager identifies the risks to testing, handles those within the test team’s authority, and passes the rest to the project manager with a proposed response and an escalation date.
What is the difference between mitigation and a contingency plan?
Mitigation is done now, whether or not the risk occurs, to make it less likely or less harmful. A contingency plan is prepared now but carried out only if the risk occurs, when its trigger fires.
What happens to a risk once it has occurred?
It becomes an issue: something to resolve rather than predict. Keep the risk entry with its history, record the effect on testing, and track the issue to closure. Some teams keep risks, assumptions, issues and dependencies together in one RAID log.
References
- ISTQB Certified Tester Foundation Level (CTFL) v4.0The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
- Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB's advanced syllabus on managing testing: test planning and estimation, risk-based testing, monitoring, metrics and reporting.
- ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesThe test process model: organisational, test management and dynamic test processes, with their activities and outcomes.
- ISTQB GlossaryThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
Practise with Mutqan tools
Score features by likelihood and impact, then generate a prioritised risk-based test plan.
Generate regression scenarios from a change description and a list of affected and related modules.
Add or subtract days, weeks, months, years, hours and minutes from a date.
Convert CSV and TSV files to PDF tables in your browser: delimiter detected, header row repeated on every page, landscape chosen automatically for wide tables.
Go deeper
Your progress on this topic
Not started
Mark the topic complete when you have studied it and done the exercise.
Sign in to track your progress
Mark topics complete, continue where you left off and unlock specialisation exams.