The quality of any data analysis created to inform business decisions will ultimately be constrained by the quality of the underlying data. If the data is faulty, then the analysis will be faulty too. This is why data wrangling–the transformation of raw data into a format that is appropriate for use–has become such a ubiquitous task in most organizations. Unfortunately, the significance of data wrangling is still often overlooked. And this is where data-savvy business analysts can help save the day.

Thanks to infrastructure as a service (IaaS) and software as a service (SaaS) architectures, the utility of and business case for model-driven, no-code and low-code platforms have become more compelling than ever. More and more enterprises are entrusting their digital transformation, regulatory compliance, and business process management objectives to model-driven, no-code or low-code business application platforms.  These model driven platforms also raise the bar for the business process modeling skills of the business analysts, systems analysts and process owners who use them.

Many BAs struggle to produce ‘normalized’, function-independent data models (or don’t produce them at all). Very few business stakeholders can appreciate such models as “… a picture worth a thousand words.” This article describes an easy-to-create, simple-to-understand view data model. The view is of just those records involved in an information system capability supporting a specific business activity.

NOTE: This article uses the business-friendly terms record and field rather than the usual data modeling terms entity (or class) and attribute.

A crisis always highlights the need for specific managerial and leadership Behaviors (Behavioral School of Leadership). These behaviors of course are triggered by specific personal characteristics of the leader (Leadership Trait Paradigm), by the specific conditions (Leadership Contingency Theory) and by the willingness and devote of individual in continues practicing these behaviors any possible occasion. Although it is my intention to approach the leadership from a behavioral point of view, a synthesizing and integrating logic is more than necessary to have a holistic view that can lead to insightful conclusions.

In this fun piece, Ron examines the connection between rules and counts, such as KPIs. Ever wonder why different people can count the very same things and come up with different answers? Fear the numbers you’re going by aren’t telling exactly the right stories? In viewing a measure, how far the truth might have been stretched? Come along on this short travel story and let’s explore the matter together.

Learning how to become an effective people manager can be difficult. Becoming a manager of business analysis resources has some unique challenges, but I hope to make it easier for you by sharing some advice based on my experience managing three different business analysis teams in three different organizations.  There are two ways people become business analysis managers; from having a lot of business analysis experience or being a people manager and transitioning to leading a business analysis team.  

In my experience while working for different companies, I have seen that some organisations are learning to be agile while some pretend to be agile and others are not agile at all. While we are not here to talk about the last category (assuming they have a very good reason for not wanting to go agile), I would like to put down some challenges for organisations who are on their journey to becoming agile and for those who think they are agile but are possibly not. In this article, I am going to talk about my understanding of the plausible reasons why some organisations struggle to make it.

The practical applications of data science are multiplying. From predicting if a delivery will arrive late to recommending how much herbicide to use to save money and protect the ecosystem, there are endless examples of organizations harnessing data science solutions to improve the efficiency and quality of business decisions.

An information system maintains data in fields within records. Equally important is the system’s ability to navigate between records. Parts 5 thru 9 of this series discussed fundamental business data field types. This article discusses a record navigation field. These fields do not themselves contain business data, but support the system’s ability to navigate from a given record instance to business data in related record instances.

A classification field allows the recording of a meaningful fact about a record instance, with that fact drawn from a pre-established set of values. Online access to values applicable to a given instance might be through a drop-down or pop-up list, or as labelled check boxes or radio buttons. The organization may be interested in just the values, or there may be additional information about each value that the system needs to manage.

A point in time field supports a business need for an information system to know when an event took place (or will take place). Date, Time, and Date/Time field values represent a quantity of time involving a specific unit of measure and precision. Like other quantity values, they can participate in calculations (E.g. subtracting one date from another to determine the number of days in-between).

In this article we focus on record name fields. These fields are intended to contain a user-recognizable value by which a person or thing is known, addressed, or referred to. Unlike a record business identifier field, a name field’s value may change over time. Also, there are ‘real world’ names for things (e.g. people, cities) for which valid duplicate values can exist. 

Having discussed fields intended to name record instances, we move on to fields intended to satisfy the need to say something quantitative about a record. A quantity field requires particular attention be paid to its unit of measure (UoM) and precision. 

Is there something called as Agile BA or DevOps BA? Or is there a dedicated role such as ‘BA in DevOps’? How are Agile and DevOps related? How does BA role change or goes through metamorphosis, when it comes to DevOps?

One day, I got a corporate training enquiry and that is when I heard the term ‘Agile BA’ for the first time. At that time, I had already worked on Agile projects yet nobody had referred to my role particularly as Agile BA. A thought came to my mind, what if there was a job post saying “looking for a ‘Waterfall BA’?” I even heard once: “With DevOps there is hardly any role a need for BA or PM”.

As BA's our fundamental job is to understand the business problems proactively, determine the consequences of not solving them, and then define a solution that eliminates or alleviates the problem. When given our directives: (i) a problem exists- define it (ii) provide a solution to that problem- describe it (iii) a change is required in the business to solve the problem- realise it. We must have effective tools in our arsenal, and a sure way to see beyond the bars on the window is to understand the fundamental truth of the situation and reason up from there. A first principles mindset could be that dominant tool to understand the seed to reap the fruits, enabling us to be the change agents that improve business processes and add value.