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 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.

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.