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. 

The Tyranny of Templates

On the journey known as Business Analysis, outlines are the gas stations.  Templates are the fast food restaurants.

The next time you begin a Business Analysis document, first fill up the tank.  Outline that document.  When you run out of outline, stop writing or get some more outline.

If you are writing a System Requirement Specification, or a Test Plan Document, or a Technical Solution Design, you may want a template as well.  This is much like the craving you get for doughnuts or a hamburger while on a road trip.  You navigate the drive-thru, they hand you a bag and you're back on the road.  You have everything you need.

Except nutrition.  By the end of the journey, if you rely on fast food, you will feel a little sick.

By the end of a project, if you rely on templates, the quality of your work will suffer.

An employer or esteemed colleague or corporate custom may insist on use of a template.  Okay.  Use it correctly:  as an outline, not as a form.

You already have a content outline.  The template will be your structure outline.  Merge the content into the structure.  If this leaves bare structure, lacking content, then you have more research and outlining to do.  More likely, you will have content beyond the structure.  Appendixes will hold any of this if the template must remain intact.

A template may look like a form, but it is not a form.  It is fast food on your journey to meet a business need.  Forms have little boxes that tell you how much to write.  Fill-in-the-blank, and you are done.  No need to think too much about what you are writing - just leave no blanks.

You can be paid for work like that, and you can call junk food a meal.  That is the tyranny of templates.

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.