Three weeks into an integration project, the steering pack shows green and a risk register with four entries: “Resource risk: Medium”, “Scope creep: High”, “Third-party delays: Medium” and “Client engagement: Low”. Nobody can say which milestone they threaten or who should act. Two weeks later the payroll supplier still has not granted API access, testing cannot start, and the project manager is explaining a slipped date the register “identified” all along.
Here is how to identify project risks so that the register prompts action instead: a focused workshop, a way to rewrite vague entries, and a sample register you can adapt this week.
How do you identify project risks?
Identify project risks by asking the people who know the delivery work, the client’s business and the client’s constraints what could stop a specific commitment being met, using prompts that cover scope, access, capacity, suppliers, approvals, adoption and support. Write each risk as a present cause, an uncertain event and its effect on a named milestone or outcome. A risk is only identified once it has an owner, a response, a trigger that shows it is materialising and a date for its next review.
The rest of this guide turns that answer into a working session.
Risks, issues, assumptions and dependencies: one scenario, four records
Most weak registers mix these four ideas together. The distinction matters because each one prompts a different action. Take a single hypothetical situation: an integration needs access to a supplier’s test environment before testing begins.
| Record type | What it means | In the scenario |
|---|---|---|
| Assumption | Something treated as true for planning | “The payroll supplier will provide sandbox API credentials by 12 October.” |
| Dependency | Something our work needs from someone else | Integration testing cannot start until the supplier provides credentials. |
| Risk | An uncertain future event that would affect an objective | Credentials may arrive late, which would delay testing and the go-live date. |
| Issue | Something that has already happened and needs action now | It is 13 October and no credentials have arrived. |
The assumption is the source of the risk, the dependency names who you are waiting on, the risk is what you manage while there is still time, and the issue is what you handle once the uncertainty has gone. Keep them as separate, linked records rather than editing one entry from “risk” to “issue” and losing the history.
Who should attend the risk workshop
Invite people who can see different parts of the work, not simply the project team:
- Delivery: the lead consultant, engineer or developer who knows how the work is actually done and where it usually goes wrong.
- The client’s business process: someone who does the work the project changes, or supervises it. They see adoption and operational risks that the delivery team cannot.
- Client constraints: the client’s project sponsor or coordinator, who knows about approval routes, procurement rules, blackout periods, other projects competing for the same people and suppliers the client controls.
- Support: if the result will be supported after go-live, include whoever will support it.
The Association for Project Management notes that stakeholders should be treated as potential sources of risk and opportunity within a project. In practice, the client’s own people often hold the most important information about risk, so a workshop run only by the delivery firm is likely to miss risks that only the client can see.
Keep the group to six or seven. On a small engagement, the project manager may also be the lead consultant. That is fine as long as the client-side view is still in the room.
Run the workshop in 90 minutes
Send the charter, or at least the agreed objectives, milestones and client obligations, beforehand. If you do not have a written charter yet, how to write a project charter for a client engagement covers what it should contain. Risks can only be identified against something you have promised.
- Restate the commitments (10 minutes). List the three to five milestones or outcomes that matter most to the client. Every risk must connect to one of them.
- Surface the assumptions (15 minutes). Ask: “What are we treating as true that nobody has confirmed?” Write each one down. Unconfirmed assumptions are often where delivery risks start.
- Work through the prompts (30 minutes). Use the prompt table below. Ask each person to write their own risks before discussing them, so that the most senior voice does not set the agenda.
- Rewrite and merge (20 minutes). Turn every entry into cause, event and effect. Merge duplicates. Drop anything that does not affect a named commitment.
- Assign and schedule (15 minutes). For the most consequential risks, agree an owner, a response, an action owner with a due date, a trigger and a next review date. Lower-priority risks can be completed by the project manager after the session and circulated.
Risk identification prompts for client projects
| Area | Prompts to ask |
|---|---|
| Scope | Which requirements are still described in one line? Where do we and the client use the same word differently? What did the sales conversation promise that the plan does not show? |
| Access | Which systems, sites, data, buildings or accounts do we need, and who grants them? How long did access take on the last similar engagement? |
| Capacity | Who is the only person who can do a given task? What else are they booked on? Which client staff must give time, and has their manager agreed? |
| Suppliers | Which third parties must deliver, respond or approve? What does their contract with the client oblige them to do, and by when? |
| Approvals | Which decisions need a committee, a sign-off or a budget holder? How often does that body meet? What happens if it defers a decision? |
| Adoption | Who has to change how they work? Were they involved in agreeing the outcome? What busy periods, such as month-end or an audit, overlap with go-live? |
| Support | Who supports the result after handover, and do they know it is coming? What knowledge exists only in the delivery team’s heads? |
The prompts apply beyond software. For an engineering consultancy, “access” might be site entry and survey permits. For an advisory engagement, “approvals” might be the board meeting that must accept the recommendation.
Also ask one opportunity question: “What could go better than planned, and how would we take advantage of it?” APM’s definition of risk includes upside opportunities as well as downside threats. Threats will dominate most delivery workshops, but an early client decision or a reusable component from another engagement is worth recording too.
Rewrite weak risks as cause, event and effect
APM advises separating causes (facts now), risk events (situations that may occur) and effects on the project’s measures. A useful sentence pattern is: “Because [cause], [event] may happen, which would [effect on a named commitment].”
| Weak entry | Rewritten risk |
|---|---|
| Resource risk | Because our only data migration specialist is also booked on another client’s cutover in the week of 26 October, the migration rehearsal may slip by a week, which would leave no time to fix rejected records before UAT starts on 9 November. |
| Scope creep | Because the reporting requirement says “management reports as per current system” and nobody has listed them, the client may expect all 23 legacy reports, which would add work not in the estimate and delay acceptance. |
| Client engagement | Because the finance manager who must approve the design is on leave for two weeks in October, sign-off may be delayed, which would push the start of build and the go-live date. |
The rewritten versions are longer, and that is the point: each tells you what to watch and which commitment is exposed.
Give each risk an owner, a response and a trigger
Separate three roles that are often merged:
- Risk owner: watches the risk and makes sure a response happens. Choose the person closest to the evidence, who is not always the project manager.
- Action owner: does a specific piece of work in the response, by a due date.
- Decision-maker: approves anything outside the team’s authority, such as a date change, extra budget or a reduced scope.
Choose a response that fits the exposure: avoid the risk by changing the plan, reduce its likelihood or effect, share it with a party better placed to manage it, or accept it with a contingency ready. For an opportunity, the mirror responses are exploit (make it happen), enhance (make it more likely), share it with a better-placed party, or accept it. Then write a trigger: an observable signal that the risk is materialising, such as “no credentials by 12 October” or “fewer than three of five finance users booked for UAT by 23 October”. A trigger turns a vague worry into a date on which someone must act.
Rate likelihood and impact if it helps the discussion, but record why. Ordinal scores such as 1 to 5 help a group agree what matters most; they are not probabilities, and multiplying them gives an appearance of precision the evidence does not support. “Likely: supplier took five weeks on the client’s last integration” is more useful at the next review than a bare 4.
Finally, set the next review date for each risk. How often to review a register is its own decision and depends on how quickly the evidence changes; the principle here is that the next look must come before the latest date on which a response could still work.
Hypothetical example: supplier access on an integration project
A consultancy is connecting a client’s HR system to its payroll supplier. The plan assumes sandbox API access by 12 October so that integration testing can start on 26 October, with go-live on 1 December.
In the workshop, the client’s HR systems lead mentions that the payroll supplier took five weeks to provision access on a previous project. The team records four linked entries:
- Assumption A1: sandbox credentials by 12 October. Owner: client HR systems lead, who will confirm with the supplier by 2 October.
- Dependency D1: integration testing needs supplier credentials. Due 12 October; the supplier is responsible, with the client HR systems lead as the contact.
- Risk R1: because the supplier’s provisioning has taken five weeks before, credentials may arrive after 12 October, which would delay integration testing and put 1 December at risk. Owner: client HR systems lead. Response: reduce, by submitting the access request this week (action owner: client HR systems lead) and building against the supplier’s published specification in the meantime (action owner: technical lead). Trigger: no confirmed provisioning date by 5 October. Decision-maker if triggered: client sponsor.
- Issue I1 is created on 13 October when credentials have not arrived. It records the decision taken: the sponsor chooses to move integration testing a week later and compress the regression cycle, and accepts a short overlap with the start of UAT on 9 November, rather than move go-live.
The difficult exception. Look first at R1’s own response. The HR systems lead submitted the access request on time and the action was marked Done, but nobody obtained a provisioning date from the supplier, so the 5 October trigger still fired and R1 became I1 on 13 October. The action was completed; the risk it was meant to reduce was not.
Then, on 19 October, credentials arrive, and someone proposes closing I1 because “credentials arrived”. But they are production-only credentials, not the sandbox access D1 requires. The team keeps I1 open and updates it: usable test credentials are still unavailable and D1 is still unmet. R1 is closed as “materialised, see I1”. A new risk, R2, is added: because the only credentials available are for production, the team may be pushed to test against live employee data, which may breach the client’s data-handling rules and would halt testing. The owner of R2 is the client’s information security officer, not the project manager, because only they can approve a workaround such as masked test data.
Moving an action to Done, or receiving a delivery, is not the same as removing the risk or meeting the dependency. Always check what the record was actually waiting for.
Sample risk register: ten entries you can adapt
This hypothetical register belongs to a client implementation with a 1 December go-live. Row 8 shows a non-software adaptation. Copy the structure; replace the content with your own.
| Objective affected | Cause, event, effect | Basis for rating | Owner, response, action | Trigger, residual, review |
|---|---|---|---|---|
| Integration testing 26 Oct to 6 Nov | Supplier has been slow before; sandbox access may be late; testing and go-live slip | Likely (five weeks last time); high impact | Client HR lead. Reduce: request now, build against specification. Action: HR lead submits request, 2 Oct; tech lead builds to spec, 9 Oct | No date by 5 Oct. Residual: medium. Review 5 Oct |
| Design sign-off 16 Oct | Approver on leave 5 to 16 Oct; sign-off may slip; build starts late | Possible (leave confirmed; approver has deferred before); medium impact | Project manager. Avoid: review sessions booked before leave. Action: PM, 30 Sep | Sessions not held by 2 Oct. Residual: low. Review 2 Oct |
| Migration rehearsal 26 Oct | One migration specialist, double-booked that week; rehearsal may slip; no time to fix rejects before UAT | Possible (both cutovers planned for the same week); high impact | Delivery lead. Reduce: pair a second consultant now. Action: delivery lead, 9 Oct | Pairing not started by 16 Oct. Residual: medium. Review 16 Oct |
| Accepted reporting scope | Reports listed only as “per current system”; client may expect all legacy reports; unplanned work | Likely (23 legacy reports exist; none listed yet); medium impact | Business analyst. Reduce: list and prioritise reports with client. Action: BA, 14 Oct | List unagreed by 21 Oct. Residual: low. Review 21 Oct |
| UAT 9 to 20 Nov | Finance users busy with October month-end close; too few testers may attend; acceptance delayed | Possible (three of five testers also run month-end close); high impact | Client sponsor. Reduce: book named testers now. Action: sponsor, 16 Oct | Fewer than 3 of 5 booked by 23 Oct. Residual: medium. Review 23 Oct |
| Data quality at cutover | Duplicate employee records in source; migration may reject rows; cutover delayed | Likely (sample showed duplicates); medium impact | Client data owner. Reduce: cleanse before rehearsal. Action: data owner, 19 Oct | Over 1% rejects in rehearsal on 26 Oct. Residual: low. Review 26 Oct |
| Go-live 1 Dec | Client change board meets monthly; approval may defer to January; go-live slips a month | Possible (board deferred two items last quarter); high impact | Project manager. Avoid: submit for the November board. Action: PM, 20 Oct | Not on November agenda by 27 Oct. Residual: low. Review 27 Oct |
| Site survey report 30 Oct (engineering variant) | Site access needs a permit; permit may be late; survey and design pack delayed | Possible (permits took three weeks at the last site); high impact | Client facilities manager. Reduce: apply now, agree alternative survey dates. Action: FM, 7 Oct | No permit by 20 Oct. Residual: medium. Review 20 Oct |
| Adoption in first month | Payroll clerks not involved in design; they may keep using spreadsheets; benefits not realised | Possible (clerks not in any design session to date); medium impact | Client operations manager. Reduce: include two clerks in UAT and training. Action: ops manager, 23 Oct | Clerks not in UAT plan by 23 Oct. Residual: low. Review 23 Oct |
| Opportunity: earlier go-live | Supplier offers a pre-built connector; build effort could fall; go-live could move earlier or absorb delays | Possible (supplier has listed the connector; fit untested); medium benefit | Technical lead. Exploit: assess connector fit. Action: tech lead, 9 Oct | Assessment not complete by 9 Oct. Residual: n/a. Review 9 Oct |
Notice what every row has in common: a named commitment, an observable trigger with a date, and a review date no later than the trigger, early enough that a response can still work. If a row cannot be completed, the risk is probably not yet understood well enough, and finding out is the first action.
Limits and the most common failure
A workshop will not identify every possible event. It identifies the risks that the people in the room can see, which is why who attends matters more than which template you use. New risks will appear as the work reveals more; APM describes risk management as capturing emerging risks and reflecting new knowledge in existing analyses.
The most common failure is not a missing risk but a register that becomes a record of anxieties rather than a set of decisions. It happens when entries stay as category labels, when every risk belongs to the project manager, and when actions are marked complete without anyone reassessing the risk. The register then looks thorough while the project drifts.
Your next step
Before your next project review, take the three risks your team worries about most and rewrite each one using the “Because…, … may happen, which would…” pattern. Give each a trigger with a date. If you cannot name the commitment a risk affects, or who would decide what to do about it, you have found your first action.
For the wider thinking behind this approach, good project management is really about reducing uncertainty explains why making uncertainty visible matters more than a perfect plan.
If your risks currently live in a spreadsheet separate from the plan and the people doing the work, Chronodesk’s project management gives every project its own risk register alongside its tasks and dependencies, with the option to escalate issues to the portfolio level. The method above works in either; keeping it next to the work makes it easier to keep current.
Frequently asked questions
What is the best way to identify project risks?
Run a short, structured workshop with people who understand the delivery work, the client’s business process and the client’s constraints. Work through prompts for scope, access, capacity, suppliers, approvals, adoption and support, and write each risk as a cause, a possible event and its effect on a named objective. Then give every risk an owner, a response and a trigger.
What is the difference between a risk, an issue, an assumption and a dependency?
An assumption is something you are treating as true for planning purposes. A dependency is something your work needs from someone else. A risk is an uncertain event that would affect an objective if it happened, and an issue is something that has already happened and needs a decision or action now. One situation can produce all four, so record them separately and link them.
Who should own a project risk?
The risk owner should be the person best placed to watch the risk and make sure a response happens, not automatically the project manager. The action owner does the specific work in the response, and the decision-maker approves anything beyond the team’s authority, such as a change to the date or budget. On a small team one person may hold two of these roles, but the decision authority should still be explicit.
Should I use a likelihood and impact score for project risks?
Ordinal scores such as 1 to 5 are useful for ordering a discussion and agreeing which risks deserve attention first. They are not precise probabilities, so do not multiply them into false accuracy or treat a score of 12 as twice as bad as a 6. Record the evidence behind each rating so that the next review can tell whether anything has changed.
How many risks should a client project register contain?
There is no correct number. A register of eight well-written, owned risks with clear triggers is more useful than forty generic entries nobody reads. If the list grows long, check for duplicates, merge risks that share a cause and make sure the most consequential ones are visible at the top.