What?

In 1999, Buckingham and Coffman authored First, Break All the Rules. They used Gallop data from manager interviews to identify how good managers drive employee satisfaction. Internally at ArgonDigital, we use the methodology described in the book for gauging employee satisfaction. People who join us are sometimes surprised by our survey. We ask a number of questions, none of which are “How satisfied are you by your job at ArgonDigital?”  I’ve been asked a number of times “Why don’t you just ask the question that you want the answer to?”

The logic behind our methodology (as outlined in Buckingham and Coffman) is that if we measure the things that objectively correlate to employee satisfaction, we get a much better gauge of employee satisfaction than by asking about satisfaction directly.

We frequently do work with clients to help them assess the maturity of software requirements in their organization. This frequently involves analysis of existing requirements documents, trying to understand the requirements methodology being used, interviewing stakeholders (management, IT, and BA’s). This is relatively time consuming, though it does allow us to make specific suggestions on how the requirements process can be improved. But there’s a more important question to ask:

Do the requirements need to be improved?

How?

At an objective level, I can look at almost any requirements document and start finding holes – places where the author of the document or requirement is making assumptions about the reader. When these assumptions turn out to be wrong, it frequently leads to the incorrect thing being built or to needless rework. The trick is to understand when those assumptions are working for an organization and when they aren’t. We can use tools similar to those in First, Break All the Rules to assess the satisfaction level that all parties have with the requirements process.

Questions that we ask to try to dig deeper almost always have the same format. We make a statement, usually a strong one, and we have people answer on a scale of “Strongly Disagree” to “Strongly Agree”.

Sample Questions

1. The business objectives for every project that we do are clear
2. The quality of the software requirements being delivered to IT have been getting better in the last year
3. We are rarely finding missing requirements after a software launch
4. Requirement changes rarely cause significant rework in our software
5. Our business stakeholders love the software that we build for them

We typically like to survey three groups – Business Analysts, Developers, and Business Stakeholders. If all three groups are ‘Agreeing’ with each of the statements, we generally don’t recommend making a lot of changes to the requirements methodology. The internal process can always be improved, but there’s no sense of urgency.

I tend to get concerned about the health of the requirements process when there are consistently lower scores for one or more questions or where different stakeholder groups have very different answers. Knowing how the questions were answered doesn’t tell us specifically what the problem is, but it gives us a place to start looking.