Reduce your delivery cost – link requirements to benefits

I have been trying to focus myself on benefits and achievements whilst preparing my CV and other personal marketing materials, but I have suddenly realised how valuable benefits can be when defining requirements.

An acronym many people use the help them define benefits is “FAB” – Feature, Advantage, Benefit. The Feature is the activity that I carried out as part of my role, the Advantage is how this improved what was there before, and the Benefit is a tangible description of how the company or people’s working lives were better thanks to my achievement. It’s not always necessary to write out the Advantage, because it is usually very similar to the Benefit – however that act of describing the advantage helps identify the benefit in the first place.

But hang on, why are benefits important in a CV? Well, to borrow an expression from sales and marketing, people buy benefits, not features. They buy the relaxation of being by the pool on holiday, not the model of plastic sun lounger they will lie on. Likewise, people hire you because of your past achievements, not because of any lines in your old job description.

So bringing this back to Requirements Management, how does this fit? Read the rest of this entry »


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.

Making durable decisions easy

Making decisions always seemed simple and satisfying, and easy to change to suit circumstances.

But that was back in the days when they were design decisions, and I had developed a number of tools and techniques to help me shake the pieces into place. Things like evaluating requirements, identifying options, noting constraints, and twisting and turning the results until clear winners start to emerge. And of course – number one rule – note it ALL down. You need to know how you got where – and most importantly why, because then, once you plug in the newly changed circumstances, the design could flex and easily produce new results.

But now it all seems to revolve around money – the cost of doing something versus the cost of not doing it. Early attempts to record decisions were far from perfect. Scoping the decision was not a problem – describing what we need to decide and giving weightings to the factors that would help us decide. Nor was it difficult to list out costs, benefits and risks of the different options. The biggest issue turned out to be the inter-relation between the different options – the benefits of one option were to avoid the risks of another, or the risks involved not achieving the benefits. Tedious, repetitive and confusing!

So the solution I am using for now is to assume that the benefits (positive outcomes) and risks (negative outcomes) are all “theoretically possible” across all options, marked on a scale of 0% to 100% probability of maturing. This means the difference between the options is expressed as a combination of negative versus positive probabilities. I have stopped short of allotting a price to the benefit or risk, because these are so often subjective – in the eye of the beholder. Still, seeing the balance of plus and minus percentages should help people do their own calculations from their point of view. After all, many would-be decision-makers work from preconceptions, and massage the statistics to make the formula give the result they want, so no point in putting them through the unnecessary effort, is there?

In some ways commercial decisions are less complex than technology design, because there are fewer dimensions to consider. Money, however, can cause rather emotive reactions in people, and hard cash can boil things down to black and white results that might not have been obvious when you first asked a technological question.

Read the rest of this entry »

Another solution design pattern looking for a base

Its a shame this programme doesn’t have access to a Content Management System, because there are so many aspects of the planning and solution design that are just crying out to be (single source) stored in a structured and related content-base, ready to be pulled out using different views for the various levels of stakeholder.

There are simple elements (such as the list of 8 projects comprising the 47 technical components that will deliver the required scope), where it might make sense to place them into a couple of related tables. Ok, its not so straightforward to create related lists in SharePoint 2003, our current collaboration platform, but at least it’s basic RDBMS style stuff that could be done there give time. However it starts to get far more difficult if you want to try and get the mix of document fragments like multiple paragraphs and bulleted lists to fit into what you know is a useful and logical structure. It will probably become clearer if I describe the type of pattern that I’d like to represent in a content-base.


  • Explain the purpose of this project with a multi-paragraph Description.
  • Give two textual lists of top-level Scope items – those In and those Out
  • Textual list of any Assumptions worthy of mention at this level

All of these are, however, merely an edited summary of what comes in the individual Components delivered as a part of each Project, which leads us on to:

  • Item list of Components this Project comprises

Finally there are a couple of fields that are important considerations for the business case, but are too difficult to break down at a lower level than Project, because they relate to the current state (before we deliver):

  • Paragraph list of Key Differences, outlining what will change most dramatically if we compare before and after
  • Textual list of Benefits that the Project will bring to the service consumers, or to the internal teams that provide the service


As I mentioned, the Project level content fields are just summaries of the Component level fields, so you won’t be surprised to see them repeated:

  • Explain the purpose of the component with a multi-paragraph Description.
  • Give two textual lists of Scope items – those In and those Out
  • Textual list of any Assumptions that need to be aired and perhaps challenged

So far so good? Yes, OK, its a shame that some poor fool has to copy and paste a bit of this between documents, and reconcile differences later, but that’s kind of what happens on change programmes, isn’t it? Well unfortunately yes, but you see there’s more. Because we’re thinking about the way Scope splits and meshes between various Components, and because we want to save this to help with later planning (resource schedules and deliverable deadlines) we also add the following content:

  • Two item lists of Component Dependencies, depending upon and dependant of

I will admit that these are the two senses of the same relationship, but don’t forget this is still a Word document, so we have to do them both manually for now. And because we are locking this valuable information away in the bowels of a word-processed document, then it will merely lead to more copy-paste-reconcile later.

But this is only the start – once the design starts to flow down like a waterfall you start to find all manner of information wants to maintain relationships. These Assumptions may actually have had some influence on what was In or Out of Scope, so that would be a relationship worth tracing. And beyond the realms of this document, into the detailed design, it makes sense to relate the constraints and choices back up to these Assumptions and Scope lists.

Those become valuable notes later when some scope creeps, or any worms turn, later – project change requests are usually more inevitable than exceptional. Yet relying on someone to copy and paste all of this down the design levels is asking for facts to be overlooked. And we all know what are the chances of having both top-level documentation and detailed designs updated properly and in tandem post- change acceptance – a big fat zero.

This is why I say, it seems so lemming-like to load this information into a flat document when it should be drawn out properly across a structured, related content-base, so it flows automatically and efficiently to everyone who needs to know it. Oh well, haven’t got time to sort this out now – our masters have set very tight deadlines for us to reach that jumping cliff. Geronimooooooo!