Your Guide to Getting the Most Out of Business Requirements
Understanding your project stakeholders goes a long way when it comes to expectations and satisfaction. The main goal of the interview is to understand the business needs which will define the approach and specifications. If the process is conducted properly your team’s takeaway will be much more colorful.
Many years ago I worked on a government website for a large art museum. As we began to define stakeholder interviews the client felt strongly that we should speak to all departments. Yes ALL. At the time I don’t think anyone on our team saw the value of speaking to departments not directly associated with the website, such as the kitchen staff or maintenance crew. But as we interviewed them it became clear that their input was valuable -- not necessarily as input to features or flows but instead it was their perspective of the museum as an institution. As we went from department to department the museum’s brand became very clear to us. It was this perspective that fed into the site experience. It taught our team that every employee can contribute to their company’s brand. This was eye-opening.
Getting to the facts
The core interviewees should be your client, IT, and whomever internally will be signing off on the end product. The list will usually expand as you begin to see other critical features. For example, capturing sales online will require an interview with the sales director. All interviews should be prepared in advance and reviewed by your client. And by all means, avoid interviews via email. Questions should be grouped into categories:
- Knowing brand and audience will inform site design
- Understanding the competition informs the priority of features
- Defining processes and workflows will inform features and user paths
- Insight into clients and users will inform the user experience and design aesthetic
- Awareness of the IT structure and 3rd party integrationsinforms the technical architecture
In executing an IT interview, it was once uncovered that the IT team would now become the development team in addition to their daily tasks. Odd decision, but something we needed to prepare for. Knowing our audience allowed us to tailor how we authored transition materials. This had a great impact on the level of comments we inserted into code, and the level of detail we included in documentation. Without personal interviews this would never of been uncovered. Leave time during your agenda to explore unknown territory. Let the interview happen organically and use the interview guide as what it is, a guide, not a limitation.
Understanding the political game
The process of interviewing is about getting the info you need to create a great product. But its also about project buy-in and the political game. Through the process you’ll hear many ‘wants’. Understanding who’s ‘want’ has priority is based on their influence in the company and how close they are to their customers. But all ‘wants’ need to be heard. Knowing they’ve been heard now allows them to support this project and become an internal cheerleader for the project, and your client.
Turning information overload into brilliance
You’re finished with all the interviews, now what? Begin to analyze the responses (hopefully you’ve recorded them) and try to find recurring themes and feature specific comments. Summarize what you’ve heard and present this back to the client. These interviews will be a valuable tool throughout the lifecycle of the project. Client needs have been heard, first hand information has been noted, and relationships have been strengthened. You are now an expert on their brand and on your way towards developing a valuable tool for your client.