How To Identify Client Needs vs. Wants
When getting into a project, it is important to proceed with thought and purpose and avoid the temptation to jump directly to tactics. Taking a methodical approach ensures that you are solving the right problems and have a more holistic view of the problem at hand.
By Dan Thompson, Senior Business Analyst at The Triple-I Corporation
How can you tell what the client actually needs as opposed to what they say they really want?
Since we typically build websites and mobile apps, this article will be geared toward those types of projects, but the same flow can be used anytime you need an easy framework for organizing wants and needs.
Generally, options that benefit revenue or go toward attainment of strategic objectives are ‘needs’ and those that don’t are ‘wants’.
We can think of this as a simple four-step process:
- Define the Ecosystem
- Define the Objectives
- Gather the Requirements
- Prioritize the Requirements
When getting into a project, it is important to proceed with thought and purpose and avoid the temptation to jump directly to tactics. Taking a methodical approach ensures that you are solving the right problems and have a more holistic view of the problem at hand.
Define the Ecosystem
Most good business people will already know this, but it is still a valuable step in order to familiarize the business analyst with all external and internal factors that influence a business. Below is a list of factors with example questions a business might ask themselves during this part of the exercise.
- Political outlook - Are there regulations or laws that could impact business?
- Economic outlook - Do interest rates or consumer confidence impact business?
- Market analysis - How will market size, demand, and distribution chain impact business?
- Competitive analysis - How many competitors do you have? How do you compare?
- Existing website performance - Are visitors pleased with the existing website?
- Budgetary constraints - Do you know what can be spent on a solution?
- Organizational culture and structure - How will business be impacted by values/vision, levels of hierarchy, centralized decision-making vs. more autonomous management structure?
- Internal processes - What processes will be impacted or taken into account?
- Staff strengths and weaknesses - Do the right people exist to do the work needed?
- Technology - What innovations will help or hurt your business?
Define the Objectives
What are the specific long-term objectives for this project? These objectives are generally given by those who are responsible for the success of the project. Most will roll up to a specific opportunity defined in the analysis of the business ecosystem. The objectives must be prioritized based on a couple factors. How quickly does the objective need to be met and how important is the objective to the business? While each project can be different and have unique objectives, the following are some of the common business objectives you may encounter:
- Generate leads
- Develop new revenue streams
- Demonstrate thought leadership
- Enter new markets
- Enable easier content management
- Expand sales territories
Gather the Requirements
There are many methods for gathering requirements. Generally, we employ any or all of the following when documenting requirements for a project:
- Stakeholder Interviews
- Brainstorming
- Focus Groups
- Questionnaires
- Job Shadowing
- Process Modelling
- RFPs
Prioritize the Requirements
This is one of the most difficult and important steps of the process. Throughout the gathering phase, the business analyst will encounter many desires from many different stakeholders. Some of these requests are not realistic, or they are more expensive than the business benefit. Because of this, it is important that each requirement should roll up to an objective defined earlier. A common method is to start by prioritizing requirements according to the priority of their parent objectives. We generally finish by doing a “MoSCow” exercise with all the requirements.
The letters in MoSCoW stand for:
- M - MUST have this.
- S - SHOULD have this if at all possible.
- C - COULD have this if resources are available (time and money).
- W - WON'T have the time. I’ve also heard WISHLIST used here.
Each requirement should get one of the four letter designations. This exercise is completed in collaboration with the initial project leaders who set the objectives. Doing so allows them to clearly see which requirements will advance their objectives and which ones won’t. It is also a good idea to have some rough estimates ready for discussion since in many cases, the cost-to-value ratio is a determining factor in choosing features.
Closing
If you take a methodical approach to gathering and prioritizing requirements for a project, you can usually show objective reasons why one requirement is needed more than another. This can reduce the political feather-ruffling that comes from not seeing a particular request on the roadmap. And remember, requirements that benefit revenue or go toward attainment of strategic objectives are ‘needs’ and those that don’t are ‘wants’.