What is Risk Management?

Common Project Risks

Risks fall into predictable categories. Identifying them by category at project start catches most threats:

• Scope risks — requirements change, client adds features, third-party dependencies expand
• Resource risks — key team member leaves, developer gets sick, vendor delays
• Technical risks — technology doesn't work as expected, integration fails, platform changes
• Timeline risks — dependencies slip, approvals take longer than planned, external factors delay
• Budget risks — estimates were wrong, currency fluctuates, unexpected work is required
• Stakeholder risks — decision-maker changes, organization restructures, conflicting requirements surface late

Assessing Risk: Probability and Impact

Not all risks deserve equal attention. Assess each risk on two dimensions: probability (how likely is it to happen?) and impact (how bad would it be if it did?). Multiply them to get a risk score.

A risk with high probability and high impact is your top priority. A risk with low probability and low impact can be monitored without active mitigation. Most project risks fall in the middle — medium probability and medium impact — and need a brief mitigation plan.

Risk Response Strategies

Once you've identified and assessed risks, you have four response options:

Avoid — change the project plan to eliminate the risk entirely. If a particular vendor has a history of delays, use a different vendor.

Mitigate — take steps to reduce probability or impact. If a key developer is critical, cross-train a second person on the same codebase.

Transfer — shift the risk to someone else. Contracts with fixed deadlines transfer timeline risk to vendors. Insurance transfers financial risk.

Accept — acknowledge the risk and decide to deal with it if it happens. Some low-impact risks aren't worth the time to mitigate — document them and move on.

Building a Risk Register for a 3-Month Project

A risk register is a living document that logs every identified risk, its probability, its impact, and who owns it. For a 3-month project, build it before kickoff and update it at every weekly status meeting.

The format: risk ID, description, probability (1-5), impact (1-5), risk score (P×I), owner, response plan, status.

For a typical agency project — 6 people, 12 weeks, building a client website — a starter register looks like this:

- Client delays content delivery. Probability: 4. Impact: 4. Score: 16. Owner: account manager. Response: build a 2-week content buffer into the timeline. - Key developer gets sick. Probability: 2. Impact: 5. Score: 10. Owner: tech lead. Response: document codebase from week 1, identify a backup resource. - Third-party API breaks. Probability: 2. Impact: 4. Score: 8. Owner: developer. Response: test fallback behavior, add to QA checklist.

Eight to twelve risks is the right size for a 3-month project. More than 15 and you're tracking noise, not risks. The register should reflect the actual project, not the project as it was planned on day one.

• Risk score = Probability × Impact. Anything above 12 needs an active response plan.
• Every risk needs one named owner — not 'the team.'
• Review the register at every weekly status meeting, not just when something goes wrong.
• A risk with no response plan is just a worry written down. The plan is what makes it useful.

Risk Management for Agency Client Work

Client projects carry risks that internal projects don't: you don't control the client's decisions, availability, or budget.

The most common risks in agency work:

Scope creep. The client adds requests that aren't in the contract. You need a documented change request process before the project starts.

Approval delays. The client takes 3 weeks to review a deliverable that needed 3 days. Build approval windows into your timeline and state in the contract that late approvals extend the deadline.

Budget changes. The client's budget gets cut mid-project. Have a minimum viable deliverable conversation early.

Personnel changes. Your main contact leaves the company. Get sign-off from multiple stakeholders at kickoff, and document all decisions in writing.

An unclear brief. Requirements are vague, leading to rework. A 2-hour discovery workshop before the project saves 20 hours of revision after.

• Document every client decision in writing, even decisions made on a call
• Approval deadlines belong in the contract, not just in the project plan
• Change requests need a written process from day one
• Get at least 2 client stakeholders to approve the brief — one point of contact is a single point of failure

When Risks Become Issues: How to Respond

A risk is something that might happen. An issue is something that has happened. When a risk becomes an issue, your response shifts from prevention to containment.

Step 1: Confirm what happened. Before reacting, get the facts. 'The API is down' might mean 'one endpoint returned an error' or 'the whole service is offline.' Take 15 minutes to confirm the scope of the problem.

Step 2: Assess the impact. Does this affect the delivery date? The budget? Quantify it. 'This delays the payment module by 3 days' is actionable. 'This is a problem' is not.

Step 3: Notify the right people. For a client-facing issue, the account manager contacts the client within 24 hours — not at the next weekly meeting.

Step 4: Implement the contingency plan. If the risk register had a response plan, use it now. A good decision made quickly beats a perfect decision made too late.

Step 5: Document the response. Log what happened, what you decided, and what the outcome was. This feeds your next retrospective and improves your risk register for the next project.

• Confirm facts before escalating — the actual impact is often different from the initial report
• Client notification within 24 hours, not at the next scheduled meeting
• A fast imperfect decision beats a slow perfect one when a project timeline is at risk
• Document every issue response — it improves risk planning on the next project