Distinguishing requirements firms from Staff Augmentation

Requirements consulting firms must find ways to distinguish themselves from other types of consulting firms and staff augmentation firms in the eyes of corporate procurement departments. The way that companies view requirements gathering is shifting to a more model based approach. This has created a niche for firms that specialize in requirements gathering and management. Application developers and project managers alike are eager to use these highly specialized firms to help them standardize processes and tools to obtain better and more complete requirements. Business units and end users are also on board with engaging requirements consultants to ensure that the developers and project managers have a more complete understanding of their needs for the software systems that they use. However, procurement department personnel have not yet become as knowledgeable about the unique ways that these firms operate and will often group them with staff augmentation firms and the like. The problem is that a requirements consultant is most often embedded within a team for an extended period of time which bears resemblance to a staff augmentation consultant. They may not see that they are engaging the entire firm vs an individual to work on a project. This affects the structure of a statement of work and can create challenges in the billing process. Most of these firms bill by establishing hourly rates for various levels of resources which is similar to the way that staff augmentation firms bill. The simple solution is to change the billing methods from hourly rates to a set price for each engagement. This can be risky if the scope is not completely defined upfront, which is often the case. The benefit is that these firms can better manage resources by not having to commit a particular consultant for the entire length of a project. As time goes on and companies engage specialized requirements firms more often this may become less of a challenge, but that will require the combined efforts of the corporate business units that engage these firms and the firms themselves in educating procurement managers.

Take Note of This

At RE'06, we heard a talk called “Making Mobile Requirements Engineering Tools Usable and Useful”, in which these guys are developing software to use on a PDA device to capture requirements while walking around. My thought is that while adding mobility into the requirements facilitation effort is an interesting problem to research, that frankly, doing the basics while sitting still aren’t actually trivial.

Something I have struggled with is how you can effectively lead a requirements session while taking good notes about the actual requirements you are gathering.

Inherently it is hard to juggle the tasks of listening, parsing what’s being said, asking questions on the fly based on what you hear and writing down the relevant information (though I’d settle for writing down everything).

Scribes
In the ideal world, having a separate scribe and facilitator in the requirements sessions is the perfect answer. If you do not have another analyst handy, use a developer or a quality engineer who might want to be in the session to listen anyway. Or even in a worst case, hire a temp to take literal scripted notes from the conversation.

Unfortunately, using a scribe is not always an option - maybe the rest of the requirements team is too busy to help or on the other side of the world. Or in one case, outside of the SMEs and the individual facilitating the session, the rest of the available people did not speak English as a first language. Ok, so let’s assume that it’s bound to happen - we are all eventually going to be in a less than ideal situation where there is no dedicated scribe. So then what?

Type faster
When I find myself in this situation, my only hope of survival is simply to type really fast. Though, if you don’t type fast, this solution is useless. And, if you do type fast, I guarantee you are still missing a lot of information.

I also find that a facilitator sitting behind a computer screen is really impersonal. It’s accepted as part of the culture at many companies, that people just have laptops attached to their noses. But that doesn’t mean it’s the most effective way for us to run the sessions. It certainly does not bring energy to a room and potentially will actually stifle conversations. Most likely at some point during the session you need to be in front of the audience drawing or writing something for others to see, so inherently the computer solution isn’t going to work alone.

Record it
You could choose to record the sessions. I’ve done this with some success, but realistically, do we want to go back and listen to hours of requirements sessions again? I suppose we could pay someone to scribe from a recording. However, fundamentally, recording a session is not always a good option because people hesitate to open up with such devices in the room. If you really need to get to the heart of a contentious issue, that’s going to be very hard if it’s recorded. Other cultures react even more negatively to this option.

Whiteboarding
Writing on the whiteboard, does keep the session leader engaged with the people in the room, however that’s a lot to manage. Personally I write even slower than I type, particularly on a whiteboard. And there is no way you can capture all of the information anyway.

On the messageboard, Marc pointed out that when doing this, you often run into ideas you want to further explore, but do not necessarily find appropriate to write in the public forum of a whiteboard. As a side note, this only works if you have a lot of whiteboard space, or whiteboards that you can print to paper before erasing to continue on.

Getting out of the box

Here is a new idea to think about - what if we could turn the SMEs into scribes without actually taking away from their role as SMEs?

Paint this picture in your mind:
Let’s say you have a nice sized room. You have a few people in a room to discuss the requirements on a topic. The walls are wallpapered with paper (or lots of printing whiteboards). The room is sprinkled with markers.

Perhaps Jane starts to talk about the user needs on a particular function. You immediately ask John to jump up real quickly. You toss a marker at him and have him capture what she is saying on the wall. Jenny gets excited about the ideas and contributes a few comments too. Maybe while writing, John has an idea and doesn’t want to lose it, so he can turn to you and asks you to jot down a note for him. Or maybe he tosses the marker back at you and asks you to take over for a bit because he has a new idea about this topic and doesn’t want to lose it.

You still need to facilitate the conversation, but as someone is exploring an idea, you have someone else writing the idea on the walls. As a facilitator you can help make sure that everyone is being heard and that John is able to capture all the comments.

If needed, you can also take brief notes on paper or a computer on the side for you to translate the walls into detailed requirements, but it’s less important that you capture all the details now in that format since the wall has most of it.

Because the role of scribe is rotating, that will help ease people’s fears about writing in front of the group – they will see everyone has to do it and no one is actually great at it because it’s hard! They will be able to help each other with missed points. To make this work, as a facilitator, you need to foster an environment of team work and not one of scrutiny and which individual is best.

The great thing behind this idea is that you have now engaged the entire room in your session, even people that maybe didn’t initially think a topic was relevant to them. As you move through topics, you have actually got everyone in the room out of their seat and moving around. The added energy to the room over the standard sessions is bound to help the requirements process in itself.

Spreadsheet Abuse

You have a lot of information you need to track and share with others. This information will have various attributes you will want to be able to sort and filter on. Perhaps you’re keeping up with issues on your project, enhancement requests for your application, or the requirements for your next project. What do you do?

The answer I frequently see is “Put the information in a spreadsheet and pass it around.” The problem then becomes larger. Different people or groups want to add different attributes to the information and update that information independently. What do they do? This answer “Duplicate the common information and add new fields for my attributes.”

I’ve seen this frequently--multiple spreadsheets which contain common core data and different additional columns or attributes. Or, spreadsheets that are so massive a human can’t comprehend them. I recently saw a very intelligent person reject a very detailed, well-thought-out set of requirements because the information was stored in a spreadsheet that was too dense for expedient human consumption.

My own personal term for this solution to the problem is “Spreadsheet Abuse.” Spreadsheets are not databases. Issue tracking systems, defect/enhancement tracking systems, and requirements management systems may take a bit of work on the front end to set up, but are well worth the advantages. Anthony C. addressed issue tracking in an earlier post, Issue Tracking for Requirements. We’ll explore requirements systems in a future post.

In the mean time, let's stop the spreadsheet abuse!