Technical risk is any risk your project may go sideways because you don’t have the appropriate technical skills. An example of technical risk will make things much clearer for you, so let’s dive deep into this guide.
What is Risk in Project Management?
Before we talk about technical risk, let alone make an example of technical risk, we should spend a few words on risk in general. Since you are reading this, you may be familiar with the concept of risk, but I suggest you spend the extra 30 seconds needed to agree with my definition for this article. It will be much easier to understand all the rest.
A risk is an uncertain event that can affect your project in many ways. Risk is the collection of all the risks.
The focus here is uncertainty. Risk does not have to be bad, although it most often is: it is just uncertain. If a risk happens, it will impact your project. For example, the town hall is reviewing your proposal and may decide to not approve your construction plans. There is a risk that they do not approve therefore, and if they do not then this will impact your project (you can’t construct anymore). On the other hand, there may be a risk that a customer you contract for will request more work (so you will make more money, a good risk, but you may not even have the resources needed to deliver, a bad risk).
As a project manager, it is important that you manage risks. This means identifying the risks in advance, assess their likelihood of happening and their impact if they do. A good strategy is often to assign a risk owner, a person who is in charge to monitor the risk and say “hey, this may be starting to become a reality”. The owner is not necessarily the person that will “fix” things, but the person who should keep an eye on how things might evolve.
What is Technical Risk?
Now, before we dive into the example of technical risk, let’s start with a simple definition.
Technical risk is the possibility that technical challenges will block or slow down the project or impact it in general.
Of course, this is some sort of circular definition, because it explains technical risk with technical challenges. We need to expand a little bit to bring clarity.
Projects and activities have inherent complexity. Typically, every task goes through a curve: first, you have to figure how what you are doing, and that is uphill. Once you do figure out the right way to go forward, then you just need to execute, and that is much easier. Reality is never so crisp dividing the first from the second phase, but at the beginning you have much more uncertainty.
The more the work you have to do is creative and new, the harder it is to estimate what you will actually implement. For example, a software project is more ambiguous than building a two-story building (because that is always “more of the same”).
So, there is a chance that things will not work out as expected, and that you will encounter obstacles that are more difficult to overcome than you thought. In a software project, you may find out that debugging this Java module is harder than you think. In a building, you may found out that you have to dig the foundations in a ground that is harder to excavate than you realized.
Those are all technical risks. Now, to tell if it is a technical risk it is easy: would you be able to solve it if you had more hard skills? For example, will you be able to debug your software more easily if you had more experience with this technology? Will you be able to dig the foundations easily if you had newer equipment?
Example of Technical Risk
Why just one example of technical risk? Let’s go with three.
Example of Technical Risk #1: Software
We already mentioned software projects as an example of technical risk. Let’s dive deeper, or rather see this example of technical risk in another flavor.
You are creating a web application that works with two main components: a backend server that keeps the user data and business logic, and a frontend web app that interacts with the backend to show the data to the user. Pretty basic functionality.
You want to use Javascript for all your code, so you use Node.js in the backend server, and decide to go with Vue.js on the frontend. Vue.js is a Javascript framework to create frontend applications, and you heard from friends and colleagues that is fast to learn. The problem is, you had no prior experience with any frontend framework, so there learning will be harder than you think.
But the technical risk is much more than “it took me longer than expected to learn”. That is something you can fix simply by putting more hours, it is more of a resource constraint, not a technical risk. The real example of technical risk is that you may realize, after you learn, that Vue.js does not do what you wanted to do, or does not do it well enough. Or maybe it cannot integrate with your backend for some reason.
Most likely, those are not hard showstoppers, but obstacles you can work around creating additional code and logic, or adding parts of the app that are outside of Vue.js. But now you have to increase the scope (do more things) just to meet your original goal. This is an example of technical risk
Example of Technical Risk #2: Construction
Our second example of technical risk is in the construction sector. This sector is more predictable than software, but you can still experience technical risks. This is why many large infrastructure projects are delayed, because the larger and the most ambitious initiative, the harder it is to correctly foresee and address technical risks.
Imagine you are digging another tunnel between Manhattan and New Jersey that you will use for a new subway line. This is something that was not attempted in years, you have some information about the ground and the soil, but you will never know for sure until you start digging.
When you do start to dig the tunnel, you find out that the soil is too muddy to use your normal excavator. Unfortunately, there is no technology for that type of ground that can reliably dig the tunnel, so you have to move several meters further down. There, the terrain is better, but now you never had to put an excavator so deep under sea level, so your cranes are not suited for the job.
This is another example of technical risk.
Example of Technical Risk #3: Manufacturing
The third and last example of technical risk we have for today is in manufacturing, and especially in the design and engineering of new products. In fact, mass production should be an operationalized process where technical risks are virtually non-existent.
Imagine you have to design a new aircraft to make it as fuel efficient as possible. For this purpose, you will need larger turbines, but you have already designed the wings in such a way that turbines that big won’t fit. This is the technical risk becoming into a reality. Then, you think of a workaround: you can raise the wings to allow space for the turbines. However, doing so will change the balance of the plane mid-air.
So, you have to write mathematical models and then do tests so that you can correct in software this imbalance. You don’t know if that is possible, but you will want to have a software that makes the plane “feel” as if it was the usual plane to the experienced pilot, taking care of readjusting this imbalance under the hood. Eventually, you find that it is possible for this to work in software, but you had to spend time creating a software you did not expect to need.
Yet eventually, two planes crash, and all the planes of this model are grounded worldwide. This is a true story.
Technical Risk in Summary
In this article, we saw what is technical risk: the possibility that things will go sideways because they are too difficult than originally imagined, or because you do not have the proper skillset.
As you can see, it is important to have the proper skills. Start now by learning about referent power, and how you can use it as a project manager.
