Follow me on this trip…

It’s the first week of March; SPRING BREAK is just starting! You’re hanging out with your friends at the Maniak / BC Office, drinking some sheves. Suddenly, one of you has a brilliant idea: “What if we go to Cancún this weekend? We’ll take a cheap flight, find a really good all inclusive Hotel and maybe go to Isla Mujeres”

“What can possibly go wrong?”, they have wondered, and Murphy has answered: “Anything that can go wrong, will go wrong"

  1. They spend 3 hours at the airport trying to find a ticket, and finally pay 4 times more than a regular ticket.
  2. They don’t found a good all inclusive hotel; not even a nothing inclusive, not even a Hotel… a creepy/crappy hostal, but with a 5 star hotel price.
  3. Renting a car was completely impossible, so they have to pay two cabs every time they go out(because they never find a taxi who accepts the 5 of them at the same time)
  4. All the Catamarans, yachts, boats and tours are already booked. NOTHING can happen because everything was sold out.
  5. A BIG etcetera…

Is it surprising, absurd or illogical? Well, this is the kind of situation that we are exposed to when we try to run a project without a proper risk analysis, risk management and/or zero understanding of the possible impacts of “Murphy´s Law” on our projects. However, many of us are averse to handling or even touching risks. This can be because we don’t really understand what risk entails. Far from being fearful or cowardly, taking everything into account can help us react to obstacles and unforeseen circumstances. Here’s a couple of examples of what we believe risk management is, and the reality.

MYTH: Risk management is a complex analysis that can be used only in big companies.

REALITY: Risk analysis and Risk management are part of good practices that cannot be limited only to projects’ environments or big companies. It should be a regular behavior to apply in every single day of our lives.

A family trip without understanding timelines or budget is a big risk. For example, a plan for a Carne Asada (Barbecue) assigning the beer responsibility to a guy who lives far away and doesn’t have a car, or building a new data center without considering the backup plan in case of natural disaster. Each one of these cases is a time bomb that could potentially explode.

But, what is a risk anyway??
All methodologies and all the good practices (not only focused on project management but management in general), define a risk as the possibility of an event that might either positively or negatively  impact a project, occurring to a company or plan. (A bomb that could or could not explode).

MYTH: I don’t think about risk, because I’m not a negative person.

REALITY (And a Concept): Believe  it or not, I have heard this kind of answer before. Not all risks are bad things about to happen. To those “Positive people”, yes Positive Risks exist!  If the possibility of occurrence of an event could impact positively, and benefit the project or company, then that’s a Positive Risk. It’s complicated, yes, but it can happen. Delays on the development process of a Cryptocurrency app has moved the target 2 months, and when the day comes, a major break occurs in all the markets. Cryptocurrencies prices fall into the deep, and the euphoria on the news brings a big wave of new users on the newly created Crypto App (Project owners are millionaires in a blink of an eye).

FYI: A good Risk analysis itself could be a complex process, so the ability to see Positive Risks is destined for those with whom the force is really strong. Not only because risk analysis is difficult, but because most of the Positive Risks are related to external factors that might not be controlled by anyone on the project.

MYTH: I do Agile-SCRUM, I don’t see risks.

REALITY: One of the biggest myths in our project's universe, came out of the differences between Agile and Waterfall. While it’s true that for waterfall methodologies EVERYTHING could be more complex (PMI has a really big chapter dedicated to Risk Management, the conclusion of which is a big big document named Risk Management Plan), it doesn't mean that Agile methodologies doesn't play the same game (but with different rules). They are also thinking about risks! Why do you think Scrum doesn't establish a big scope to achieve by the end of the project? Instead, they have several shots, functional pieces of a big scope in a short (but continuous) period of time.

YEP! They make us think about risk, without thinking about it! (Insert Blow your mind meme)

Among other things, the structure of SPRINTS basically allows the project to minimize all the risks inherent to the realization of any Software. It does this through small-scale, fully functional deliverables in short time frames, that allow us to "correct course" on the project in case of technical issues, changes in the business model, financial impact or absence of team members. You might minimize the risk by delivering indeed a “DONE”, potentially releasable Increment and releasing it to the market. (Let’s talk later about the definition of “DONE”).

As a matter of fact, every one of the Scrum´s ceremonies could be defined as a consequence of a Risk management point of view:

  • During the Daily Scrum the team manages risk in terms of reaching the Sprint Goal and other items that have to be delivered.
  • Throughout Sprint Planning, we create a forecast, Sprint Backlog and a Sprint Goal. A forecast is all about uncertainty and, thus, risk. When creating the Sprint Backlog and sizing Product Backlog Items you are evaluating risk as part of that discussion.
  • The Sprint Review is the ideal occasion to discuss business and technology risks while debating results of the last sprint.
  • Sprint Retrospectives contain fruitful conversations about what to improve as a Scrum Team and what might be considered to reduce risk (process, people, technology, Definition of Done, etc).

By the end of the day, we are always focusing on three kind of risks:

  1. Financial risk - Can we pay for it? Do we have enough resources to build it?
  2. Business risk - Will it be used? Does it solve a problem or THE problem? Will the client be happy with the solution?
  3. Technical risk - Can it be made/built? Does my team have enough knowledge to build it?

MYTH: I can’t afford to hire a Specialist Risk Manager to evaluate my projects.

REALITY: Again, the bottom line is most of the decisions (especially on projects) are taken considering the most important thing: MONEY. Knowing this, it’s quite difficult to find a really senior badass specialist on risk management, but you don’t actually need Reuben Feffer (Ben Stiller on Along Came Polly) to have decent risk analysis on your projects. Some really simple techniques could be used on the projects to have a good approach on the risk management area (hand by hand of Scrum ceremonies), and no-one in your team has to be senior on Risk Analysis. Here’s a couple of things you can do for free.

"WHAT IF?" Analysis

"WHAT IF?" Analysis is a really easy tool that can be used at the beginning of the project (or even in every Sprint Planning) to help the team understand the consequences of absences, dependencies or a lack of scope definition on the project. This exercise should be hosted by the scrum master / project manager, but with the participation of everyone on the project (Client, Product owner, Developers and any stakeholder who understands the scope). Basically the team has to evaluate the possible scenarios in which the project could be at risk, and/or the software to be built could be failing. For example:

What if React Native is not the best option for our app?

What if we don’t implement security alarms?

What if we don’t evaluate SEO in our web?

Most of the answers to these questions could lead us to one of two options: the definition of a new scope or target, OR a strategy to prevent the result of that question.


Yes, checklists; as easy as it sounds! To make a checklist with a structure/project oriented point of view, could be important for risk prevention on the project. We are not talking about a checklist regarding each deliverable (Which is not such a bad idea), but a checklist with the required events, actions or documents that may guarantee a successful result for the project.

In any case, Project Management is a science (and not an accurate one) that allows us to control the creation of something completely new and different, with the help of specialists in different areas, in a specific timeline. And no matter what methodology you prefer (PMI, SCRUM, SaFe, Prince, etc) Risk Management is a fundamental piece of each one of them, and may represent the difference between ending a successful project or just ending a project (Finally).

Last but not least, as almost everything in Project Management, there is no secret perfect recipe or the perfect guide to lead us step by step to finish every project successfully; but we can find a bunch of good practices, guidelines and techniques that a lot Project Managers over the world have implemented successfully (or disastrously). So the most important thing is to find the correct strategy that actually works on your freak team!

PS: If you want to go to Cancún, do not hesitate to call me and i’ll help you with the plan!