Decisions are at the heart of every business transaction. That’s why it is crucial to make the right decision at the right moment in time. In high turnover environments this can be an issue, as new staff need constant monitoring as they ‘learn the ropes’. This can lead to a significant deficit in efficiency and customer satisfaction.

To counter this problem, we advocate what we call a ‘Decision-Centric Approach’, which is designed to address the business challenge by enabling innovative technology in those crucial ‘moments of truth’

What do you put down in non-functional requirements when you are documenting requirements in your project? When we say non-functional we typically mean those requirements that are not related to functionality of the system, then what exactly are these and why do we need them.

There are a small number of core concepts that can be said to embody the essence of an enterprise. This article asserts that one such concept is the business algorithm, the unique combination of business logic, algebra, and rules that is used by the enterprise to convert real world data and events into useful outcomes that benefit all stakeholders – giving rise to happy customers, prosperous proprietors, and fulfilled staff! ... The business algorithm is a unique and fundamentally important concept that no enterprise can function without. There are other aspects of the enterprise like brand or culture that may also claim to be ‘of the essence’, but the business algorithm is the only such concept that has a formal existence inside computer systems. The business algorithm is like the soul of the enterprise, uniquely defining the enterprise and giving it life via its systems. As such it has a unique claim to relevance as a first-order systems requirements artifact.

Project statistics state that most project rework/failure is due to incomplete/improper/unclear requirements, hence the role the Business Analyst becomes even more critical as they shoulder a huge responsibility of eliciting and collaborating with the stakeholders to obtain clear, concise and complete requirements.  The elicitation and collaboration knowledge area focuses on drawing forth or receiving information from stakeholders and other sources by directly interacting with stakeholders, researching topics, experimenting or simply being handed information.

Many professionals and organizations understand the value of a business analyst (BA), however, the role itself is still ambiguous to many. There are numerous articles and resources that outline business analysis and the general role of a BA so I won’t be focusing on those aspects. Every organization and industry is unique therefore the needs and expectations for a business analyst can vary greatly. However, there are a few core competencies that remain consistent. The goal of this article is to give BA practitioners (especially new practitioners) an approach to determine what their specific organization expects from them in order to get on the path of success throughout their career. Below are some steps you can take to define your role in the organization you serve.

Business Requirements Advocacy is neglected in the business analysis practice!  Once considered to be an essential part of IT teams, the business analyst has become an integral position in any successful, market-driven organisation. Rightly said to be the change agents for any business, business analysts help organisations adapt to the changing environment while meeting the needs and demands of all their stakeholders, including employees, customers, and suppliers.

There is much to say about the often challenged relationship between IT and “the business” that has existed since IT became IT. Centralization, decentralization, self-service tools and applications, enterprise tools and applications – the pendulum swings again and again.  You’d think by now that we’d get it. There is no one all-encompassing data management or BI solution that will satisfy all of your data related requirements.

In this article, I am going to focus on the key 3 tools that you can use to help you identify the pain points in your workflow.  One of the key things to identify when working in a visual manner is understanding where your blockers are. It is only when you have identified these blockers, you then able to do something about them. There is no use trying to change something when you don’t have the evidence to baseline the problem. As business analysts, we wouldn’t tell the business where the problems are without conducting a thorough root cause analysis. So, why do we do it at work, why do we think without evidence we know exactly what the problem is and the impact it has on. 

The purpose of this article is to cite an example of using Lean-Agile project management for a small home construction project – a bathroom remodel. The remodeling firm unknowingly uses a Lean-Agile project approach that was the result of lessons learned over years of experience. In fact, when I questioned the remodeling firm about Lean-Agile, the firm’s response was “What is that?” Regardless of what you call it, the firm uses their construction approach because it works.

Somebody inquired to me in one of the professional networking site if I can suggest what the difference between a Business analyst and data analyst is.

This is a dilemma that is common in the minds of numerous professionals who are new to Business analysis or intending to get into this space.

As the name proposes a first hand analysis by any layman will state that the business analyst role includes analysis from a business perspective, though the data analyst role deals with primarily analyzing data.

In order for any project or initiative to be successful, an agreed upon business need must be determined. This need may present itself as a problem or an opportunity. Business Analysts must be able to guide the business in articulating which of these is the catalyst for the initiative prior to starting any BA work. Projects without a clearly defined business need get drawn out due to issues such as increased stakeholder conflict, poorly defined requirements, and excessive rework. So, to save you some pain and effort, below are some reasons why defining the business need is a critical starting point for any organizational change.

I wanted to get to the bottom of things once and for all. We had been having several discussions about the birth of business analysis and how the profession of business analyst came into being. There were no business analysts, at least as currently incarnated, in Data Processing when I started a long time ago, and a look into the history of business analysis might be interesting. So I went sought out Doctor BA who has been around a lot longer than I.

Chaos! Stress! Everyday mess! Isn’t this an everyday situation for a business analyst? If not, either you’ve job satisfaction or you’re not being introduced to the real world of business analysis.

A person might possess great skills, however, (s)he might not be able to utilize skills without the right mix of tools and environment. A toolbox enables a person to implement the skills in the most efficient way. Possessing necessary tools is just the one part of it. Another is the knowledge to utilize the right tools at the right time to cater the solution and ensure timely committed delivery.

What are these tools? How do we map the usage of tools to the given circumstance? How can we efficiently utilize the tool? Does it depend on the solution or the approach?