General Business Analysis

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.

Whether it’s a requirements document for a solution enhancement or a stakeholder analysis for a business case, the information cultivated by the Business Analyst can often have use beyond its initial purpose. How can we make BA work come alive for the entire organization?

As a business analyst you don’t have to put on a disguise to do your job, but you can take lessons from Undercover Boss; ask questions and discover where you can make business processes or systems operate more efficiently, engage and collaborate with your business stakeholders to get needed information from those subject matter experts, and make recommendations to decision-makers to solve business problems that you have discovered along the way.

Next time you start to think that your stakeholder is crazy, ask yourself why. Chances are that there is a rational rationale, and it will be up to you to come up with a solution that meets the needs of your organization and your stakeholders.

Some programmers consider documentation a waste of time (see “Agile programming”), even going so far as to claim it is detrimental to productivity. Instead of getting all the software specifications recorded on paper at the start, they prefer to begin hacking on the program code and keep modifying it until the end-user is satisfied.