How to Be Awesome At Being A BA

 

Chances are, if your career has landed you in the role of a business analyst, it was probably by accident.

Even if it wasn't, I'm willing to make another guess: You've probably never received any sort of formal BA training, and you're wondering if there is even such a thing.

How did I do?

The roles of BAs vary, for the most part, based on the size of the company: Simply put, BAs seem to do more in smaller organizations. But in any sized company, I believe that I have observed some traits that are consistent across the most skillful and, dare I say, awesome BAs that I have had the pleasure of meeting.

So, instead of looking at any methodologies behind business analysis (there's plenty out there already), in this article I intend to examine those characteristics of the awesome business analyst, and point out some specific tools and resources that I guarantee that you can use to make yourself awesome (or awesomer, as the case may be).

In a nutshell, the role of the business analyst is to capture, organize, and communicate large volumes of information.

Let's start with the capturing part.

Capturing

To record information, you use a computer: You know, that thing you sit in front of all day? How good are you at using it, really?

Learn how to type faster.

I know this sounds like a no-brainer, but it astounds me how many people still hunt and peck for letters on a keyboard. At the very least, at this point you should know how to type without looking at the thing. If you're not there yet, take lessons, or just force yourself not to look at your keyboard; that's how I learned (and look how I turned out!).

Use technology to take shortcuts.

...after all, that's what technology is for, isn't it?

Start by spending less time with your mouse. What you don't realize is that you're constantly costing yourself time by using the mouse, especially when you don't have to. Your mouse has two buttons, and your keyboard has, what, a million? Those magical keys can do so much more than simply put letters on the screen!

Windows has a ton of built-in, time-saving keyboard shortcuts that you may already be using, that work in pretty much any application you use. Here are my favorites:

* First, there's the old standbys: Copy (Ctrl+C), Paste (Ctrl+V), and Undo (Ctrl+Z).
* Then there's some for getting around Windows faster: Switch Between Open Programs (Alt+Tab), Show Desktop (Windows+D), Run (Windows+R), Open Explorer (Windows+E).

Want more? Here's a rundown of keyboard shortcuts for Windows.

The tools you're using also have keyboard shortcuts of their own; by all means use them. You can typically find a list of time-saving key combinations in the User Guide.

If you have the ability to, there's also some tools you can install that will speed things along even further:

* Use a text expander. Texter is one such tool. What this little beauty of a utility does is run in the background as you use other applications, and when you type something like "tss" it expands it to "The System shall", or whatever you tell it to. The beauty of it is that it works in any application where you type, be it Word, your email, your web browser... or your favorite requirements workbench.

* Use email templates. Chances are you probably bang out a lot of emails that look similar to one another: "You'll find the answer here...", or "Talk to the following people about these areas...". You can use Texter, or Outlook Templates, or even just keep a text file handy (accessible via a shortcut) with a bunch of common responses, to do this. The trick is to not sound like a robot, so be sure to add at least a bit of personalization and warmth to it.

* Search first. Don't trust whatever filing system you came up with yesterday, as that may no longer apply today. While Outlook's email search capability has improved over the years, it's still not as lightning-fast as Xobni, or Lookout.

In general, what I'm recommending is to look at the repetitive tasks you do every day, and think about ways you may be able to automate them, or at least ways you can get faster at them. (So, basically, do for yourself what you already do for your business!)

Organizing

As you capture all that information, in all of its various forms, you also need to organize it, so you can later communicate it effectively. But, let's take care of something, first:

Organize yourself.

Your job requires you to talk to a lot of people in order to discover your business's needs, and then to communicate them. Unfortunately, this requires time-consuming activities such as those dreaded meetings, and frequent distractions such as constant stream of emails - the combination of which prevents you from actually getting your real job done.

Combat this!

* Manage your time. In particular, guard that time wasted by meetings. Block off your calendar for meetings with yourself. Ask why you end up in the meetings you get invited to. By the same token, don't waste other people's time: Provide an agenda, a clear reason as to why you needed certain people to attend (make it clearly optional for everybody else), and aim to end the meeting as soon as you can while still achieving its goal.

* Reduce distractions. This is probably my biggest pet peeve: It's time to turn off those vibrations, or blasted little pop-ups that let you know you have a new email every five minutes. There's no reason why you need to know about every email when you can't act on the majority of them right away; you've got your job to attend to, remember? Other tricks such as email filters, and BlackBerry Contact Alerts help to weed out the important people from the noise.

* Manage your tasks. Adopt a task management system. Once you learn a process, it will help not only your professional life, but also your personal one. I'll defer to an article I wrote on my blog about this. Once you've done this, read, and apply the principles of Getting Things Done.

* Manage your inbox. Adopt a dead-simple filing system, such as The Trusted Trio, and discipline yourself.

Get good at structuring your thoughts.

When considering what groceries to buy, you might work through a stream of consciousness, as follows:

"I need spinach, and a couple pounds of cheese. My Mother also really likes that frozen casserole we had the last time she was here. What was it called again? I'll probably recognize it when I see it. Hmmm. On second thought, I probably don't need so much cheese..."

Instead of writing it out that way, you take the time to list each item out in a nice, orderly list. Why? Because it's easy to read, and to check off (process) as you make your way around the aisles. Yet, a lot of communications we receive really is just a stream of consciousness.

How can you make this sort of structured thinking a habit? I believe that it can start with improving the communications you spend the majority of your day writing: Your email.

Here are some of my suggestions for composing better email messages:

* Include the thing you want me to make sure I see at the top of the message.
* If you have several questions to ask, list them out and number them, so I can respond to each one easier.
* Clearly list out the actions you want me to perform.

For more tips, buy a book on writing email, such as this one. (I haven't read it, but the reviews seem overwhelmingly positive! If you have any to suggest, feel free to mention them in the comments.)

Your good email habits are bound to carry over to the other part of your job: Actually writing requirements.

Communicating

Learn to write more betterer.

Outside of work, and your email client, consider spending time writing about something you're passionate about.

Start a blog about gardening. Write about your Lego collection. Tell everybody about that time that thing happened.

You only get better at expressing yourself by writing more.

Learn to network.

Your job is also about making connections and knowing the people in your organization.

Connect to other people in your company via LinkedIn. This is an innocent way of saying hello, without really saying hello.

For those of you who consider yourselves introverts, or are just shy about approaching strangers, I heartily recommend Leil Lowndes' How To Talk to Anyone.

Learn to think in flows.

I'm going to suggest something here that some of you may consider controversial. Are you ready?

Take a simple programming course.

This will, at the very least, get you to start thinking in terms of processes, and breaking down things into a step-by-step, logical series of events. This is a concept that a fair amount of BAs I have encountered have some trouble wrapping their heads around.

Remember that you're a translator, so knowing both the language of the business, and the "language" of your implementers is vital to bridging that gap effectively.

Learn to think like a designer.

In case business analysts don't do enough, they also frequently have to play the role of a designer.

In this area, I suggest reading books on user interface design, starting with The Design of Everyday Things.

Another way to look at design is that of "selling" information: Think through how to best present the data you have, and how to make it look good. To help here, pay attention to things like templates you like, to print advertisements in magazines and the layout of designs on bus shelters; examine the fonts chosen, and the structuring of the information it's aiming to convey.

How Are You Awesome?

I hope you find something in all of this somewhat useful. If you have any of your own tips to offer, please post them below!

Photo by SeeMidTN.com (aka Brent)

 

 

 

 

 

 

For unity's sake, clean up those requirements documents!!!

It's easy enough to tell a story, but what happens when the consumer's comprehension of the story determines how it will turn out. Imagine a book that automatically changes the ending based on the reader's understanding of what the author was attempting to say. Inevitably, no two readers would share the same ending. There would always be differences of opinions and the value of the story could be drastically reduced if the author wasn't extremely precise in what was written.

 The Business Analyst is an author and the ending to the story they write will vary based on how the story is understood. The Analyst sits between the Business Partner and the IT group, and authors a story based on what they understand the Business Partner to need. This story then gets handed to IT and their job is to go and write the ending. As we all know, in this type of story, the ending is rarely what the Business Partner or the Analyst expected.

Although there are many factors that contribute to an unhappy ending, I want to focus in on the topic of unity. As a parent I'm often looking at my kid's room and saying, "For goodness sake, they need to clean this room." When I look at most requirement documents I think, "For unity's sake, they need to clean up this document." Unity is what holds the story together and gives it a clear and precise context. Every story needs context in order for the reader to relate and connect. If the document feels like a scrambled jumble of parts and pieces, the reader will never connect with the story. If they don't connect, they can't provide the feedback that's so desperately needed before IT starts to write the ending.

To accomplish unity in a document you must do the following:

1) Always provide a consistent look, feel, and structure - a template
2) Leverage hyperlinks in the document so it's easy to navigate to related elements - easy navigation
3) Clearly identify how the different elements relate to each other - rich context

The reader needs to understand how a goal is accomplished (Use Cases), how each step used to accomplish the goal relates to the needs of the Business (Business Requirements) and the tasks of the users (User Requirements). How the system steps in the Use Case drive the System or Functional requirements. What UI Mockups should be used for a given step in the process, and so on. When all these different pieces are in unity throughout the document, then, and only then, can the Business Partner drive precision into the story, (via feedback) so that the IT Group can write the most accurate ending.

Although I agree with Chris Gurney's post, "The Big Freaking Document Must Die," until Analysts adopt better tools that help tell a more unified story, via visual simulation of requirements, or at least generate documents with unified content, we're stuck manually creating documents. But keep in mind, especially with manual documents, it's not just about having content, it's about unity of content. Content alone is useless, unified content is easily understood and opens the door to precision. And when the reader is writing the ending, precision is king.

So, for unity's sake, clean up those documents.

Big Freaken Requirements Documents Must Die!

 The typical requirements document is a long, sprawling piece of literature. Within it, one might find a title page, table of contents, change history, complex headers and footers, legalese, confidentiality notices, and, if you're lucky, maybe even requirements.

Its length is probably, primarily due to the fact that it tries to be everything to everybody. But, the problem is that this big freaking document isn't read entirely by any single person, except perhaps by the person who wrote it in the first place.

Every company refers to these documents as something different: BRDs, PRDs, BPDs, DRDs, SRSs, FRDs... or any other number of acronyms that people have forgotten the meaning of. OMG! To complicate matters, each department, project team... heck, person, uses their own template; so, one BRD does not necessarily equal another. But, who can blame the people that write these things? There are deadlines to be met, and all templates do not accommodate the needs of the many. Adjustments are made.

But luckily, from where I sit, I believe that the typical, mega-honking requirements document is nearing its death. And the good news is that this eventuality is closer than most people think. Don't believe me? We have actually witnessed this happening at some of the more progressive companies that we've worked with.

Let's walk through the reasons why I think these documents exist, and the problems that lie within.....

 

Click here to check out the entire article posted on Business Analyst Times!

Tools for the Business Analyst? Better Late than Never

In the 90's the Standish Group with their "CHAOS Report" quantified the alarming rate of project failure in the software development industry and the associated costs businesses incurred as a result. It also identified poor requirements as a primary contributing factor. Over the last twenty plus years, the CHAOS Report has consistently told us that the project failure rate has not dramatically improved and poor requirements continue to play a leading role.
RM or Requirements Management was a term coined to cover the entire problem set at the time and a push was underway to convince development organizations to stop relying on office automation tools (Word, Excel, PowerPoint, Email) to document and communicate their project's requirements throughout the SDLC. Solutions such as DOORs, RequisitePro, and CaliberRM were introduced to the market as RM repositories. Textual requirements were typed directly into these tools instead of a Word document and they could be used to track each requirement's priority, status, due date, risk factors, etc. Edit histories were automatically recorded and trace relationships could be established and maintained between requirements for more meaningful analysis of both requirements coverage and the impact of proposed change. The focus moved from the document to the individual requirements themselves.
However, this early RM approach assumed the correct requirements were entered into the repository to begin with and that was a false assumption. As the old adage goes "garbage in, garbage out". It doesn't matter how well you version, baseline, trace requirements to each other. If the starting requirements are incorrect, incomplete or missing altogether then the team will surely encounter some unpleasant and very costly surprises further down the line.
RD or Requirements Definition was born of the acknowledgement that requirements had to be discovered and defined properly before they could be managed forward through the SDLC. As you might expect, solutions appeared in the marketplace to help facilitate the accurate definition of requirements: DefineIT, SteelTrace, and Profesy (later renamed "Requirements Center").
Additionally, there was focus placed on the visualization, prototyping, simulation of requirements to enable true validation that requirements are correct, complete, and aesthetic concerns, important to the business users, were not left to developers to figure out. Again, solutions like Apptero, Simunication, and others appeared on the scene.
Today the industry knows this collective space as RDM: Requirements Definition & Management and it includes visualization/simulation. However, the desired goal is not a collection of standalone products each addressing their own specialty but rather, a single integrated solution that addresses all of the challenges analysts face day to day, effectively becoming their workbench.
Developers have had their IDEs and integrated source code repositories for decades. Likewise, QA has had their test management and execution platforms for years. Finally, emphasis has been placed on the intrinsic importance of requirements and getting them right and the BA community will get the attention they deserve in the way of holistic solutions catering to their needs as a defined profession. It seems we're the last in line but better late than never.

 

Subject Matter Expertise - Take Your Medicine Wisely!

We've all seen the drug ads with the picture-perfect family playing Frisbee with the dog on the beach and the narrator telling us how your symptoms can be wiped away and usher in the dawn of a whole new healthy and contented lifestyle. Then the narrator becomes monotone as he reads at warp speed through a long list of pre-existing conditions that exempt you from taking the drug. Yes these drugs can be very beneficial but only under certain circumstances and in certain situations. If you take the drug outside of these circumstances it could actually cause more harm than good. I have a similar answer for people who ask if it's good for a business analyst to have subject matter expertise. In certain situations it can be a great asset, but in others it could actually be harmful.

The case "for" having subject matter expertise is pretty straight forward. The analyst doesn't have to be educated about the domain and can leverage his or her experience in the area and previous lessons-learned to the project's advantage.

There are occasions where it can actually work against the project's best interests. More than once I've seen subject matter experts who cut short the analysis that should be performed because they "think" they know the answer based on previous experience. Sometimes they're right - but many times they're wrong. In some of these situations I've also seen others on the project hesitate to challenge because the subject matter expert is supposed to be - well, the expert.

For a skilled and inquisitive business analyst to enter a project without subject matter expertise can actually be a benefit. Non subject matter business analysts have an open license to ask the so-called "stupid questions" and people have this expectation. These types of questions routinely uncover hidden issues that could have been disastrous later in the project. I've also noticed people can be more with this type of business analyst - possibly because they assume the business analyst knows less about the subject than they do so there's an element of feeling less threatened coupled with an natural inclination to help along "new comers" to the subject.

So should you actually try to steer clear of business analysts with subject matter expertise? Well, like the drug example, it depends. Before considering subject matter expertise, there are far more important skills a business analyst should have like being able to truly listen, facilitate, negotiate, and to have real analytical skills and modeling skills. To this I'll also throw in diplomacy and political savvy. Because vast majority of people I speak with agree with this, and after some discussion also agree that subject matter experience is lower in importance, what I find puzzling is why most ads for Business Analysts list subject matter expertise as the most important aspect of what they're looking for. Here's a sampling of ad headlines I just took from some online boards:

• Seeking strong BA with digital media and online content experience.
• Looking for Business Analyst with HR and Recruitment experience.
• Looking for Business Analyst with Vendor Management experience.
• Excellent Opportunity for ERP Business Analyst.
• Business Analyst - Investment Banking.

Perhaps as the profession continues to mature the key characteristics of what makes a good business analyst will become better known and sought after.

So if you're going to take subject matter expertise, here's my prescription:

• Before considering taking Subject Matter Expertise you should already have: listening, facilitating, negotiating, diplomacy skills, analytical skills, modeling skills and political savvy.
• Only take Subject Matter Expertise in combination with humility, true listening, and the liberal asking of ‘stupid' questions.
• Use the effects of subject matter expertise to probe more deeply, as a source of additional questions, and to help validate what you discover.
• Never rely on preconceived notions - do your analysis, and leverage your subject matter expertise to do better analysis.

BA World Ottawa - Should the PM be in the BA's business?

BA World Ottawa continues to be a great success with track sessions, panel discussions, and the final panel "throw-down" event.  The day started not with a keynote, but instead a series of round-table discussions on current BA Topics.  I think this is a great change-up to the traditional opening, is a wonderful way to initiate new connections, and a terrific way to kick-start the grey-matter first thing in the morning being an active participant rather than in listen-only mode.  

I was fortunate enough to moderate a round-table discussion on whether PM's should be doing BA-focused tasks.   The table included a wide variety of roles to my surprise.  There were of course BA's but also QA professionals, project managers, and even a trainer.  What emerged was a general concensus that the PM should be focussed on 'process' execution to drive the initiative while the BA needs to be focused squarely on what is to be built (as expressed by the requirements) and why (mapping to business objectives). 

Of course these two things are connected at the hip and you need to have very effective communication between the roles, but in essence each needs to focus on these two distinct aspects. The experience of the BA's at the table, each of whom had experienced a PM getting too far 'in their business' at one point or another, was that it happened mostly with new PM's or PM's who were insecure in their position and felt the need to micro-manage as opposed to simply being the result of poorly documented roles.   Another interesting experience was one whose company had a core group of BA's but would bring PM's in from the outside for each new project.  This meant that the subject matter expertise would reside with the BA and thereby limiting a PM's ability to go too far into BA tasks, and arming the BA with the information and knowledge needed to effectively 'push-back' on PM's who went too far.

All agreed that inter-role communication is one of the biggest sources of error on software projects.  Based on this it was proposed then that the ideal situation is when the PM and BA functions sit with one person so that there should be no communication issues.  One argument against this was put forth by another BA at the table who currently has a very good relationship with their PM and finds their ability to challenge each other on almost every aspect of the requirements and process would be lost if one person was doing both jobs.

There are clearly pluses and minuses to each arrangement and by the end the group felt that while each should focus on their core tasks (PM-process; BA-what&why) it would be more a function of the particular individuals involved and their ability to communicate and collaborate more than any other aspect that would determine how far they 'crossed the line'.