Peter Senge, in The Fifth Discipline: The Art & Practice of the Learning Organization, said that “[a]t its simplest, a shared vision is the answer to the question, ‘What do we want to create?'” I’ve mentioned several times that I think a business analyst’s primary responsibility is that of facilitating shared understanding (or shared vision) among project stakeholders. We help our organizations arrive at an agreement as to “what we want to create” within the parameters of the elicited needs and constraints.

Some of my most important “eureka” moments as a business analyst have come when I realized that producing cookie-cutter documents conforming to all the stylistic rules of “good requirements” didn’t necessarily constitute effective communication. And debating the relative merits of whether it’s best to specify requirements with use cases or user stories or declarative statements is not nearly as important as the question, “how can I express these requirements in a way that engages and makes sense to this audience for this project?”

James Shore, describing a situation where his team had specified requirements accurately, thoroughly and to the best ability of the team, said (emphasis mine):

What went wrong is that the customers didn’t engage in the up-front requirements process. They looked engaged–they were physically present and participating–but they didn’t know what they were getting and couldn’t imagine it from the materials we were giving them. I think what went wrong is that imagining software from a verbal or written description is a difficult skill, one that most customers don’t have.

I think Shore makes a significant point, here. It’s easy to get wrapped up in the textbook process and deliverables and doing them the proverbial “right way” and then overlook the notion that our real value lies in, first, identifying the requirements, and then in modeling them in a way (whatever way that may be) that makes it as easy as possible for the audience to understand what success for the project looks like, and hopefully achieve that ever-elusive goal of “shared vision.”

Let me say this again in just a slightly different way, because I think this is so important, and because I think a lot of analysts miss the point: Your value as an analyst is not in asking a bunch of questions and cranking out documents, but in facilitating understanding; in optimizing the requirements models you create to maximize their communicative value. Our value is in creating a shared vision of what constitutes success in the minds of every project participant.

I do have some ideas as to ways to maximize the communicative value of requirements, but we’ll leave that as a topic for another day. But in closing I will ask – what are you doing to make it easy (or at least easier) for your audience of stakeholders to understand requirements? Or, for your project team to reach a “shared vision” of what you’ll create?