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? The requirement is the Feature. Generally we have defined it as a requirement because we have identified it as one of the detailed mechanisms we can add to the overall process, in order to ensure we gain the advantage that delivers us the benefit. This is great, because when we come to compare the deliverables against the design requirements we know that if we tick the box to say “yes” that feature is present, we then know we will achieve the benefit without having to look.
So why should we care about benefits when defining requirements. What’s the advantage of justifying why the requirement is there? Well, let’s take the worst case scenario during testing when you fail to get a tickbox against that requirement – oops! What do you do now? Do you have to go back and rework your deliverables until you fix them by making sure the specified feature is present? Well, not necessarily!
Remember that features such as requirements are only there to deliver benefits, and if the benefit has already been successfully delivered via other features that are there, maybe you don’t really need that missing feature after all.
If you know which benefits depend upon a requirement, then its easy to work out whether fixing that requirement is worth the effort. If it can’t improve the situation, because the benefit is already fully present, then it may have seemed like a handy feature at design time, but it’s not worth going through the effort of fixing up because it will not make any difference!