By Steven D. Davis
Courtesy of App Developer Magazine
Throughout the software development world—on websites, in books and in lecture materials—one can read discussions about the development of requirements (or their variants, such as use cases and user stories). Almost all of them stress the importance of determining what a stakeholder wants.
As someone who preaches requirements across the country, I can honestly tell you, “What stakeholders want is not important. What matters is what they need.”
At first glance, it might seem logical that these two terms describe the same information. Nothing could be further from the truth. Exacerbating the problem, in the rush to accelerate delivery and trim expense from software projects, companies often minimize the importance of the one person who might recognize the difference—the business analyst.
In some instances, business analysts don’t have the right skill sets to discern between wants and needs—or to capture the appropriate information. In others, tight time frames and/or budgets lead developers to chat directly with stakeholders to gather requirements, eliminating the business analyst role altogether.
The result is unsatisfactory, and predictable. After the functionality doesn’t meet expectations, it fuels the belief of many development teams that stakeholders don’t know what they want until they see what they don’t want, and the cycle begins again. This logic is flawed, and it perpetuates other flawed assumptions, leading teams to make inaccurate decisions that drive up errors, costs and delivery time frames.
Wants Versus Needs
Just because code functionality doesn’t meet a stakeholder’s requirements doesn’t mean the stakeholder did a poor job of explaining them. In my experience, the problem more likely lies with the process by which the requirement was gathered and/or communicated.
Consider the following examples:
Development Project Scenario #1: Generating a Sales Report
A stakeholder says he wants a report of quarterly sales figures, either delivered to his sales assistant or available to him as a download from his company’s internal portal. The business analyst, who has the mentality of an order taker, writes this bit of information down and communicates it to the developer, who shares it with the coders.
The first iteration returns a very simple report that the sales assistant can download. As anticipated, the salesperson has additional requests for the report, including specific formatting with certain fonts and logos and the incorporation of additional details.
After numerous iterations, the report is fine-tuned to the salesperson’s liking. In the meantime, three other salespeople have asked for additional tweaks to the report so that they can use it, increasing the scope of the project and causing budgetary overruns. After six months of effort and significant additional budget, the report is available on the portal in a variety of formats for various sales personnel and their staffs.
Scenario #2: Providing Access to Sales Figures
The business analyst, who understands the difference between wants and needs, asks the sales person why he wants the report. The sales person responds, “because I have always gotten it.”
The business analyst then asks him what specifically he needs in the report, and why he needs that information. The salesperson responds, “I need quarterly figures for the sales meeting so I can validate the next quarter’s budget.”
The business analyst probes further, and asks, “Do you need a report specifically, or do you just need access to the sales figures?” The salesperson answers, “We really just need the figures—my sales assistant currently appends our quarterly review package with the printed report. He could drop the figures into my report and format the information to match everything else if he had access to the download.”
By asking those additional questions and getting to the true “what” of the matter, the business analyst realizes that the salesperson doesn’t really need a report. A better (and faster; cheaper) solution for the salesperson would be secure, portal-based access to—and download privileges for—the company’s sales database.
The analyst communicates that information to the developer, and the deliverable becomes a download interface. When the salespeople and his associates ask for additional report variables, the coders are tasked with adding more field selection criteria, not with writing code to generate additional reports.
The project hits the trifecta of development—it is completed accurately, with the least amount of time and expense invested. On the stakeholder end, the salespeople and their assistants are all happy.
Final Thoughts
This is a very simple example, of course, but the same principle holds true no matter how complex a project becomes. If an appropriately skilled person doesn’t do a good job of helping the stakeholders separate wants from needs and that information isn’t effectively communicated to the coders, there is a strong chance the project may start down the wrong road completely.
At the end of the day, it is the job of the developing entity and its team—not the stakeholder—to figure out all of a project’s true needs and translate them into accurate, efficient requirements. I firmly believe that failing to distinguish between wants and needs—and then projecting blame elsewhere when software doesn’t serve its intended purpose—is behind a large percentage of software project cost overruns and failures.
To succeed in a highly competitive, fast-paced software market, enterprises can no longer afford these mistakes. The requirements gathering phase cannot be short-circuited, and the importance of having a properly trained business analyst cannot be downplayed. Only in such an environment can any project proceed with a minimum of errors and restarts.