What is the business benefit?

As an analyst, it’s not enough to know what your customer wants. It is essential to unearth what the customer needs and how the customer’s business will benefit by fulfilling that need.

Customers are often the last to understand what their business truly needs, even when they have a clear idea of what their software requirements are. Over the years I have often wondered why this is so and I think I have some answers.

Teaching an introductory course on analysis to a project team (including some of the project’s customers), I asked: “What is a requirement?” and the main customer immediately replied: “Anything I want.” Her desire for everyone to be reminded that “the customer is always right” was blinding her to other things. I think the very word “requirements” is a large part of the problem. It focuses everyone on what the customer wants, almost making it sacrosanct. Requirements traceability (while an important and often under-emphasised discipline) starts with the requirement and obscures anything that came before that. But a requirement is not a “first cause”, even though can be taken as such by requirements analysts, developers and testers alike. A requirement should not spring up out of the imagination of the customer; it has (or should have) its roots in something else. I feel “requirement” is an outdated word that should be relegated to the past and I applaud the Agile approach for doing away with it – although I am not thrilled with “user story” either (more on that in a future post).

Even those customers (and analysts) who try to see behind the requirement think too often of “problems”. But this is an exclusively negative mind-set. What about opportunities? They need to be addressed and expressed just as much as problems. New markets, new technologies, changes in the social, economic and political situation can indeed present a business with problems, but just as often they provide opportunities.

Time to Market
This buzz phrase is starting to annoy me. While I acknowledge the importance of the concept behind it, I feel it can encourage the kind of short-term, quick-win tactical thinking that A) has allowed the world’s economic “experts” to ruin the world’s economy, and B) encourages companies to get software into production rapidly, but not necessarily robustly. Most customers are really not very good at expressing their requirements, for which I am grateful, since it keeps me in work, and when you add the pressure of the Emperor sending Darth Vader to say that he is most displeased with their apparent lack of progress, you end up with hastily redacted requirements that largely serve to please Palpatine by getting Death Star II to market quickly, regardless of how likely it is to fulfil his strategic plans for galactic domination.

Pressure to succeed often makes customers present technical solutions under the guise of requirements. Business need: defeat the rebellion forever. Stated requirement: an armored space station with enough power to destroy an entire planet.

If you are not familiar with the Star Wars universe, please contact me for an analogy-free version of that paragraph. Or just watch the movies.

Too many so-called analysts simply write down what the customer wants, drop it into a neat requirements specification, toss it over the fence at the developers and testers and clap themselves on the back for a job well done. In the words of Luke Skywalker:


And if you have no idea what I am referring to, then you are not the kind of person I want reading this blog. Be on your way. Go on. Click the “Home” button now.

Analysts should not behave like stenographers. They should challenge (although some customers hate that) and guide. But customers should not just be guided by analysts, they should be educated. Every time I work with a customer, they should need my skills a little bit less, because every time I should be passing on some of my skills. If a customer is not better at examining and expressing the needs of the business after a period of working with me, then I have failed in my duty to that customer. Either that or they are just unwilling to learn, which is sometimes the case.

These are not the only answers, of course, and I am sure I shall explore more in future posts. I think the key to a solution is, in part, for analysts themselves to drive a change in the way customers think: firstly by ceasing to document “requirements” and thinking about “problems” but instead expressing “business needs”, and secondly by constantly asking: “What is the business benefit?”

  • Challenge
  • Understand the business benefit
  • Express the business need

Kind regards,

Declan Chellar

Related posts:

2 comments to What is the business benefit?

  • Ryan White

    I love this post. It makes me want to get a cyclic tattoo which says “Challenge & Guide”.

    Yes; I hate that term too for the same reason(s) you outlined. We should employ a new word… ‘Transmutations’ or something else borrowed from alchemy =)

    Now, I would argue that it’s perhaps not wrong to look behind the business requirements to parse out the ‘problem(s)’, depending on the situation.

    If a red-light pings up on the dashboard of your millennium falcon telling you there’s a problem with the fuel-pump; it’s a good indication that you should go and fix the fuel pump – though I take the point that considering the warning as an opportunity, may encourage you to take a more holistic view – replace the pump with something more efficient/reliable rather than just repairing a sensor or something…

    Would it be fair to say if the scope suggested something ‘strategic’ was viable, then you should think in the opportunity space – but if you’re remit is tactical, then problem remediation is ok?

    Green-field project = opportunity mindset
    BAU defect fix = problem-solving (-addressing) mindset
    Annual Service = New fuel pump
    Red-light-warning during death star incursion = duct tape over the warning-light =D

    Just spitballin’… now let’s get drunk and get those tats? After I’ve copy+pasted my customers’ wants in to my requirements document that is! Gotta keep that time-to-market rollout schedule down!

  • Declan Chellar

    Good thoughts, Ryan.

    My issue with problems is really that many analysts think of analysis as the “problem domain” and it is so much more than that.

    If the remit is tactical, the customer might not even be aware they have a specific problem because they are unaware of opportunities that have arisen since their process was first defined. In that sense, the customer has not identified a problem, but the analyst might identify an opportunity to make things better, which then gets expressed as a business need.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>