Business Analyst Handbook

Business Analysis and getting dressed: a worn-out metaphor

BA’s!  As you prep for that next interview, dress carefully.  Just as a book can be read by its cover, employers can judge Business Analysts by their clothing. You disagree?  Consider any of these button-down solid similes:

1. Product is more important than process.   No one cares which arm first goes into which sleeve; just don’t mix them up (that could be uncomfortable).  Likewise, your methodology will attract less management interest than the thorough, accurate functional requirements that you list.
   
2. Some things are more essential than others.  Wear shoes to your interview, but that lapel pin? – maybe/maybe not.  And when you get the job, your planning and scripting of User Acceptance Tests will bear more weight than that Smoke Test, which maybe doesn’t need a 50-page document.
   
3. What you do depends on where you are going.  Headed to the beach?  Yeah, business casual would be overkill.  Deploying a new reservation system for a billion-dollar hotel chain?  You may need to churn out level 1 and level 2 support docs first.
   
4. Ultimately, someone notices if you aren’t careful.  Dang!, that shirt or blouse is buttoned wrong.  Shoot!, didn’t think that a Service-Level Agreement would be necessary with the good folks hosting our databases.
   
5. You get to make a lot of choices.  Solid or pin-stripe; charcoal or navy:  all are good.  Page numbers left, right or center?  Don’t stress on the decision.
6. One choice impacts the next.  Oh-oh; now you’ve done it.  You’ve captured attention with those plaids and stripes.  Well, try redirecting their gaze over to that test plan, where every approved new function has become a tested new function.
   
7. It takes resources.  You won’t get the job if all of your professional attire is in the wash.  Users won’t like the solution you designed unless you write-up data and business rule requirements along with those functional requirements.  Depending on scope and complexity, you may need to consult a Data Architect or DBA… maybe both.
8. Check the weather before you begin.  Don’t let Interview Day become a Bad Hair Day, for want of an umbrella.  If the Coders all use UML and Object-Oriented Programming, you may have to churn out a Use Case or two, along with that wireframe mock-up.
9. A second set of eyes is good.  I hate it when asked, “Did your mother dress you funny today?” or when a helpful hand fusses with my shirt collar just as the meeting begins.  It is no less awkward to explain why so many requirements were missed in this release.
   
10. Don’t dawdle or you’ll be late.  If you believe “there is always room for improvement”, also remember that “time marches on”.  Get to the interview on time, and deliver that product on schedule. 

A logical beginning to Business Analysis

You, the Business Analyst, have been there many times:

You walk into a Project Launch meeting.  The PM claims the catbird seat at the head of the table.  Seated nearby and never looking up, a scribe clacks away on an ultra-thin notebook.

You take a chair near the middle of the long table and reach around for a few handshakes as you drop a yellow tablet to claim your place.

Half of the people you meet represent the business.  They seem just delighted to begin this work.  The application built by your I.T. colleagues will free them from the awful legacy system now constraining their lives. 

You have already met the rest of the people.  They represent Project Management (catbird seat), App Architecture (across from you), I.T. Security (lurking at a corner seat), and the Developers (arms folded, already frowning at the time line posted on the white board). 

As Business Analyst you literally and figuratively sit between these stakeholders, your constituents.. or maybe you call them your clients.

The Business side thinks you are there to capture requirements; to get it right.  They hang a lot on you, and they are always correct.  The I.T. side thinks you are there to dig out contractually-sound specifications that never waver, never cause a re-write and never expand scope.  They, too, hang a lot on you, less than the PM who only wants you to churn out a hefty, never-to-be-read document for signatures within the three allotted weeks.

So, Business Analyst, where do you begin?

Begin at the Logical beginning.  Gather the nouns that you hear and begin to create a Logical Data Model (LDM).  In the Launch Meeting, jot down the "who's", the "what's", the "where's" and the "when's" as shared by the Business.  Listen to your I.T. colleagues as well.  Never miss a noun.

Those verbs are important as well.  Tuck away the "how's" and parts of the "what's" for your functional requirements list.  Record the why's as potential business rules.  You will need those functional requirements and business rules later.

Start with the data requirements.  Draw up a model based on your noun list.  Be sure to include data elements from every sample report you can gather.  Parse the report and column headings:  those are your nouns; more data elements for your model.

What do you call it?

You might want to call it a Conceptual Data Model or CDM until you are certain of a few things:

1) The Business agrees that those data elements are accurate and complete.  You must hold a few model reviews before you reach this point.

2) You have researched and recorded metadata for all of those data elements.  That means you have the definitions, the data types, the default values, the valid values, and the NULLs/NOT NULLs... at a minimum. 

3) The relationships... the solid and dotted lines, the crows feet and that turtle-looking thing below "DAILY FLASH" are all understood and verified by the Business.

Now you can call it a Logical Data Model or LDM.  Keep it away from the DBA, who now wants to convert it to a Physical Data Model and then forward-engineer it so the Developers can have a "working, prototype" database.  If you let that happen too soon, you will pay a toll for every necessary change throughout the development cycle... which will exceed its timeline... and you will own a measure of accountability.

You are not ready for that forward-engineered database.  Remember, this is the logical beginning.

It's all about the data

A wise Manager once told me... actually told me several times that "It's all about the data."  He had been in corporate Information Technology for 20-some years and now led a team of DBA's and Data Modelers, so may not have been the most objective source.

As Business Analysts, we bridge the sometimes scary gulf between a customer and a development team.  I say sometimes, thinking of those occasions when the developers were all too eager to code something, anything, when the customers had just begun to think about the problem.

Sometimes, it seems like a developer may have a hidden agenda; some program he or she has wanted to code and is just waiting for a budget to write that thing.  That's the BA perspective; I've heard the developers express frustration over waiting weeks for documentation... and in the meantime having no available charge codes... and then receiving wildly inaccurate specifications.  After developing to those, it was of course up to them to implement the necessary design changes on their own time and budget.

We Business Analysts can make things better for both groups we serve by getting the requirements correctly and quickly.  One key factor for accomplishing that is understanding that requirements are more than function lists.  We sometimes have to tweeze out business rules... even recommend that the application allow for evolving changes.  And we certainly have to get a handle on the data.

A Data Architect or Data Modeler may join us on the team.  That's fine, as long as we can stay in tandem with them.  Many have highly refined skills in drawing third-normal-form diagrams, then adroitly changing them into physical databases. 

When we work with them, our responsibility as BA is simply to be sure they have opportunity to draw out all the necessary nouns from our mutual clients.  Those nouns become entities and attributes, and later become tables and columns in the database supporting the technology solution our clients seek.

If you know a bit about third normal form and data modeling, you might want to draw a preliminary Conceptual Data Model (CDM) or more detailed Logical Data Model (LDM). If you have license to such diagramming powerhouses as Embarcadero ER/Studio or CA ERWin, you can quickly draw an impressive Entity Relationship Diagram (ERD).  If you really want to be helpful, include definitions, relationship names and data types with those diagrams.  Otherwise, your partnering Data Architect may cry, "Where's the metadata?"

I am biased towards ER/Studio because it draws beautiful diagrams so easily and even will untangle all the relationship lines for you with one click.  ERWin now does that, but with far fewer options and not so elegantly.

Recently, I needed a data modeling tool for another machine and another client and had no budget.  Fortunately, Dan Horn had posted a very handy chart online, listing 65 products, each with a link to the vendor website, a price quote and comments. Prices range from free to $14,000 with many in the $100 - $200 range. 

After looking through that chart, I settled on Power Architect.  It wasn't as easy to learn and use as the $2K+ enterprise tools I had used before, but it did the job.  It did at least the part of the job where the model was drawn and then forward engineered into a database.  The other part of the job was meetings with the client to review iteration after iteration of the paper diagram until I really had drawn the data elements they needed. 

The work was all very much in line with what a BA must do.  And in that case, it was all about the data.

Rules not made to be broken

Business Rules were made to change!

When was the last time you worked for or consulted at a company with stable business rules?  If such a company existed, no one would ever transfer to another department.  There would be no promotions (actually, I have heard that a few times).  The company would always use the same suppliers, and they would have the same customers - year after year - with their needs and interests never changing.

Consider these examples:

• Ann Jones is responsible for the I.T. department (governance)
• The database must be backed up between 2:00 and 3:00 a.m., 7 days each week.  (systems)
• State and county sales tax of 6.5 percent is to be collected for all merchandise shipped to Florida addresses.  (calculations)

But people move from job to job, and software is constantly upgraded, and it has been a while since tax laws were carved on stone tablets.

This volatility means two things to the Business Analyst.  First - that beautiful requirements document with all of the detail you so faithfully captured will be out of date soon after the final signature is scribbled on the last page.  In fact, the signature page is probably out of date as well.

If you must produce a document, produce it from a repository.  Select the always-volatile rules from some form of database... even a spreadsheet... and if possible distribute it via an intranet rather than killing yet another tree.

If volatility causes the need for a repository, then it also brings the need for organization.  If the repository is not organized, you won't be able to search and update and extract business rules.  If it is poorly organized, the business rules will not trace to data and functional requirements.

The suggestion is, then, record your business rules as data, and organize them using some sort of taxonomy.  Maybe develop a hierarchy based on the company organization, or based on your enterprise data model, or simply a hierarchy of tasks.  Regardless of the form of organization, find a way to link business rules to functional requirements and to data elements.  The home page of my web site, gpond.com kind of illustrates this.