I’ve long been of the opinion that involving as many stakeholders in the project as early as possible is a key to successful business analysis, and, more importantly, to successful projects, and have said as much in a few of my posts on this site.
Jim Highsmith, in the book Agile project management : creating innovative products, thinks that the reason projects tend to have so much documentation and so few results is that:
[T]here is a fundamental flaw in many people’s understanding of documentation—documentation is not a substitute for interaction. When a customer and a developer interact to jointly develop specifications and produce some form of permanent record (documents, notes, sketches, feature cards, drawings), the documentation is a by-product of the interaction. When the customer sits down with a product manager and they write a requirements document that gets sent to a development group, then the document has become a substitute for interaction. In the first scenario, the documentation may be valuable to the development team. In the second, it has become a barricade to progress. Little knowledge is either gained or transferred. Furthermore, as interaction decreases, the volume of documentation often increases in a fruitless attempt to compensate.
Highsmith, James A. Agile project management : creating innovative products. : Addison-Wesley Professional , 2004.
I especially appreciate the point that no knowledge is transferred when “sending a document” takes the place of actual interaction. And it especially hits close to home as one of the key functions of the business analyst is to facilitate the transfer of knowledge. How successful can we truly expect to be by substituting thick documents for actual dialog?
I think I can safely say that my most successful projects (and best spec docs) have been jointly owned among business and technology stakeholders with me there – not to pass out completed documents, but to help elicit requirements and facilitate dialog.
Thanks for the insight, Jim. Good stuff.
JB, Nice post. I happen to agree. It’s the understanding of the need that’s most important, and the documentation helps to confirm that what was communicated was understood.
A similar mistake is made in process where process is followed for process sake rather than to facilitate the production of product.
I do believe, however, that the BA can serve as a substitute for the customer with the developers.
I am feeling your comment Re: “following process for process sake.” I still run into projects occasionally where it seems like we are holding up the works by making sure that all the i’s are dotted and t’s crossed and all sections of every document full of verbiage just to follow process.
As a BA, no one values good, solid documentation more than I, but the trick seems to be learning to document “just enough” and then move on. More isn’t necessarily better.