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.