Since then I’ve relayed this story many times, only to discover that it wasn’t just my erstwhile interviewer that was unsure of what a Business Analyst actually does. Very often it’s not until a BA has delivered on a piece of work that the business that they are working for appreciates exactly what it was that the BA did for them, even then I suspect they would find it difficult to define exactly what it was that the BA did.

In a cold economic climate when IT budgets are being cut, it’s important that BAs answer the question of what we actually do, after all, our livelihoods depend on it! While our documentation skills and communication style will prove invaluable during the development phase of a project, when fingers are being pointed and vendors are demanding more cash, this will be no good to us if we haven’t won the business in the first place.

We have a very positive story to tell about what we do, but what exactly is it that we do?

Other IT professions don’t suffer from this sort of ambiguity, a project manager, for instance, has several very clear definitions of what they do, my favourite being:

A project manager has overall responsibility for the planning and successful execution of a project.

That’s it, it’s to the point and everyone knows exactly what to expect from a Project Manager and how they are going to benefit a project. On the other hand, we have the definition as stated by the International Institute of Business Analysis (The IIBA®) in version 2 of it’s Business Analyst Body of Knowledge®:

Business Analysts must analyze and synthesize information provided by a large number of people who interact with the business, such as customers, staff, IT professionals, and executives. The Business Analyst is responsible for eliciting the actual needs of stakeholders, not simply their expressed desires. In many cases, the Business Analyst will also work to facilitate communication between organizational units. In particular, Business Analysts often play a central role in aligning the needs of business units with the capabilities delivered by information technology, and may serve as a “translator” between those groups.

It does describe what we do, but it’s not quite as easy to digest as the definition of a Project Manager and you can see why there may be confusion about what the role actually entails. I can hear the business now, ‘Where is the value add?’. It’s a fair question, how does analysing and synthesizing all this information actually help an organisation to meet its goals?

To try to understand more about what Business Analyst actually does, I want to look at each phase of a typical project and examine what is required of a Business Analyst during the life cycle of a typical project:

Initiation

The initiation phase is the period during which the business is feeling some kind of pain and is looking to alleviate the stress that this pain is causing, usually by implementing some form of technology or process based solution.

It’s the role of the BA to clearly identify the problem that the business is experiencing and to map out what a possible solution would look like.

This map is then used to create a business case which shows why a problem is being tackled, how much it will cost to resolve the problem and what benefits the organisation can expect to see once the problem has been resolved.

It is the business case which a Business Analyst will constantly refer back to as the need for changes occur during the course of a project, constantly checking to ensure that a change is in-line with the expected business benefits and to ensure that the business case is still relevant and that something still needs to be changed within the organisation.

Analysis

The analysis phase is the period during which the Business Analyst defines the requirements in detail, stating clearly and unambiguously what the business needs in order to resolve its problem.

During this phase the BA will also work with the development team and, in particular, an Architect, to create the design and define exactly what the solution should look like.

Taken together the design and the requirements will guide the rest of the project, with the testers looking to ensure that the requirements have been met and the developers trying to deliver against the design. It’s the responsibility of the BA to ensure that the design meets the requirements and that the testers are testing the requirements.

During this early phase of the project the BA will expend a lot of energy ensuring that any possible changes that can be identified are identified, while they are easily, and often more importantly, inexpensively corrected. Once the initial requirements are documented they need to be tested to destruction by the BA to ensure that they will actually deliver a solution to the problems that the business are facing.

Development

The development phase is possibly the most challenging phase for a BA. It’s quite normal after the pressure of the analysis phase to sit back a little, safe in the knowledge that both quality requirements and design have been delivered. However, it’s during this phase that a BA needs to step up their meetings with the development team, attending daily meetings and generally being the eyes and ears of the business, constantly looking for deviations in course that would otherwise go undetected.

Testing

The testing phase sees the Business Analyst back on firmer footing. There is a process to follow as the testing team go through the process of testing and identifying bugs and the BA can work with the business to set defect fix priorities.

Disputes between the business and development concerning what is and what is not an off spec defect will often be resolved by the BA using documentation created in earlier phases. The mere existence of this documentation is often enough for one side of the other to admit a mistake and for the issue to be resolved amicably.

Implementation

The implementation phase is not the end for the Business Analyst. It’s the last chance for things to go awry and for goals to be missed.

It’s during this phase that a BA should be conscious of how users are using the system. Are they actually seeing the benefits envisaged in the business case? Do the training materials support the business case?

Looking at each of these phases in this way, a common theme of discovery, validation and verification appears throughout a project life cycle. Given the opportunity to answer the question again, I would define the role of a Business Analyst using the following statement which clearly shows what a Business Analyst adds to a project, a business or an organisation:

A Business Analyst is responsible for knowing what the goal of a project is, how to achieve it, managing any changes to the goal and ensuring that all deliverables are aligned with the goal.

In essence, a Business Analyst is a navigator, responsible for reaching the end destination, in our case that destination is the successful resolution of a business problem. The BA always knows what the end destination is, how to get there and is capable of handling course adjustments as they arise.

In the future, when pitching for work, I’ll be better prepared to answer the question and will have a great story to tell.

I hope you found this article useful. If you have a definition of what a BA does, then please feel free to let me know by leaving a comment below.

In some ways, I feel I have grown along side the profession. Very early in my career the IIBA did not exist, then mid-way in my career it came to fruition, and now as they continue to drive new, and different conversations about the role of business analysis in the modern corporation; I find myself in the same position – attempting to provide leadership in an ever evolving and still much needed field.

I give you this background to give you context to my ah-ha moment as I sat in yellow belt training. To me, it is a rigorous and well tested process for conducting business analysis whether the solution is technology or not.

As we walked through the methodology it sounded curiously familiar to the Enterprise Analysis chapter in the Business Analysis Body of Knowledge (BA BOK). The interesting part is that regardless of what you call the activities, every organization should be doing them and have people proficient in doing them.

The six sigma continuous improvement methodology follows the DMAIC approach which involves:

• Define
• Measure
• Analyze
• Improve
• Control

Define simply has to do with defining the problem. As business analysts” we can use problem statements to define this, we also typically scope a project from a business perspective where you may create a context level dataflow diagram. The purpose of this activity is to simply understand the problem and put some boundaries around what you are trying to solve.

The Measure activity is what really intrigued me and seems to be the area we have been missing in the business analysis world. Many times we present information based on hunches or previous experience whereas with measure, you focus on the facts. This is an extremely powerful aspect of the six sigma methodology. It says, ‘you think there is a problem, but let”s find out if there really is”. In other words, what may at first seem like a problem may not be the problem at all but you can only determine that through gathering metrics. The six sigma methodology recommends things like the time series plot and pareto charts. If you are not familiar with these types of artifacts, I recommend taking a class or at a minimum, googling to get more information.

Analyze again provides power and I think this is an area we are still struggling with as business analysts. In this field, there continues to be this behavior where a solution is decided before true analysis is even done. As an example, on a project I was on, the leadership team insisted the problem was the technology supporting a specific business area. Essentially, they said the technology was no good. After doing a root cause analysis, it was determined the real issues had to do with amount of time it took to make a request and receive a response from the IT team. The technology itself was not the problem, the process around it was.

Improve has to do with offering up solutions. Again, it is important to look at all possible solutions to a particular problem. From the example above, one the solutions was to improve the process and response time for the business from the IT team. Although it may not be widely supported in your organization, I still challenge you to look at a problem from all the angles and provide objective solutions (even if the solution has already been dictated to you). At the very least, you may uncover some additional requirements through your detailed analysis. There are several benefits you will reap from this approach. As you begin to provide valuable information to your leadership, you will become the go-to person. Leadership typically wants a well rounded picture before they make decisions. You can help provide a view of all the possible solutions. In addition, you will be adding to your repertoire of skills and improve your own marketability (which is important in this world of ever increasing lay offs).

Control has to do with monitoring a project all the way through its lifecycle and evaluating the results at the end. This is yet another opportunity for business analysts to take it to the next level. In the last 10 years of my career, we continually fall down in this space. We don”t do a good job of measuring whether we were successful or not. When we don”t do a good job of measuring success, every project begins to look like a failure. If you look at the statistics, there are still a high number of IT projects seen as failures. What are we doing wrong? There are several pieces to the problem (which I will save for another article) but one piece most definitely is not establishing critical success factors up front (another six sigma trick) and then measuring against those at the end of the project.

In conclusion, whether you are a business analyst, business architect, customer engagement manager, client engagement manager, enterprise business analyst, system analyst, project manager, or any other title we can come up with and whether you are a six sigma shop, a BA BOK shop, PMI BOK shop, a Lean shop, or an Agile shop – I hope you are doing these activities. We should all be doing these activities to make our projects more successful.

Even if you are perfectly content in a current technical writing role, most of us can benefit from at least considering other organizational roles and making ourselves marketable for more than one position. Additionally, in many companies, a business analyst position is in a higher salary range than that of a technical writer, making the transition financially appealing.

If you are a technical writer wondering what you might have in common with a business analyst, consider these commonly shared skills and character traits:

• Both roles require diligence in tracking down subject matter experts and locating existing research. Like you, a business analyst must likely develop a roster of experts that he routinely turns to in order to accurately document his work.
• Both roles require strong interviewing and listening skills. A business analyst also has to ferret out details, continually ask “Why?”, and read between the lines to discover what they can’t afford to miss.
• Both roles strongly benefit from close familiarity with the inner-workings of an organization’s products or services.Like you, a business analyst has to know every possible occurrence of a product or service (and know how to document those occurrences in clear and understandable ways).
• Both roles require the ability to write clearly and precisely, including the ability to describe products or functions graphically (such as diagrams, tables, charts, etc.). Indeed, your step-by-step help manual probably requires much of the same creative thinking as a business analyst’s use case diagram.
• Both roles must actively solicit reviews and feedback for their work. Both also require the ability to evaluate and integrate that feedback as appropriate, and to keep detailed records of what changes were made and why.
• Like you, business analysts are sticklers for details. Methodical thinking through every aspect of a company’s business is also part and parcel of a business analyst’s work. Whether a writer is creating a how-to manual, help copy, or requirements, she has to pay close attention to all of the steps and features of the service or product and their potential interactions with other services or products, including the lesser-known ones.

Despite these similarities, becoming a business analyst may not be the right choice for every technical writer. The role of a business analyst requires effective oral presentation skills and no small amount of diplomacy. If the following are a natural part of your work persona, you will want to do some careful consideration before applying for a business analyst’s position:

1. You enjoy working alone most of the time, spending most of your day reading, writing, and editing. Throughout a project, business analysts continually interact with stakeholders, project managers, developers, and even training and customer care.

2. You do not enjoy oral presentations, or explaining concepts to larger groups. Requirements are normally presented to all stakeholders in meetings, and the analyst must be prepared to explain and defend them.

3. You do not want to host multiple meetings to facilitate a project from scope to conclusion. Depending on the company, meetings to define scope, business reviews, usability reviews, and technical reviews are all part and parcel of an analyst’s work.

4. The thought of working to resolve conflicts between stakeholders sounds disagreeable you. Almost no business analyst enjoys resolving conflicts when stakeholders offer contradictory wish lists for inclusion in a requirements document, but such conflicts are often a regular part of the requirements cycle, so one must at least be amenable to addressing them.

If you’re still wondering whether a business analysis position may be a good fit for you, the answers to these three questions may reveal the answer:

(1) Would I enjoy business analysis work?

If you enjoy technical writing, the chances are pretty good that you have the temperament to enjoy business analysis. But one easy way to find out is to volunteer for a small business analysis project within your project management division. (Most analysis groups are overloaded and would be glad for the help.) Go through the entire process of discovery, writing your requirements documentation, soliciting feedback, and getting final approval. Not only will this reveal whether you have an affinity for business analysis, but if you decide to pursue it as a career, it will give you some experience for your resume. Of course, before you can “try on” the role of the business analyst, you may need a bit of training.

(2) Where will I find the proper training and resources to make such a career transition?

You don’t need a degree in business analysis. (I know business analysts with degrees ranging from accounting to English literature.) And although it will help, you don’t need a college course to get started. You will, however, need to familiarize yourself with industry terminology, the process of requirements discovery, and the standard templates for requirements documentation. One industry-acknowledged resource is BABOK 2.0, available here. Although your organization may use slightly different terminology or processes than those described in BABOK 2.0, the basics will serve you well.

(3) Can I become a business analyst in my current industry?

Industry familiarity helps when you enter any job, but particularly so in the role of business analysis, where details are king. If you can make the move to analyst in the industry you’re already trained in, you’re ahead of the game.

If the answers to these questions whet your appetite for business analysis, naturally your next question is going to be, “As a technical writer, how do I market myself as a candidate for business analysis when experienced business analysts may be competing for the same position?” Three ways: (1) If you’re not already doing so, attend your organization’s requirements reviews. Pay close attention to the style of your organization’s requirements as well as the requirements process. Note what you could bring to the table that might enhance what is in place, and be prepared to highlight that in an interview. For example, “I’ve noticed that the discovery stage is sometimes rushed because of our current production schedule. I bring five years of experience of painstakingly documenting our services, and I don’t need a long discovery process.” An outside business analyst candidate is not likely to offer that. (2) Volunteer for smaller analyst projects to gain experience with discovery and writing requirements. (3) Highlight your transferable skills to the analyst position (listed at the beginning of this article) on your resume and in your interview.

Most of my business analysts colleagues and I began our careers as technical writers. We each benefited from our technical writing stints because they afforded us deep, necessary knowledge of our organization’s services. Also, in our technical writing research, we each read numerous requirements documents to help us understand the services we were documenting. Most writers learn to write by reading, so by the time we became analysts, writing requirements was almost second nature. If you decide the move to business analyst is one that is right for you, take advantage of every opportunity in your current role to prepare yourself for what may lie ahead. As far as job transitions go, you’re likely to find this one a natural.

Over the last 20 years, we lost sight of that, as the technology focus began to shift away from IT and toward the business users. The PC dethroned the mainframe and minicomputer. Local-area networks enabled whole companies to run on PCs and servers. The chips powering PCs got more and more powerful, allowing the software to get more full-featured.

Then the Internet hit the big time, and for the past 10 years, we’ve been exploring the many things you can do when you combine people and computers in real-time networks via the Web. But by now, the newness has worn off, and we are back to thinking about that old concern of how to use this stuff to make money. That’s where the business analyst comes in once more.

A lot of IT functions have been outsourced, including data center operations, programming and the help desk. The one function that doesn’t seem to lend itself to outsourcing is business analysis. To effectively look out for their best interests, companies have to analyze their specific challenges and find unique responses to them. If they play the “me too” game of simply doing what everyone else is doing, they will reap no real competitive advantage. Sure, a company can bring in consultants to help and to train its analysts, but it cannot get consistently good results if it outsources the whole analysis function. Why? Because an analyst needs to really understand the company he is working with, and the best way to do that is to live there and be part of it.

I often hear that companies have not developed their business analysis capabilities because they believe that analysts use soft skills that anyone can exercise without much training. I beg to differ.

I was once asked to start up and run a group of business analysts for a company that already had a 100-person IT department. As part of that job, I had to define the specific skills my analysts should have and then put in place a training and career advancement program that would develop those skills. This gave me cause to think carefully about the skills that analysts need and how to develop them.

Here’s what I found:

• Business analysts must be able to facilitate joint application-design sessions that involve groups composed of both business and technical people. They need to actively include everyone in the sessions and encourage people to contribute their ideas.
• They need to do process mapping. This is often a very good way to focus the conversations of a group in a design session and provide a big-picture context in which to place people’s ideas.
• They need to apply data modeling to organize the data flowing through the business processes they are designing. By this I mean logical data modeling (not the creation of physical data models in fourth normal form).

Once analysts have facilitated group design sessions, created process flow diagrams and organized the relevant data into a logical data model, they must pull this all together and create the user interface for the system that will drive the activities in the process flow and handle the data in the data model. This is where analysis turns into synthesis, and where the design of any new system emerges. And as ifall that weren’t enough, good analysts must also be skilled at system testing, user training and even project management.

Soft skills? These are some of the hardest skills to master in the whole IT profession. And companies need good business analysts now more than ever if they are going to thrive in our fast-changing global economy.

In retrospect, I am thankful for the difficulty I experienced in finding a job. As a result of this experience, I have learned how to make myself stand-out, no matter the economic situation. This article will share my top 5 tips for maintaining an edge in a difficult market and landing a job.

1. Know your trade, inside and out. Get back to the basics.
During the time I was unemployed, I found I landed interviews fairly easily. It was sealing the deal that I found difficult. Part of the reason I had difficulty was due to my inability to naturally speak the language of my chosen profession – business analysis (BA). I had been a practicing BA for a good 5 years at this point, but I was shaky about my skills when interviewing. Once I realized this was part of my problem when interviewing, I started to study my own trade. I purchased a few basic books on the subject and read them all. I knew most everything in the books, but it reinforced what I hadn’t practiced during my 8 months of unemployment. This gave me a common language to speak with the manager with whom I was interviewing. It also gave me confidence that I really did know what I was doing – which can be easy to forget when you go through long periods of unemployment.

In the same sense, keep yourself marketable. What sets you apart that makes a potential employer want to call you in for an interview? Future employers search for people that will be an asset to their organization. Demonstrate this by participating in activities that set you apart. For me, I try to publish articles in my field, attend and present at trade shows like Business Analyst World. I also look for opportunities to lead within my organization – like starting a Business Analyst Center of Excellence for my latest employer. These activities demonstrate my ability to lead a team, conduct public speaking, and write. Look for opportunities within your community or current organization to similarly demonstrate how you are an asset to an organization.

2. Interview, Interview, Interview. Practice makes perfect.
Interviewing is a skill you must keep current – no matter how long you have been an employee of an organization. One recommendation I make to people is that they try to interview with another company every year. Interview even if you are perfectly content in your current position. Why? You need to practice interviewing and the best way to do that is to explore different opportunities. You may find that you discover opportunities you would not have otherwise pursued. If you do find that you are in the position to look for a new job, you will be better prepared to face the challenges of navigating through an interview then someone who has not practiced the skills in years.

3. Know your strengths and weaknesses.
Prospective employers will inevitably ask you what your strengths and weaknesses are. These questions usually make me squirm because it is difficult for me to talk about why I am so great (I tend to downplay my own strengths.) To help myself get over this fear, I purchased a book called Strengthfinders 2.0 by Tom Rath. I took a short test and was surprised at the accuracy of the results. The test will produce a top 5 list of your strengths and a strengths profile. While this may seem hokey, it is a great tool to use to make this conversation easier. I would never list my top 5 strengths verbatim from the book. However, I would tell my prospective employer that I am known best for being a great team builder. I would then list examples of how I have used this skill in my day to day work.

Strengthfinders or any similar tool, can give you insight into areas of weakness. Any strength taken to an extreme can be a weakness. Most Websites which offer interviewing advice will tell you that when answering the question “What is your greatest weakness?” you should use this as an opportunity to highlight one of your strengths. For example I could say something like: “I like to build consensus among my team members and can become frustrated when certain team members are antagonistic. To combat this, I would sit down one-on-one with the individual and try to probe the root cause so that the team can address the individual’s concerns.”

4. Keep your resume up-to-date.
This seems like a no-brainer right? I am always surprised by the number of people who tell me they do not have a resume or have not looked at their resume in years. A friend of mine recently found herself looking for employment after 11 years with her company. She started at the organization fresh out of college and had spent her entire career there. She fully expected to spend her entire work life working for this organization. She was shocked when she found herself a part of a reduction in force. She also had never written a resume. She didn’t know where to start. Don’t let this happen to you! Have a current resume ready and available at all times. I also suggest that you have different people periodically review your resume for areas of improvement. This outside perspective will enhance your resume and ensure you are putting your best foot forward at all times.

5. Find a path to success.
During my 8 month period of unemployment, I had many rejections from many companies. Prior to this experience, I had found it fairly easy to land a job. This was a different business climate and I needed to adjust my expectations. After about 6 months of not finding a job as a Business Analyst, I started to expand my definition of acceptable employment. I applied, tested, interviewed and accepted a position as a Metro bus driver for the Seattle metro area. While I had no intention of making this a permanent career move, it did me a world of good. It gave me a success under my belt. I was able to land a job. I was a desirable employee to someone. While I never did end up driving a bus, the experience gave me tremendous self confidence that I had lacked dearly at that point. I used that newly found self confidence to land the perfect job a few weeks later at a large Insurance company as a Senior Business Analyst.

Another approach may be to keep your skills current by contributing to an Open Source project. Grant Ingersoll1, a distinguished contributor to the Open Source project Lucene, recommends you find a well known Open Source project and start contributing. These types of projects often need people to de-bug, test, write small patches (if you know how to code), and contribute ideas. They are grateful for the help. There are similar projects available to Analysts. Eclipse.org produces the Open Requirements Management Framework. Check out their website (http://www.eclipse.org/ormf/project_home/get_involved.php) to see if there is potential for you to contribute. Using this technique allows you to publicly demonstrate your skills and keeps you active in the software community while you continue your search for a job. Who knows, you may even find that this type of work is a good networking vehicle to launch your next career!

In Summary – Stretch Yourself
I have a quote framed on my desk which I take with me to every job. It states: “Twenty years from now you will be more disappointed by the things you didn’t do than by the ones you did do. So throw off the blowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover.” (Katsumi Sugita) Apply this principal to your career. Take a risk. Sail away from the safe harbor and stretch yourself, you won’t regret it.

In the end, each of us is responsible for our own career. We decide whether or not we are an asset to a company. We decide how well we perform. We decide how long to work for an employer. We decide our future. Own it. Live it. Be your best, every day. We owe that much to ourselves.

While I can’t guarantee that following these tips will land you a job every time. I have found they have worked well for me and have helped me stay competitive no matter where my career takes me.