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?

Delivery by Crisis – taking pragmatism to extremes

Risk management conditions us to feel it’s vital to be cautious. We must plan properly, test thoroughly, document clearly and deliver with control. And these are principles that have stood innumerous projects in good stead.

But could there be another way?

Is there a devil’s advocate that appears in the form of a service crippling crisis?

When the lights go out a dust-covered candle stub shines as a bright beacon…

Because when nothing is working, you have nothing to loose!

I have witnessed occasions when technical solutions have been crash-delivered before they were properly ready in order to fix operational issues, when it has been worth cutting corners and dealing afterwards with the minimal amount of clean-up required. These urgencies have actually been to to mutual benefit – saving the project’s time and the operational team’s bacon 🙂

Will rightsourcing allow you to balance strategic service with tactical delivery?

Towards the end of a project to outsource a large section of a company’s infrastructure I learned that a previous IT Director was very proud of her decision a few years beforehand to insource much of what we were putting back out. Looking into the reasons for both of these transitions you could conclude that there is a right time to have stable operations run at a low fixed cost, and there is a right time to increase the cost, and the risk of cost escalation, in order to allow rapid change by removing barriers and pooling knowledge tightly within a highly skilled team.

Well if both are valid at times, could they not both be valid at the same time? Is there not a case for “rightsourcing”?

A simple road to success

Have you ever heard of something, and thought it was a good idea?

Great! The good news is that you’re already on your way to achieving it. The bad news is that 9 out of 10 times simply agreeing that it’s a good idea is not enough.

Ok, so why not make the clear decision that you are going to aim for this goal? Much better – but still, you’ll fail three times out of four.

Do you want to know what can bring you success a full 19 times out of 20?

Just increase your commitment by including another person and a review…

Phones and cameras with a really powerful Flash

I apologise up front – despite trying to keep technical matters away from this blog, I felt this article was worth posting because it explains so clearly and abundantly a technology that you almost certainly carry in your pocket on a regular basis.

Most of us are familiar with cut-open images showing the spinning platters in hard disks that store our data at home and in our data centres. Every time we put on a film in our living room, we feel at home with the notion of little optical knobbles that reflect blinding laser light and are often used to back up our personal data.

But, when you snap your friends at the party with your digital camera, or listen to music on your phone, how much do you actually understand the vast differences in the way that those tiny plastic flash memory cards work, and how much they will begin to encroach on other types of storage?

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!

Did we forget to put our #1 deliverables in the plan?

Planning a project is a opportunity to look forward to what we expect to deliver, working out the list of activities that move us from where we are to where we want to be, and marking the major stages of achievement along the way.

Think for a moment about a very simple model of what we are working towards. In order to implement process A, we need delivery framework B to connect system C to information source D, then we provide training E to customers F. Doesn’t that sum it up in a nutshell?

But hang on, how come we are even doing this in the first place? What was it that justified our very existence as a project? Well, chances are that someone pitched a business case to some executive sponsors and showed how a short term investment would bring long term benefits, either by increasing revenues, or as so often with major operations by reducing costs.

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…

Making your mind up is only the start…

I am finding that decisions form an increasingly important part of my role, so I was intrigued by this ComputerWorld article about reasons for decisions failing to deliver – Why decisions don’t stick

• did somebody make a decision?
• it was just a discussion!
• it doesn’t apply to me!
• it didn’t make any sense!

So did it seem that making the decision was difficult? The lesson here from CW is that communicating the decision can be even harder, but is certainly vital to your success. You need to make sure that you tell people you made it, that it sticks, that it needs to be adhered to, and most importantly why, so that people can internalise it themselves.

If you don’t bother sharing it, definitively, assignably and clearly, then you may as well be still scratching your head going “ummm, ahhh …”

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.