I was happy to read a Rich Maltzman post on the “lifecycle of assumptions” (Scope crêpe: The biology of assumptions). Its reassuring to see that others place similar importance in tracking such potential bumps in the road, and realise that they can morph from one from into another.
I began some work a few months back into defining what I called Technical Governance. The classic entities used in project governance are known as “RAID”, for Risks, Assumptions, Issues and Decisions. Two of the simple lifecycle stages I identified were that
- Issue = circumstance that requires an Action that is not yet in the plan
- Risk = Issue that has not yet matured (or might not at all)
- Assumption = unvalidated fact that potentially leads to a risk
Although this was becoming promising, my focus was pulled away before I could complete the circle with with some earlier work on Requirements. Working on technological projects requirements are not just an important tool, they are fundamental. In the past I have had to widen the consideration of what constitutes a Requirement:
- Goal – top level requirement that guides choices in downlevel requirements and design
- Benefit – implication that a requirement will deliver a service improvement or cost reduction
- Standard – requirement implied by someone who is not a direct stakeholder
- Constraint – negative requirement (“must not” or “won’t”)
- Dependency – an outgoing requirement, where something is needed from someone else
- Assumption – made in lieu of a requirement
Here you can see Assumptions in another guise, where they are stated for clarity and audit traceability – better to have an assumption stated in the workings rather than hidden in someone’s head, where it can become really dangerous. Remember that with all of these entities it is important that all stakeholders can see them if they are interested – awareness is the first step to resolution.
I note that Rich describes an Assumption maturing into into a Risk as either as a Threat that something will get worse or as an Opportunity that things will improve. I’ll have to make sure I carry forward this idea that Risks can be positive as well as negative, because it is always so common to focus only on the potential for disaster – not what you need when your trying to make serious progress.
Another link between RAID and requirements is a Decision – if its a choice
made during design, it may lead to fresh constraints and dependencies.
As you can see there are plenty of ways in which you can get value from observing and understanding the behaviour of these various entities, to watch their lifecycles and the way they interact. I believe that Ethology can help Technology, but I have yet to convince my project manager that a day at the zoo will help us meet our milestones.