When Business Analysts take their analysis and recommendations to stakeholders, we often use workshops. There is a trap in the workshop. You can only fit so much communica
3. Our intrepid Business Analysts has invited five project stakeholders along for a requirements verification workshop. She wants to get endorsement on the next 7 requirements the team are working on.
4. Let’s take a look at how complex this discussion could get.
5. R1 Our heroine announces Requirement 1 and reads it out. It is simple, straightforward and there is little in the way of exceptions to the core requirement statement. Two stakeholders feel they have something to say on this topic (maybe just so they can feel useful.) Everyone quickly endorses the requirement.
6. R1 R2.1 R2 Requirement 2 is read out and kicks of a lively discussion about the definition of the word “Shall”. Additionally there is an important and common ‘exception to the rule’ that is discussed robustly by most of the stakeholders. It seems that putting this new function in an IT system is going to be a challenge for some people who like the fuzziness of the rule today.
7. R1 R2 R3.1 R3.2 R3 By Requirement 3 everyone is on a roll. Let’s really get into the guts of this issue. There are two points e want to really nail here.
14. Pick your methods Lots of people A professionally facilitated and agenda run meeting, time boxed with any detailed discussions being broken up into smaller facilitated groups Lots to talk about A conversation One topic Just you and me to match your needs