Business Analyst Handbook

To Win that Tech Job, Know the Contest

It's the first morning of your new job.  You have shaken some hands and filled out some forms.  You find a place for the supplies you brought; the half-box of paper clips, the scissors and the yellow tablets all go in the top drawer of the desk you now use.

You won use of that desk in a contest.  Any time two or more people want the same thing, there has to be a contest.  Think of the other competitors now, checking their email for new opportunities, maybe choosing the right wardrobe for yet another interview.  No one wins them all, but why were you chosen in this particular contest?  If you are not certain of the answer, your job search probably took longer than those who know why and how to win competitive interviews.

You may have heard that job hunting is a matter of right-fit.  That right-fit is determined by just a few people, based on the limited evidence of your resume plus a few interviews.

To make yourself right-fit for your next opportunity, first understand the nature of the contest.  To get insight on the contest, do a little analysis of the published requirements.  You can use these 20 right-fit qualities.  Match these against any written job requirements you may have received via email from a recruiter, or you found on an online job board. 

Consider each of the qualities.  Circle the number of any which are prominent - clear and/or near the top of the list - of job requirements.  Put a check mark beside any qualities that seem most essential to the described job.

1. The requirements describe specific tools (brand names of software, databases, report writers) and possibly even version numbers.
2. The ability to work under pressure and to meet strict deadlines is emphasized.
3. You must be able to work as a team member.
4. Presentation skills, interaction with upper management, or leading JAD sessions are essential to the job.
5. A flexible schedule and frequent overtime are likely to be required.
6. You must have exceptional verbal and written communication skills.
7. You will represent the company in client meetings, and must present a good image.
8. The requirements specify more than five years of proven technical skills.
9. You must have demonstrated ability to take risks and produce positive results.
10. The successful candidate must be willing to travel and/or to work evenings, nights and weekend hours.
11. Proven experience with stated methodologies, strategies and/or processes will be essential.
12. You must often work independently to accomplish a goal.
13. Show ability to adapt to changes in business processes and goals.
14. Critical skills include team leadership and/or achieving consensus on any issues which arise.
15. Given limited resources, you must be able to quickly arrive at a technical solution.
16. You must be able to influence others who have varying opinions.
17. Professional appearance and/or outgoing personality are essential.
18. You must have proven results in delivering multiple and varied work products.
19. You will be accountable for achieving business goals.
20. This is an entry-level opportunity to develop substantial technical skills.

Now look back at the circles and check marks.  Choose the top three or four items.  These reveal the nature of the contest.  Match the numbers to those in the list below.

When you know the type of contest, you can more effectively prepare.  Prepare well to increase your chances of winning!

ITEMS	TYPE OF CONTEST	HOW TO PREPARE AND WIN
1 and 11	Game Show	Mention your matching technical skills early and repeatedly on your resume.  Work them into a brief "elevator speech".  Bring a portfolio that proves your skills and knowledge.  Be prepared for technical questions in the interview.
2 and 12	Race	Your resume should highlight any projects you completed within strict time and dollar budgets.  Prepare yourself to describe a few in brief and always positive stories.  At the interview, show energy and determination.
3 and 13	Scavenger Hunt	Include team projects on your resume.  Be ready to describe your individual contribution to collaborative school and work projects.  At face-to-face interviews, listen and specifically respond to the interviewer's questions.  Keep the discussion focused, but friendly.
4 and 14	Run for Office	Let your resume show your interest in leadership.  Feature projects in which you held a critical role in achieving success.  Include one or two of these in your "elevator speech".  Be ready with the firm but not crushing handshake, smiles and eye contact through the critical first minutes of any interview.  Offer a handshake and friendly farewell at the end as well.  Ask for the job.
5 and 15	Battle	Your resume must prominently show work delivered on time and within specifications.  Describe the positive results as well - especially any expenses saved and revenue earned.  Give the compelling reasons for each time you were promoted.  Bring ample copies of a concise, well-organized portfolio to the interview.  Take the initiative in leading your interviewers through it.
6 and 16	Debate	In your resume, document any occasions where you identified a solution, and then participated with others in its delivery.  Be prepared for standard interview questions ("Why should I hire you?"; "How would your friends describe you?") and for technical questions as well.  In the interview, keep answers brief and maintain a friendly, confident appearance.
7 and 17	Pageant	Without overlooking content, check your resume for aesthetics like clean fonts and balanced white space.  Visit the company website and have good knowledge of their business.  Dress for success at the interview, consistent with the way managers would present to a new client.  Be ready with relevant questions so the conversation never falls to awkward silence.
8 and 18	Weightlifting	Your resume should reveal growth, both technically and in responsibility.  Prominently list matching experience with required tools and techniques.  Include specific version numbers and state your level of expertise.  Be prepared to explain any gaps or direction changes.  Also be prepared for technical questions.
9 and 19	Texas Hold 'Em	Each time your resume mentions a project, it should also list quantitative results.  In your "elevator speech", include an example of how your controlled risk produced a win for your previous employer.  Prepare for the interview by learning as much as possible about the organization and its current projects.  Be confident, concise and friendly.
10 and 20	Auction	Emphasize the value you place on achieving goals.  Your resume should highlight each new experience that added to your skill set.  In the interview, answer questions promptly and ask for feedback.  Show sincere interest in the company and its goals.

You can prepare for any or all 10 contests, but pay most attention to the details of those which match the job requirements.

Be the right fit. Win the job!

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.

Metadata will rock your world

Today, most places you look, metadata is scarce.  Try to find definitions within most corporate databases.  Ask to see the data dictionary.

When you find that isolated corporate application built with a data dictionary, other applications in the same environment duplicate the data, and have no metadata.

These conditions are true at every scale.  Small businesses have less need and fewer resources to invest in organizing their data.  They find it cheaper and faster to build scarcely-defined data buckets, lacking constraints.  As these businesses grow, acquire other companies or merge into major corporations, their legacy applications still work and so remain isolated.  Within most enterprise architectures, undefined, unconstrained, duplicate data limits knowledge available for analysis, while constraining daily operations.

Metadata has only begun to surface within and between businesses.

It surfaced in 1996 when two Sanford students were convinced that the knowledge within the internet could be better accessed.  They devised a scheme for cataloging and searching it.  This led to Google.

At the user interface, Google is a rectangular box and a push button.  Type anything into the box, and Google searches its metadata and retrieves web pages for you, really fast.  By providing this free service, Google runs a 21 billion dollar advertising business.

The Google rectangular box holds nothing but metadata.  Their metadata is the largest information catalog that ever existed.  It tells what information exists on which web pages.  It keeps track of how the information is accessed, and from where.

Look near the top of any page on Amazon.com, and you will find a similar rectangular box.  Step back from your computer, and drive through any city looking for the vast warehouse that holds every Amazon.com book, DVD, groceries, toys, appliances, clothing, and office supplies.  There is no such warehouse.  Amazon.com uses metadata to sell merchandise, quickly, abundantly, from warehouses worldwide.  Because they profit from using metadata, they don't mind selling from warehouses of other companies.  In fact, they encourage their customers to re-sell books after reading them, along with outgrown toys and anything else with market value.

Wikipedia.com has a rectangular box.  When you type just about any noun (person, place or thing) into that box, Wikipedia retrieves an article.  Last year, it provided about 2.5 billion page views per month, governed by a non-profit organization with about 7 million dollars revenue.

Where is the rectangular box in your organization?  Where do your leaders find accurate strategic information as quickly as Google finds 9,500 yackadoos? - as conveniently as Amazon.com finds 184 varieties of potato peeler? - and as thoroughly as Wikipedia digs up Machu Picchu?

Most organizations - large and small - lack the metadata to power such a rectangular box.  When its time to define a "customer", someone writes a definition and that information is distributed to a few departments, read and understood by only a few employees.  When its time to build a new application, the wheel is re-invented, a new silo is constructed and the metadata is left for later.

This will change.  As the pioneering Google, Amazon.com and Wikipedia have abundantly shown us, there is gold in constructing a means of organizing corporate data.  One day, this will be the corporate norm.  The standard.  Just as little bookstores with jumbled shelves have been replaced by big bookstores with workstations where any book can be found, counted, priced, sourced and described (that's all metadata)... I.T. shops lacking that kind of organization will one day acquire it, or will be acquired.

One day, a common taxonomy will link I.T. shops across lines of business and across international boundaries.  The well-paid wheel re-inventors and silo constructors will have moved on to other work.

Business users in cubicles, conference room and corporate offices will have that little rectangular box which holds all the information that they need to make their organizations prosper.  Metadata will have reshaped their world.

Feel the rumbling underfoot, just a little?

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.