Risk Questions
The two risk questions typically asked (and postulated in the article) are "how likely is it to go wrong" and "if how what's the impact".
These questions have a fundamental flaws. Firstly, there isn't a single dimension. A typical change has some low-likelihood change of something going a little bit wrong, and a very-low-likelihood chance of going very seriously wrong. These can't be put into a single answer.
Secondly, both of these questions are next to impossible to answer objectively and hence with a degree of repeatability. Different engineers will, perfectly legitimately and competently, come to different answers. For example one engineer might consider a typo in applying a change with impact to one particular service as the impact to focus on as it's the most common scenario. Another one would instead consider triggering an unknown software defect that impact a whole host of otherwise not directly related services, as this is the worst case impact. In either case it's difficult to see how "likelihood" could be objectively described.
Thirdly, these questions put the focus in the wrong place. It focuses on the expected outcome of the change so encourages not just wishful thinking but also focus on the "expected unexpected" outcomes.
I am advocating two different questions instead: "How quickly do you notice a problem" and "how quickly and reliably can you roll back". These two questions are considerably more objective, and they drive good behaviours such as focusing on monitoring which might otherwise be overlooked. Crucially it encourages to think about worst-case service restoration which is often most relevant for the business - think about 5min worst-case impact vs. hour of worst-case impact. So these questions focus on dealing with the biggest issues in a mature change control environment - the "unexpected unexpected".