General Business Analysis

A business analyst is a person who analyzes, organizes, explores, scrutinizes and investigates an organization and documents its business and also assesses the business model and integrates the whole organization with modern technology. The Business Analyst role is mostly about documenting, verifying, recording and gathering the business requirements and its role is mostly associated with the information technology industry.

My inclination is the smarter and harder approach but again I am asking you to contribute your thoughts. Channel your inner Justin Timberlake and consider how do we get sexy back to Business Analysis? How do we get the attention of the decision makers when we are no longer the shiny new product that every one wants.

Congratulations! You have been asked to act as the lead Business Analyst (LBA) on an important project. It is more than likely someone recognizes the good work that you have done in the past and their hope is that your past success can be replicated with multiple Business Analysts on this new initiative. Like any new experience, you may have some anxiety or nervousness regarding this new role. It is important to you that what happens turns out to be a future success story and not an experience that stays in the closet.

Consider an agile project on the other hand. Agile projects do not require massive documentation in advance. Moreover, in agile projects, the business owner might communicate directly with the agile team (developers) and sometimes the agile teams are even co-located, which makes the communication between business owner and agile team easier.

So, there is no role of a Business Analyst in agile projects you say!

This is the time for the BA community to expand its capabilities and provide critical value to the organization. With a massive 86% of global CEOs reporting a lack of time to think strategically about the forces of disruption and innovation shaping their company’s future, businesses leaders must lean on the evolving capabilities of the business analysis community.

Every organization has some degree of “chaotic” culture. Some of them breed chaos and unconsciously operate in chaos. Project management is designed to operate with structure. However, reality has always contained a dose of “Wonderland” as well. Projects find themselves at odds with the environment that they operate within when the underlying organizational culture tends to be chaotic and less disciplinary and operates randomly. Project management methodologies and execution processes’ logic and convention are contradicted by the chaotic, shape-shifting setting of “Wonderland.” This conflict threatens a successful outcome for a project. The uncertainty that projects are confronted with throughout the execution process can be fatal. Chaos, by its very nature, is impossible to control completely, and so projects struggle to deliver as they fail to manage the conflict they find themselves in with the organization’s way of life.

A story is defined as a narrative or tale, true or imaginary. Each story has a moral hidden in it. A story writer won't directly say that hard work and patience is the key to success. Instead the writer came up with a story of Hare and Tortoise. And if we observe carefully, stories are everywhere; we ask a friend about her love story, we watch a prime time news story, we ask a new friend about his life's story, the movie I watched the other day had a good story. 

The Business Model Canvas is a common method to build a business plan in very large and small companies because it is both structured and very simple to understand. The Business Model Canvas is also very Customer-Driven. Yet, there has not been in the past an easy way to plan a detailed Business Architecture model starting from a Business Model Canvas to enable marketing and operation planning. In this article, we will demonstrate how to easily bridge a Business Model Canvas to a Business Architecture model to optimize with agility your marketing and operating modeling.

An analyst must frequently contend with structure-less environments and relentless rejection, and the character of Alice highlights many desirable characteristics that constitute the makeup of a good business analyst. Having identified the value of the Mad Tea Party as a learning ground in the previous episode of this series, we will now examine some of the key lessons learned and how they are applicable to the work of the business analyst.

By signing up to go through this process, you will be doing yourself a huge favor – a favor that you will never regret especially when people will look at you as the ‘wow’ person who completely transformed his or her life, achieving something that was not even vaguely possible otherwise.

We implemented A/B testing into our product 6 months ago. During that time we conducted a variety of A/B tests to generate insights about our user's behaviour. We learnt a lot about our specific product. More generally, we learnt about how to run valuable A/B tests.

Business analysis is an indispensable function in all business organizations, performed at myriad forms and scales.  Maintaining high quality of business analysis consistently is a challenge to many organizations. Inconsistent business analysis output quality results in undesirable project outcomes, poor decisions, operational disjoints and missed opportunities.  This article uses an actual case to discuss how low quality business analysis impacts an organization and what improvement initiatives the organization implemented to address the problems.

Given the right circumstances, even good people can go astray as our psychology push us down the slippery slope of questionable behavior.   A little bit of knowledge about the forces that drive us to cheat can go a long way helping avoid bad behavior. Here are some common landmines to become aware of so you can make sure to defuse them as you embark in a new BA project

The context diagram and the use case diagram are two useful techniques for representing scope. This article describes two other methods for documenting scope: feature levels and system events.

Once requirements analysis is completed, Business Analyst has all the information needed for a well-running function. Further actions for design, development, test and eventually roll-out are conduct accordingly. Usually and unfortunately, because of the rush of ongoing project execution no one thinks about the roll out activities until the end of the project plan and when the PM starts to drill down the roll out plan in details, project team face with the big nasty surprise of new requirements necessary for the selected software changeover (a.k.a. software adoption) strategy. Cost increase, delays, unmet deadlines create the nightmare one by one.