Often when managing a software project, you want to elicit requirements. If you don’t, be ashamed of yourself.
The basic technique for requirements gathering is dumping all stakeholders in a room and asking them what they want. A good moderator will know the right questions to ask in order to tickle the right answers out of people. But you know how it goes, 2 hours into the meeting things are still slow. The VP’s cousin has been making valiant attempts to finish his sentence for over 15 minutes, the users from Accounting aren’t talking to those from HR anymore because of a dispute over interface background colors and all the developers are playing Line Rider, God knows it’s nigh-impossible to tell what they’re doing behind those laptops anyway.
This isn’t productive, and don’t even talk about the smell in that room. It could be much better, but at the expense of the PM’s time. The approach I’ve found to be pretty good might make you sweat a bit more as PM, and perhaps you’ll have to put in the odd hour of overtime, but I found it improves the atmosphere between people and the accuracy of the requirements you gather.
I have only tried this with smaller projects so far. Let’s say the stakeholders of an inventory system are made up of the following groups:
- Group of users that relies heavily on the leasing contracts and bookkeeping interface the system has.
- Group of users that mainly needs to track inventory, report things as stolen, reorder lost items etc.
- Group of users that uses almost all features of the application, but not heavily.
- System developers.
- Database designers.
I am talking of “groups”, but every position could also be a single individual in a smaller organization.
Now with this setup, I would sometimes combine groups 1, 4 and 5 in a meeting. The meeting would focus on legal requirements, but it concludes quickly because most people are in agreement and we are discussing things at a level of detail that is interesting to everyone.
Then I visit group 2, again including 4 and 5. This group needs a lot of details about usage locations, times, the date an item is lost and which insurance company covers the loss. They are comfortable discussing these things, so we can discuss specialist features like that with them.
As a last step, I visit group 3 alone. I (as the PM) know enough about the system’s implementation to gauge whether something this group requests is a huge undertaking or just a small issue, so I can leave the developers and database designers to their own work. This third group has a good overview over the whole system but doesn’t use many specialist features. They are my check group that will tell me when e.g. the user interface is turning too unwieldy because of specialist features that are intended for group 1. Then an alternative interface needs to be found.
This allows me to have focused meetings, and group 3 helps think outside the box, something that might become hard once you delve too deep into specialist functions with the other groups.
I have found that this technique, while it does use a lot of time, generally leads to more harmonious meetings. It avoids many in-fights and the negative atmosphere that I often found happening at larger stakeholder meetings. Perhaps in the end, the time invested with this method is still less than with the traditional approach. One pitfall: it’s probably best suited to agile methods, as the people required are often geographically close and can be called into meetings more easily.
I think many projects might have users you can group in this way. I haven’t found any documents describing a technique like this. If there aren’t any yet, let’s be snobbish and call it “user group partitioning” 
Photo CC 2005 ciro@tokyo.
