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?
Great post. Very valid points.
As analysts we have to be careful when we say things like “What went wrong is that the customers didn’t engage in the up-front requirements process. ….. “, as it is the responsibility of the analyst to engage the customer. (It is excellent that you say “customer” as opposed to “user”)
If the engagement is not being achieved then there is only one option – stop the project! It is pointless proceeding. This is the most overlooked options in most IT projects and one of the major reasons why so many fail to deliver.
Calling a halt is a huge wake up call. It either rouses the customers and all stakeholders to get involved or highlights the fact that the proposed system is just not required.
Once again, great post.
Very good post and I do agree with John's comments.
What helps me constantly in communications it is images: diagrams, schemas, UI prototypes etc. Human brain works with images, actually – words are just “mediators” in communicating ideas. UML is good, but when you are focused on the question “What are our goals” even the simplest bull’s-eye works well. And of course “why?” and “why?” until stakeholders answer as a chorus.
You guys would get a kick out of the Mendix Business Modeler… Its amazing for getting immediate feedback from 'customers' – this is the basic idea: First you model the business requirements in the business modeler (which, as Andrew mentioned, is already a step in the right direction towards visualizing requirements), then it has a one-click deploy feature that pops open the application. You show it to your customer, they give feedback, and you go back to the drawing board (which is intrinsically reforming the app as you go). This post reminded me of it.