How to Build Consensus on Software Requirements
Three colleagues walk into a bar. Sam from sales, Megan from customer service, and Nick, senior software developer. The conversation goes like this: “What do you think of this project to consolidate sales, customer, and product data in one web application? Sam: “Great idea if sales is driving. The app has to be built around the data we need to sell more products and build our brand.” Megan: “I’m on board if customer service is calling the shots. You can’t sell unless you know what customers are calling about.” Nick: “We can’t access half the data you need as it is, because it’s siloed in incompatible applications. Plus, we don’t have the resources to do anything else.”
As the product owner, what are your chances of aligning these stakeholders around a new platform, application, or API that could really grow the business? Consensus around a shared vision and key requirements is often the hardest part of an application development project.
Requirements gathering is all about the stakeholders
Before you can gather requirements, you need the right stakeholders in the room. Your cross-functional team should represent stakeholders who will use, interact, or be affected by the software—and people whose support is vital. As a rule of thumb, six to eight stakeholders will have the breadth of knowledge and user insight to define the software requirements for any size of company. Your project team’s first order of business is to create a vision document that addresses these four questions:
- What problem do we need to solve?
- Why is it important?
- Who is it going to affect?
- How will it make life better for an end user?
Have stakeholders write the answers in an elevator speech format. Here’s an example:
What problem must the application solve?
“Our sales team is currently using a series of ways to sell. As a large company, we would like to standardize that practice to provide a consistent brand experience for any client, as well as to enable our sales team to employ best practices from around our sales territories.”
Why is this software application important?
“It is necessary to standardize this practice now since we are consolidating our practices and looking to build brand trust. By creating a consistent sales experience, the company can ensure that if an employee leaves or changes roles, anyone stepping into the vacancy can pick up with the same high quality service experience, avoiding customer loss or unnecessary training on different systems between sales areas.”
Who will the new application affect?
“This change will impact end clients, salespeople, and corporate. End clients will get a consistent experience that aligns with brand expectations; salespeople will have a straightforward way to uphold those practices that will allow lateral movement within the company and reduce training costs; corporate will see reduced training costs, as well as an increase in client retention.”
How will the app make life better for an end user?
In the end, the client will know what to expect from interacting with our brand. A change of personnel will not negatively impact their experience and the tools that the client and sales team have access to will facilitate a continued relationship that is consistent during their relationship with our brand.”
Do not jump the “why” for the “how” in gathering software requirements
As the product owner, you will spend a lot of time referring back to these questions, so getting it right is critical. There are a million tiny decisions that you and your team will make that can lead to the right outcomes or something that looks like what was described, but doesn’t get to the heart of a real, usable solution. Too many development projects jump from the idea stage into development, which accounts for the high rate of failure. Lack of planning, unrealistic expectations, lack of user involvement, incomplete requirements, or changing requirements and specifications are among the top 10 reasons cited for why software projects don’t succeed.
The vital importance of each stakeholder’s vision
It is your goal is to find common threads to distill the priorities—what is critical, what is great, and what goals would be better served in later iterations of the project or spun off to a second or third project. A Forbes article on this topic refers to this as finding the “Goldilocks Zone”, in which conflict, competition and consensus are perfectly balanced.
Each stakeholder will have a different understanding of the requirements and constraints that are necessary to solve the problem and reduce the risks. Getting each stakeholder’s individual vision is so important that you should consider a 15-minute break if stakeholders show up unprepared. There are several reasons for this.
- Some stakeholders may not feel comfortable articulating answers to these questions “on the fly,” which risks the group being unaware of the needs for those voices and leading to missed requirements down the line.
- Some stakeholders may not share the same vision–at that point, it is prudent to understand if there is a unified vision or overlapping requirements, or if a second project is warranted.
- It is easy to defer to the loudest voice in the room, which can be due to rank within an organization or simply personality. Asking a stakeholder to commit their first pass ideas in writing allows you to ensure that all voices are heard. If someone has been invited, it is because they have a valuable opinion, and should have a chance to be recognized.
- This process creates “buy in” before the first meeting has happened–everyone has an opinion on a pain point. Getting a chance to voice what it is and why it is important will make for a more willing group of participants.
Common Stakeholder Personalities
We’ve collaborated with many product teams who have collaborated on truly innovative and profitable apps. We have also seen stakeholders who can’t agree on requirements and derail the project. Curiously, the latter seem to share the same personality traits.
The How Person
This person loves to describe the color and placement of the buttons before having identified why you have a button at all. It is very appealing to start designing before the “why” has been answered but leaves out critical features and can miss the big picture.
The Gunslinger
This stakeholder often feels like there is a “magic bullet.” Although they may be correct, beware of a person who oversimplifies to make a solution sound “simple.” it is important to go through the process of understanding the nuances of the needs before you stack hands on the “of course” answer. Often these types of solutions solve the problem for one type of user, but not all of those in the room.
The Line Jumper
This stakeholder wants to get the prototype out before going through a discovery or investigation process. Inevitably, it leads to unexpected costs as new requirements shake out during development. If that is the kind of team you have, that can be OK–a Proof of Concept is quite helpful–BUT if you are looking for a controlled budget, you will want to allow for a bit more discussion and design before committing to a final result.
The Expansionist
The expansionist will find many ancillary good ideas and pull them in as needs for the project. It’s critical to keep their enthusiasm, but it is also important to help them table ideas that are outside of the vision that the team has agreed on. If there is not a direct line to how an idea fits the vision, the idea should be sent to the parking lot for a later discussion.
The Hijacker
Hijackers are only mildly interested in the project being developed but have a real passion for a parallel project that may get a boost from this work. Unfortunately, they will often attempt to direct development in a way that will be beneficial to their passion project but may not be the best strategy for the project at hand. They may also short resources to the current project in favor of the other, or simply attempt to turn this application into the one they really want to build.
The Resistant Participant
The resistant participant doesn’t understand the project, and most importantly, doesn’t want to. This person doesn’t understand the basic need for the project at all, and if they have enough influence in the decision making or engineering required to complete the project, can often kill it either through fiat or simply sabotaging the project through inaction. There will always be stakeholders with their own agendas, but they are in the best position to define requirements for the function they represent. If they can agree on a vision, use it as a North Star in defining features and functionality.
Don’t try to define all the requirements up front
A better approach is to define the vision, then work toward a Minimum Viable Product with enough features to validate a concept early in the product development cycle. We refer to it as a Minimum Valuable Product, because the product must have enough value at that point to be viable. This is the agile approach to software development—building an application gradually to allow for changes at each phase of the project. Agile development is a team exercise, with stakeholders involved at every stage of the process. The result is shared ownership, flexibility in making changes, and better control over time and costs.
Like what you’ve read? Subscribe to our blog on The Digital Frontlines.