Project Risk Management: A Guide for Non-tech Project Managers

Mastering managing projects can be difficult, and if you’re just starting out as a Junior Project Manager, project risk management is one of the most challenging aspects of it. You need a lot of intuition, experience, and the ability to predict what may go wrong to get it right.

This post was created in collaboration with our Head of Technology - Tomasz Kania-Orzeł and Magdalena Barańska, Senior Project Manager at Monterail.

What is Project Risk Management

Project risk management is the process of determining, analyzing, and addressing any threats and opportunities for your project. It’s also an essential part of the project planning procedure where you should prepare a risk register with a list of how you will respond to these risks, so anything that can impact your project’s schedule, budget, scope, or outcomes. It’s worth noting that risk can be both negative (threat) and positive (opportunity), so you need to learn which of them to enhance, mitigate or avoid at all costs.

Why Should You Manage Risk in Your Project?

Even if you’ve just started working as a Junior Project Manager, you cannot assume that everything will go smoothly and as planned in the project you work on. That’s rarely the case, and preparing in advance will help you not only respond to any issues quickly but also you will start planning your project workflows differently to accommodate for schedule, budget, scope, or outcome disruptions before they occur.

Risk management is incredibly important for every single project to ensure that we prevent any critical failures but also spot the opportunities for improvements. Registering risks in a risk diary and monitoring them regularly definitely helps with preventing the risks from occurring and defining the proper steps to respond to them if needed.

Magdalena Barańska Senior Project Manager
at Monterail

To put it simply: identifying and addressing various risks early on will be crucial if you want to become a better Project Manager and excel at what you do.

What Is a Risk Register and How to Prepare It?

You may not be familiar with this term I’ve mentioned above, so just to recap: a risk register is a document where you list all identified risks that can affect either the scope, timing, or budget of your project. Once you’ve made this inventory, sort the items according to their severity (low, medium, and high risk) and then add information on how you will respond to each of them.

According to Magdalena Barańska,'once the risk is defined, it’s important not only to assess the probability of the risk occurring but also the likely impact it will have on the project if it occurs to understand the materiality of the risk.

A risk diary helps to have a proper action plan in place - firstly to outline the steps to be taken to prevent the risk from occurring but also to consider upfront what steps to take if the risk materializes.

There are also plenty of other techniques that help with risk management in software development projects - from applying Scrum methodology that helps with regular communication and transparency and allowing for things to be picked up on in a timely manner, to implementing the right workflow, including code reviews to create a space where the team feels comfortable with raising issues they’re facing so that they’re spotted early enough to be tackled accordingly.'

Risk Management in Technical Projects - What Phrases To Look For

Now that I’ve covered the basics of project risk management, let’s move on to the more tricky part.

If you’re a Junior Project Manager in a technical project, things can get complicated pretty quickly, to put it mildly. On top of that, there’s the developer jargon that’s just difficult to follow if you’re just starting out in the tech sector.In addition to general risks that accompany every project and are easy to determine or spot at the planning stage, there are also threats that may appear later down the line when your project is more advanced, you will need to act promptly to mitigate or limit them. 

There are various techniques for risk identification - some of them come with experience - the more projects are being executed, the easier it gets to spot the issues that could be prevented if relevant steps are being taken. But one of the crucial aspects of risk management is to listen to the development team and stay alert to anything that is being raised - a lot of it comes down to the art of reading between the lines and capturing what might come across as a red flag.

Magdalena Barańska Senior Project Manager
at Monterail

On top of that, there’s the developer jargon that’s just difficult to follow if you’re just starting out in the tech sector.Once you progress in your project management career, you will learn what phrases to look for when working with the development team.

As much as we all love our developers, sometimes it’s hard to understand what they mean when they talk about work. 

Deciphering all of the abbreviations they use and the jargon they throw around during daily stand-ups can be difficult, especially when you’re doing everything you can to ensure the project runs smoothly.

After all, what does “A feature needs refactoring” really mean to the average person? Is it something bad? Will it have considerable impact on the scope or will it require just a minor change? It's difficult to follow these discussions, especially if you're a junior or a non-technical Project Manager.

Sometimes, we tend to shrug off issues or terms that aren’t exactly clear to us or get brought up at every stand-up by default. Left unchecked, however, problems like that tend to blow up in the most unexpected moments.

The consequences can be numerous, and none of them are pretty. You might end up with a severely over-engineered product or miss your delivery deadline. The product may end up failing to reflect business requirements. Multiple bugs may “suddenly show up” in the production code. Finally, the client might not want to pay for a delayed or buggy product or developers may want to drop out of the malfunctioning project.

And so, I've compiled this brief guide to help you avoid consequences like these and to improve the communication between you and developers. It will help you understand what developers really talk about and decide whether you should be taking action to mitigate the risks ahead.

With this guide in hand, you will be able to tell when they’re over-engineering a task or when they lack the necessary knowledge. To make use easier, I’ve split the contents into three categories of risk in terms of severity, which will let you know how fast you should be moving in order to reduce or even defeat a potential threat.

Low Risk

Let’s start things off easy. A yellow light means you may run into a small delay in the project's timeframe or problems in feature delivery. However, you still have enough time to take action and deliver the sprint without major hiccups.

You will know a yellow light has flashed when you hear or see the following:

1. A library/plugin is incompatible: this phrase means that the pieces don’t match. The task that the developer is working on will take longer than planned.
2. A developer needs to reconsider their strategy for a feature: well, this usually means that you will have to scratch all of the progress for this task and that the time spent on it so far failed to yield any results. If a developer raises this issue early, there’s still time to cut the feature out of a sprint or change its scope.
3. No information about the architecture of third-party APIs: means that your team feels lost, like babies in the woods. Developers can start working, but they won’t be able to complete some tasks. Often enough, issues like that stem from a lack of documentation that should be delivered by the client.
4. Developers are not reusing the code from other projects: it means that your team is probably reinventing the wheel. Instead of drawing on past projects for a specific, reusable piece of code, the devs, for one reason or another, intend instead to write it from scratch. More often than not, the reason for that is a lack of communication between different project teams.
5. Junior developers are working without supervision: the car is picking up speed, the driver’s asleep at the wheel, and nobody’s wearing seatbelts. In all likelihood, the code you end up shipping will be buggy and need additional work.
6. Developers finished working on features too soon: miracles every once in a while are nice and all, but two weeks of uninterrupted successes should raise eyebrows. Either tasks lack key information or developers don’t read the requirements carefully. Either way, most probably the delivered features won’t cover all the use cases they should.
7. Developers create tasks without the necessary business knowledge: it means that your team, rather than the client, is deciding what features the application should have. That’s a big no-no.

Medium Light

Usually means that things are getting serious. If you encounter any of the situations described below, you probably won’t be able to deliver the features without any hindrances. The developers will be able to do some work, but blockers will prevent them from delivering the full planned scope.

You will know a orange light has flashed when you hear or see the following:

1. A feature needs refactoring: means “We did it! Well, almost.” Although a portion of the product was delivered, it still needs work.
2. The staging/test environment is not ready: means that you won’t be able to either see or demonstrate the results of work already completed.
3. Developers don’t know how to set up the production build/release environment: “Well, we created this thing for our client but we’re keeping it in our basement.” This means that there’s no strategy in place for delivering the product to the client. This can also mean additional costs if, for example, you need to suddenly set up a cloud environment.
4. Frontend waiting for backend: means that some developers are sitting idle, so the sprint/tasks need to be adjusted. Solutions? Frontend developers can instead run through tasks that don’t require the backend to be ready, or the backend parts can be delivered iteratively so that the frontend devs have something to work with.
5. Developers are not preparing tests or omit them completely: although developers should strive to always deliver top-quality code, no one can do so 100% of the time. Consequently, not having a testing framework in place can blow up in your face later, in the form of bugs or performance issues. If time is short, tests should be performed at a later stage.
6. A junior developer is making decisions about architecture and technology: means that you have a rookie on your team with live ammo in their weapon. Even if all the regulars or seniors on your project are on sick leave, a junior should never be allowed to make decisions of that caliber. Often enough, junior developers simply don’t even know what knowledge they lack.
7. Lack of DoD (Definition of Done): “We’re completing our tasks, but who knows if we’re getting the job really done?” That means that there likely is some crucial part of the delivery process missing and you need to work on defining it.

High Risk

This is when you know your ship is really starting to take in water. There are some major holes in the project and, while you can still fix them, considerable delays in the delivery schedule are probably going to be unavoidable. Problems like these can occur in projects both big and small, and there’s no particular set of circumstances that would always precede their emergence.

With projects that face high risk threats, it’s incredibly important that all the steps to prevent the risk from occurring are regularly monitored and consulted with others and there’s a proper escalation process in place too. The most important thing is to ensure that the right experts are alerted and involved where needed and we are proactive rather than reactive, with a notion that how you approach the risks would depend on their nature.

Magdalena Barańska Senior Project Manager
at Monterail

Fortunately, the situations listed below are rare, because in most cases the Project Manager would have to be completely delinquent in their duties to precipitate their appearance. However, if you see them in someone else’s project, you’ll know they need help.

You will know a red light has flashed when you hear or see the following:

1. Sprints are passing, but no features are coming: means that the client is paying for nothing. It’s a major issue that usually means delayed costs and potentially more grave consequences.
2. We don’t know how many bugs the application has: means that no one is checking where the pipes are leaking. You should always know your bug count and your test coverage.
3. Releases are very rare (lack of routing production/staging deployment): when releases are rare, they tend to become major events—balloons, popcorn, and confetti celebration style—that stifle productive work. A healthy setup allows developers to release their work without turning it into an event.
4. The Quality Assurance specialist doesn’t have time or is behind in the testing schedule: means that QA is overburdened, causing a major bottleneck in the process. The most common solutions involve rearranging the tasking schedule and adding more QAs to the project.
5. The developers don’t have time for Code Review: means “We’re going so fast that we’re past caring for quality.”
6. Switching technologies during a project (changing framework/language): means that we started building a house with the wrong materials. Usually, the reason why developers would want to change technologies is poorly planned architecture.
7. One of the developers refuses to listen to the experts: means that you have a lone ranger on your hands. If someone refuses to comply with the decisions of Subject Matter Experts, not only will it cause unwanted disruption in your team, it may also result in the final product being suboptimal.

Main Takeaway

Understanding developers can be hard at times, but we have to learn to communicate effectively, otherwise, it’s the work we do together that suffers. When we’re not exactly sure what we’re hearing, it’s easy to dismiss that misunderstood piece of information as unimportant.

I hope this post will help you develop a common language with your fellow teammates. While you don’t have to start speaking in acronyms yourself, it’s good to know the meaning behind most of them.

And here's a handy glossary of technical terms for dessert. Enjoy! (Simply download it by clicking the image below)