Requirements

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