Project Risks

We’re on track

We've already covered project economics, so let's use the same example of a company developing a client portal. The budget is 1 million rubles, and the timeline is four months. The team is working, but there's still no access to the partner's API, some requirements haven't been agreed on, and the client hasn't appointed anyone responsible for acceptance testing. Access is already delayed, and development has stalled. We're assuming the API matches its documentation, but nobody has actually checked. And we've already based the project estimate on that assumption.

Where to look for risks

Requirements, technical dependencies, the team, the budget, approvals. Walk through the plan with your colleagues and check which assumptions are holding the whole thing together. To assess the risks, we use a probability–impact matrix. Score each factor from 1 to 5, then multiply the two scores.

The higher the score, the more attention the risk deserves. Agree on the scale first, though, or everyone will assess the consequences differently. Multiplying two subjective scores doesn’t magically turn them into an accurate forecast. The results go into the risk register: description, assessment, owner, trigger, response actions and status. Without the last three fields, it’s just a list of things that might go wrong.

What could the risk cost us?

EMV (Expected Monetary Value) lets us estimate the expected financial loss.

Suppose there’s a 30% chance the integration will need extra work, with a potential cost of RUB 200,000.

0.3 × 200,000 = RUB 60,000.

That’s an expected value, not an invoice. If the risk materialises, we could spend the full RUB 200,000. If it doesn’t, we spend nothing.

That gives us RUB 100,000 in expected losses. It’s a useful starting point for discussing a contingency reserve, but the total EMV guarantees nothing, especially if several risks hit at once. It also helps to know where those percentages came from.

What to do about the risks

For threats, four response strategies are to avoid, mitigate, transfer or accept the risk. Request test access early, check the documentation and prepare mocks. If access hasn’t arrived by the agreed date, bring in the owners and review the plan. Better to agree on the response before the integration blocks development.

It’s in the register

Update the register when requirements, deadlines or dependencies change. Once a risk materialises, log it as an issue, record the actions and reassess the impact. A spreadsheet will do for a small project. Larger projects need reserves and ongoing monitoring.

If the integration falls through after the PM has spent a month reporting that it might, everyone has technically been warned. A fat lot of good that does now.

About the author

Anya Kargina

I’m a project manager. About working with russian clients and teams, sharing experience and things I’ve noticed.

Back to the top