Home | Login | Recent Changes | Search | All Pages | Help

FacingReality

It seems that some of the folks I work with have a problem getting clear requirements. And, beyond that some people even have a hard time accepting someone else's design or code as a component of what they might deliver as a solution.

What sorts of tactics have you used to get people to deliver clearer and usable deliverables that have meaning to both the broader business audience and the technical audience? How long did it take for people to buy-into the process?

- BeckyWinant 2003.04.15

On the requirements (user side), I've had some successes with facilitated brainstorming, getting people to externalize and analyze consequences together. Retrospectives help build this reality too, but that can be late for a given project!

In some situations, it seems to require crisis to resolve the "Everything is priority one, so get to it!" mindset. The best hope I see for that is iterative delivery forces hard choices earlier by having to choose each iteration rather than wait for the big bang triage. This is mentioned on one of the agile sources (maybe Jim H. can recall which) that short iterations flush choices sooner. --BobLee 2003.04.16

MikeMelendez 2003.04.16

Becky, it seemed to me that some of the discussions about modeling and requirements that we had last summer were relevant, so I went and looked. Take a look at DoTestersResonateWithModels and AssumptionsAboutModeling and see if anything there helps.

From a testing perspective, I have had some luck with examples of what needs to be clearer and why. Address information is a simple example. Will the user enter a state or pick it from a list? If they enter it, does it have to be valid? Does it have to be a state? Does the zipcode have to be 5 numbers or can it be 5 numbers, a dash and 4 numbers? (Hundreds of Canadians use California and 90210 on websites that insist on a state and zipcode.) Can it be an address for another country? And so forth.

SherryHeinze 2003.04.16

I like the idea of decision reviews to feedback at the meta level.

available free at:

Thanks to KeithRay for pointing out the link on his blog.

-BobLee 2003.05.16

A tactic that often helps with folks rejecting deliverables, declining to make a decision, or etc. is this:

"So, what's your alternative?"

If you are congruent, and present, and stay with the process, someone doing something silly, like rejecting "their" component because it is "their" component tangles themself up in knots pretty quickly. One way to let them off the hook when they end up all pretzeled:

"Well it sounds to me like there is something there. Do you want to work it through a bit more and come back when you have it a little better organized?"

Amazing how a lame and deficient proposal suddenly becomes much better when an alternative is required. -- JimBullock, 2003.05.17

I find that folks have a hard time prioritizing without context. When people can articulate a specific goal for a project or release, (or an operational group for that matter), they have an easier time seeing that everything is not a #1 priority.

ED 051803

Sometimes a challenge is getting people in the room to discuss both context and priorities. Contexts can easily shrink around whatever the perceived immediate need is. Bigger picture issues make those sorts of people panicky. They want to make sure their problems get to the top ten list. That can be hard!

BeckyWinant 5-19-2003

I like the prompt for alternatives and a delay of jumping to solve the problem. Curing the crisis can be easier when you decline the invitation to participate in the crisis.

BeckyWinant 5-19-2003