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.

The development team should trust a BA; this was the first lesson that I got from a senior BA. When I asked him how to do it, he told me that you have to figure that out for yourself there is no proven formula. Some of the things that I tried and how they helped me in building a good rapport with the development team.

• Interact with the developers regularly and keep asking them if they have any doubts. The idea is not to overdo it as they may get a feeling that you are trying to judge their work. Keep it simple and just make sure that they know you are there if they need any clarifications in the requirements.
• Make sure you run the development team through the requirements before they start with the implementation. Do it on module-to-module basis, plan with the Project Managers and Team Leads. Make sure you keep these sessions as informal as possible and try to make them understand the business pain points rather than teaching them (as they may switch off).
• Encourage the team to approach you for any clarification in the requirements. When they approach you make sure you clarify their issues or get the issues raised to correct person, if you are not the right one.
• It is a good idea to explain the business side to the developers and also let them know about the domain, as you have that knowledge. Have these talks at non-work timings like lunch, coffee or while traveling. Make sure you don’t come out as a person who is bragging about his knowledge but as a person who is genuinely helping. Keep it honest; if you are not comfortable don’t try it.

I tried these things and they helped me immensely in building a good relation with the development team. Do let me know what works with you and how you achieved it?

We’re not strictly tech and we’re not strictly business. The definition of what we do is usually written in semi-tech language (we write requirements). But how do we write those requirements, what makes us different? How do we see things and why do we see them in the way that we do? What is the potential of the Business Analyst profession? What do senior managers want that causes them to listen to us? How do we move from Business Analyst to Business Architect? How do we advance ourselves in our positions and advance the profession as a whole?

Let me define the difference between an analyst and an architect. The differences are subtle but I will try to define the three most critical as I see them.

- A Business Analyst reports to developers or an IT project manager. A Business Architect reports to managers or senior managers who may be business or IT but are independent of the project.

- A Business Analyst documents requirements as defined by users. A Business Architect documents and may define a business strategy using requirements provided by the users.

- A Business Analyst operates within the confines of a predetermined technical architecture. A Business Architect is a part of the decision making process to define the technical architecture.

A few more things:

- An Architect is considered a neutral voice and because of that will make more critical decisions than an Analyst.

- An Architect must have the ability to think in both a strategic and tactical manner whereas an Analyst is normally tactical.

- An Architect must be cognizant of enterprise strategies whereas an Analyst is normally concerned with specific projects independent of enterprise strategy.

So we see that each type of “BA” is necessary. How do you become the best BA you can be? Or how do you move from Analyst to Architect? Hopefully I can provide some tips. If this interests you the next few posts will concern listening to the needs of the business in order to become the one who assists in driving out the business strategy – if that’s what you want to do.

Until then – Dum Spiro Spero! (Look it up on Wikipedia)

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.