Six Ways to Avoid Requirements Workshop “Traffic Jams”

We recently visited India to give presentations in Pune and Bangalore. As we travelled around India we were initially amazed at how the traffic flowed. India is a populous country, of course, and they have an ever-increasing number of vehicles. Their road system is not what we are used to in the US. For example, they have few stop lights and stop signs.

No matter what time of day it was, the traffic seemed heavy. So, how can their constant flow of traffic work? For one thing, they use their horns to communicate. A lot. At first this seems rude to Americans who only honk to alert someone of danger or out of frustration. Honking to Indians was a way to let other vehicles and pedestrians know there was another vehicle approaching. Some buses and trucks even had signs on their backs proclaiming “Please Honk.” Honking was actually very helpful to them.

For another, drivers seem to use extensive non-verbals to communicate. If a car is coming at you, a driver is supposed to move away. (This was a bit disconcerting at first when a passing car was heading straight for us!) If a car is entering the intersection in front of your car or motorbike, the driver slows down to let the car pass. Pedestrians watch for cars and move out of the way of a moving vehicle. Drivers use their lights to let other vehicles know they see you, which helps when making turns or similar maneuvers.

Surprisingly, we saw no accidents, and no irate drivers cursing or shaking their fists (or worse). The whole system seemed to flow like a well-scripted dance. What struck us both is that motorists and pedestrians in India operated with a set of simple and well-known ground rules to keep everyone safe. Of course, the above “ground rules” were completely our interpretation and may not be entirely accurate. Now, what does this all have to do with business analysis, you might ask?
It occurred to us that there are similarities between traffic flow in India and requirements workshops. Here are some examples:

1. Sometimes we need to slow down.In Bangalore, a city of over 5 million people, we found few traffic lights. Traffic control seemed to happen through the use of speed bumps called road humps, which slowed traffic at regular intervals. It allowed vehicles to enter the traffic flow from side streets, to turn left in front of heavy traffic, etc. However, these humps can be dangerous. Articles in Indian papers allude to the dangers of back injury and even death if not approached at the proper speed.Some of us practitioners, particularly those of us who have been project managers, like to have meetings, make quick decisions, and move forward with the project. At times other participants or various issues can appear like speed bumps. They seem to slow us down, to get in our way. We need to realize, however, that sometimes slowing down is needed to let other ideas enter the existing flow. The end result is usually better when we slow down at intervals and let other stakeholders participate.

2. Establish ground rules.Ground rules help establish behavioral norms and guide participant behavior. Some of our stakeholders know these “rules of the road,” for requirements workshops, but others often are unaware of whether they exist at all and if so, what they are. These ground rules may or may not be obvious to participants. When we ask clients whether or not they use ground rules in their requirements workshops, we often hear something like “we don’t need to write them down. We all have an idea of what they are.” However, when we ensure everyone is aware of and understands the rules of the road, we can be more productive and avoid behavioral accidents.

3. Ensure ground rules are understood.After a very short stay in India we might think we understand the rules of the road, but we might be misinterpreting them. In requirement workshops there might be different interpretations of the same ground rule. If we make assumptions about what they mean, our behavior might be misinterpreted. We might never even know that our interpretation is incorrect. Let’s say, for example, there is a ground rule in our requirements workshop that states “we agree to start and stop on time.” Start and stop what? The meeting? Each agenda item? Each discussion? What does “on time” mean? Is there any leeway? For example, one of our clients considers being five minutes late to a meeting “on time.” Different teams, organizations, regions, and countries have a different relationship to time. We need to determine each group’s acceptable norm.

4. Consider different cultures.We need both verbal (honking) and non-verbal communication (flashing lights). Yet what works in one culture may not be appropriate in another. What may seem impolite to some may actually be helpful to others. For example, in some cultures interrupting someone when they speak is considered rude. In other cultures interrupting, if done in a friendly, non-aggressive way, is a sign of engagement. We need to understand these cultural nuances if we are going to succeed.

5. “Co-opertition,” is our word for the balance between competition and cooperation. It enables drivers to enter the traffic flow, but in a way that doesn’t harm others. In a requirements workshop, some of our stakeholders are more aggressive about their requirements and some more collaborative. Generally speaking, collaboration brings better results with fewer “accidents,” as long as everyone agrees that the needs of all stakeholders must be met. We have seen the more aggressive participants get into more conflicts and consequently get “injured” more frequently than those who have learned to collaborate. And collaboration usually enables participants to get to their destination sooner with fewer detours.

6. Make room for everyone.It’s not the biggest cars that get to push their way into the traffic. Even tiny two-wheelers (scooters, bicycles, and “tuk tuks”) can jointhe traffic flow when they know the accepted way to merge. When we elicit requirements, we need to get information from the tiny two-wheelers as well as the biggest cars. In other words, we need input from stakeholders in various positions in the organization. C-level stakeholders have one perspective and end-users another. Both are important, and we need to get that perspective from both.

What does this mean to project work in general, and requirements sessions in particular? For maximum effectiveness, we need to understand and abide by the implicit rules people follow in our organizations. Even if everyone thinks they understand them, it helpsto spell themout for your sessions (like reminding people of the dangers of driving too quickly over speed bumps). It is especially important to articulate ground rules when we have disparities in geography, culture, or organizational rank. It’s good to remember that it is not just the large buses, but also the small, two-wheel scooters which can add value to your sessions.

Authors: Elizabeth Larson and Richard Larson

Elizabeth Larson, CBAP, PMP, CSM and Richard Larson, CBAP, PMP are Co-Principals of Watermark Learning, a globally recognized business analysis and project management training company. With over 30 years of industry experience each, they have used their expertise to help thousands of BA and PM practitioners develop new skills. Their speaking history includes repeat appearances at IIBA and PMI Global Congresses, chapter meetings, and professional development days, as well as BA World conferences.

They have co-written the acclaimed CBAP Certification Study Guide and The Practitioners’ Guide to Requirements Management. They have been quoted in PM Network and CIO magazine. They were lead contributors to the BABOK Guide® Version 2.0, as well as the PMBOK Guide® – Fourth edition.