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

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.

My experience this week involved a missed requirement in a feature that we worked on last week. I felt, actually, that the requirement was missed by the developer, not by elicitation and documentation. Nonetheless, I conceded that perhaps that requirement wasn’t made clear enough or perhaps a use case (or test case) or two would have illustrated it better. So, I updated the requirements document to better call out the missing functionality. The updated requirement was simple and, yes, I could have just stated that single update. Perhaps I should have. But instead, I included the subset of requirements around that updated requirement and drew attention to it, by highlighting it as new, as well as calling it out in the introduction of the request.

The feedback I got was that I should be more concise, since what I had put in was “epic.” So, I’m torn between being concise (where perhaps not everything gets stated explicitly and things get missed) and being complete and providing context (which gets interpreted as “epic”).

I know it is my job is to be helpful to developers and testers, so I need to provide them what they need in a way they need it. And I admit, it’s a blow to my pride to be criticized for my efforts. So I sucked it up, said “ok” and I will check in with both the developer and tester who both use the requirements in different ways to find out how to meet their needs.

But thanks for letting me vent my flustration (can I make that a word to explain how I feel?) to my compatriots.