Coming short on estimations? Might have something to do with your risk strategy.

Any project, no matter the industry, should be aware of the risks and their impediments when they occur. Whether a manager, a cook, a developer, or a mechanic, you face risks every day, you just might not comprehend them as such or just see them as a regular thing happening.

Working in outsource, where expectations are high, estimations taken for granted and unknowns measured in dozens, some sort of risk strategy and understanding is more than welcome, unless you’re on a mission of pushing your nerves and most probably your team to a breaking point.

Occasionally, mostly during post-mortems and sprint reviews, I ended up talking about the reasons for falling back with estimation and the same number of times, in hindsight, I was leaving with the same conclusion: We didn’t plan for this nor did we anticipate in any way. The thing is that we were actually aware of most of the risks, we just didn’t incorporate them anywhere.

Since I believe the engineering world can turn a blind eye to risks (there are reasons why many projects keep on being delayed and failing), I’d like to put some spotlight on this problem and what you can do to improve and adjust certain expectations. Being a project manager, it’s your obligation to be completely aware of all aspects of one risk.

The blind eye

Okay, so since you might be wondering Well, why wouldn’t you incorporate risks if you knew them, let me highlight what I believe is the main reason, staying competitive.

The fight is brutal. Although engineers are the most sought-after on the global market, both the immediacy and the opportunity each new client/project carries make many Yes Men willing to turn a blind eye on this part. I get it, to land a client is a huge deal and businesses should be aiming for this. However, not without some risk strategy or understanding is taken into account.

Risks in general, extend the deadline and incur higher costs for the project. In the constant race to cut time and costs to stay competitive, because most of the time the book is judged by its cover (which is the initial estimation), you agree to skip this step or sometimes just add some buffer time (which by the way, is better than nothing) and hope for the best.

Many teams accept projects without some sort of risk strategy set in place and many end up having unsatisfied clients, burnt up teams and frustration of the overall outcome.

Why considering risks

The first reason is because it’s your job. Secondly, because you’ll spare few hairs on your head (and your team’s). Thirdly, you’ll work better and increase your productivity.

Understand that risks are real and if put on the map, to some healthy extent they remove pressure and set reasonable expectations.

The bigger the team and the longer the project, the more probable the risk is to happen.

Risk awareness is essential when working with a hard deadline (or any deadline for that matter) and in my experience, it’s especially important for projects that are usually longer than 2–3 months, complex, and have many parties involved.

Identify

You want to change but do not know how and where to begin.

Start by identifying risks, for your own personal sake. Talk with people and ask them why they believe they’re failing. You’ll be amazed by the amassed understanding and hidden information each team member possesses. Ask them what they believe were the three things that happened in the past two projects they worked on that caused delays. Most of them will probably give you the same 3–7 reasons which will indicate that these are most likely to happen on any project.

In my case, these were in the lines of frequent change requirements without proper estimation revision, swapping developers, working on existing code, general oversight, sick leaves, new technology, different seniority and experience across the team, etc.

All these affect the project in various ways. They create dependencies in the team, affect motivation and productivity. You, as a project manager, have the obligation to communicate this, otherwise, you risk creating frustration among your team that can be manifested in different shapes.

The gathering shouldn’t stop here. After all, you’re the project manager and you’ve probably observed much more than the others. Add your input and if you’re not sure it’s valid, ask your team whether they remember those things that happen on the projects they worked on. Almost always you’ll get an affirmation.

Build a matrix

Once risks are identified, build a matrix. With certain tweaks, this matrix can be expanded and reused for every project in your company.

Risks can vary in their nature, probability and proximity of happening, their severity and in the approach for their handling.

Based on this, your matrix must consist of the risk’s description, the probability and the proximity of happening, the severity of its effect and the possible action plan if it’s bound to happen. Here you can find our risk matrix model.

It’s important to note that not all parameters refer to each risk. For example, proximity cannot be applied to a new technology when seen as a risk. Joggle between these and find what works best for you.

Other parameters can be added, like the nature of the risk and whether it’s in the team’s control or not. These can help you have a clearer view of where the problem lies and who should be responsible for taking care of it.

Some things in our matrix might seem funny but I assure you, I’ve seen a bunch. I’m totally aware of the lowered productivity arising from adaptation when people return from their vacation. I’ve seen oversight that came from blindness caused by over-optimism. I’ve seen motivation drains on the hour when working on existent code that makes developers want to cut their heads off. These, although small when seen independently, summed together are worthy of concern.

Here it’ll be good to remind ourselves by Fred Brooks, the author of The Mythical Man-Month, who says:

How does a project get to be a year late? One day at a time.

When building your matrix, be sure to have this as one of your postulates.

Prioritize

One risk, if it comes true, can take its toll on different things. It’s either time, cost/budget or quality. Knowing where to place a risk helps you define the severity. Some of your clients might be interested only in the time and the cost so the risks threatening these two should have higher impact than those related to quality.

So if switching senior with intermediate engineer affects the quality but doesn’t affect the time and the cost to a great extent (to be clear, I know that it does), you’ll end up considering this as not so threatening on the project’s time and budget. Change of requirements without proper revision would be higher up on the risk matrix knowing that this could cause both huge delays and a big dent in the budget. In another case, you can have the other way around. If high-quality solution is of utmost priority, switching devs wouldn’t be recommended and should be in the top section of your matrix.

When prioritizing, think about the main business goal and client’s needs, priorities, and activities.

With this in mind, try looking back and figure out what happened on the previous projects you’ve worked on. Do ask around and validate your view on the matter. Use percentages or 1–5 numbers for both severity and probability to calculate averages and to prioritize risk.

You can even reshape the matrix by putting the severity on the X-axis and the probability on the Y-axis. This visual representation enables quick understanding of the main threats.

Use the proximity column to additionally stress the importance and priority for one risk. This should help you focus the attention on something that seems negligible in the long run but can be quite important in near future.

Calculate the averages or just see the top left section of the table (if creating your matrix by using X/Y axises) and move on to the action plan.

Define approach

All of the points mentioned so far can help you have the bigger picture but it is only by defining an action plan that you can start to reap the benefits of your risk strategy.

When defining the strategy, you can decide on different approaches in case a risk becomes a reality.

I’ll start with the type I believe is the worst but happens the most in outsource, acceptance. In other words, when the risk becomes a reality, you’re caught with your pants down because you don’t have anything set in place.

A member of the team leaves, a new technology proves to be a bad choice or you’ve made a huge oversight due to a poor communication process? Not having any backup plan means that you’ll face this risk head-on. It’s a risky approach that can result in losing clients and/or people and harming your reputation.

Look, some of the risks can be approached in this way (the least probable or the ones that are negligible) but if by any chance, you happen to decide to go with this approach, you can at least do it more actively by thinking about some alternatives and by adding some buffer of time/budget/resources in place that can buy you some time to mitigate part of the risk.

Avoidance is different. This approach enables you to avoid threats by completely altering the plan so that the issue threatening the project is removed. Imagine you have a feature that should be implemented by using other service providers which has his product in beta. The client is planning a huge promotion in one month and expects to obtain 50,000 new users. Since it is in beta, you’re well aware that lots of issues might arise from using this service and negatively impact the newly acquired users. In consultation with the client, you agree not to rock the boat and to alter the plan so as to focus more on stabilization and implementation of other important features instead of the planned one.

Transferring is another one. If you work in outsource, you’ve probably been on both sides of subcontracting. Someone lacks the expertise or the capacity to cover all aspects of a huge project so you’re called to jump in the action. You also might be asked to cover certain penalties in case your part of the job is not done on time (or on a budget) and hinders the whole project.

When transferring risks, think in the lines of insurance. Insure for the work you’re outsourcing and also understand why you’re asked to commit to your work when you’re the subcontractor.

Mitigation is the mother of all. This one costs the most since it requires thought, resources, and time to devise, execute and monitor a plan. Having this one in place, communicating it, and being prepared for execution presents a great level of understanding and professionalism which can, in turn, send a very strong message and help you to stand out from the crowd.

This approach actually means that for every risk you have a backup plan, or few, in place. Mitigation is closely related to the nature of the risk and whether it’s in the organization’s control or not.

Let’s say you’ve landed a new big client and the project is expected to be delivered in a year. Upon reviewing the specs and scope you indicate a tight timeframe with many probable risks. Let’s be honest, tons of things might go wrong in a year and if you decide to go on these head-ons, may God have mercy on your soul.

So, how are you planning to handle the issues that will probably spur out of nowhere due to the new major update of the OS or due to a new piece of hardware that’s released? How do you prepare for sick leaves? You’ve already scheduled a new project 2 months from now for which you’re planning to switch designers or QA engineers. What’s your agenda when you know that productivity will decrease due to the badly written code you took over?

These are all risks that will threaten the project big time and that can almost never be fixed by pouring more money and by adding people (even if you have them at your disposal). On the contrary, they require a closely monitored action plan consisted of multiple proposed actions, resources, and clearly defined responsibilities for each and every risk.

So in the above-mentioned cases, you can have other engineers from your company test the beta version of the new OS and provide insights on time that might indicate a need for switching developers. In order to increase productivity for the engineers working on an existent code, you can put them to work together in the same room, remove all other ongoing trivial tasks and let them focus on the actual work, you can have weekly or monthly gatherings outside the office so that they can let some steam off (it’s healthy) and relax.

It’s worth mentioning that mitigating risks is a live process and will change over time. You have to have an action plan where if something doesn’t work, something else has to be instilled.

Measure (Quantify)

To additionally measure risks, you should decide the probability and severity of the risk for each of the mentioned areas where it can take its toll (time, budget, quality). Some of these are mixed together; in some cases, more often than not, a high risk in time goes hand in hand with budget. If you currently don’t have anything set in place for risks, I advise making small steps by identifying and prioritizing in a simple way. After all, having an extensive risk strategy and plan can be costly and requires time in monitoring, adapting and executing actions.

In case you do want to measure risks, you should start by quantifying the meaning of a, let’s say, extra obligation added to your tech lead and its effect on the product’s budget, time, and quality. Let’s assume that your lead engineer is requested to devise a program for the newly acquired interns and junior devs while he’s already one month into the project. This new program will require from your lead engineer an additional 2 hours per day for the next two months which with easy calculus can be rounded at 80 hours (2 hours per day X 40 days, 20 working days per month). Note that I’m not even going to address the content switching and its toll on productivity nor will I take into consideration the actual possibility of needing more than 2 hours per day from your lead engineer. Not taken into account at the beginning of the project, these hours will affect your client’s product deadline and your company’s operational costs. Although your tech lead will create a value and contribute in the long run, your company will probably lose some money that it wasn’t prepared for at the beginning. Your client’s project, on the other hand, will be delayed for at least 3 weeks and this is again derived from the most basic math. If you charge your lead engineer for let’s say $100 per hour, this simple math will put a dent in the budget of at least $8,000.

I narrowed this example with simple calculations, without many other probable effects, only to show one possible way to quantify the risks.

Numbers can be scary and quantification can have some added value when perceiving and prioritizing risks.

Communicate

This one is probably the point where many fail.

We’ve all been to a meeting where something like Well we have to make an effort and push. It’s of utmost necessity that we land this was said. The thing is that you completely understand the importance. What are you probably not doing is communicating clearly the hazardous approach of jumping on board. Although you might get carried away by the optimism that’s spread in the room, you have to state the consequences, loud and clear. You have to be on the same page with your team. You have to have each others backs.

Communicate this with your top management and with your client. Despite your concerns and insecurities of how you’ll be perceived, resist being the Yes Men. I’m not saying go and be negative, just be more realistic about the possible problems you might face. I know many of you might think this is the definition of negative but it’s not. Being realistic doesn’t mean that these risks will come true.

Many Yes Men are sugarcoating the risks by disclosing them in a fashion that makes them not perceived as such.

Let your top management know the possible effects of the risks. You might even point to an area worthy of concern at an organizational level. Build trust with your client, state as clearly as possible that you can see this happen and that it’s somewhat okay for it to happen, but assure them that you’re working actively towards removing all obstacles along the way, before employing your risk strategy. Present them your matrix. Discuss past experiences and approaches you took to overcome threats.

And above all, take time to communicate, don’t rush it, and think every step of the way.