Resilience Engineering sees the "things that go wrong" as the flip side of the "things that go right" and therefore assumes that they are a result of the same underlying processes. In consequence of that, "things that go right" and "things that go wrong" should be explained in basically the same way.
It therefore makes as much sense to try to understand why things to right as to understand why they go wrong. In fact, it makes more sense because there are many more things that go right than things that go wrong, the ratio depending on how (im)probable an accident is considered to be.
If, for instance, the probablility of failure is 10-4 (meaning 1/10,000), then humans are usually blamed for 80-90% of the one case out of 10,000 when things go wrong. By the same "logic", humans should be praised for a similar 80-90% of the 9,999 cases where nothing goes wrong.
....
Resilience Engineering proposes that we should try to understand a system's performance in general, rather than limit ourselves to the things that go wrong, that is, try to understand all the outcomes shown in the figure, rather than only the negative ones - with the possible exception of "good luck".
Erik Hollnagel, Resilience Engineering in Practice, Ashgate 2011, p xxxiii