Want vs Need in Business Requirements Analysis. According to the International Institute of Business Analysis, a business requirement is “a condition or capability needed by a stakeholder to solve a problem or achieve an objective […].” The BABOK manual makes a fine distinction in this case. As opposed to mere want or desire, the concept of need defines a certain compelling feature that is essential, or at least very important. At the same time, desire or want are a milder manner of asking for something that is good to have but not mandatory. For example, Maslow’s pyramid defines food as an essential requirement for life, whereas an expensive car would be somewhere at the top of the pyramid. The BABOK definition goes on to discuss that the prerequisite covered by a need addresses an existing problem or helps to attain an objective. Consequently, it must mean that a requirement is described by two circumstances:
- It is a basic business need.
- It solves an important ‘problem’ or helps attain a business goal.
Any process that wishes to accurately map business requirements must remain faithful to these principles. Anything that is not an actual need does not provide a solution to a real problem nor does it deliver on the business objectives.
The most skilful business analysts learn not to implicitly take for granted what is presented as needs and requirements by business stakeholders. Instead, they know how to carefully identify the real needs of a business and provide integral solutions as deliverables. The requirements—as they are presented by the customers during the first phase—are only the first piece of the puzzle. Gently probing around those statements and finding out more about the structure and challenges of a company will most often result in new discoveries. Perhaps the most important part of mapping out business requirements and distinguishing between what is wanted and what is needed is to avoid making assumptions.
Approaching each case and refusing to make assumptions based on experience is one of the most challenging tasks. All professionals, especially the experienced ones, bring a baggage of years of experience that influence their approach. Sometimes the phenomenon of bringing preconceptions to the table is extremely useful since they function like shortcuts to an optimal solution, but other times it can lead to disaster and wrong deliverables. Experience is a valuable feature that eases the identification of solutions, but sometimes the right solutions are assumed to apply to the wrong case.
In requirement analysis, it is important to avoid taking the statements of stakeholders as the absolute truth. Perhaps they lack previous experience with a certain situation, and they can be offered a better solution. The analysis process aims to discover the best solution for a given situation regardless of whether it coincides with the solution stakeholders believe they need.
Understanding Want and Need
The key to successfully obtaining and analyzing essential business requirements is a good understanding of the stakeholder’s position. One of the common starting positions that all experienced project managers have encountered is a firm position: “I know what I want,” stakeholders say. Either consciously or unconsciously, they decided that they were able to identify their own needs and the appropriate solutions. This is absolutely normal because all individuals want to be in control of their choices. And yet an excellent business analyst will be able to extract true business necessities and present better solutions as benefits.
I will next share an interesting situation from my own experience to demonstrate the point.
I was supposed to meet a customer during a kick-off meeting. My role was to work with the customer and elicit business requirements. Prior to the meeting, the project manager had handed me a project brief describing the situation. During the meeting, the customer repeated multiple times that they wanted a Customer Relationship Management (CRM) software. “We want a CRM,” they said, and they were adamant about it. Naturally, my takeaway was that the customer would like to implement a CRM.
At the end of the meeting, I realized I was faced with the “I know what I want” situation. Although the need might not have been real, the stakeholders had already selected the perfect solution to their supposed need. My experience was telling me that there may be issues that were not visible at first glance. Taking the statements at face value was hiding a trap that I was well aware of. Even though implementing a CRM is a perfectly normal demand, I knew that I had met my old enemy, the “I know what I want” position. Consequently, I became sceptical.
“I Know What I Want”
It is a valuable lesson, usually learned the hard way, not to assume that the stated requirements are indeed needs. In the same situation, I advise the reader to go above and beyond, investigate, probe for information, gather hints from all sources available, and create a synthesis that will reveal the real needs. These needs may be hidden for various reasons:
- Whereas the problems are known, they are not confronted. The business may be aware, superficially or deeply, that the problem exists; however, the stakeholders are not willing to face it.
- There is a philosophy that states one should discuss solutions rather than problems. Hence some organizations will talk about what they think the solution is but will not describe the problem. As an example, a person may say, “I need a car,” not “I live far from work, and commuting by train takes three hours daily.” The first statement is not the real problem; the second one is. In this case, the best solution may be a motorcycle, a bike, or a new home closer to work. You will never know what the correct solution is unless you first find the problem.
What Is a ‘Want’?
It is upfront obvious that ‘want’ does not necessarily address a business bottleneck or goals. But perhaps the key to describing what ‘want’ is comes from sales. The SPIN Selling framework provides a separation of want and need and a corresponding separation of product feature, advantage, and benefit.
Something that is wanted or desirable is appealing to the user on a superficial level but does not greatly improve the quality of his life or the revenues of his business. Customers may ask for what they want, but project managers should be aware that offering advantages (answers to ‘want’) rather than benefits (answers to ‘need’) may put the deal in danger. True problems have consequences. Always explore those consequences.
Why would stakeholders hide their needs and discuss what they want instead? As pointed out earlier on, perhaps they avoid open discussion about problems. However, in most cases, this happens because the stakeholders are storytellers. They communicate to us a narrative that they may have well invented to satisfy themselves. This narrative, when placed in the future, will almost always be about what they wish and not what they need.
What Is a ‘Need’?
Needs are completely different from wants. Firstly, they are much more difficult to identify for both the project manager and the customer. People almost always know what they want, but they tend to not realize their own needs. It is a classic case of not seeing the forest for the trees.
Project management is much like selling. Sometimes it directly involves upselling existing customers. Both processes should start with a careful investigation of the background. When problems are detected, they should be insisted upon, a procedure called ‘problem development’. This involves following the string of consequences a problem has—all the way to the end. Fully realizing the consequences of a problem is the same as evaluating how large that problem is. Only when a problem is fully developed can one address it. Demonstrating capabilities necessary to solve the problem opens the way to offering the features of your product or service as benefits meant to cover all the unwanted consequences you just explored.
Always Question the ‘Want’
Capable business analysts will challenge the “I know what I want” position when they encounter it. This is because business value is not necessarily obtained when the customer obtains what he wants. On the contrary, the delivery of a ‘want’ may accentuate a pain point. BABOK recommends that we ‘ensure that all requirements support the delivery of value to the business, fulfil its goals and objectives, and meet a stakeholder need.’ Otherwise stated, the deliverable must respond to a real requirement and add business value. The question to ask when faced with a ‘want’ is “What is the business justification behind it?”’
But back to my story with a customer wanting a CRM. I simply asked. “Why a CRM?” only to be quickly given valuable information that uncovered the real business pain points, such as:
- The current processes rely heavily on time-consuming manual tasks.
- The current system does not meet the needs of a mobile workforce, even though the sales team is not on site most of the time. Furthermore, they can only log in from inside the company building and need a desktop to do so.
Even though CRM software had the functionalities to support the business, it was not directly addressing their needs. My analysis revealed that what my client was referring to as ‘CRM software’ is a set of functionalities and features that they already currently have. However, they were not utilized optimally. Acquiring a new fancy software was not going to remediate their pain. Their needs were actually simpler:
- Current processes re-engineering: The current processes were in need of a revamp. Over the years, the business practices had changed, but the processes did not follow to accommodate the ongoing changing nature of the business.
- Upgrade of existing software: The business did not need to add new functionalities or replace existing ones. However, there were changes in the nature of the workforce, from a desktop salesforce to a mobile one, where the salesperson visits clients and makes cold calls instead. Current applications required an upgrade to portable versions. Portability was the real need for accessing functions from mobile devices and home. The current software was portable and could be upgraded to versions that can run from mobile devices and remotely.
- Training: Current functionalities were underutilised because end users had a limited understanding of the capabilities.
Retracing the unknown to arrive at acknowledged facts, issues, conditions, and legacy, combined with the subsequent analysis uncovering requirements, is a process rather than an end in itself. This is a valuable lesson to remember.