The same risks in every projects

To avoid the big problems with projects, everybody recommends risk management. At the same time, I’ve rarely seen risk management practiced effectively. Do we identify the same risks and do we actually prepare to handle them? The ironic thing is that I think most projects have the same top four risks. In this blogpost, I explore these common risks. To avoid exposing my customers and colleagues, the examples given is based on hearsay and not actual experience.

The biggest risk: Is the problem even worth solving?

The biggest risk of a project is that the problem we’re trying to solve is not worth solving. The project may have uncertain costs and will only save the company an insignificant amount of money, or we may be creating a product that nobody is interested in paying for. If what we’re doing is not worth doing, it doesn’t matter how well we’re doing it.

Lean startup recognizes this risk at the center of the process. This is why the Minimum Viable Product is such a strong concept. This is a great idea if the project is about developing a product for a market.

What if the project is about delivering something that a customer ordered? What if your customer ordered something that they don’t need? Your contract may protect you financially, but you will still have wasted your time working on something insignificant.

As an example: Everyone wants to develop chatbots today, but do you know how much you are currently spending on your human customer services representatives? Is it even worth reducing this cost?

Will the proposed solutions solve the problem in a reasonable way?

Even if we know the problem is real, will our solution actually address it? In the example of the chatbot, we expect that our customers will get their answers from the chatbot, so they won’t bother our (expensive) human operators. But what if our customers always end up transferring to a human after all? Many chatbots are nothing more than fancy, less usable, FAQ databases, which may be cheaper to implement anyway.

Do we have the means to execute our solution?

Even if the solution would solve the problem if properly used, do we have the skills, data, customer relationships and market conditions to execute it well and without extreme expenses? In the case of our chatbot, the chatbot won’t do us any good unless we have the people who can train it and the data to train it with. As technologies are becoming increasingly specialized, it’s often much less available skills than demand.

Do we have the processes to deal with fundamental risks?

When a fundamental risk materializes on a project that has been started, it may be very hard to actually deal with it. We had a project at my company where it turned out that after putting in a few person-years worth of effort, we realized that there was no value to the project. It took us two weeks from the realization until we had discussed the discovery sufficiently that everyone saw the same situation and that we had described the situation in a way that made the top management able to make an informed decision to terminate the project and cut our losses.

We’re not always so lucky. In many organizations, the inertia of a project is so large that there is no understood decision process that makes us able to terminate the project once we realize it’s a waste of effort.

Dealing with the fundamental risks

The three biggest risks to the value of any undertaking are:

  1. The problem may not actually be worth solving
  2. The solutions we select may not actually solve the problem
  3. We may be unable to actually master the solution effectively
  4. We may be unable to terminate out-of-control projects

If one or both of the first two risks actually materialize for your project, your current undertaking is a waste of effort. If the third occurs, it costs more than it’s worth. If the last occurs, you will be unable to stop the bleeding. All projects have these risks, but they may materialize differently. What are your fundamental project risks?

About Johannes Brodwall

Johannes is Principal Software Engineer in SopraSteria. In his spare time he likes to coach teams and developers on better coding, collaboration, planning and product understanding.
This entry was posted in English, Non-technical. Bookmark the permalink.

Comments are closed.