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 »

Agile decision-making

For many of us, making decisions is an important part of our job.

Sometimes you can make the decisions in isolation, but on other occasions it seems important to consider the views and opinions of other valued colleagues. Often the nature of the circumstances are so complex that it can be difficult to gather all the relevant information ready to make the right decision. And waiting for these people or this information can delay the point when you are in a position to make the actual decision.

But, after all, it is important to make the right decision…

…or is it?

Not according to Percy Barnevik’s “7-3 formula”! The man who ran Swiss engineering giant ABB for a decade insists that you can still be successful if you make nearly half as many wrong decisions as you make right decisions!

Read the rest of this entry »

Do alpha releases deliver value? Maybe more than you think!

When you’re planning a project or designing products, you know that you don’t need to produce any early mockups because you, and possibly many of the team, can see the vision already. You don’t need to see anything tangible before it’s due because you believe in what it is going to look like, way before you can hold it in your hands. Seeing as you’ve got so much ground to cover before then, its not worth delivering a symbolic item so early.

However, not everyone shares this same vision so clearly, and there can be so many advantages to producing and making available early beta and even alpha versions because tangible articles, even if they’re a long way from the final embodiment of perfection, are sometimes the best way to avoid very common obstacles.

Here are four that spring to mind immediately… 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.

Complex designs come unstuck on the simple things

I used to think that the most difficult part of creating a complex infrastructure design was fretting over the important technical choices that would affect the configuration of deliverables. Once those were sorted then I could get on with listing the order in which elements needed to be implemented, and producing a list of all the technological resources needed to implement them.

Over time I’ve come to realise that this is actually the wrong way round. Often design choices are the easiest stage, partly because many infrastructure components work best when following vendors’ best-practice configuration guidelines (or even just set up as they come out of the box). Also, because most configuration is soft, its easy to make such choices at the last minute and still deliver it right and on time. The more important elements to get right up front, however, are those that require the time and the money, also known as dependencies and resources.

Read the rest of this entry »

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 »

Potholes in your CMDB roadmap

Implementing a Configuration Management DataBase (CMDB) is not a single action, but a gradual process that may take months or years to establish. Even after that, it is subject to change and improve like any area of your IT operations, especially as your business changes around you.

In many organisations there can be similar pitfalls when tying to create an effective CMDB, and the best way to avoid them is to be aware of them, and plan around them. Here are my top three:

1) Ownership and dispersed authority – the information that must be captured and held within a CMDB typically extends into the domains of many teams. Although one of these teams has overall responsibility for the “whole”, there are people in other teams who truly hold the knowledge and are aware when fundamentals change – it can be difficult to pin the responsibility on those other people for keeping their part of the database up to date.

2) Inequality of investment and return – by its nature, a CMDB is unfair to its various clients. The people who get the most out of the system do not have to put much effort in. Yet the people who have to spend most time putting the information in are rarely interested in getting anything out of it.

3) The value is in relationships, not data – many people see “automatic data feeds” as the nirvana for maintaining a good CMDB. Yes, it’s true that you can get rafts of detailed configuration information automatically imported in the blink of an LED, but that is only half the story. What SMS, Insight Manager and CiscoWorks can’t give you on a drip-feed is the richer knowledge about how systems interconnect and inter-depend. That’s stuff that IT folks typically carry around in their heads (or store on complex and un-referenced Visio diagrams that are never collated into a single repository). These system relationships are what let you analyse your ability to resist points of failure, to predict the likely impact of planned change, and to ensure that you really understand exactly how your customers make money using the iron you manage. If you manage Change, Configuration and Release, you are at the best point to keep track of such interdependencies over time, but don’t expect the machines to do all the hard work for you just yet.