One of the responsibilities of the Project Manager is to be able to make the right decisions to handle risks properly. Take note to the following 3 tips that will help you to manage projects and face those risks on a daily basis.

Having a great development team is not enough for a successful project. In any large or complex system, there will be a lot of risks and uncertainties, which is why one of the key responsibilities of the Project Manager (PM) is to be able to make the right decisions to handle those risks.

If we don’t take care of them carefully, it is highly likely the project will get delayed, go over budget, or end up with lower than expected quality.

This might be interesting: Project Management vs Leadership

As a PM, we all must think about how to minimize all menaces we may face, which is why I came up with the following 3 tips that I have learned and that have helped me to manage several projects and properly face the risks on a daily basis.

1. Divide and conquer

Do not try to deliver everything at once! Completing the entire project may take you 6 months, 1 year, 2 years, or even more.

Building the project and putting it in the hands of the client, only when everything is done, is frequently the perfect recipe for failure. I am sure this is not something new for you. Since 2001, the Agile principles have recommended delivering working software frequently, from every couple of weeks to every couple of months.

Work with your project’s stakeholders to find and define the Minimum Viable Product (MVP), which will allow you to deliver value to your client as soon as possible. Build a roadmap to define incremental deliverables which will incorporate features into the product until you reach the final version.

2. Have a plan but be flexible to changes

Having a plan of how to accomplish the goals of your project will be essential to successful development; otherwise, your team will be in chaos, going nowhere.

Although having a plan is important, we need to be flexible to accept unforeseen changes. We should not only accept them but expect them to happen! Given that it is exceedingly likely that changes will occur, spending too much energy on creating a very detailed plan is a waste of time and a future source of frustration for you and the team.

Define the vision of where you are going and come up with a plan of how to get there. However, you don’t need to have a complete and perfect plan to start. When you get a good enough one, start to execute it.  As you and your team learn more about what you are building and you move forward with the plan, you can adjust it, correct it if needed, and fill the gaps.

Content related: Lessons learned in software: from Junior dev to Architecture Manager

3. Implement your rollout plan

Imagine that you are building a new software for an important retail company. On Monday morning, and for the first time, your system goes live in every store around the country. Very early, you start receiving several urgent phone calls because the new system is not working. Everyone is in panic. No store can sell anything because the new system has failed. It took you (and your team) 4 hours to figure out what was going on and fix it. All the goodness that the new system provided was eclipsed by this unfortunate launch.

What can be done to avoid this? Someone may say, “Do better quality control.” But that will not guarantee 100% success since zero defects is something impossible to accomplish. Also, other things could go wrong, such as a misconfiguration in the production environment, problems in the IT infrastructure, and network issues, among other situations outside your control.

Things can (and will) go wrong, and we need to accept that fact. Be prepared for all sorts of surprises (yes, including the bad ones), and be ready to face them!

One of the best ways to manage this risk is to incrementally rollout your system. In the example I mentioned, you can pick a few stores (maybe just one), launch the new system there, and keep the rest of the stores working with the old system.

In case something goes wrong, only those few ones will be affected, and you can respond more quickly and efficiently in order to solve the problem without affecting the entire business. Ultimately, the impact will be smaller as well as the pressure. Once you fix the problem and confirm the new system is working fine, you can start enabling more stores until everyone is using the new application. The last step of the plan will be to do the housekeeping: completely remove the old system.

Reducing the risk of a failed deployment is not the only benefit of having a rollout plan. It is useful to confirm that you are building the right thing. Those early adopters or beta testers can give you real feedback about how your system behaves. You can make the necessary corrections to the system before enabling it to everyone.

Also, a rollout plan enables you to release the software sooner, helping you to accomplish my first advice. You don’t need to implement all the features, only those necessary for the target audience.

Finally, there are different approaches on how to implement this plan. It could be based on users, based on customers, based on business units, etc. Choose the one that makes more sense to your case. Work with your business stakeholders to figure this out.

Do not miss this article: 5 clues to keep your software development team productive

To Sum Up

There will always be uncertainty in projects. Accept that, plan for that, watch for changes in your environment, and be prepared to quickly react and readjust your plan. In this constantly changing world, our resilience and ability to adapt are key to success.

Keep that in mind when you are planning and leading in software development projects.

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need.