Technical governance entities

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.


Sorting your cats into classes

Call me pedantic (you wouldn’t be the first), but I have found terms like category and class end up being used ambiguously, and interchangeably – and I do it sometimes, too! So I have decided to put a stop to this and define the way I think the terms should be used. And it all comes down to exlcusivity…

Class(-ify, -ification) – a given item can only be a member of a single class (unless it inherits from a super-class) and indeed it MUST be a member of a class.

Category(-ise, -isation) – a given item may concurrently be a member of multiple categories, or indeed of none.

So, the item’s position in the prime hierarchy or taxonomy, usually detemined by who owns it or who is responsible for it, indicates its class. Within the whole domain, this structure is generally relatively stable. It can change, just like organisations can restructure, but it takes time and effort and involves upheaval.

If you want to have alternative forms of grouping, like search tags, or secondary means of browsing items, you can create categories. Because they are optional, flexible, and can be multiple, there is more scope to refresh, restructure, add new structures and depreciate irrelevant ones.

“Each item must have a single class and may have multiple categories”

It seems so simple now. Maybe you already understood this definition – sorry if I’m stating the obvious. However, this reminds me of the day I learnt the difference between authentication and authorisation – the dark clouds of doubt just fell away. But then you should know by now that I’m a geek as well as a pedant 🙂