Eight Competencies a Business Analyst Needs to Know


Every year, organizations around the world face startlingly high project failure rates. Some research has shown that less than 30 percent of software projects are completed on time and on budget—and barely 50 percent end up meeting their proposed functionality. If you’re a big league baseball player, failing five to seven times out of ten will get you an endorsement deal and a spot in the Hall of Fame. But, for the rest of us, these types of failure rates represent billions in cost overruns and project waste.

In 2005, ESI International surveyed 2,000 business professionals to try to find out why projects fail. The answers were numerous and varied and included such common thorns in the side as inadequate communication, risk management and scope control. But of all the answers, one showed up more than any other. Fifty percent of those surveyed marked “poor requirements definition” as their leading project challenge.

Failing to properly and accurately define requirements at the very beginning of the project lifecycle points to a distinct lack of business analysis competency. The role of the business analyst is an important one, and, sadly, one that is underutilized by many organizations around the world. In essence, a business analyst acts as a translator or liaison between the customer or user and the person or group attempting to meet user needs. But, that’s just speaking generally. What about the specifics?

Below, I’ve put together a list of eight key competencies that every business analyst—or every professional performing the duties of a business analyst—should possess. I’ve included specific emphasis on tasks associated with junior, intermediate and senior business analysts. If performed effectively, the items on this list could save organizations millions.

Competency #1: Eliciting Requirements

A major aspect of a business analyst’s job is eliciting and documenting user requirements. Requirements can be conditions, functionality, products or services for internal or external use. Requirements are needed by a user or client to solve a business problem, and they’re tied to the needs of business rather than the constraints imposed by technology. Business analysts spend time gathering requirements not because they enjoy it, but because it’s the most effective way to help organizations understand the challenge at hand before trying to propose the solution. Think of it as printing a Google map before hopping in a rental car and hitting the gas pedal.

The techniques necessary for capturing requirements are often referred to as elicitation. Depending on an individual’s level of competency and the situation, the type of elicitation techniques applied will vary.

Competency #2: Creating the Business Requirements Document 

A business requirements document (BRD) is an exhaustive written study of all facets of regulatory, business, user, functional or non-functional requirements and provides insight into both the as-is and to-be states of the business area. The BRD is a detailed profile of primary and secondary user communities and should come directly from the requirements the business analyst has already gathered. Once the document is completed, the business analyst and the client or user should meet for a formal review to approve the BRD. Next, the document should be shared with the rest of the development team, including the project manager.

In creating the BRD, the senior business analyst will be largely responsible for defining the various sources for requirements as well as the placement and relevancy of those requirements. For example, senior business analysts may identify such items as the project charter and vision, business case, requirements work plan, vendor request documents and, potentially, business contract documents. They may also work with the project manager to define the project and product scope. Any requested changes to any area of the BRD—before or after work has begun—must be carefully reviewed by the senior business analyst. An intermediate business analyst may work with the client or user, discussing changes necessary to gain approval. And, the junior business analyst is expected to assist the intermediate and senior business analysts with the organization and the actual documentation.

Competency #3: Structured Analysis

Structured analysis refers to the art of modeling. In business analysis, modeling is used to support and enhance text-based requirements, help identify and validate requirements, document and communicate requirements and, finally, organize information into coherent ideas. The most common types of business analysis models are business models, process models, data models and workflow models.

When modeling, junior business analysts should be able to easily identify a variety of modeling techniques and to create simple models based on information given to them by their intermediate or senior counterparts. Examples include organizational charts or business interaction models. An intermediate business analyst may begin to develop such models as entity relationship diagrams, functional decomposition diagrams and ever-popular use case models. The senior business analyst takes the models from the junior and intermediate business analysts and examines the as-is state in order to create the ideal to-be state.

Competency #4: Object-Oriented Analysis

Within a business context, an object model is an abstract representation of a system’s process and data requirements based on decomposing the system into units—which are called objects. Each object encompasses the data and operational characteristics of one business item. Object-oriented analysis is particularly important as a business planning tool to depict the hierarchy of business functions, processes and sub-processes.

Those looking to master object-oriented analysis should be competent in structured analysis. Object-oriented analysis requires a clear understanding of both the process and data modeling techniques, including functional decomposition.

Junior business analysts may get involved in the functional decomposition of the as-is state of a project, including forming a simple model of this state. From this model, an intermediate business analyst may consider developing activity diagrams to further clarify requirements. With diagrams in hand, a senior business analyst is likely to begin designing the to-be state during one-on-one interviews, group interviews and the documentation process.

Competency #5: Testing

The first thing to understand about testing is that the term applies to several different levels of work. First, business analysts are looking to test the products to validate whether the requirements have been met. Test scripts, test plans and test scenarios are based on the as-is state as well as the to-be models.

The second level of testing is more familiar and consists of testing the functionality of the physical product. This ensures that the desired state has been reached based upon user acceptance.

Junior business analysts are often not heavily involved in testing, acting usually as assistants. The intermediate business analyst, however, might take on the role of designing test cases and reviewing the results. The senior business analyst acts as an overseer in the testing phase. His or her job is to see the project to fruition and manage quality.

Competency #6: End-User Support

It’s a common misconception among project teams that the project ends when the deliverable is completed. Not so. Business analysts should be aware that end-user support after the product is delivered is a vital part of the process. Also, it’s important to note that the role of the business analyst is not to act on behalf of the training team, but to complement the training team’s efforts with their knowledge of the business requirements.

Ideally, a junior business analyst will work with end-users in the post-deployment phase to clarify any high-level questions that need to be addressed. An intermediate business analyst would work closely with training managers and facilitators to define requirements to deliver the training support the business needs. A senior business analyst would assess and evaluate all feedback from his or her team members, those individuals involved in the deployment of the product and any pilot or “test” groups to ensure that the requirements necessary to correct any issues are addressed in future releases, iterations or versions of the product.

Competency #7: IT Fluency

How much IT knowledge is enough for a business analyst? The answer is a little complicated because it depends on the individual project and the industry vertical in which that project exists. Just because an individual is fluent in a given technology does not automatically qualify him or her as a business analyst. In theory, a great business analyst should have the wherewithal to understand which resources are appropriate to help define and validate requirements and specifications within a given project and product scope.

A junior business analyst would need to have a clear understanding of the IT products and tools necessary for the business to function. An intermediate business analyst may understand interconnectivity and relationships between the tools and system architecture and information architecture. A senior business analyst will demonstrate his or her IT fluency across an industry vertical. He or she may also have a very clear understanding of how different IT products are related, interface with and connect to each other, as well as the positive or negative effect they may have in a given situation.

Competency #8: Business Process Re-Engineering

Considered the “big-picture thinking” of business analysis, business process re-engineering (BPR) is a rapidly growing part of business analysis. In fact, lately, many companies have been grouping business analysts around this specialty and developing teams of process analysts. This is the phase in which business analysts seek out and identify problems and opportunities. BPR uses a variety of modeling techniques in order to look at the bigger picture while still thinking tactically.

BPR is a competency in which all levels of business analysts must be highly skilled. The junior business analyst’s responsibility is often to identify, using various modeling techniques, possible areas of improvement. The intermediate business analyst might have the job of walking the client or user through each step of the process, examining individual tasks that could potentially be improved. The senior business analyst begins to actually make suggestions for improvements.

Where to From Here?

A list of competencies in an article is just a list of abstract ideas. To put them to work in real life, organizations should begin implementing each competency as guidelines for all projects. Once this is accomplished, it’s essential to formalize the business analyst job description and begin developing the suite of skills in each business analyst through comprehensive training and internal mentorship. There are a number of organizations around the world that offer such training. My advice: find the one that fits your organization’s goals and objectives and get started immediately. 

Author: Glenn Brûlé, Director of Client Solutions for ESI International, has more than 18 years of experience in many facets of business, including project management, business analysis, software design and facilitation. He is former Chair of International Business Development for the IIBA, and is a frequent speaker at professional association meetings and conferences around the world, including ProjectWorld/World Congress for Business Analysts and IIBA events. At ESI, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. Glenn's background as an educator, communicator and business consultant has served him well through his many client engagements across various industries, including financial services, manufacturing, pharmaceutical, insurance and automotive, as well as government agencies.

Glenn has authored numerous articles on business analysis and was instrumental in the development of two ESI white papers: “Eight Things Your Business Analysts Need to Know – A Practical Approach to Building and Improving Competencies” and “Establishing and Maturing a Business Analysis Centre of Excellence – the Essential Guide.”

Like this article:
  100 members liked this article


manishjaiswal posted on Tuesday, July 8, 2008 2:00 PM
Hi Glenn:

Congratulations for a nice article on BA, but I beg to differ with you. Why?

Your article talks more of hard-skills of a BA than softer skills, much needed for success. Most of the project fails, if they fail (50% according to you) is because there is always an expectation mismatch between:

a) Client & the IT Vendor
b) Project Manager & the BA and last but not the least
c) BA and the Development Team

The Client feel (or is being convinced) that automation or IT solution is the best way to get operational efficiency / control and sure mantra for cost cutting / growth. Every debate, every one says IT is just an enabler but in reality, IT is a business now. Larger the project better it is for the Tech Team and the organization that is managing it. Challenge remains, how to manage it well.

Having said that on general terms, I agree with you 100% that a BA is very important link in finding durable IT solutions for client's business needs. A satisfied customer means repeat project. So, the stakes are high to search for a right Business Analyst (BA).

On Macro level, success of a project depends on 6 Right Things:

1. Right Management motivation to bring change Top Down. It is never bottom-up
2. Right and Present identification of challenges where IT solutions is sought. Clarity is the key.
3. Right IT Vendor. An ERP specialist can’t deliver Insurance Projects
4. Right Technology and Solution Architecture
5. Right Business Analyst & PM
6. Right Development Team and Testing Team

We can go in details about all of them some other time, but let me dwell upon Point 5, which is the center theme of your article i.e. Right BA

A successful BA should have 6 Skills to deliver his/ her job :

1. Business Skills: A BA is not scaled-up version of a Programmer. A Programmer even with 20 yrs is coding / programming experience may not graduate into a successful BA. Business Analyst should have worked with Business some time in his past career because that helps him / her connect with Stake-holders and SME (Subject Matter Expert), essential to deliver his job & KRA (Key Results Area). Capturing MACRO business view and vision is important.

2. Domain Skills: BA’s are like Doctors who must build an expertise in a particular field say Retail / Insurance / Banking / ERP etc. ‘One size Fit All’ does not help in successfully completing the BA role or for that matter in complete the project.

3. Management skills: In present world Projects are complex with huge dependencies on different People, Processes and Projects. BA with management skill plays an integral part in aligning the resources quickly. BA is perhaps the only constant connection between Tech Team and the Business Team while the project is ON; hence he / she should be in position to get the work / info out from both sides with ease. Importantly both sides should respect BA for his / her role in managing & delivering the project. Any disconnect in the team is a recipe for sure disaster.

4. Tech Skills: Tools and Technology: As much as BA is supposed to be a great domain expert, he / she should also be very familiar with Technology Terms and capabilities of employed technologies or tools. A BA can’t function without having decent level of understanding of Languages / Architecture / Databases / FOS / SDLC / PLC / SQL & MS Tools.
5. Editing Skills: BA is like an editor of a magazine. He or she should be in position to grasp the business requirements and convert (edit) them into smart and portable manner. Concise, & Correct conversion of Processes help build the IT solution.

6. Project Skills: BA is the second line project manager or the future PM in the team. Unless BA thinks that he / she is a project manager and is working towards it, his / her contribution in the project or with the team will not be felt. BA should look his role & responsibilities from Scope / Time and Cost (STC) perspectives all the time.

Manish Jaiswal
[email protected]
Vasanth posted on Sunday, July 13, 2008 6:04 PM
Hi ..thanks for posting a very useful article. If somebody could answer me this question , I would really appreciate
1.Being a BA how to manage multiple projects efficiently .
2.As a senior BA , How to allocate the jobs to the other BA's
3.How a BA can groom himself as a PM.
4.Plss post some Smart tips for the Conflict management between BA and PM,Client sides.

I hope these questions will be really good enough for the emerging BA's


email : [email protected]
Tim posted on Tuesday, July 15, 2008 7:15 PM

If you believe that being a BA is just a stepping stone to being a PM then you have it all wrong.
They are two completly different disciplines..if you want to be a PM - then go be a PM
posted on Wednesday, July 16, 2008 6:31 AM
I agree what Tim said that PM and BA, both are totally different streams.
But at the same time i think this confusion lies some where in industry only. Many times BAs report to PM, In other instances software companies shows vertical growth hirerarchy as BA to PM role.
posted on Wednesday, July 16, 2008 6:31 AM
I agree what Tim said that PM and BA, both are totally different streams.
But at the same time i think this confusion lies some where in industry only. Many times BAs report to PM, In other instances software companies shows vertical growth hirerarchy as BA to PM role.
Tony Markos posted on Wednesday, July 16, 2008 7:46 AM

I feel that the BA community really needs to get back to basics! We need to move away from a focus on techniques (SSA, OOA, IT technology) and ask: What is analysis?

Analysis is discovery: In our efforts, are we subconciously largely just validating our own BS by trying to force fit reality into our (initial) limited understanding? Do we as-is model, or just jump into to-be implementation.

Analysis is proper partitioning: How should we "divy up the pie"? Are we highly aware of the need to avoid a forced, artifical partitioning?

Why is it so important to strive to postpone consideration of implementation aspects until the appropriate time?

Only by understanding what analysis really is can we know what we are doing, and can we truely understand the essentials such as what is the significant difference between a use case and a data flow diagram.


nlanzante posted on Thursday, July 17, 2008 9:22 AM
Hi Glenn.

These are great. How do you fit this in with the BaBOK and the Knowledge areas needed there?
Janani posted on Thursday, July 31, 2008 4:52 AM
Hi All,
Great article Glenn! Keeping writing and kudos for your good job!

I would say, the role of a BA is still in the nascent stage and most of the organizations are not clear with the exact job role definition for a BA.

Adding to the article, I feel that the following competencies are required now a day for a BA to excel.

1. Better understanding and application of Project estimation techniques.
2. Working knowledge in different kinds of requirement gathering and documenting Tools and techniques like, Mega Software.
3. If BA's are viewed as the liaison role between the IT and Business Community, then one must have a sound knowledge in pre-sales role. This will make him\her to be in the IT cycle right from the project initiation.
4. Readiness to learn new verticals and able to visualize a Big-Picture!

Coming to growing a BA’career into PM, we must understand and accept as said in this forum; both are different career all together. Also, there is no hard and fast rule in today’s knowledge industry, that a BA can’t become a PM. The question one should ask him\her is, what Goal I m going to achieve in another 5 or 10 years time frame and aim for it to accomplish.

Ideally, I feel one should be looking to have the following career options as BA in long-term (please add to the list if wrong):
Business consultant
Project director
Deliver Manager
Marketing Director
Domain Process Specialist
Or of course a BA is like “Jack of All”. Why not go and start your own Organization? – An Entrepreneur!

Janani (Ganesh)

Anonymous User posted on Wednesday, March 4, 2009 9:08 AM
Anonymous User posted on Tuesday, October 13, 2009 4:50 PM
jkostal posted on Sunday, November 20, 2011 4:44 AM
Hi Glenn,

Thank you for the great article on BA.

Really nice and really helpful!!

Keep it up!

Best regards,
sderosa posted on Wednesday, November 23, 2011 9:44 AM
Thanks Glenn,
a very interesting read indeed. There is one other key competency that I would consider an absolute pre-requisite for a sucessful BA and that would be to have very strong social and interpersonal skills. The traites and personalities of the business comunity and s/w engineers are inherently different and it takes a special skill to bridge that dangerous chasm that often exists between the two. Being able to foster and nurture the collective feeling of partnership and common objectives between them is in my humble opinion one of the core competencies that a strong BA should possess.
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC