I recently had the opportunity to talk shop with Dave Saboe, who runs the Mastering Business Analysis website and accompanying podcast. The topic of our conversation was the “essence” or underlying “why” of business analysis, and how focusing on that “essence” or “why” can benefit the individual analyst, and the organization as a whole.
The process of collaborative creation; of drawing and deliberating and rationalizing potential paths together until we reach an agreed upon “best way forward” provides the real value in visual modeling.
“The chief virtue that language can have is clearness, and nothing detracts from it so much as the use of unfamiliar words.” – Hippocrates
Apparently, even back in Hippocrates’ day (approximately 450 BC), business professionals had a tendency to confuse their stakeholders with acronyms, jargon, and odd colloquialisms. In business communication, first and foremost in importance is achieving mutual understanding. Some may be able to follow jargon or sophisticated phraseology, but one stands a far better chance of ensuring understanding with clear, simple, common language. Some things never change!
Communication using only words – whether verbal or written – leaves much to the imagination. Which is part of the appeal when it comes to reading for pleasure. Unlike a great book, most of us don’t read business documents such as a requirements specification for enjoyment. And unlike the book, there can be significant repercussions when one reader’s interpretation of the content varies widely from another’s. So, how can we improve the precision and clarity of documentation without getting too long?
Ryland Leyton recently released his book, The Agile Business Analyst: Moving from Waterfall to Agile. Over the years, Ryland has provided training and mentoring for events and individual members of the Greater Atlanta Chapter of IIBA, so I was thrilled to see him take pen to paper and share his insights through a medium with broader reach. Ryland agreed to provide some additional information and background on the thought process behind the book for Practical Analyst readers.
“A problem well stated is a problem half solved.” – John Dewey
One of the more valuable lessons I’ve learned is that good solutions begin with a clear understanding of the problem to be solved. By starting with the problem, following up with objectives that articulate the definition of success, and then ensuring that requirements and subsequent solution artifacts and trace cleanly to, and support the original problem, we can avoid the confusion and wasted resources associated with deviating from or adding scope to the solution’s original problem and intent.
Let’s face it, lots of software projects continue to fail every year, even after so many advancements in the theory and practice of software development and business analysis. After working on countless complex software projects that delivered great business value, here’s what I learned about the reasons for a project to succeed.