Glossary
The process of removing physical, spatial, or temporal details or attributes in the study of objects or systems in order to more closely attend to other details of interest.
The process of testing an Internal Model by testing it, through taking action to Meet Reality. Typically, we talk about short or long feedback loops, depending on the intervals between Meeting Reality.
A picture of the future that an individual or team carries within their Internal Model; An imagined destination on the Risk Landscape.
The model of reality held by an individual, team, software system or other Agent. You can regard the concept of Internal Model as being what you know and what you think about a certain situation.
Obviously, because we've all had different experiences, and our brains are wired up differently, everyone will have a different Internal Model of reality.
- Within an organisation, we might consider the Internal Model of a team of people to be the shared knowledge, values and working practices of that team.
- Within a software system, we might consider the Internal Model of a single processor, and what knowledge it has of the world.
- A codebase is a team's Internal Model written down and encoded as software.
An internal model represents reality: reality is made of atoms, whereas the internal model is information.
Any moment where we test an Internal Model by exposing it's predictive power against reality. Note that "Reality" might be limited in some way, for example, a trial period or test users.
Pay-Off refers to the value of the [actions we take](#taking action). When we decide on a course of action, we have in mind a risk we wish to manage. If the action is likely to have a big positive effect on the risk of a project, we say it has a promising pay off, whereas if the action fails to manage the risk, then it hasn't paid off.
A possibility of loss or cost. Anything that can go wrong on a project, or is going wrong, but so far hasn't been quantified. We talk about risk because we wish to recognise both the range of possibilities and the range of cost.
Usually broken down into:
A Risk you expect to face as the result of Taking Action.
Hidden Risk
Risks you aren't aware of when you consider Taking Action. i.e. an unknown unknown.
Risks that, as a result of Taking Action have been minimized.
The possibility of things going well, and leaving us with a benefit. We may take action to maximize the likelihood and return of upside risks.
A hypothetical landscape on which risks can be placed. Taking Action means making a move on the Risk Landscape to reposition a project so that it has a different profile of Attendant Risks.
Refers to any activity in the project. Actions are usually in order to manage some kind of risk. At the same time, Taking Action usually means interacting with reality and updating the Internal Model.
| Risk | Definition |
|---|---|
| Boundary | Risks due to the choices we make around dependencies, and the limitations they place on our ability to change. |
| Agency | Risks due to the fact that things you depend on have agency, and they have their own goals to pursue. |
| Channel | Risks due to the inadequacy of the physical channel used to communicate our messages. e.g. noise, loss, interception, corruption. |
| Communication | Risks due to the difficulty of communicating with other entities, be they people, software, processes etc. |
| Complexity | Risks caused by the weight of complexity in the systems we create, and their resistance to change and comprehension. |
| Conceptual-integrity | Risk that the software you provide is too complex, or doesn't match the expectations of your clients' internal models. |
| Coordination | Risks that a group of agents cannot work together in a mutually beneficial way, and their behaviour devolves into competition. |
| Dead-End | The risk that a particular approach to a change will fail. Caused by the fact that at some level, our internal models are not a complete reflection of reality. |
| Deadline | Where the use of a dependency has some kind of deadline, which can be missed. |
| Dependency | Risks faced by depending on something else. e.g. an event, process, person, piece of software or an organisation. |
| Feature-Access | Risks due to some clients not having access to some or all of the features in your product. |
| Feature-Drift | Risk that the features required by clients will change and evolve over time. |
| Feature | Risks you face when providing features for your clients. |
| Feature-Fit | Risk that the needs of the client don't coincide with services provided by the supplier. |
| Funding | A particular scarcity risk, due to lack of funding. |
| Implementation | Risk that the functionality you are providing doesn't match the features the client is expecting, due to poor or partial implementation. |
| Internal-Model | Risks to communication caused by the fact that the internal models of the participants are semantically incompatible in some way. |
| Invisibility | Risks caused by the choice of abstractions we use in communication. |
| Learning-Curve | Risks due to the difficulty faced in updating an internal model. |
| Map-And-Territory | Risks due to the differences between reality and the internal model of reality, and the assumption that they are equivalent. |
| Market | Risk that the value your clients place on the features you supply will change, over time. |
| Message | Risks caused by the difficulty of composing and interpreting messages in the communication process. |
| Operational | Risks of losses or reputational damage caused by failing processes or real-world events. |
| Opportunity | Risk that a particular set of market conditions. |
| Process | Risks due to the fact that when dealing with a dependency, we have to follow a particular protocol of communication, which may not work out the way we want. |
| Protocol | Risks due to the failure of encoding or decoding messages between two parties in communication. |
| Red-Queen | The general risk that the competitive environment we operate within changes over time. |
| Regression | Risk that the functionality you provide changes for the worse, over time. |
| Reliability | Risks of not getting benefit from a dependency due to it's reliability. |
| Scarcity | Risk of not being able to access a dependency in a timely fashion due to it's scarcity. |
| Schedule | The aspect of dependency risk related to time. |
| Staff | The aspect of dependency risks related to employing people. |
| Trust-And-Belief | Risk that a party we are communicating with can't be trusted, as it has agency or is unreliable in some other way. |
