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 »


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 🙂

Read the rest of this entry »

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…
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 »

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. 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 »

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 …”