Paul, sounds like you have a great plan. Just by asking your team what they need and getting their buy-in on what you produce, you’ll go a long way toward building trust and raising the potential for delivery. This is a nicely thought out plan for next week and I look forward to hearing how things go.

Laura

Don’t forget a Crystal Clear Objective; an unambiguous statement that makes sure no one can possibly misunderstand what’s to be achieved.
(http://www.goodplan.ca/2009/11/crystal-clear-objectives.html)

There will be conflicting views among the stakeholders; a CCO can go a long way toward resolving those conflicts. Involving them in developing the CCO statement cuts them off at the pass.

We have been trying to do a better job at requirements elicitation/analysis/management but the one thing that is never right is WHAT the developers receive….adding to the multiple locations scenario, we also have an ‘off-shore’ model….and throw in the language barrier (and I’m not talking about program language) and it only exacerbates the problem.

Management needs to recognize this is a problem state and provide their support. You can create all the fancy documentation you want…do all the feedback sessions you can stand – but if you don’t know WHAT the receiver (i.e. developer) really NEEDS – then what’s the point?

To that end, next week I will suggest we, the ‘BA community’, run this like any another project… identify the Stakeholders (Designers & Developers included) have a BA lead effort getting agreement on the PROBLEM, then on to Requirements elicitation (focus on WHAT is needed)… take the NEEDS & FEATURES move on to the next step of Functional/Non-Functional…Use-Cases…etc, etc – so just like any other project, we now we have the Stakeholders/involved parties contributing to solving the problem – and recognize we are all benefactors of the solution

Kind of SOP for a BA, no?

We’ll see where this all goes next week

It sounds to me like you did the right thing, providing the requirements in a new way in context to ensure communication is clear. I actually do not think it’s a weakness to admit that different people will need different types of communication and that you might not know what that is upfront. Sometimes it is a matter of trial and error before we learn just the right mix of documentation and verbal communication for each of our implementation team members.

In an ideal world, the question to be addressed would be “how can we all communicate better in the future to ensure that this doesn’t happen”? It might also help to share a bit of your perspective about why you thought a particular detail should have been clear from the documentation you provided — not defensively, but just from a learning stance. The feedback you receive from that kind of question might help you see your documentation in a new light or might help others see their oversight. Whatever the result is, everyone learns a bit that way.

Best,
Laura

You should make it clear that you understand there’s probably a Goldilocks zone somewhere between the first version where they missed the requirement and the second version where you hammered on it so they could not possibly miss it. Also explain that, in the interest of not missing anything, it’s better to say too much than not enough, so in future you’ll probably err on the side of the epic.