Skip to main content

Tag: best of

Best of BATimes: 5 Characteristics of Effective Business Analysts

“Business Analyst” is not just a title. Is not a job. It is a mindset, a concept and a structured process executed by people in different positions inside an organization. It’s more like, an approach of making the things happen from the realization of business need towards the final implementation.

It’s easy to call yourself business analyst but difficult to be a good and effective business analyst. The field can be great fun, and very rewarding, but you need to be prepared. People who take on business analysis roles typically believe they need three things: skills and experience, a bit of marketing, and an interest in working in a variety of environments. However successful business analysts know they need much more than a technical expertise and specific skills. They need a mindset and a specific attitude in order to serve with the best possible and feasibly way their clients business needs.

What is expected from business analysts can vary widely. And what they actually need you to do can be completely different from what they expect. Business analysis is an exciting, dynamic form of work. You can have a positive impact on your clients and be well paid for your effort. But you have to be appropriately equipped.

To be an effective and successful business analysis you need to continuously develop some specific characteristics.


The first is technical depth. It’s critical that you have the technical background to satisfy your clients’ needs. This means you have experience in a variety of environments. The more breadth of experience you have in your technical area, the easier it will be to apply your skill as a business analyst.

Second, effective business analysts need to understand quickly and accurately what’s happening in their client’s environment. Your power of observation needs to be well tuned. Being able to listen carefully and patiently, observe the behavior of your clients, and make sense of what is happening is very important.

Third, effective business analyst care about the welfare of their client’s business and the clients themselves. You need to be able to put yourself in your client’s shoes and appreciate the difficulties they may be facing or have faced. While what you do may seem routine to you, it probably isn’t routine for your client. You need to appreciate that fact and behave accordingly.




Another important characteristic is emotional intelligence. Often clients will engage you because they’ve had substantial difficulties. They may have a skill shortage, or they may not be sure how to manage what you’ve been asked to deliver. All these conditions create stress. On top of that, you’ll be striving to learn as much as you can as quickly as you can, so you’ll be under stress as well. Dealing with all that requires personal emotional maturity and the ability to assess and deal with the emotional state of your client.

Also, you have to develop the observation and effective listening as a personal characteristic, make recommendations based on sound business judgment, and be patient. As trust builds, the direction your client provides will likely become more reasonable. Work out your contract. Understand your client’s needs and desires, and establish a good relationship with your contract manager, and you could put on your superhero costume to celebrate your success. Observation helps towards a really robust problem definition statement. So as you look at your problem-solving, and you’re getting ready to start pursuing that initial set of ideas, you need to go through that prioritization and pick the highest value one that’s going to have the biggest impact on your overall solution.


Business analysis is performed on a variety of initiatives within an enterprise. Initiatives may be strategic, tactical, or operational. Business analysis may be performed within the boundaries of a project or throughout enterprise evolution and continuous improvement. No matter their job title or organizational role business analysts are responsible for discovering, synthesizing, and analyzing information in order the best solutions to be derived and the clients’ needs to be accommodated in the best possible way.



Published on: Dec 2, 2021

Best of BATimes: The Quest for Good Requirements

The main responsibility of the analyst is the discovery, analysis, documentation, and communication of requirements. A requirement is simply a feature that a product or service must have in order to be useful to its stakeholders. For example, two requirements for a customer relationship management system might be to allow users to update the payment terms for an account and to add new customers.


In this article, we will look at the different aspects of the requirements management process and the lifecycle of requirements.

Definition of a Requirement

A more precise definition is provided by the IEEE Glossary of Software Engineering Terminology and the Business Analysis Body of Knowledge® (BABOK®). Both define a requirement as a

  1. condition or capability needed by a user to solve a problem or achieve an objective.
  2. condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
  3. documented representation of a condition or capability in (1) or (2).

Not all requirements are at the same level. Some might be high level requirements expressed by the business sponsor (e.g., reduce the cost of invoicing customers), others might be very specific requirements that describe a function needed by a particular user (e.g., allow me to click on a customer name and then display that customer’s account history).

The BABOK® defines the following requirements types: business, user (stakeholder), functional (solution), non-functional (quality of service), constraint, and implementation (transition).

Note that these terms are overloaded and often have different definitions within some organizations. For example, a user requirement is referred to as a business requirement in some organizations and a business requirement is sometimes called a business goal or project objective. Functional requirements are also often called technical requirements, detailed requirements, or system requirements. So, it is important to understand the semantics of the terms being used. If in doubt, ask, but don’t assume. In fact, publish a glossary of terms to clarify the meaning of terms that are used by the project team.

Examples of Different Types of Requirements

To clarify the different kinds of requirements types, let’s take a look at some examples for each type.


Table 1. Requirements Examples


The scope of a project refers to the agreed upon set of features that the final product will contain. Scope creep is a common occurrence and it describes the propensity of scope to expand as stakeholders add requirements during the project without regard to its impact on budget, schedule, and deliverables. The project manager must work with the stakeholders to get agreement on the scope.


The stakeholders are the main source of requirements. They have specific needs that the analyst must identify. This is easier said than done: often stakeholders are not quite sure what they need and they often don’t know how to express what they need. It is the analyst’s job to help uncover the requirements of the stakeholders.

A stakeholder is anyone who has an interest in the successful outcome of the project, including project sponsors, users, business executives, managers, developers, clients, customers, vendors, and government or regulatory agencies.

Eliciting requirements is surprisingly hard work. Stakeholders often do not know exactly what they need and eliciting the requirements can be quite challenging. As Fred Brooks has stated so poignantly in his seminal essay “No Silver Bullet: Essence and Accidents of Software Engineering”

“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirement, including all the interfaces to people, machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”

He goes on to say that in a systems development project there are two kinds of complexities that must be managed: accidental and essential (or inherent).




Much of software engineering is focused on reducing accidental complexity, which is the complexity that we add to a project by way of the tools and programming languages that we use. For example, writing code in C is much harder than Java and writing code in Java is much harder than doing a “mashup” with web components.

While it is good to focus on reducing accidental complexity, much of the complexity of a project is rooted in essential (or inherent) complexity. Essential complexity is the difficulty of the problem itself: launching a rocket into orbit is hard no matter what programming language you use. The techniques studied in this book are about managing essential complexity.

Brooks also argues that systems are best developed incrementally. Start with something small that you understand and improve and expand it rather than building the penultimate version at the outset. This approach is the foundation for iterative and agile methods.

Requirements Management

Requirements management is the process of defining and maintaining the requirements that form the agreement between the project team and the stakeholders. A requirements management plan (RMP) is a document that defines the process, procedures, and standards for eliciting, documenting, storing, and updating the requirements. The typical requirement management activities include the following:


Figure 1. Requirements Management Activities

Requirements Management Activities

Requirements management is generally supported by the use of requirements tracking or requirements management tools. There are numerous commercial, free, and open source tools that can be used.

Requirements Process

The process of requirements specification can be broken down into discovery (elicitation), analysis, modeling and documentation, communication, and validation (see Figure 2.) As part of the process, the project team must also negotiate the relative importance of each requirement, so that an appropriate prioritization can be established. The requirements that are considered to be implementable within the allocated time and budget are called the project scope or simply scope.

The project team generally implements the requirements in order of priority, starting with the most important ones. The reason is simple: most projects have limited time and budget and commonly not all requirements can be addressed. By the time we run out of time and money the stakeholders would want the most important requirements taken care of. While this sounds simple, establishing and negotiating the priorities of requirements can often be very difficult and politically challenging. Stakeholders don’t want to prioritize for fear of not getting what they want; the project team does not want an unlimited scope as they know that they likely cannot accomplish everything with the allotted resources.

Figure 2. Requirements Management Process

Stakeholder Obligations

For an IT project to be successful, the stakeholders have certain responsibilities:

  • they must spend the time with the analyst and educate them about their business and help them understand their objectives
  • they need to allocate the time necessary to provide clear requirements and validate the requirements in a timely fashion
  • they must precisely describe their requirement; vaguely stated requirements are not implementable and documenting them is a waste of time
  • they must provide feedback when needed
  • they must provide additional information in a timely fashion
  • they must prioritize the requirements
  • they must respect the estimates for time and budget provided by the project team and resist the urge to “negotiate”
  • they must inform the project team of changes to requirements as soon as they occur

The analyst must continually remind (in subtle ways, of course) the stakeholders of their responsibilities. If the stakeholders don’t live up to them, then that introduces project risks which must be made known to the projects manager and included in the project’s risk catalog.

Requirements Elicitation and Discovery

To discover requirements, the analyst applies a variety of techniques. The steps in requirements elicitation are generally as follows:

  • Plan the requirements elicitation process and how the team will document and validate the requirements. This plan is referred to as the Requirements Management Plan (RMP) and is considered a key document for project planning.
  • Write a Project Charter or Project Mission Statement containing the business requirements and the overall scope of the project. Often a Context Diagram is provided to clarify the scope of the system development effort. All stakeholders must agree to the vision for the project. Some organizations refer to this document as the Business Requirements Document (BRD). Use brainstorming and interviewing to arrive at the key business requirements.
  • Identify the key users and their usage characteristics and select a proxy for each user that can present the requirements for that class of users. These “user representatives” will be consulted throughout the requirements elicitation effort.
  • Collaborate with the user representatives to identify use cases and then analyze those use cases to derive the detailed functional requirements for the product.
  • Analyze any events to which the system must respond, such as input from hardware devices or messages from other systems.
  • Identify any other stakeholders who might provide requirements or constraints.
  • Convene requirements workshops in which users work together for a few days to explore user needs and to agree on the requirements. Requirements workshops are a way to reduce the amount of time it takes to find all the requirements by getting everyone together at the same time. Joint Requirements Planning (JRP) and Joint Application Development (JAD) are examples of facilitated requirements workshops.
  • Shadow users as they perform job tasks and use the results of the observations to identify needs and to understand business processes. Document these insights in flow charts or UML Activity Diagrams.
  • Hold feedback sessions during which users can provide feedback on issues or problems with the current system. The results can be used to formulate requirements on how to enhance the system. Looking at problem reports from the help desk can be particularly insightful.
  • Build a prototype that demonstrates the requirements and provides realistic feedback to the users.
  • Identify, document, and address any risks that might have a negative impact on the project, i.e., that might cause a delay in delivery, an increase in budget, or a reduction in scope.
  • Validate the requirements through walkthroughs and other formal or informal meetings with stakeholder to assure that the right requirements have been discovered.

Requirements Analysis

As soon as requirements have been identified, they must be analyzed to ensure that they are correct, not in conflict with each other, and that they are precisely understood by all stakeholders. During analysis, the requirements must be decomposed into sufficient detail so that the project team can accurately estimate effort for implementation and assure that the requirements are indeed feasible.

Analysis Artifacts

During analysis, the analyst constructs a number of textual, digital and visual artifacts, including:

  • context diagrams
  • use case model
  • conceptual data models and data dictionary
  • user interface model
  • business process models
  • prioritized requirements catalog
  • business rule catalog
  • prototypes (horizontal discovery as well as vertical feasibility prototypes)

Requirements Documentation

To communicate the requirements to the stakeholders for validation and to provide the development team with a thorough understanding of what must be done, the analyst must write a requirements specification. This is simply called the requirements package as there are no industry standards for the format of that specification. Every organization has adopted a different document template. It is important, however, that an organization has a standard document template. The template must be flexible as no single structure will fit all projects.

The successful analyst knows how to select the right documentation techniques and does not limit himself to just one documentation approach, such as wireframes, use cases, or narrative requirements. He blends the different approaches to specify all requirements clearly, unambiguously, and concisely.

While writing documentation is generally not a value-added activity from the user’s perspective, it is a necessary mechanism to mitigate certain project risks. The amount of necessary documentation is dependent on the specific risks that are present, particularly when projects are implemented by outsourcing partners, distributed teams, or when access to stakeholders is limited or sporadic.

Requirements Validation

Requirements must be validated prior to implementation to assure that they are correctly understood and still valid lest the team wastes precious resources implementing functionality that is not needed. Validation is achieved through several means, including:

  • Formal and informal inspection: In this approach, the project team meets and walks through the requirements package, including any visual and executable models.
  • Stakeholder reviews: Present the requirements, models, and prototypes to the stakeholders for review and validation. At the conclusion of the review, the stakeholders “sign-off” on the requirements to indicate their approval.
  • Acceptance criteria definition: For each user requirement (generally expressed as a use case), define post conditions so that tests can be constructed that verify that the requirements have been met.

Writing Effective Requirements

Documenting requirements is an essential part of the requirements process. Over the years, many approaches to documenting requirements have been developed. Among the more prominent recommendations is IEEE Standard 830, which contains the recommended practices for writing software requirements specifications (SRS).

Requirements that are useful, exhibit several important characteristics:

  • complete: the requirement must contain all the information necessary to allow the project team to fulfill the requirement
  • accurate: the requirement must be correct; validation is generally done through reviews with stakeholders; an accurate requirement cannot be in conflict with another requirement
  • testable: the requirement can be verified through a test
  • feasible: the requirement can be implemented; there is no technical or other impediment that make the requirement undoable
  • necessary: the requirement must describe a feature that the stakeholders actually need; it must relate to a business objective
  • unambiguous: the requirement must be described in a simple and concise manner that guarantees that there are no differing interpretations of what the requirement means
  • prioritized: the requirement’s degree of necessity relative to other requirements has been established through stakeholder consultation

Documentation Formats

Requirements are commonly written as simple narrative statements. User requirements are best expressed as more elaborate documents. A common format for documenting user requirements are use cases. In addition, constructing visual models simplifies communication of complex requirements. A visual model, such as a UML diagram, can more precisely describe requirements than a written paragraph. It is also easier to discover mistakes in a diagram than a lengthy narrative. A requirements specification typically includes a combination of narratives, use cases, and visual models.

Requirements Identification

All requirements must be labeled so that it is easy to refer to them through a unique handle rather than its description. The following conventions are often used:

  • User Requirements are expressed as use cases and use the prefix UC, e.g., UC1.
  • Functional Requirements use the prefixes R or FR, e.g., R92, FR876
  • Business Requirements use the prefix O (for objective), e.g., O2
  • Business Rules use the prefix BR, e.g., BR12
  • Non-Functional (or Quality of Service) Requirements also use the prefix R, although some prefer to use NFR, e.g., R14 or NFR23

Requirements Traceability

Requirements must be traceable. That means for any requirement, one must be able to ascertain its source and its realization, i.e., a reason why the requirement exists and a guarantee that the requirement has actually been implemented. Generally, analysts construct a matrix that traces each requirement to implementation, test cases, and sources. The source of a requirement is generally some stakeholder but might also be a regulation or mandate.

Requirements Approval

Many organizations have a formal process of “sign-off” or approval where the customer or project sponsor formally agrees to the requirements that have been captured. While it is somewhat formal, sign-off must be viewed as a project milestone rather than a formal contract. Requirements very likely will still change after sign-off. After all, the business does not remain static; things change constantly in the business world. Project teams must adopt a requirements change procedure that stakeholders can fall back on when a requirement does indeed change. Naturally, the project manager must explain to the stakeholders that a change to the requirements (either by adding, modifying, or removing a requirement from the specification) likely will have an impact on the project’s schedule, budget, and delivery milestones.

While it is desirable for the project team that requirements are eventually “frozen” it is not realistic. The project team should be prepared to continually manage the requirements scope: scope is not static, it is dynamic and the development lifecycle must accommodate the dynamic nature of requirements. Because of that inherent dynamic, agile methods have become more appealing to many organizations. Agile methods acknowledge that requirements change and therefore they do not force a formal “sign-off” and “freezing” of the requirements. Scope is managed much more flexibly and informally in agile projects.


In this article, we summarized the important aspects of gathering, analyzing, documenting, communicating, and validating requirements. The techniques provided should serve as a foundation for your own best requirements management practices.



Published: 01/25/2011


Dr. Martin Schedlbauer, consultant and instructor for the Corporate Education Group, is an accomplished business analysis subject matter expert, and has been leading and authoring seminars and workshops in business analysis, software engineering, and project management for over twenty years. Beyond that, he coaches his clients in business analysis practices, process modeling, and lean project management. When he is not working with his clients or delivering workshops for CEG, he lectures at Northeastern University in Boston in his capacity as Clinical Professor.

[1] Brooks, F., “No Silver Bullet: Essence and Accidents of Software Engineering”. IEEE Computer, 20 (4), April 1987, pp. 10 – 19.

[2] A mashup is a re-combination of available web components to provide powerful new functionality using simple visual editors and little programming. As examples, see Yahoo pipes and Google mashups.

Best of BATimes: BRD Vs FRD

Documentation is the most important aspect for any BA.


The documentation is useful to depict the requirements and the detailed discussion about new features and change request if any. There are many different types of documents that a BA prepares. Some of the important ones are listed below –

  • Business Requirement Document (BRD)
  • User Stories
  • Use Case Specification Document
  • Functional Requirement Document (FRD)
  • Requirements Traceability Matrix (RTM)
  • Market Requirements Document (MRD)
  • Product Requirements Document (PRD)

Apart from these there are several other documents that is created by Business Analyst. It helps in understanding the business process and business events. A business events is a trigger that gives birth to the requirement. These requirements are then fulfilled by opting for IT solution.

Diagrammatically the documents can be pictured as a simple sheets of papers which contains some useful matter.

Let’s take a look at the similarities and striking differences between BRD and FRD.

Business Requirement Document

  • BRD highlights “Business Requirements” – i.e., high-level business goals of the organization developing the product or solution with the help of IT.
  • In other words it describes at very high level the functional specifications of the software
  • A formal document illustrating the requirement provided by the client
  • The requirements could be collected either by verbal or written or both
  • Created by a Business Analyst (usually) who interacts with the client
  • Entire work is executed under the supervision of the Project Manager
  • It is derived from the client interaction and requirements

The BRD is important since it is the foundation for all subsequent project deliverable, describing what inputs and outputs are associated with each process function. It describes what the system would look like from a business perspective. Following are the most common objectives of BRD –

  • To arrive at a consensus with stakeholders
  • To provide input into the next phase of the project
  • To explain how customer/business needs will be met with the solution
  • Holistic approach to business needs with the help of strategy that will provide some value to the customer

Basically, stakeholder’s requirements can be small or big. Thus it needs to be break wherever it requires and should be taken as multiple requirements.

Format of BRD –

There are many formats or templates that the organization follows. However, it depends upon the practices that is carried in the organization. For a product based company the BRD format is different as compared to service based firms. Standard format which is followed in most organizations are shown below. It is important to note that for clear understanding of the document we should include list of acronyms used.

The BRD template contains –

  • document revision
  • approvals
  • RACI chart
  • introduction
  • business goals
  • business objectives
  • business rules
  • background
  • project objective
  • project scope
  • in-scope functionality
  • out-scope functionality
  • assumptions
  • constraints
  • risks
  • business process overview (modelling diagrams for instance, Use Case and Activity Diagram)
  • legacy systems
  • proposed recommendations
  • business requirements
  • appendices
  • list of acronyms
  • glossary of terms
  • related documents

Now let’s try to dig more in FRD..

Functional Requirement Document

  • FRD highlights “Functional Requirements” i.e., functionality of the software in detail
  • Depending on the product, FRD document can be between 10 to 100 pages
  • It too describes at a high level the functional and technical specification of the software
  • Usually created by Business Analyst under the supervision of technical expert, for instance System Architect
  • In a small and medium sized organizations a BA take care of this
  • Few companies did not create FRD, instead they used BRD as it is detailed enough to be used as FRD as well
  • FRD is derived from the BRD





Actually, the process to reach the expectancy of the BRD is an FRD itself. Here an analyst after discussing with stakeholders and project manager ponder on questions like –

  • How we develop the expected requirement(s)?
  • What are the features and functionalities?
  • What are the tools and/or systems used and their dependencies?
  • How will the customer reacts when they start using the solution?
  • Any assumptions or constraints?

Most common objectives of FRD –

  • Depict each process flows for each activity interlinking dependencies
  • Holistic view for each and every requirements, steps to built
  • Estimating detailed risks for each new change request
  • Highlight the consequences if the project health is weak to avoid scope creep

The FRD should document the operations and activities that a system must be able to perform.

Format of FRD –

Likewise BRD, FRD has a somewhat different format focusing more on risks and interfaces. Although there is no such standard format that a Business Analyst should opt for. Companies belonging to different domains use their own template. For instance, you would find many points would be repeating as in BRD.

But there should be no confusion for BA to prepare this document.

The FRD template contains –

  • Introduction – It should contain Purpose, Scope, Background, References, Assumptions and constraints, document overview
  • Methodology
  • Functional Requirements
  • Modelling Illustrations – Context, User Requirements, Data Flow Diagrams, Logical Data Model/Data Dictionary, Functional Requirements
  • Other Requirements – Interface Requirements, Hardware/Software Requirements,
  • Glossary

Now the use of BRD or FRD in organizations depends on the organization policies, practices followed by the project team and stakeholders. As in my organization all projects are being hoped from Waterfall to Agile. If the stakeholders is positive with the documents then BA will design the same. But if there is a need for the continual delivery of working product then documentation will not be preferred.

However, documentation will remain a valid artefact of any project in distant future.

Published: 06/12/2017

Best of: 6 Personal Traits That a Professional Business Analyst Should Have

Business analysts are facilitators, communicators, agents of change and negotiators.


They have to understand the needs and purposes of a business in order to consider technology solutions.

They need degrees and certifications, skills, experience and domain knowledge but they also need critically important soft skills to be most successful and become CEOs in the future. Here are some of the personal skills they need.

1. Good communication skills

Business analysts must have communication skills as they have to communicate with a variety of stakeholders. They need to understand why what they’re doing has value and then articulate that to stakeholders. This includes convincing people to work on activities that may not be their top priority.

For example, a business analyst might have to persuade a Sales Director to help define performance metrics for the upgrade of a CRM database.

Good communication skills involve both verbal and written communication. Business analysts who have excellent verbal communication skills but battle with the written words may decide to receive help from writing services with skilled writers at Essay Mama.

Various forms of communication, such as workshops, meetings and other informal methods may be necessary to bring every stakeholder on board.


2. Active listening skills

Business analysts use active listening skills to make sure that all stakeholders are heard. They understand the importance of making eye contact with speakers and always attempt to identify exactly how they feel about what they are saying.

Observing words and body language is important for them to get to the bottom of what is being said. To do this, they must know how to dial out any internal or external distractions.

Business analysts can keep an open mind and acknowledge different opinions as well as know when to move the subject along. They are able to take all input into account without being too ruffled by disagreements. There will always be disagreeing stakeholders and part of their skill is in being able to handle this.

Holding excessively lengthy sessions is not necessary for them and they understand that these often lead to a lack of interest and attention. They prefer web conferences over traveling to different offices and hold meeting. This saves times and shows that you believe in working fast and don’t mind being tech-savvy.

They and honor confidentiality agreements and are generally seen as being above listening to any office gossip. This enables them to establish trusting relationships where they follow through on commitments.


3. Problem-solving skills

Many business analysts say that what they love most about their work is solving problems. Problem-solving can combine analytical thinking and creative thinking. It involves resolving cases of conflicting information, incomplete information, missing information etc.

Solutions aren’t always simple when problems occur within a company. Analysts often have to examine multiple scenarios and operations to find a solution. Understanding the problem usually involves exploring the overt symptoms, in the form of the effects on costs, sales, and performance metrics.

Examining every aspect of the situation provides context and a greater understanding of the big picture. All parties need to have input and give feedback. They have to answer many questions posed by the business analyst such as “why do you need this?”, “what does this mean?”, and “what happens next?”

Finding a solution involves some kind of change within the organization. For example, putting the change into practice could involve augmenting technology or improving a process. The ideal scenario when solving a problem is not only to solve the current problem but to ensure that it never occurs again.




4. Analytic skills

Analytic skills are necessary to be able to interpret business needs and translate them into practical, operational requirements.

Business analysts have to analyze information from a variety of sources, such as documentation, surveys, existing systems and requirement gathering sessions. EssayHave is a reliable custom writing service that’s available to write papers, such as research papers, if necessary.

Business analysts are passionate about analyzing data and usually have a variety of different ways to analyze it. They want to see what they can do with it and how they can tease different facets of meaning from it.

Everyday interpretations of data can easily fall into patterns that can hide shades of meaning. Critical thinking and valuable analysis are not necessarily straightforward. Good analysts will resist trying to come up with a neat solution to solve the problem before extensively analyzing data. Of course, analysis paralysis can also occur and they have to understand when to stop analyzing.


5. Multi-disciplinary skills

Many business analysts have expertise and experience in IT and their domain. However, it also helps to have experience in performing tasks in unrelated fields across various industries.

Those with such experience are more easily able to elicit information, interact with stakeholders and identify opportunities. They know more about the world, business trends, tech updates and have a deeper knowledge of the processes of business.

They can leverage this knowledge to apply information and techniques to their current project. Their wide range of knowledge affords them with innovative ways to deliver value. They tend to be more versatile and to avoid the thinking that certain tools, techniques and work products are suitable for every situation.

Business analysts wanting to change jobs and looking for a new resume should consider reading a ResumesPlanet Review. Find out about expert resume writers who understand exactly what to include in a business analyst resume.


6. Decision-facilitation skills

In consulting with managers and offering advice to developers, business analysts need to exercise sound judgment. After they have received input from all the stakeholders and assessed a situation, they need to facilitate the making of certain decisions.

The goal is not just to bring about change but to bring about the right change. Business analysts need to help others to make the right decisions so that the right needs are met. If a decision isn’t made, nothing happens.

Good business analysis involves defining all the decisions that need to be made, who will make the decisions and the information the decision-maker will use to make the decision. When multiple people need to make a decision, they are not always on the same page. Getting buy-in from all decision-makers takes some skill.


Concluding thoughts

Finding the best business analysts can take some time and effort. The above traits can help to identify individuals who have the potential to be great, even if they don’t have the experience yet or are in different roles.

Individuals who have a unique blend of the right hard and soft skills are usually most successful as business analysts. They know the importance of communicating and listening properly and are adept at managing and analyzing large amounts of detailed information. They know how to present and articulate value to stakeholders enabling them to make the right decisions.

Best of BATimes: 4 Common Mistakes Made When Looking For Your First Business Analyst Job

Published on: May 12, 2021

Often when I coach Business Analysts to land their first Business Analysis Job, I find that either they have no strategy and just throw darts and hope one of them hits the bullseye, or that they make some serious errors in how they approach it.

Darts does sometimes work, but not always (read my e-book on 13 strategies for your first Business Analysis Job) and if you do the following errors then it takes just as much wasted effort.

Let’s look at some of the common errors I see:


1. Don’t Have A Plan Or Strategy

Many prospective candidates who want to break into Business Analysis don’t have a strategy or plan. They send their CVs out to every job ad that mentions Business Analysis.

The first thing I look for when I get CVs for job ads is if the person takes the time to match his/her skills and CV to the position they are applying for.

A successful business strategy comes down to the following. First, what are your goals? Getting a job as a Business Analyst isn’t a SMART goal.

If we think of SMART then it comes to the A – achievable ask yourself is this achievable i.e. are you accountable for it.

I think it is important to have a goal you are accountable to achieve, no one else. Getting a job isn’t entirely in your control, is it? Someone else has to agree to it, and you don’t have that authority.

An appropriate goal would be something like:

“I will engage at least x recruiters per week with my CV”, or

“I will spend at least x hours a week looking for Business Analysis jobs that match my skill set”.

So let’s test those two through SMART:

S (Specific) – Yes, I am specific about what I wish to achieve.

M (Measurable) – Yes, I can measure how many

A (Achievable) – Yes, because I am responsible for them.

R(Realistic) – Yes, I can do either one.

T (Timeous) – They follow a schedule.




2. Your Resume Or CV Makes You Sound Like You Know You Know What A Business Does – Not That You Can Do The Job

When receiving a CV, I also look at it to determine if it seems like the person has a good understanding of what a Business Analyst does and if their experiences on the CV reflect that.

You don’t have to actually work as a Business Analyst to have real Business Analysis experience. You can have it regardless of what you do.

So I am looking at the title.  Even the BABOK 3.0 says it is not about the title but the tasks when defining what a Business Analyst is.

It is the skills, the experiences, and the tasks and related activities that a candidate performed in that role that speak to their understanding of a Business Analyst, and that even the candidate can recognize the tasks they have performed that are applicable to a Business Analyst.

A few weeks ago, I was talking to an employer and they told me about how many CVs they are rejecting just because the CV does not position a candidate with relevant Business Analysis task experience.


3. Your CV Must Speak The Language Of The Job You’re Applying For

You putting job before experience and not experience before job

A few days ago I was coaching a client who wanted to become a Business Analyst. They are in a non-Business Analyst role. I was trying to find out how much experience they have in tasks related to Business Analysis.

I asked what I could do to fill the gaps of experience. He said there are none and I will wait until I have a Business Analysis job to acquire the experience.

Here is the problem. Employers value experience. It is no different in any job application. Even doctors have to go through a community service program before they are allowed as practicing doctors.

You must embrace it, so think about how you can gain relevant experience at your current location.

I love the saying “We grow into opportunity”.  Apply the skills now and learn, gain experience, and reflect that on your CV.  Then the opportunity will come.


4. Focus On Certification

As a member of the IIBA, and CBAP certified individual, you are probably raising your eyebrows. Let me explain.

Certifying yourself is one good way to learn about Business Analysis, gain accreditation with peers, and boost your confidence. Yes, it does play a role in getting a job.

However, for an entrant in Business Analysis you must understand that employers want experience foremost.  A certification doesn’t give you that. Just like a degree doesn’t give experience, it gives knowledge.

Do the certification to gain knowledge that you can apply to gain experience.  Back to having the right goals again.

You need to put in the time and have SMART goals that you can achieve. Then, your strategy flows from there. It’s not an overnight thing either. Work at it, and adjust your strategy as you go.

When you have worked hard for your first opportunity, it will come.


For more strategies download my free e-book “13 strategies to getting your first Business Analysis job” –