When Is a Bad Reaction a Good Thing?

Take the same set of requirements, and ask for signoff from two different people. One says they're fine and signs off. The second returns them two days late, and says he can't sign off until you have one more meeting.  During that meeting, he shows you a copy of your requirements with so many comments you barely recognize it.  He asks you questions like, "Do we really need this one?" and "This doesn't make any sense to me.  Can you explain where this requirement came from?"  and "What is the impact of this change on the downstream system?"

Some people would call that second guy a jerk.

I call him my best friend.

People who genuinely want to solve the problem will give you their full attention and consideration.  And there is no way, people, that we as analysts can get all of the documentation done right in the first draft, alone.  Look at software development - QA is built right in!  Why do we have QA?  Because everyone assumes that the first thing to come out of software development is going to be a big round of bugs.  There is an entire role specifically trained to find and document those bugs.  It's a widely accepted iterative process.  No one assumes that a developer will just write a big batch of perfect code and send it off to deployment.

So let's break down what the second stakeholder actually gave us, and look for the hidden treasure.

1.  He returns the requirements two days late.
This one is good, because you know he spent time reviewing them.  The stakeholder's primary job is.... HIS JOB.  That is usually what qualifies him as a stakeholder.  He does not, in general, review software requirements for a living.  So what you're asking him to do will take time away from his job and will take focus and consideration.  I usually build a margin into my due date so that I give my stakeholders a few days of extra time to return feedback, before I'm late to the PM.

2.  He comments up the requirements document.
This is golden - if you can get it to happen.  Does it hurt for a minute to see your work all scribbled over in MS Word Track-Change red and purple?  Well, it depends on your perspective.

It used to hurt me a lot.  For a while.  Why?  Because my documents were MY DOCUMENTS.  I was emotionally attached to my work.  I was designing, analyzing, strategizing.... I was CREATING.

Then I woke up.

Once I started seeing the documentation I was producing as a service I was hired to perform for the client, I became about 300% more productive and about 3000% less of a pain in the neck to be around when it came time to shape things up as a team.  If the project failed, who lost a ton of money?  My client.  If the project needed more resources, who hired them?  My client.  And at the end of the day, where did my paycheck come from?  You guessed it.  

3.  He asks annoying questions.
This falls into the same category as the understanding that this documentation is the client's property, and I am the guardian.  I am also the guardian of keeping these requirements accurate, and in scope, so these are great opportunities if I recognize them:
"Do we really need this one?" - Possible opportunity to cut scope.  Almost never happens.  It's like a four-leaf clover made of rainbow gold.  Don't get offended.  Cash it in.
"This doesn't make any sense to me. Can you explain where this requirement came from?" - This is another great opportunity to either cut scope or clarify the requirement.  Maybe it's unrelated to the business objectives and therefore out of scope, but was brought up by a secondary stakeholder.  Or maybe it's just poorly written, and if he doesn't understand it, the developer might not either.  He caught that for you.  Maybe say thank you.
"What is the impact of this change on the downstream system?" - You have no idea how much I love stakeholders with a conscience.  It is really, really good when someone has your back in these areas.  If this hasn't been considered, it's a good catch.  If it has been considered and just hasn't been documented (or documented clearly), it's a good opportunity to hash it out one more time from a business perspective (his), which could yield valuable data format or business rule details.

On the other hand, some people are just in the room to get a promotion, and eventually it shows.  Getting a nod and a smile will feel good for a moment, but seriously - it's not going to feel as good in post-production when you're writing midnight requirements for that hotfix.  Trust me.