Risk tolerance is defined on investopedia as the degree of uncertainty that an investor can handle in regard to a negative change in the value of his or her portfolio. Sounds pretty good to me for project portfolios too.  In our case, negative change includes concrete things like expenditures that fail to return expected value and more abstract things like automation in the development process that fails to create consistent, reoccurring increases in project velocity.  Some negative changes are more subtle but at least as damaging; staff failing to demonstrate expected skills, significant ambiguity in scope, and external dependencies that fail to meet their promised level of performance, just to name a few.

More clinically, risk can be defined as is standard deviation, a statistical measure of dispersion around a central tendency.  The the central tendency equates to what we generally refer to as the Planned Value portion of the Earned Value calculation.  The dispersion is represented by cost and schedule variance across a given period of time.  In our case that would be the entire duration of activities from good idea to delivered.

To do this, all you need is;
1- identify the type of project you have and
2- determine the historical trend for similar development efforts. 

Of course, this is incredibly hard given the industries terrible record keeping, our complete lack of broadly agreed on taxonomy (what is a large complex project really?), and the project stories that do exist out there are largely optimistic fables with limited basis in fact .  Even when we have reliable records our methodologies and practices have evolved so quickly that it may be impossible to find the necessary trend information to answer the question with any statistic validity.

This leaves you with two less-than-optimal but viable methods to establish a baseline.  The first, takes the total time available to you and divides it by the number of features you believe you need to produce.  We will call this "pure linear optimism".  It assumes everything works, works well, and works the first time.  The second option is look deep into your Magic 8-ball and layout a plan that reflects your personal experience, knowledge of the team, the tools, and the customer.  This has long been referred to as a scientific-wild-ass-guess or SWAG.  In the absence of real historic data both the pure linear and SWAG models are equally likely to be correct.

With your recently determined planned value baseline in hand lets figure out your risk tolerance.    Our goal is to decide, for either the entirety or at least what remains of the project timeline, where on the following scale does the project fall;

Risk_Tolerance

It seems simple enough but it’s not.  The more pressure you feel to improve and deliver faster, the more attractive high risk, high reward practices seem.  Alas too many high risk decisions actually increases the likelihood of incurring one or more of the associated high losses.  Conversely. it seems obvious that staying with as many low risk practices as possible should reduce overall risk and increase the likelihood of success.  But don’t forget that too many low risk choices actually increase the risk of too little return.

While there is no single model to determine risk tolerance every project here are 4 important things to factor into your risk tolerance identification process;

  • Experience with the team, the tools, the technology, and the problem space must be significant factors in determining just how much risk you can take.  If you are short on experience with two or more of these areas you already have created a high risk project and should seek predominately low and medium risk remedies.
  • Must meet goals such as quick release to production, more features than ever tried before, or a solution that is significantly more performant than has been achieved in the past, create constraints that limit where and when you can choose higher and in many cases lower risks.
  • Your Risk capital reserves - what you can afford to lose and still deliver – in time and budget.  The more you have in reserves the more open to take risks you be.  The more Risk Capital on hand the more you can gamble on high risks yielding high returns … until a high risk gamble fails and your reserve is consumed.
  • Risk pressures in the form of immovable and dangerous constraints can drive you to accept risk without alternatives.  Being the first to scale a technology beyond the vendors stated limits, or inheriting a team without the required skills may induce project performance issues that paradoxically can’t be addressed without increasing the risk further.

There is no ‘right’ answer to what your risk tolerance should be.  Without exception, your tolerance is what it needs to be.  The only question is will you determine the level of risk your project can tolerate or will you be surprised by it sometime in the future.