Anticipating Software Project Requirements

(You can’t always get what you want, unless you ask the right questions)

Avoiding unforeseen showstoppers and “gotchas” in software development projects can be as simple as knowing what to ask your customer upfront. Identifying and addressing these “but what about. . .?” or “and then what. . .?” questions at the outset of the requirement gathering process is essential to safeguarding everyone’s time and money..

Helping a customer think about and answer deeper-dive, project-critical questions they haven’t yet considered will keep your project moving ahead smoothly with fewer speed bumps, delays, and roadblocks. Here are some overall guidelines for getting the most from your customers when gathering project requirements:

1. Prepare high level questions ahead of time: To make the most of your time with your customer, prepare a basic list of questions ahead of time. Using the How/Where/When/Who/What/Why framework, you can gather a great deal of core project information before you turn the conversation over to the client to give you their take on the project, or you can use them to guide the conversation with a customer who may wander off-topic. Some examples might include:

• How Will this feature be used? OR will we measure success?
• Where In the workflow does this process begin? OR Would a user access the feature/tool/solution?
• When Does this feature/tool/solution need to be available? OR do you need our final plan in place?
• Who Is the audience for this solution? OR is the Subject Matter Expert (SME) we will be working with?
• What Needs to happen before we begin the project? OR are the metrics that need to be tracked?
• Why Have we chosen this methodology; are there other ways to accomplish this? OR does the user care about this?

2. Cover all of the basics: Make sure you cover all the core questions before you dive deeper, as they may drive new questions:

• What’s the “big-picture” vision for your project? Have the customer outline their goals and objectives at a high level.
• Who will directly benefit from this solution? Find out if the solution is targeted at in-house staff, customers, sales, partners, third-party vendors — or any combination of these.
• Who are the stakeholders and decision makers for this project? Understand who will be contributing to the process, who will be participating in reviews, and who makes the final call on questions or concerns.
• What infrastructure, products, and services will be associated with or affected by this solution? Learn how the solution will be used to develop or support these deliverables and determine what kind of infrastructure changes will be required to enable legacy systems to work with the new solution.
• What kind of development schedule are you anticipating? Go over milestones and any incremental implementations you should be aware of to keep things realistic and avoid scope and schedule creep.
• Will we need to bring partners, collaborators, or SMEs into the project? Know upfront whether third-party resources will be involved or required — and what they must bring to the table.
• Will any specialized systems or tools be needed? Outline any software, hardware, or other infrastructure that will be required, and get clear on who is expected to source or supply them.
• What are the known risks associated with this project? Understand the risks associated with this project, and the expectations for managing and mitigating them.
• Are there legislative requirements or compliance mandates that this solution must satisfy? Be aware of compliance issues before the Discovery phase begins. You need to plan for, address, and avoid requirements that will become deal-breakers.

3. Start high-level and drill down: Use client requests as a jumping-off point for conversations that will unearth important details about project requirements:

4. How will you measure the success of this project? In addition to understanding upfront goals, having a concrete idea of the specific metrics the project will be measured against can help you better plan and course correct as needed.

5. Utilize Active Listening strategies: Use Active Listening to hear not only the words your customer is saying, but also the complete message they’re conveying:

• Keep your eyes focused on your customer as they speak, ignore any distractions around you (or in your head!)
• Use your body language to demonstrate that you’re listening (nod, smile, etc.)
• Don’t interrupt or ask questions until they are finished speaking.
• When you respond to them, repeat what they’ve said to you (“What I hear you saying is. . .”) to confirm your understanding, and ask question that clarify points on which you’re unclear

6. Listen for cues: As you communicate with the client, watch and listen for subtle cues that reveal more than they may be telling you about:

• Pain points — Small complaints might generally go unnoticed if they are hidden in an email exchange, etc.
• Desires — These could be a customer’s “nice-to-have” features and functionality, rather than their “must-haves.”
• Unstated goals — Keep an eye out and capture what the customer may implicitly expect from the solution
• Assumptions — What does your client take for granted about the project/solution, and how can you uncover that?

7. Account for user roles: Review each function or feature of the solution from the vantage points of different user types (accounting, marketing, administration, field sales, HR, etc.) to get a fuller perspective on how their goals and objectives will be impacted by the solution.

Navigating knowledge gaps during a development project is difficult, and not a good use of anybody’s time. Asking probing and leading questions during the discovery phase of the project can help highlight additional requirements, uncover blind spots, pinpoint budget shortfalls, and provide valuable guidance to stakeholders who may need outside perspective on what will truly be required to bring their vision to life.

This article was first posted to the Pegasus One blog at anticipating-software-project-requirements