An important task for any BA is finding out why. Why do we need this project? Why do we need this requirement? Without understanding the why (the rationale), there is a significant risk of building the wrong solution or implementing features in an ineffective way.
Saying no to strategies, projects and requirements, is a quick and fun technique to uncover a stakeholder’s reasoning and increase your understanding of the project and proposed solution.
Different why = different solution
Suppose you are a BA at a school and your stakeholders want to introduce a learning environment on tablets, including an integrated chat feature. Depending on the rationale for this chat feature, the implementation could be very different:
- If your stakeholders propose this integrated chat feature because they want to give students a quickly accessible way to ask teachers questions, you might create a wiki-like solution that integrates course material and comments in a single user interface.
- If, however, they want to add this chat functionality to increase the communication between students, you might consider using a tool students already use heavily in their daily life, like Facebook Messenger.
The same is true at a more strategic level:
- If your stakeholders want a digital learning environment to increase collaboration between students, the project will focus on creating tools, times and places for collaboration and communication. This does not necessarily have to be limited to a digital environment.
- If your stakeholders want a digital learning environment to increase student engagement by enabling them to use their preferred tools, the project will put more emphasis on finding engaging tools and approaches (gamification could be an example).
Say no to reveal the rationale
Asking why five times is the classic technique to reveal unexpressed needs. Putting no in front of a solution or strategy is a fun alternative that quickly triggers insightful conversations.
- What if you would have to build a solution without a chat feature (say no to chat)? You could ask your stakeholders if a solution using SMS would work. They then may say this is not a good solution, because it does not allow group communication. This reveals an unexpressed need, but it also inspires you about alternatives. You could perhaps use WhatsApp, which features group chat.
- At a more strategic level, what if you propose your stakeholders to think about decreasing collaboration between students (say no to collaboration)? They may respond that this would prohibit students to give each other feedback about their work, while peer reviewing and peer teaching is an effective way to improve a student’s own skills. This way, you learn that the project’s focus is not to stimulate any kind of collaboration (like group projects), but rather to stimulate tutoring in particular.
Say no to questioning
Above examples show that saying no to projects and requirements is a simple technique to elicit additional information from your stakeholders. However, make sure your stakeholders understand you are not using it to question their ideas, as some may not appreciate that. You are using it to facilitate the requirements gathering process and improve your understanding of your stakeholders’ reasoning.
The fact that alternative ideas for the project and solution will pop up is a valuable consequence of using the technique, but not the goal.
What will you be saying no to today?
- I got the inspiration for this technique during Ron Tolido’s talk at the IT Works seminar on The Future of IT in the Age of Digital Transformation.
- Photo by Andy Tootell on unsplash.