Also, it occurred to me that calculating risk warrants a separate spreadsheet similar to the one you created. One of the inputs into this sheet would be the scenarios. One of the outputs would be, in a way, some of the weights and scales in your project estimation spreadsheet.

The sort of parameters one would manipulate in such a spreadsheet would be: complexity, priority, severity, competition factor (could be quite complex & elaborate e.g. based on Gartner quadrant + market share), likelihood of scenario occurrence / scenario depreciation, integration / handover / adoption problems, staff & skill-set parameters, perceived amount of unknowns.
I think the output of such calculations should ultimately be the “percent of certainty of success” (I won’t garbage up your blog about what success criteria is, I promise) where 0% is a doom and 100% is a sure thing. It would be useful to get such output per scenario, per logical group of scenarios and per project.

Putting my pen down now…

This is very interesting. This got me thinking about MY ways of doing such estimations…
A thought about steps #2-4.
When I do *technical* project estimations, I always try to come up with a rating based on 3 things: complexity, priority and severity and then adjust them according to the perceived number of unknowns, etc, etc. I call my rating “risk indicator”. Thus far, nothing new…and I think I understand why you omitted the two latter ones from your spreadsheet.
But looking at you spreadsheet, I realized how one could “scientifically” calculate the actual risk! I think this could really help with #3-4 because I think you are doing this calculation outside of the spreadsheet and then using this mental indicator to tweak #3-4. I might be reinventing a well known truth here but nonetheless:

Risk is NOT a COMBINATION of complexity, priority and severity.
Risk is a MISALIGNMENT / DISCREPANCY between complexity, priority and severity!

Just think about it. Risk grows not due to your complexity, priority and severity being high but rather, it grows in cases where e.g. your severity is high but your priority is low – and you end up doing things in a technologically wrong (priority) order.

If you were to assign complexity, priority and severity ratings to technological scenarios (based on the same scale), just identifying the misallignments between the ratings of a single scenario would give you a good idea of the RISK involved.

The same is probably true about business scenarios but since in business, priority (of initiative) and severity (of impact) seem to go together, I would probably stick with just priority and complexity…

A bit more about risk.
———————–
Risk indicator is good for 4 things:
1. Influencing project feasibility rating
2. Influencing project scope (e.g. descope the most risky artifacts)
3. Influencing prioritization (e.g. do risky things first)
4. Translating risks into time. Specifically, it is useful to translate risks into a contingency buffer because no matter what you do, some risks will get realized and will end up costing time.