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.
Table of Contents
1. What is Project Management?
2. Why Should You Manage Risk in Your Project?
3. What is a Risk Register and How to Prepare It?
4. Risk Management in Technical Projects - What Phrases To Look For
This post was created in collaboration with our Head of Technology - Tomasz Kania-Orzeł and Magdalena Barańska, Senior Project Manager at Monterail.
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.
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.
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.
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.'
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.
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.
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:
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:
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.
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:
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)
