The Business Analysis Body of Knowledge (BABOK) which is the current documented standard for Business Analysts lists the following techniques as ways to elicit requirements from stakeholders.

• Brainstorming
• Document Analysis
• Focus Groups
• Interface Analysis
• Interviews
• Observation
• Prototyping
• Requirements Workshops
• Survey/Questionnaire

In this post I am going to focus on Document Analysis and how it can be a useful step in your requirements gathering efforts.  Blog posts in the future will touch on some of the other techniques.

If you are reading this blog, you more than likely have a history with the challenges a consultant faces surrounding the political and social environment of the client worksite. At one such client, I was thrust into a volatile situation that had grown from a failed bonus system that had inaccurately calculated payments to its union employees. By the time the miscalculation had been discovered, it was too late; some workers had received too little, while others too much. The union works were greatly upset by having their pay deducted to make up for the mistake caused by the client’s poor implementation of the system. The issue was not a defect in the system created; in actuality the system operated precisely as it was designed.

I’ve often thought that conceptual data modeling was an underused tool in the arsenal available to requirements analysts, and in a recent conversation I found that many were surprised that it would be used in the requirements phase at all.  Checking the Business Analysis Body of Knowledge (BABOK) I found data modeling listed among the tools available to requirements analysts to “to describe the concepts relevant to a domain, the relationships between those concepts, and information associated with them.”  There’s also Steve Hoberman’s excellent book on the topic, Data Modeling for the Business, an introduction to data modeling aimed at a business audience

I have participated over many years as a successful BI Consultant, but still the true nature of consulting seems elusive to me.  Simply put, "Consulting" means providing expertise, advice or recommendations to someone else whose responsibility it is to act. Good consultants solve problems for their clients.  Good consultants have some sort of expertise that their clients don't have.

Before going any further let me share a joke about consultants - A nuclear power plant was about to blow, so a consultant was called in.  The consultant came in, punched a few buttons in the control room and the situation was fixed.  When the consultant presented the client with a bill for $10,000, they said, "You were only there for 5 minutes and you're charging $10,000?  That's outrageous!"  To which the consultant replied, "The 5 minutes of my time only cost $5.  Knowing which buttons to push to avoid disaster costs $9,995."

"Our goals can only be reached through a vehicle of a plan, in which we must fervently believe, and upon which we must vigorously act. There is no other route to success." - Pablo Picasso

It is an old story: about 30% of IT application projects succeed, 45% are "challenged," and the other quarter fail altogether.   That's the consistent result over the years of the Standish Group Study of Project Outcomes.  Jorge Dominguez, here, displays a chart of the remarkably similar results since 1994.  Not a pretty picture, right?  Some question the validity of the Standish studies, but Scott Ambler parallels the Standish story in a recent Dr Dobbs column called "Lies, Great Lies, and Software Development Project Plans," which itemizes the strategies commonly used by IT project managers to "stay out of trouble" when schedule/budget results don't match initial estimates.  For example, "18% change the original schedule to reflect the actual results".

After reading Chris LaCroix’s blog entry on Requirements gathering (see Five Things Analysts Should Always Do To Ensure Success), I was reminded of a previous assignment where two things I had learned long ago were reinforced.  The first was a mantra preached by a senior Business Systems Analyst:  “You can never have too much detail in your requirements”.  The other was “A picture is still worth a thousand words”.  They both fit together into one statement:  Requirements must be communicated effectively, in a way that is easy for everyone to understand.

Over the years that I've spent practicing, studying, and quietly observing all things analysis across a handful of projects I've come to learn that following a few simple rules can help lead to a successful project. Let's take a look at the top five things that you should always do to make your job easier in the long run, keep your customer happy, and ultimately deliver a winning product:

1.) Maintain consistency in document design, and file storage structures. It's a very simple, but often overlooked practice that can mean the difference between avoiding last minute confusion and encountering some embarrassing heartache (Read: Exactly where is it in this document?!?).

Not only is document structure an important part of successful delivery, but file structure is important as well. Forget “where in this document is that feature” when you cant find the file easily.

In a recent very thoughtful post on data quality, Paul Erb plays out an analogy comparing data users with Don Quixote and data quality professionals with Sancho Panza, then reverses the analogy to cleverly coin the “Sancho Panza” test of data quality professionals.  He encourages data quality professionals promoting the critical role of data quality to apply a what would Sancho say test to ensure tha

In a new post at Insurance Networking News Ara Trembly provides a balanced perspective on IT/business misalignment (Business/IT Misalignment: Whose Responsibility?).  He describes the problem as cultural, more amenable to relational than management solutions.    His conclusion sums it up: “Take a geek/suit to lunch today!”