General Business Analysis

With 24-hours a day, unceasing news being forced in our ears and down our throats, with computers that blog, phones that text and everything that twitters, we have information rushing back and forth at us at speeds that can only be measured in nanoseconds. It is information on steroids and it can and often does get us in trouble[1]. Analyzing, corroborating, vetting and authenticating this rush of information, misinformation and hyperinformation are at times almost impossible.

More successful business analysts seek out feedback, face tense situations head-on, and actively pursue new challenges. While they don’t necessarily like to fail, they trust in their ability to bounce back so they choose the difficult over the simple.  It’s not uncommon for a successful business analyst to need to navigate any of the following situations, with grace.

The question of efficiency in business analysis and, what is more, of potential obstacles that prevent an analyst from being efficient, has always been considered very important. It goes without saying that there are some more or less objective reasons that prevent analysis from being done properly... There are however some types of problems that are caused by not so obvious reasons.

The purpose of this article is to show the expansion of an existing Business Process Model and Notation (BPMN) model due to an increased interest in a partner’s processes.  In a previous article, I developed a BPMN model on a home medical process associated with peritoneal dialysis. In that article, I modeled a process, Ship Dialysis Equipment, as a black box pool;

Business analysts of the not-too-distant future must and will become visionaries, innovators, strategists, and transformational leaders, executing strategy through project results. Successful business analysts will learn how to embrace organizational values, empower their teams to thrive, bring customers into the change process, and drive innovation through global partnerships.

Based on our projected trends, 2015 looks to be a year of significant change, and business analysts are on the front line of change. Several major industries, and the many organizations within them, are in the process of transition so it should be no surprise that the importance of the business analyst only increases as markets shift and organizations are forced to deal with the accelerating pace and volatility of business.

The 3 Amigos (sometimes referred to as a “Specification Workshop”) is a meeting where the Business Analyst presents requirements and test scenarios (collectively called a “feature”) for review by a member of the development team and a member of the quality assurance team.

In the book  Risk Savvy: How to Make Good Decisions, Gerd Gigerenzer describes the two sets of mental tools required for making decisions. When risks are known, good decisions require logic and statistical thinking. But when we are dealing with unknowable risks, good decisions also require intuition and smart rules of thumb.

One of my favorite tools in business analysis is the premortem. Instead of waiting until the end of a project to find out what went wrong, and learn for the future, we can use this technique to go on an “imaginary time travel” to avert real failures.

Are you a Senior BA who is looking for a new challenge? The Management Consulting BA role may be for you. This role is particularly interesting for BA’s who have adapted best practices to their strengths and are looking for a greater degree of independence and responsibility.

In this article we address the question of How TEM? by providing a deeper look into TEM main constructs and how to do a high level design in TEM. For those who missed the first article we hope that you will still find this article useful and self-contained in such a way that it will be easy to follow and understand.

The “good old workshop”. As a business analyst practitioner and trainer I often get asked the question “should we use a workshop?” quickly followed by “how do we run it?”. This article addresses the first question (subsequent articles will look at the second).

An alternative to eliciting use cases and user stories is to identify the external events to which the system must respond. An event is some change or activity that takes place in the user’s environment that stimulates a response from the software system. An event-response table (also called an event table or an event list) itemizes all such events and the behavior the system is expected to exhibit in reaction to each event.

Makes me wonder if the industry really grasps the duties and responsibilities of the BA. The industry talks about such people, but have we standardized a job description? We wrote several such descriptions as part of our “PRIDE” Methodologies for IRM and based on this, let me see if I can establish a standard job description.

This is a complete example of a Business/Systems Analysis Model using UML and including: Use Cases, Activity Diagrams, Context Diagram, and more.