Where I work, we're having a problem getting the powers-that-be to commit to concrete requirements, rather than buzzwords and hand waving . This is primarily due (IMO) to their inability or unwillingness to express themselves in writing, or read and understand what other people have written.

This of course leads to them changing 'what they mean' but not 'what they say' and vice-versa.

Has anyone else had similar experiences that they dealt with successfully? How do you make people whose primary mode of expression is verbal commit (and I mean REALLY commit) to concrete written requirements?

-- Anonymous, November 03, 2000

Answers

Take a pad of paper to your meetings with the noncommitters. Write down what they say. Later, type it in and e-mail it to everyone that was in the meeting.

-- Anonymous, November 03, 2000

I've tried that. I get statements later on like "but that's not what I meant!" and "I didn't approve that". Pathetic, I know, but there has to be some way of getting through to people like that, and getting them to commit. I just haven't found it yet.

-- Anonymous, November 03, 2000

Headology

When people disagree with what you wrote, that's not the same as disagreeing with you. If you treat the notes like an object, a thing, you can try to get them to work with you on beating the notes into shape. i.e. you need to iterate your notes a couple of times before people accept them as accurate.

Of course, if you have to change your concise requirements into wooly buzzwords in order to get them to agree, then you do have a real problem. People fear commitment/making-a-decision because they are afraid of making mistakes. Maybe you can get them to agree to a pilot project or a small scale test using one of the alternatives. Once a small decision is made, making the next one is easier...

-- Anonymous, November 03, 2000

The idea of writing down notes and distrubiting them afterwards is good, however, sometimes exactly what was said doesn't really show the intent of the conversation - and distributing it later will only lengthen the unresolved conversation.

Instead, put it on a board (grease, chalk, even shared piece of paper) and let them see what you are writing as you write it. Most people will be more careful with what they say when they know they are immediately accountable. If they don't like the way you wrote something, get them to reword it. This usually works for workers getting commitments from managers, and vice-versa. And like schedules, track it. Bring notes from the last meeting to the next.

-- Anonymous, November 04, 2000

Once the requirements is written, the tough part is studying them and turning the reqs. into test cases.

-- Anonymous, November 13, 2000

At a previous employer, I had a similar problem. We had written a requirements document, but in order to get it approved, we had to replace all of the concrete statements with vague buzzwords. I maintained both versions -- with and without concrete statements. This led to conversations like:

"Can I get a copy of the requirements document?"

"Would you like the official one, or the one that says what we're really doing?"

"What's the difference?"

"The unofficial one has more concrete."

After approval, I don't think that anyone ever read the official one again. The unofficial one went on to become the primary document explaining to the outside world what we were doing.

Try it; it may work for you.

-- Anonymous, November 16, 2000

I've found a really complete requirements gathering template. It's called Volere< /a>, and is available from the Atlantic Systems Guild at their web site (http://www.atlsysguild.com/GuildSite/Robs/Template.html).

The template forces me to identify the stakeholders of a project, then to ask them questions I might not think to ask. When I'm done, I write up a document and have the customer sign off.

-- Anonymous, November 30, 2000