The ability to build and exude self-confidence can contribute to success in many areas of our lives from personal to professional. Unfortunately, many business analysts who are beginners or experienced but new to an organization are not provided with the tools and recourses to be confident in their ability to add value to their organization. As a BA, self-confidence facilitates the ability to build relationships, gain respect, and influence others. Below are some of the most effective tactics that I have taken throughout my career to bolster my confidence as a business analyst. Once I became confident in myself, I started noticing that other people’s confidence in my abilities increased as well. Hopefully, these tips will help you recognize your true potential and the value you bring as a business analyst.

To be effective, we BAs need to learn as much as we can about the digital world—about the world of digital transformation and what it means for the organization. We need to immerse ourselves in research and journal articles and think of how to make sense of it for our organizations. We need to think of digital projects from both the data scientist and business perspectives. And we can do that. After all, we’re BAs and that’s what we do best.

Culture clashes frequently arise when teams are working on requirements. There are those who recognize the many risks associated with trying to develop software based on minimal or telepathically communicated requirements. Then there are those who think requirements are unnecessary. It can be tough to gain business-side cooperation on projects like legacy-system replacement if users see this as unrelated to their own business problems and not worth their time. Understanding why people resist participating in requirements development is the first step to being able to address it.

I like to compare a business analyst to an architect. While the architect asks questions about design, budget, and personal preferences of a person who wants to build a house; similarly, the business analyst interacts with business owners to know and understand their needs.   A business analyst also produces requirements which clearly state the needs of a business and ensures that those align with its business processes, just as an architect would draw up plans and have an agreement with the owner before reaching out to builders.

Process modeling/mapping/flowing, can be an art, and science, based on the maturity of the organization, knowledge of those doing this work in the organization, and many other factors. What I have found can be challenging is identifying the actual processes to model/map/flow. The fight identification may not occur on the first attempt as this work can be quite iterative, however, there are some concepts that can help make the identification a little easier

Capability-based planning is a growing practice in the field of enterprise architecture. Its success is due to the fact that it provides actual value to practitioners and the organizations that employs them. Indeed, capability-based planning helps in a number of ways, from providing a clear understanding of existing capabilities to promoting effective Business-IT alignment. Considering these benefits, we thought it useful to address this practice and bring some clarity to the subject for the benefit of all who might not yet have a good handle on the topic.

Becoming a Certified Business Analysis Professional (CBAP) has been one of the most rewarding and challenging endeavors for me as a business analyst. The purpose of this article is to help other business analysts pass the CBAP exam on the first try by sharing the strategy that I used. Hopefully, it will be of great service to many business analysts and aspiring CBAPs. Below is an outline to navigate you through studying for the CBAP and absorbing the BABOK material.

In recent years, agile software development has been the classic example of this pursuit of magic solutions, so I’ll use that as an example here. Over the years, though, people have leapt onto the bandwagons of numerous new software approaches. They all have merits, they all have limitations, and they all need to be applied to appropriate problems.

Our job is to be trusted advisors and one area where we can establish trust is to help our stakeholders understand language that might be confusing to them. In order words, we can establish trust by translating technical complexity into business language. We BAs have always done this. We take customer requirements and translate them into something the technical folks can understand…and vice versa.  But what about translating in the digital world? We still need to translate, but it’s different. It’s more complex. 

We live in a time when business in many industries offer similar products and use comparable technologies. One of the last points of differentiation are processes, and the evidence is clear, in sector after sector: companies that figure out how to combine business domain expertise with advanced analytics to improve their internal and customer-facing processes are winning the market.  Let’s take a look at three of the many opportunities that the advanced analytics technologies developed over the past decade are creating for business analysts..

DevOps is based on a culture of trusted partners. This partnership is between software development, quality assurance, security and controls, and operations. The result is a smooth and fast transition of software from development to operations. However, like Dover, if the trusted partners are somehow reorganized into formal handoffs each with their own software acceptance procedures, the movement of software is no longer smooth nor fast.

One of the three activities encompassed under Requirements Analysis is the process of ‘ Requirements elicitation’. IIBA’s definition of ‘elicitation’ is “An activity within requirements development that identifies sources for requirements and then uses elicitation techniques to gather requirements from those sources.”

However, this definition appears incomplete from an analyst’s point of view as it relies solely on the assumption that one can come up with requirements only by running elicitation techniques; however, the process of elicitation is not as simple and straightforward as it seems. Let’s see why.

This article describes the process of the strategic enterprise analysis utilizing text and tables. In the past 5 years, things have changed, and I have gained new insight and most important learned new aspects. As a result, this article expands previous material to include...

In this article, I want to share my knowledge on how to manage product backlog using Jira. The article will be useful not only to business analysts or product owners but also to scrum masters, project managers. Basically, anyone who works with backlog and requirements on a project will benefit from reading it. There are certain rules and approaches that you have to follow to achieve good results.

Before we take a look at it I want to point out that this approach is not a market standard yet. However, over the last 3 years, I’ve completed a good number of projects using the approach I’ll be describing here

On the image below I tried to emphasize the main activities and processes that should be presented in your project. You also have to keep in mind that each artifact and process has own goal and definition.