diff --git a/docs/methods/SAFe.md b/docs/methods/SAFe.md new file mode 100644 index 000000000..e69de29bb diff --git a/docs/misc/Authors.md b/docs/misc/Authors.md deleted file mode 100644 index 6afc19f77..000000000 --- a/docs/misc/Authors.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Authors -description: List of Risk-First authors - -featured: - class: bg1 - element: 'Authors' -sidebar_position: 12 ---- - -Currently, all articles authored by [Rob Moffat](https://github.com/robmoffat) \ No newline at end of file diff --git a/docs/misc/Start.md b/docs/misc/Start.md deleted file mode 100644 index bb3dec6a5..000000000 --- a/docs/misc/Start.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Miscellaneous -description: A bunch of random Risk-First articles that don't fit into the category structure. - -featured: - class: bg1 - element: 'Miscellaneous' -layout: categories -tags: - - Front -sidebar_position: 7 ---- - -# Miscellaneous Articles - -Pieces of news, and other articles that don't fit into the "tracks" structure on Risk-First. - - \ No newline at end of file diff --git a/docs/misc/_category_.yaml b/docs/misc/_category_.yaml deleted file mode 100644 index 0d55d58f1..000000000 --- a/docs/misc/_category_.yaml +++ /dev/null @@ -1,5 +0,0 @@ -position: 9 -label: 'Misc' -link: - type: doc - id: Start \ No newline at end of file diff --git a/docs/misc/Audience.md b/docs/overview/Audience.md similarity index 100% rename from docs/misc/Audience.md rename to docs/overview/Audience.md diff --git a/docs/misc/Contributors.md b/docs/overview/Contributors.md similarity index 98% rename from docs/misc/Contributors.md rename to docs/overview/Contributors.md index e561fa248..1fb7936b7 100644 --- a/docs/misc/Contributors.md +++ b/docs/overview/Contributors.md @@ -10,13 +10,6 @@ sidebar_position: 13 # Contributors -If you feel something important is missing, or you spot a mistake, [we need help](https://github.com/risk-first/website/blob/master/CONTRIBUTING.md). - -Although this is a collaborative Github project, it's not meant to be an open-ended discussion of software techniques like [Ward's Wiki](https://wiki.c2.com). In order to be concise and useful, discussions need to be carried out by either: - - - **[Opening an Issue](https://github.com/risk-first/website/issues).** - - **["Star"ing the project](https://github.com/risk-first/website/stargazers)**: this will cause you to be invited to join the Risk-First organisation - Ideas, issues and proof-reading: - [Ali Abbas](https://github.com/realabbas) @@ -31,5 +24,15 @@ Ideas, issues and proof-reading: - [Serhan Tutar](https://github.com/randomnoise) - [Stephan Westen](https://github.com/stephanwesten) +## Want To Help? + +If you feel something important is missing, or you spot a mistake, [we need help](https://github.com/risk-first/website/blob/master/CONTRIBUTING.md). + +Although this is a collaborative Github project, it's not meant to be an open-ended discussion of software techniques like [Ward's Wiki](https://wiki.c2.com). In order to be concise and useful, discussions need to be carried out by either: + + - **[Opening an Issue](https://github.com/risk-first/website/issues).** + - **["Star"ing the project](https://github.com/risk-first/website/stargazers)**: this will cause you to be invited to join the Risk-First organisation + +## Author _Currently, all articles authored by [Rob Moffat](https://github.com/robmoffat)_ diff --git a/docs/thinking/A-Conversation.md b/docs/thinking/A-Conversation.md index 3236d3fe8..17e7faa6a 100644 --- a/docs/thinking/A-Conversation.md +++ b/docs/thinking/A-Conversation.md @@ -10,7 +10,7 @@ tags: - Internal Model - Hidden Risk - Attendant Risk -sidebar_position: 13 +sidebar_position: 14 redirect_from: - /A-Conversation tweet: yes @@ -88,7 +88,11 @@ At this point, you might be wondering what all the fuss is about. This stuff i The problem is that although all this _is_ obvious, it appears to have largely escaped codification within the literature, practices and methodologies of software development. Further, while it is obvious, there is a huge hole: successful De-Risking depends heavily on individual experience and talent. -In the [next section](One-Size-Fits-No-One.md), we are going to briefly look at software methodology, and how it comes up short in when addressing risk. +## Where Next? + +This section has hopefully underscored the importance of _talking about risk_ with colleagues. If you're working in a team where this isn't happening then perhaps you can introduce this practice and improve your teams' odds of winning. + +If you're working in a larger organisation then the chances are that risk management is already well embedded in the organisation. So in the next section we'll have a quick run-down covering what developers need to know about [Enterprise Risk Management](Enterprise-Risk.md). diff --git a/docs/misc/Anti-Goals.md b/docs/thinking/Anti-Goals.md similarity index 85% rename from docs/misc/Anti-Goals.md rename to docs/thinking/Anti-Goals.md index b8d44d5d9..cc7a70ed4 100644 --- a/docs/misc/Anti-Goals.md +++ b/docs/thinking/Anti-Goals.md @@ -9,7 +9,7 @@ featured: author: rob tags: - Goal -sidebar_position: 10 +sidebar_position: 11 tweet: yes --- @@ -78,6 +78,15 @@ We need to acknowledge that pursuing certain goals via certain courses of action > "GIVEN the scope of this SaaS project, WHEN I develop it THEN I want to avoid burn-out and bankruptcy" +## Summing Up + +The most valuable project management skill is being able to chart a course controlling your exposure to risk. Sometimes, that will mean [hitting a deadline](/tags/Deadline-Risk), but equally it could be [reducing codebase complexity](/tags/Complexity-Risk), [making a feature more accessible](/tags/Feature-Access-Risk) or [removing problematic dependencies](/tags/Software-Dependency-Risk). + +The most important skill is to be able to _weigh up the risks_, decide on a course of action that exposes you to the greatest expected value, while looking for ways of increasing the payoff of winning and minimise the impact of losing. + +In the next section, we'll turn our attention to time: often, urgent risks _can_ crowd out the merely important. Why does that happen, and what should we do about it? In the next section, we'll look at how you can account for different levels of _urgency_ in your payoff considerations. + +On to [Evaluating Risk](Evaluating-Risk.md). diff --git a/docs/thinking/Cadence.md b/docs/thinking/Cadence.md index bdfc3b591..402f39ef0 100644 --- a/docs/thinking/Cadence.md +++ b/docs/thinking/Cadence.md @@ -80,12 +80,4 @@ Yes, CD will give you faster feedback loops, but even getting things into produc The right answer is to use multiple feedback loops, as shown in the diagram above. -## Moving On - -Let's quickly review the new terms introduced in this section: - - - - - In the next section we'll be [Considering Payoff](Consider-Payoff.md), and figuring out how we can use terminology from _betting_ to make us better software developers. diff --git a/docs/thinking/Consider-Payoff.md b/docs/thinking/Consider-Payoff.md index af920d77d..c32f124c1 100644 --- a/docs/thinking/Consider-Payoff.md +++ b/docs/thinking/Consider-Payoff.md @@ -273,12 +273,6 @@ As we've seen, figuring out payoff is made more tricky because often the actions Many Agile frameworks such as [Scrum](../bets/Purpose-Development-Team#case-2-scrum) place a lot of emphasis on estimating and time-boxing work: trying to work out when you're going to deliver something and sticking to it. But Risk-First is suggesting a totally different focus: factors like _time taken to deliver_ and _coordinating the completion of work_ are just risks to consider along with all the others. -The most valuable project management skill is being able to chart a course which minimises risk. Sometimes, that will mean [hitting a deadline](/tags/Deadline-Risk), but equally it could be [reducing codebase complexity](/tags/Complexity-Risk), [making a feature more accessible](/tags/Feature-Access-Risk) or [removing problematic dependencies](/tags/Software-Dependency-Risk). - -The most important skill is to be able to _weigh up the risks_, decide on a course of action that gives you the greatest expected value and look for ways of increasing the payoff of winning and losing. - -Often, urgent risks _can_ crowd out the merely important. Why does that happen, and what should we do about it? In the next section, we'll look at how you can account for different levels of _urgency_ in your payoff considerations. - -On to [Evaluating Risk](Evaluating-Risk.md). - +Betting generally focuses on the odds of winning. However, there are entire classes of problem (such as short positions) where you need to focus on minimising the risk of losing. +Let's look at that next in [Anti-Goals](Anti-Goals.md). diff --git a/docs/thinking/Crisis-Mode.md b/docs/thinking/Crisis-Mode.md index ce35133fe..7ada2dae7 100644 --- a/docs/thinking/Crisis-Mode.md +++ b/docs/thinking/Crisis-Mode.md @@ -6,7 +6,7 @@ description: Why 'Crisis Mode' shouldn't be a mode. featured: class: bg3 element: 'PanicCrisis Mode' -sidebar_position: 12 +sidebar_position: 13 tweet: yes --- @@ -18,9 +18,13 @@ In this section we're going to explore the assertion that good risk management p As software developers, we face crises of different sorts. Perhaps there's a production outage and we're up at 3am scrambling around to recover data from backups, or a sudden meeting with clients or investors arises in which we have to scramble to put together a prototype in short order. Agile software development doesn't have much to say about what we should do in these situations: Scrum's rigorous 2-week sprint model doesn't account for the sprint being interrupted by urgent events. -In this section, we are going to look at how a risk management approach to software development is invariant to a number of different things: the size of the project, the level of pressure and the technology being used. +## Testing For Invariances -## Crisis Management? +In this section, we are going to look at how a risk management approach to software development is invariant to a number of different things: the size of the project, the level of pressure and the technology being used. For example, I am an advocate of [Extreme Programming](../methods/Extreme-Programming.md). However, as you scale the size of the project, it breaks down. This is well understood and explains why methodologies like [Scaled Agile](../methods/SAFe.md) arose which attempt to fix this. + +Why would we want to do this? Einstein's ideas around relativistic gravity were proven because people discovered that the Newtonian model of gravity [failed to predict the orbit of Mercury](https://en.wikipedia.org/wiki/Tests_of_general_relativity#Classical_tests). So it's important to explore and understand the limits of our ideas and practices. + +## Invariance 1: Is It A Crisis? First though, let's talk specifically about "Crisis Management". A lot of literature on Crisis Management suggests that when a crisis occurs, you abandon your normal approach and switch to a different, crisis management approach. For example: @@ -36,7 +40,7 @@ Third, Crisis Management is _still just Risk Management_: the crisis (Earthquak Yes, it's fine to say "we're in crisis", but to assume there is a different strategy for dealing with it is a mistake: this is the [Fallacy of Sunk Costs](https://en.wikipedia.org/wiki/Escalation_of_commitment). -## Invariance #1: Pressure Invariance +## Invariance #2: Pressure Invariance You would expect that ideally, any methods for managing software delivery should be _invariant_ to the degree of crisis in the project. If, for example, a project proceeds using [Scrum](https://en.wikipedia.org/wiki/Scrum_(software_development)) for eight months and then the deadline looms and everyone agrees to throw Scrum out of the window and start hacking, then _this implies there is a problem with Scrum_ and that it is not **Pressure Invariant**. In fact, many tools like Scrum don't consider this: @@ -49,7 +53,7 @@ This is **Pressure Invariance**: ideally, your methodology shouldn't need to ch **See:** In [Debugging Bets](../bets/Debugging-Bets.md) I tell the story of a high-pressure situation where I applied a risk-analysis approach in order to try and bring a new problem to ground ahead of a big presentation. -## Invariance #2: Scale Invariance +## Invariance #3: Scale Invariance We are used to the idea that physical laws work at _any scale_: if they don't apply equally to big and small scenarios then that implies something is wrong. For example, Newton's Laws of Motion work fine for artillery shells but fail to calculate the orbital period of Mercury, which led to Einstein trying to improve on them with the [Theory of Relativity](https://en.wikipedia.org/wiki/Theory_of_relativity). @@ -67,7 +71,7 @@ If the methodology _fails at a particular scale_ this tells you something about In the previous section on [Health](Health.md) we looked at how risk management was used by the UK government at the scale of _the whole country_. -## Invariance #3: Technology Invariance +## Invariance #4: Technology Invariance In 2020 the world was plunged into pandemic. Everything changed very quickly, including the nature of software development. Lots of the practices we'd grown used to (such as XP's small, co-located teams) had to be jettisoned and replaced with Zoom calls and instant messaging apps. This was a very sudden, rapid change in the technology we use to do our jobs, but in a more general sense we need to understand that Agile, XP and Scrum were invented at the turn of the 21st century. The [Lean Manufacturing](https://en.wikipedia.org/wiki/Lean_manufacturing) movement originated post-WW2. @@ -79,7 +83,11 @@ The point I am making here is that while there are [technology tools to support ## Summing Up --- sum up here. +Humans have a built-in fight-or-flight mechanism which makes it hard for us to act rationally in times of stress. And as we'll explore in [Agency Risk](../risks/Agency-Risk.md), firms are able to abuse their staff's loyalty or enthusiasm in order to get them to work much longer than is healthy for either them or their projects. + +Risk management, like everything else, can be abused or misunderstood. + +In this section, we've looked at an important "proof" - the idea that risk management applies irrespective of pressure, scale or technology trends (so far, at least). This is really important as we need to know whether there's a point at which our tools won't apply anymore. -On to [A Conversation](A-Conversation.md) +In the next section, we'll start to look at how risk management can fit into working in our organisations, starting with discussing risk in a project team. On to [A Conversation](A-Conversation.md) diff --git a/docs/thinking/Enterprise-Risk.md b/docs/thinking/Enterprise-Risk.md new file mode 100644 index 000000000..c0c95ce78 --- /dev/null +++ b/docs/thinking/Enterprise-Risk.md @@ -0,0 +1,93 @@ +--- +title: Enterprise Risk +description: Understanding how risk management happens in the enterprise + + +featured: + class: bg3 + element: 'UrgentEvaluating Risk' +sidebar_position: 15 +tweet: yes +--- + + +# Risk In the Enterprise + + +In this chapter I want to look at the work being done by the risk management team and try to de-mystify this role a bit. We'll take an overview of the processes they follow and compare them with what we as developers get up to. The theme of this book is really that all work (including software development) is really risk management, so you would definitely expect the "risk management" teams to be doing risk management. It's almost reductive. + +## Process + +If you've worked in small organisations, the job of risk management generally might fall on the shoulders of the business owner or a leadership team and look much more like our dinner party example. However, if you have worked in large organisations you might be familiar with the term "Enterprise Risk Management" and the associated job title of "Chief Risk Officer (CRO)". Risk Management becomes much more _formal_ and becomes the job of a whole department of people. + +As with software development, once you start having a whole team of people doing things, you begin to need [a process](/tags/Process-Risk) to help coordinate them. The equivalent of [Scrum](https://scrum.org) for risk managers is the [COSO Enterprise Risk Management – Integrated Framework](https://en.wikipedia.org/wiki/Committee_of_Sponsoring_Organizations_of_the_Treadway_Commission#Business_risk_management). The parallels are somewhat striking: + + - Just as Agile software development arose as a reaction to the [Software Crisis](https://en.wikipedia.org/wiki/Software_crisis) (software projects generally being late, over-budget and poor quality) the COSO Framework evolved in reaction to fraudulent financial reporting and scandals such as [Enron](https://en.wikipedia.org/wiki/Enron) and [WorldCom](https://en.wikipedia.org/wiki/MCI_Inc.). + + - As with Scrum (and Agile generally), most organisations will use this as a jumping-off point for their own efforts. COSO is a [complex model to deploy](https://en.wikipedia.org/wiki/Committee_of_Sponsoring_Organizations_of_the_Treadway_Commission#Limitations) and at the end of the day a lot of risk management depends on human judgement so there's only so much a model can do. + + - And of course, there is a whole _industry_ around standards, certification and plenty of software vendors providing software solutions to help you do Enterprise Risk Management The Right Way. + +## Eight Components + +So that being said, here we're going to do a quick tour of the eight components of the model and see how this might apply in the world of software development. Specifically, we're going to see how each of these raises a question for you in a project you work on. So have an example in mind when answering the questions. + +### 1. Internal environment + +> "The internal environment encompasses the tone of an organization and establishes the basis of how risk is seen and addressed by the persons of an entity, including the risk management philosophy and risk appetite, integrity and ethical values, and the environment in which they operate." - [_Wikipedia_](https://en.wikipedia.org/wiki/Committee_of_Sponsoring_Organizations_of_the_Treadway_Commission#Eight_frame_components) + +The first component of the COSO model is the _Internal Environment_ and asks you to consider the approach of the organisation to risk. It's perhaps surprising that _ethical values_ might form a part of this, but clearly, if your organisation is willing to cut some corners and overlook some illegal behaviour this is -in a way- an acceptance of [Legal and Reputational Risks](../risks/Operational-Risk.md). + +A great example of risk appetite is [Meta (née Facebook)](https://www.meta.com) who, from 2004 until 2014 had the motto "Move fast and break things" - a clear statement of a high-risk attitude consistent with a desire to evolve their product as fast as possible. But in 2014, the firm changed tack completely to "Move fast with stable infrastructure" - _signalling an entirely different risk appetite._ + +**Question:** What is the internal environment for your project? What is your stance to risk? Are you risk takers or risk averse? Does the constituency of your client base affect this? + +### 2. Setting objectives + +> "The objectives must exist before management can identify potential events that affect its achievement." - [_Wikipedia_](https://en.wikipedia.org/wiki/Committee_of_Sponsoring_Organizations_of_the_Treadway_Commission#Eight_frame_components) + +There are not many organisations that simply allow their staff to turn up and do what they like and in larger firms objectives are usually "cascaded down" from the top of the firm. Conversely, in the small, our [dinner party example](/thinking/A-Simple-Scenario.md) requires that there is a [goal](/thinking/Glossary.md#goal) before we can consider the risks to that goal! + +In the [Health](/thinking/Health.md) chapter we looked at how _surviving and thriving_ become an objective of the organisation too. (TBD more here EXAMPLE) + +**Question:** What are the objectives of your project? Are there ways in which your team can "game" the objectives and introduce new risks? Are the objectives communicated to everyone in the team? + +### 3. Event identification + +> "Internal and external events that affect the achievement of the objectives of an entity must be identified, distinguishing between risks and opportunities. The opportunities are re-channeled into management strategy or goal-setting processes." - [_Wikipedia_](https://en.wikipedia.org/wiki/Committee_of_Sponsoring_Organizations_of_the_Treadway_Commission#Eight_frame_components) + +As we covered in the section on [Health](/thinking/Health.md), it is important not just to _react_ to events that occur to you but to look for trouble and try to be proactive / preventive about risks to health. For example, you don't need to wait until your application's hardware goes down or wait until users complain that their transactions aren't getting processed. These are risks you can think about in advance and identify. + +**Question**: What single points of failure exist on your application, whether people, processes, dependencies or hardware? Have you identified the risks surrounding them? + +### 4. Risk assessment + +> "The risks are analyzed, considering the probability and impact, as a basis for determining how they should be managed. The risks are inherently and residually assessed. "- [_Wikipedia_](https://en.wikipedia.org/wiki/Committee_of_Sponsoring_Organizations_of_the_Treadway_Commission#Eight_frame_components) + +Risk assessment is a topic we covered in the [Tracking Risks](/thinking/Track-Risk.md) section. + +### 5. Risk response + +> "Management selects risk responses, avoiding, accepting, reducing or sharing risk, developing a set of actions to align risks with the entity's risk appetite and risk appetite." - [_Wikipedia_](https://en.wikipedia.org/wiki/Committee_of_Sponsoring_Organizations_of_the_Treadway_Commission#Eight_frame_components) + +Deciding how to respond to risk has been covered in depth in [Consider Payoff](/thinking/Consider-Payoff.md) and [Derisking](/thinking/De-Risk.md) so we won't go over this again. + +EXAMPLE. + +### 6. Control activities + +Policies and procedures are established and implemented to help ensure that risk responses are carried out effectively. + +### 7. Information and communication + +The relevant information is identified, captured and communicated in a way and time frame that allow people to fulfill their responsibilities. Effective communication also occurs in a broader sense, flowing down, through and up the entity. + +### 8. Monitoring + +The entire business risk management is monitored and modifications are made as necessary. Monitoring is achieved through ongoing management activities, separate evaluations or both. + +## Summing Up + +tbd. + +Next article is on [Software Methodology](One-Size-Fits-No-One.md) \ No newline at end of file diff --git a/docs/thinking/Evaluating-Risk.md b/docs/thinking/Evaluating-Risk.md index 71346e110..9b66b0a25 100644 --- a/docs/thinking/Evaluating-Risk.md +++ b/docs/thinking/Evaluating-Risk.md @@ -6,7 +6,7 @@ description: Eisenhower's box, NPV and Discounting explained. featured: class: bg3 element: 'UrgentEvaluating Risk' -sidebar_position: 11 +sidebar_position: 12 redirect_from: - /Evaluating-Risk tweet: yes diff --git a/docs/thinking/Glossary.md b/docs/thinking/Glossary.md index bb224839c..982b552b0 100644 --- a/docs/thinking/Glossary.md +++ b/docs/thinking/Glossary.md @@ -7,7 +7,7 @@ featured: class: bg3 element: 'Glossary' -sidebar_position: 15 +sidebar_position: 17 redirect_from: - /Glossary tweet: yes diff --git a/docs/thinking/Meeting-Reality.md b/docs/thinking/Meeting-Reality.md index 1c6210668..0d1c2c8f2 100644 --- a/docs/thinking/Meeting-Reality.md +++ b/docs/thinking/Meeting-Reality.md @@ -20,7 +20,6 @@ definitions: - name: Internal Model description: The model of reality held by an individual, team, software system or other Agent. anchor: different-internal-models - own_term: true sidebar_position: 4 redirect_from: - /Meeting-Reality diff --git a/docs/thinking/One-Size-Fits-No-One.md b/docs/thinking/One-Size-Fits-No-One.md index 9fe63a950..2a587e671 100644 --- a/docs/thinking/One-Size-Fits-No-One.md +++ b/docs/thinking/One-Size-Fits-No-One.md @@ -11,7 +11,7 @@ tags: - Goal - Feedback Loop - Hidden Risk -sidebar_position: 14 +sidebar_position: 16 date: 2019-01-22 16:32:03 +0000 redirect_from: - /One-Size-Fits-No-One