Risks and Dependencies
A week before the checkout team's last big launch, they discovered that another team had never planned an API change they needed, and the launch slipped by a month. Everyone had assumed someone else had asked. This time, for UPI autopay, Meera wants to find those gaps in week one, not in the final week.
The rule
Name each risk early, rate it, and give it an owner.
A risk is something that might happen and would hurt the plan. A dependency is anything the team needs but doesn't control: another team's API, a vendor, a legal sign-off, a security review. Dependencies sink more projects than hard code does, because nobody on your team is working on them.
Managing risk takes four habits:
- List them early. A short risk list at the start of a project, reviewed weekly, is enough. It doesn't need special software.
- Rate them. Likelihood (low, medium, high) and impact (low, medium, high). Start with the items that are high on both.
- Choose a response. Prevent it by changing the plan, reduce it by acting early, prepare a fallback, or accept it and keep an eye on it.
- Give each one an owner and a next action with a date. A risk that belongs to everyone is managed by no one.
Handle dependencies with extra care. "We'll probably get to it next month" is not a commitment. Get a specific date, get the work into the other team's plan, and check on it regularly. Where you can, build a fallback.
A risk list for autopay might look like this:
Risk Likely Impact Owner Next action
Bank sandbox late Med High Arjun Request access this week; build a mock meanwhile
Reminder SMS (notif. team) Med High Meera Agree a date with their EM; get it into their plan
Security review queue High Med Farhan Book a review slot now
Farhan on leave in week 5 Certain Low Priya Accept; Priya covers reviewsThe shortcut
Walk the plan box by box and ask one question: "What do we need here that we don't control?" Every answer is a dependency, and most dependencies are risks.
Ask the question at each step
Integration needs the bank's sandbox. Launch needs the notifications team to send customers an SMS before each automatic payment. Release needs the security review.
Drills
Answer fast — trust the rule.
Which of these is a dependency?
Which risk deserves attention first?
What turns a risk-list entry into something that actually gets managed?
Another team says, "We'll probably get to your API next month." What is the best response?
Remember
- Name each risk early, rate it, and give it an owner.
- Walk the plan and ask, "What do we need here that we don't control?"
- Treat "probably next month" as a risk, not a commitment: pin down a date and keep a fallback.