Passing Thoughts on Business Analysis & Requirements

Welcome to Practical Analyst, a site specializing in practical insight for business analysts and project professionals. If you're new here, you may want to subscribe to my RSS feed or follow me on Twitter. Thanks for stopping by!

Here are just a few impressions I’ve jotted down over the past few weeks that may never evolve into full blog posts, but that I wanted to share just the same. Please feel free to chime in with your feedback, or with your own thoughts.

• In my observance, the primary difference between the expert analyst and the novice lies in the ability to recognize the recurring business (industry and company specific), technical and even political patterns in the problems we’re asked to help solve, and the knowledge of how to apply the right mix of principle, practice and personal touch to solve them.  Talent, or a knack for picking up on patterns helps, but there is no substitute for time and experience.

• As a business analyst, it’s beneficial to have expert knowledge of the systems and technology in use, but it can also make it that much more difficult to fight the urge to originate requirements instead of eliciting them.

• That a deliverable has been approved doesn’t necessarily mean it was read or understood. If you want to be sure you’re being read and understood, seek out feedback early and often. What measures are you taking to make sure your deliverable is read and understood?

• It’s a simple fact of life that the longer a document gets, the less likely it is that it is going to be read. That’s why you bought the Cliff’s Notes in high school.

• A picture is worth several – if not quite a thousand – “system shalls.”

• One man’s “what” is another man’s “how.”

• Of course we all want to be more agile, but wholesale conversion to an “Agile” methodology isn’t the only, or even necessarily the best way to do it. Salesmanship (read: evangelism) of these single, fit-all and fix-all methodologies brings to mind the maxim, “if all you have is a hammer, everything looks like a nail.”

• Be wary of the pedaler of “best practices.” That’s not to say that there aren’t best practices, only that what’s best is relative. What’s best in one or even many situations doesn’t mean it’s best for most, let alone all. The trick – and this gets back to my comment above on recognizing patterns  – is to understand a variety of “good practices” well enough to determine what is “best” in a given situation.

• Processes and templates are great to the extent that they serve as a reminder to do things that might be important, but they are a drag on productivity when they require work that isn’t critical to delivering quality product for the sake of satisfying a process or template.