Point out your own mistakes and uncertainties during document reviews

by Laura Brandenburg on March 16, 2009 · 0 comments

in Creating alignment,Requirements Validation

During a documentation review, oftentimes no one wants to be the first to challenge something or point out a mistake.  When reviews are passing along with a false sense of “wow, this is perfect!” I like to mix things up by pointing out an error in my own work or raising an issue with something I’m not 100% certain about.

This post is part of a blogosphere series to collaborate with those that “bridge the gap” on bridger tools, techniques, and tips.

People tend to go into document reviews with faith in the document owner and not wanting to hurt his or her feelings. Pointing out your own mistakes and uncertainties tends to encourage discussion by giving others real permission to find something wrong or to be uncertain.

I once pointed out an uncertainty I had during a use case review and initiated a 30 minute discussion about a design issue.  All I had to do was ask a certain individual in the room, “you know, I’ve been thinking about this data piece, and something doesn’t seem to quite fit together to me. What are your thoughts on it?”  In minutes everyone voiced contrary opinions about how that would work and by the end of the discussion we were more aligned as a team than we had been previously.

This technique is most valuable in contexts where you are not getting a lot of input or sense people are not really reading the document.  You need to trust the team and you need to be self-confident enough to point out your own mistakes. It’s probably not a good technique to use when negotiating a proposal with a customer, as it tends to open up discussion and debate.

By Laura Brandenburg. Laura Brandenburg is an independent business analyst mentor and consultant. She hosts this blog as a forum for business analysts to build on each other's experiences. To stay up-to-date on the latest from Bridging the Gap be sure to sign-up for our free eNewsletter and receive a free primer titled "3 Career Habits of Successful Business Analysts." View more blog posts by Laura Brandenburg

Related posts:

  1. Reverse Engineering Requirements: Synthesize, Document, and Validate!
  2. Best practice: Involving Quality Assurance professionals in requirements reviews
  3. Requirements prioritization – what’s the point?

Leave a Comment

Previous post:

Next post:

?>