Risk as a motive for systems Engineering		Date	2024-08-18
		Tags

Risk [noun]—A po­ten­tial sce­nario in a project that is recorded in a risk man­age­ment plan and for­got­ten about un­til it man­i­fests as an is­sue.

I’m be­ing face­tious but this does­n’t seem too off the mark as a de­f­i­n­i­tion in many en­gi­neer­ing or­gan­i­sa­tions. Risk and risk man­age­ment are fun­da­men­tal to sys­tems en­gi­neer­ing–after all, Risk Man­age­ment is one of the ISO 15288 processes which de­fines its pur­pose as:

… to iden­ti­fy, analy­se, treat and mon­i­tor the risks con­tin­u­al­ly.

Risk man­age­ment as usu­ally prac­ticed cer­tainly fails this de­f­i­n­i­tion. This pro­poses the ques­tion: what is risk and how should it be man­aged? Al­though fol­low­ing ISO 15288 and the SE hand­book will get you through a pro­jec­t’s risk man­age­ment ad­e­quate­ly, I be­lieve treat­ing risk this way alien­ates the con­cept from the en­gi­neer­ing process.

In this blog post, I’d like to ex­plore the idea of risk and to Make the point that risk is not just some­thing to be man­aged on the side of an en­gi­neer­ing project but a fun­da­men­tal part of en­gi­neer­ing that pro­vides a mo­tive, mea­sure and di­rec­tion for an en­gi­neer­ing project it­self in a way that other mea­sures can­not.

On the way, we’ll ex­plore con­cepts from the scrum frame­work and a con­tender for the philo­soph­i­cal de­f­i­n­i­tion of life it­self.

What is Risk?

Risk is a mea­sure of known un­knowns. We de­fine it by iden­ti­fy­ing a set of sce­nar­ios that may hap­pen, un­der­stand­ing the im­pact that such a sce­nario would cause and the like­li­hood that such a sce­nario could come about. The mea­sure of risk is then usu­ally de­fined with 3 or 5 lev­els based on an im­pact and like­li­hood scor­ing sys­tem. Risks in­habit all parts of a sys­tem life­cy­cle. Un­der­stand­ing op­er­a­tional risk gives us the core of Func­tional Safe­ty, Cy­ber se­cu­rity and Re­li­a­bil­ity en­gi­neer­ing (HARA, TARA and EMEA re­spec­tive­ly, for ex­am­ples). In this post, how­ev­er, we’re go­ing to fo­cus on pro­gramme risk, in other words, risks that, if they come to fruition, cause project costs and tim­ings to in­crease. What con­sti­tutes a risk to a pro­gram­me? An­swer­ing this ques­tion is my fun­da­men­tal break with tra­di­tional risk man­age­ment.

My pro­posal is that every en­gi­neer­ing arte­fact car­ries a risk.

Let me ex­plain why.

I’ll be­gin with a slightly dif­fer­ent model of en­gi­neer­ing than most are used to—The cy­ber­netic loop model of en­gi­neer­ing.

Un­like the Vee mod­el, the cy­ber­netic loop shows the de­pen­den­cies of en­gi­neer­ing-rather than the chronol­o­gy. I like to think of it as a Vee shown from above. The cy­ber­netic loop is made of the re­la­tion­ships be­tween an en­vi­ron­ment (En) and a model of that en­vi­ron­ment (Und for Un­der­stand­ing). Evo­lu­tion is the change of the En­vi­ron­ment with time; Learn­ing is the process of chang­ing our un­der­stand­ing based on how the en­vi­ron­ment changes; De­vel­op­ment are ac­tiv­i­ties that im­prove our un­der­stand­ing in­ter­nal­ly; and Ac­tion is chang­ing the en­vi­ron­ment based upon our un­der­stand­ing.

The story of any en­gi­neer­ing project is the as­sump­tion that the en­vi­ron­ment is prob­lem­atic for some key stake­hold­er. The en­g­in­eer­ing project then re­solves to make some ac­tion in the en­vi­ron­ment to re­solve this prob­lem. This re­quires learn­ing and de­vel­op­ment to en­sure that our fi­nal ac­tion solves the prob­lem-Ac­tions are ex­pen­sive! We can think of the De­vel­op­ment loop as a mir­ror to the Evo­lu­tion loop. This is where we do our de­sign­ing. How­ev­er, as de­vel­op­ment is per­formed en­tirely on the un­der­stand­ing, any places where the un­der­stand­ing does not cor­re­spond to the En­vi­ron­ment will be am­pli­fied. If our de­vel­op­ment loop runs away with it­self for ages, when our ac­tion is fi­nally made, it is highly un­likely that it will make the de­sired im­pact on the en­vi­ron­ment. We will be sur­prised.

In na­ture, as well as busi­ness, suprisal is ex­pen­sive and dan­ger­ous. Those ‘things’ that min­imise suprisal tend to last (sur­vive) longer. This is known as the prin­ci­ple of Min­i­mal Sur­prisal Or, less evoca­tive­ly, the Free En­ergy Prin­ci­ple.

where does risk fit into all this? Think­ing of it this way, risk is a mea­sure of how likely our ac­tions will sur­prise us, mul­ti­plied by the ex­tra ef­fort and time re­quired to rec­tify the state of Sur­prisal. We can be sur­prised be­cause every piece of in­for­ma­tion cre­ated by the de­vel­op­ment cy­cle is an as­sump­tion.

This idea is re­flected in the Ag­ile idea of Riski­est As­sump­tion Tested Soon­est (RAT­S). RATS is the sim­ple idea that the goal of any en­gi­neer­ing project is to val­i­date your riski­est as­sump­tions as soon as pos­si­ble. In fact, en­gi­neer­ing should only be the de­vel­op­ment of tests of riski­est as­sump­tion. This may seem a bit ex­treme at first glance, but once we’ve ex­plored what this means, I hope that you’ll see that it’s the only sen­si­ble mo­tive for en­gi­neer­ing.

I men­tioned ear­lier that all re­sults of the de­vel­op­ment process are as­sump­tions. Tak­ing this uni­ver­sal­ly, this means all per­son­al, sci­en­tific, in fact, the sum to­tal of hu­man knowl­edge is as­sump­tion. A bunch of risky as­sump­tions at that! In the en­gi­neer­ing world, all de­sign de­ci­sions and re­quire­ments carry around two as­sump­tions:

1. This will sat­isfy the stake­hold­ers’ de­sire

2. This is fea­si­ble within the laws of the land, fis­cal con­straints & physics

There­fore, to an­swer this sec­tion’s ques­tion; what is a Risk?

Every­thing En­gi­neers cre­ate!

RATS as Praxis

An en­gi­neer­ing project can of­ten con­sist of 10,000-100,000 re­quire­ments, or even more! man­ag­ing that many risks in a risk reg­is­ter would be in­cred­i­bly te­dious. Close re­lated to RATS is the con­cept of a Min­i­mum Vi­able Prod­uct. MVP is an oft-misun­der­stood con­cept, here we’re us­ing it to mean a ‘cheap’ ac­tion in the en­vi­ron­ment that al­lows us to test an as­sump­tion.

Good, prac­ti­cal, ex­am­ples for MVP’s are User sto­ries and Use cas­es. User sto­ries can be used to cap­ture stake­holder needs and near-in­stantly re­play them to the stake­holder for val­i­da­tion. Use cases add a bit of con­cept work to this to gain stake­holder val­i­da­tion on the con­cept.

An is­sue that I’ve seen play out a few times is the ten­dency for or­gan­i­sa­tions to rit­u­alise en­gi­neer­ing. Most en­gi­neer­ing com­pa­nies go through the mo­tions of an ex­per­i­men­tal pro­to­type, Hard­ware-in-loop pro­to­type, val­i­da­tion pro­to­type, pro­duc­tion pro­to­type &c. Every in­dus­try has this pro­ces­sion in var­i­ous forms. Of­ten the ques­tion of which fea­tures to im­ple­ment on each of the pro­to­types is of­ten vaguely an­swered. RATS fixes this straight away. Which fea­tures go on the XP? The riski­est ones. The fea­tures that all oth­ers de­pend on, the pri­mary use Cases &c.

To cal­cu­late our risk, for each fea­ture, we can use a mea­sure of how com­plex the en­gi­neer­ing prob­lem is—often called like­li­hood or ex­po­sure— and our im­pact of the sys­tem go­ing to pro­duc­tion with­out it or it be­ing in­cor­rectly im­ple­mented on a scale of the user not notic­ing to the sys­tem be­ing il­le­gal /un­safe.

There’s a meta risk of this im­pact/­ex­po­sure score be­ing un­cor­re­spon­dent to your en­gi­neer­s/s­take­hold­er’s re­al­i­ty—­make sure they’re in­volved in the dis­cus­sion!

Risk in Mo­tion

One fi­nal de­f­i­n­i­tion for risk is that its an er­ror bar for the project cost & tim­ing fore­casts. By their very na­ture, you can never say which risks will be­come is­sues, but, on ag­gre­gate, many of them will. There­fore, the faster risk is burnt down’ the sooner project fore­casts can con­verge to­wards a more ac­cu­rate es­ti­mate.

Think­ing along these lines leads us to un­der­stand­ing that risk is a suit­able lodestar for en­gi­neer­ing pro­jects. Tra­di­tion­ally project gate­ways are usu­ally con­ducted by un­der­stand­ing which tasks have been com­plet­ed, with a gate­way cri­te­ria defin­ing a com­ple­tion and qual­i­ty. Risk through this lens pro­vides a ‘why’ for these cri­te­ria and also helps us un­der­stand whether to pass a gate­way, post­pone it or aban­don the pro­ject- Us­ing risk as an er­ror bar, we can pro­pose ex­pected cost & tim­ing over­runs to the purse hold­ing stake­holder and let them make an in­formed de­ci­sion.

Con­clu­sion

This post has been a brief ex­plo­ration of a more in­te­grated ap­proach to risk than usu­ally tak­en. In my own en­gi­neer­ing Pro­jects, I’ve been push­ing and im­ple­ment­ing such an ap­proach to risk to help in­form stake­hold­ers, build trust and un­der­stand the pri­ori­ti­sa­tion of work.

I hope that I will be able to pro­vide some prac­ti­cal ev­i­dence and ex­am­ples of treat­ing risk in this man­ner in the fu­ture. Un­til then, I hope this post has helped clar­ify your think­ing about risk, for or against my pro­pos­al-let me know if you have any thoughts be­low!

Site proudly generated by Hakyll | Theme based on Oskar Wickström's Monospace Web.