Three women organizing a calendar. Risk alert icon in bottom right.

As a project manager, it’s hard to plan for EVERYTHING. No matter how much padding you add or timeline extensions, there are some risks you just can’t predict. With each project comes a certain level of risk. Risk is any problem that might come up down the road and set back your timeline or affect your budget. A risk management strategy eliminates the guessing game that comes with estimating a project. In addition, it sets expectations for you, your team, and the client.

How often do you begin a project with confidence, having a solid timeline and ensuring your developer’s workload is manageable, only to hit a wall in the middle of the project? Sometimes the circumstances are uncontrollable like a termination or sudden personal event. Other times it can be a matter of underestimation or lack of resources. A risk management strategy provides a clear plan for identifying risks, monitoring them, resolving them, and communicating them to the client.

Create a Risk Register

The client has just signed an agreement and you’re ready to solidify your timeline and build out the project for your developers. Before you start color coding and organizing to-do lists, start by building a risk management strategy to share with your client. Begin with a risk register; this will help you organize all possible risks for a project. Create a spreadsheet with the following columns:

  • Description: Start with identifying the risks and their causes.
  • Recognition Date: This is the date that the client/stakeholders acknowledged the possibility of the risk
  • Probability: Provide an estimated percentage that indicates how likely it is that the risk will actually occur
  • Severity: How badly will the risk impact the project. You could use a scale of 1 – 10 here.
  • Owner: Who monitors this risk and takes action if necessary?
  • Action: When the owner does notice a risk has occurred, what is the resolution?
    • Accept
    • Avoid
    • Control
    • Transfer
    • Continue Monitoring
  • Status: This is an ongoing status that labels the risk as either potential, monitoring, occurring, or eliminated.
  • Loss Size: This is the number of lost hours or days that the risk as impacted the project timeline.
  • Risk Exposure: This is the number of additional hours or days added to the project timeline.

Define the Risk

There are undoubtedly some obvious risks to consider like the risk of a personal emergency that requires you or a developer to be out. You may also pull from past experience where underestimation was an issue that you didn’t account for. If you’re struggling to determine what risks apply to you, consider these five common impact areas specific to software development projects:

New Technologies

The tools you use, the techniques you adopt, standards and platforms are always being updated. This certainly poses a risk to your project in the case that you don’t pivot quickly and seamlessly enough. Ensuring that developers are trained and certified are important here. As a project manager, a lot of trust goes into your developers’ expertise. It’s up to them to justify which technology or tool is the best to use, and it is up to the project manager to keep the client in the loop about any changes to the roadmap.

Technical Requirements

Technical requirements are usually determined during the estimation process. After translating the initial ask and going through a few phone meetings with the client, you and the developer can nail down what the technical requirements actually are. Of course, where there’s some form of translation comes a level of risk. Understand that every aspect of the project includes requirements whether it be front end user experience, backend user needs, general functionality etc. It’s always good to have more than one technical opinion during the estimation process.


Having that extra technical opinion can also inform the correct application, platform and tools to use before going into a project. A foundational risk includes things like using the wrong component or tool to build out a functionality or even choosing the wrong platform to start the build. Laying this foundation from the onset helps you to avoid going back and starting at square one.


Test, test, test, and test again! Of course you test your deliverable before handing off to the client, but it’s also important for the developers to test throughout the project to ensure that functions aren’t breaking and that goals are being met.


Lastly, there is always risk in taking on the planning of a large project. Project managers are responsible for planning the project from start to end while juggling client and developer needs.


Tracking Risk

Once you’ve prioritized and categorized all possible risks and shared those risks with the client, it up to you to monitor them. Throughout the project, routine touch points internally and with the client will promote transparency on both sides. Following your risk register action plan, you can confidently begin a project and keep an eye on risks. The process of tracking risks requires that you keep a constant pulse on the project. You can do this in a few ways so that it’s not so overwhelming. With every timeline update or touch point call, discuss and document any potential risks that may become more of a problem. Make sure that you’re reviewing your risk management plan periodically and revise it as necessary. Lastly, keep in mind that new risks that you hadn’t planned on may arise. Add them to your strategy and keep monitoring.

Once you see that a risk is starting to become a problem (it could potentially affect the scope of your project), refer to your “action” column from the risk register. Don’t panic! There are a couple of ways to address the problem as listed in the register.

  1. Accept – This action means that you, the project manager, accepts the risk without making any changes to the project.
  2. Avoid – You acknowledge the risk and adjust the scope and schedule as necessary to work around the risk.
  3. Control – Actively work with the developer and client to deescalate the risk
  4. Transfer – Shift the authority to other stakeholders that will accept the risk
  5. Monitor – Continue to monitor the risk. Again, this is an option if the risk is relatively insignificant to the overall scope.

Communicate Risk to Build Trust

As with any project, a strong foundation is necessary. This includes laying the framework for new tasks as well as ongoing tasks for other clients. Not only do you look at the big picture deliverable, you have to plan for those “what if” moments, or worse case scenarios. It’s easy to glaze over that part of the project and get off on a good foot rather than focusing on possible negatives. However, transparency from the onset will save you from hitting that wall in the middle of your project. Not only that, it helps you to build trust with your client for future projects. Sevaa Group fosters healthy relationships with our clients through responsiveness and trust. We adopt a flexible approach to partnerships and offer solutions tailored to your needs. Reach out today to get started on your next project.


Free consultation to discover your best-fit solution.