Hippocrates on Clarity of Language

“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!

The Book, The Movie, and the Business Document


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?

Interview with Ryland Leyton, author of “The Agile Business Analyst”


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.

John Dewey on Starting with a Problem to be Solved

A problem well-stated is a problem half solved

“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.

Business analyst, these are the reasons your project will succeed

Image credit: Duncan AllenImage credit: Duncan Allen

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.

Four Critical Components of a Meeting Invitation

While debates rage as to the effectiveness of meetings in general, and books have been written on meeting organization and management, I’ve found that often meetings go wrong before they even begin because the invitation is missing (or vague in) four critical components, without which the likelihood of full participation and effectiveness is diminished.

Benjamin L. Kovitz on Requirements


“Without requirements, there is no way to validate a program design; that is, no way to logically connect the program to the customer’s desires.” 

— Benjamin L. Kovitz

If human communication and human memory were perfect, we may not need deliberation and documentation of requirements. Alas, neither is close to true. It is the iterative exercise of modeling requirements, and then documenting them that enables shared understanding to be affirmed, and then shared with those who use requirements to guide design, construction and quality assurance. Requirements are the link between concept and product, and an important standard for measuring solution success.