Game Manifesto

Untitled blue

Tech risk management is an intrinsic part of the planning process of any project. It provides answers to questions like – “What if the technology we rely on fails?”. It is not unusual for many projects to have new unproven tech at their core, or even tech that has not been developed yet. How can you guarantee that it is going to work out?

Often times, the answers to questions like these are sought not only by the internal team managers, but by investors as well. If nothing else, they are putting their money on the line and it is only natural that they would want some reassurance their investment is not a gambling venture.

Good tech risk management structures the work in a way that guarantees project’s success even if the tech behind it doesn’t work out. It essentially reduces the risk of project failure, therefore making the investment (both of time and effort from the team, as well as money from investors) a safer venture.

For those unfamiliar with risk management this might sound like some black magic voodoo. After all, how can one guarantee that some tech yet to be developed is going to work out? As it turns out, though, one doesn’t have to predict the future to be able to minimize the risks. It all boils down to a few management techniques that take care of it.

During the planning phases of the project all essential tech aspects are analyzed and divided into roughly three categories – Negligible Risk, Moderate Risk and Substantial Risk. Each one of them is then treated according to its category, described below. If later during a progress review it is found that something worked out differently than what was planned, both in a good or a bad way, the respective items can be moved to a different category and re-addressed.

Negligible Risk

This is tech that has a proven track record, it is reliable and the team has experience using it. Or, even better, it was already implemented within the project and performs to expectations. There is little chance of something going wrong here. Ideally, we want as many of the tech items to be in this category, as there is nothing we have to do to court them.

Now, why would we pay attention to items that are low risk, why even mention them at all? Surely, they are not likely to create any problems, that’s why they are in this category to begin with.

The reason to list and track them is that the fact of them being low risk is not obvious to all the stakeholders. Especially to investors – they are seldom tech people. What they look for when they scan through the TDD (or the risks section of a business plan) is verdicts of “no risk”. It also shows that those items were considered for risk, not just omitted by negligence.

As a side benefit, you get a list for tracking throughout the project development, just in case one of these “safe” items silently gives up.

Moderate Risk

These are items that are not likely but might not work out, or maybe provide not quite the expected results. It can be tech that, though proven generally, the team does not have experience with. Or maybe proven tech that the team used in the past but it is being applied in a novel way or pushed to a new extreme. The tech guys say it can be done, but it wasn’t actually done yet, or not within your team.

The way to deal with these is to line up a back-up plan in case the tech in question doesn’t work out. For example – if solution X fails, we will use solution Y that is inefficient/expensive/whatever but it is proven and will provide the result within acceptable parameters.

Of course, all the work on the former tech has to be planned towards the beginning of the project and there should also be defined a cut-off evaluation point that leaves enough time to implement the backup solution if the tech in question fails. This way you know that the experimental tech can be pushed for as long as possible and still have time to safely switch to the backup in case it doesn’t work out.

Essentially we offer a Negligible Risk level backup for our Moderate Level risk item and making it safe in case of failure. The only downside cost is in the inefficiency/cost/whatever drawback of the backup solution, so from an investor point of view a failure of the tech item would only result in not gaining the benefits the new tech promised.

Substantial Risk

This category is for fun technology that has yet to be developed. It could look feasible but never attempted before, or it can even be items that “I have no clue how we will solve it”. It’s the cutting-edge of development and chances of it not working out are usually better than otherwise. It would be a gamble to pin your project on these kind of tech items, yet these are usually foundation stones of highly successful break-through ventures.

The way to turn this from gamble into a manageable process is to define a feasibility test, basically a set of questions that have to be answered to find out if this tech is working out the way it is expected of it. It can be done through an R&D phase before the full project development begins. It doesn’t have to be full tech development, just enough of the critical pieces to be able to see if it can deliver the promised goods. At that point it can be classified as a lower level risk item and then the project can proceed.

From an investor point of view, the risk is limited to the time and money invested in the R&D phase, which is considerably less than what a full project with a full team would carry, so the potential loss is small and under control. Moreover, if the full R&D phase is still too big and expensive, it can be split into several steps, each with its own feasibility tests and proceed from one to another only if the preceding one was positive.

Ultimately, one has to take a leap and risk some investment for a chance of the new tech working out, but it doesn’t have to be disastrous if it doesn’t. R&D investment is just an overhead item in any well defined budget, so these items then become part of a planned budget category instead of being categorized as loss outright.

Conclusion

Disseminated one by one, the above techniques now seem like common sense. Yet it is amazing how many teams do not employ them and then either struggle to adjust when technology inevitably fails, or even before getting to that point are puzzled why investors are skeptical to jump in.

Naturally, these Risk Management techniques are just a guideline and have to be employed according to the specific situation. A backup tech can be used for Substantial Risk items if the project is too critical not to proceed regardless of that tech, or in some cases the backup tech can be used to jump-start the project and then the R&D tech can be later substituted in provided it works out within an acceptable time frame. These kind of moves are possible with some planning in advance by structuring the work, protocols and specific implementation of your project.

Risk management is not about avoiding risk. This is impossible. It is about investigating the possible outcomes and minimizing the potential loss. Have a backup. Fail Fast.