General Business Analysis

While BABOK and other sources include Behavioral Characteristics as an essential underlying competency for business analysts, many analysts may have only a vague idea of how it applies to their personal work environment, or even exactly what behavioral characteristics are, so let’s define those first.... The term behavioral characteristics simply refers to an analyst’s workplace ethics and character. 

I take the approach that as Business Analysts, the line between requirements and design is an imaginary line. We need to be pragmatic (abandon purist thinking) and not be afraid to wear the design cloak, to adopt design thinking. 

 

So how do we incorporate design thinking in Business Analysis in a value-add way? Take the following thoughts into consideration when working on your next project that involves building or significantly updating a customer-centric application.

---

Author: Michael Roy, Business Analysis Professional / Requirements Leader

Michael is a solutions-focused Business Analysis professional with extensive experience leading change initiatives at a tactical and strategic level.

 

I bet everyone has, at least once in their career, heard the expression:

iRise gives Business Analysts the tools they need to communicate clearly with both the business and its stakeholders.  They use working previews that can be virtually indistinguishable from the final product.  When business analysts uses iRise to elicit and document requirements: the business analyst becomes a powerful weapon to get to the right answer, ...

The end products of requirements development for a business analytics project will be similar to those for any other project—a set of business, user, functional, and nonfunctional requirements. Process flows, use cases, and user stories can reveal that someone needs to generate analytics results, and performance requirements describe how quickly they need results, but none of these uncovers the complex knowledge required to implement the system... An effective elicitation strategy for business analysts (BAs) is to drive requirements specification based on the decisions that stakeholders need to make to achieve their business objectives.

We hit a challenge however when we attempt to promote the value of Business Analysis to IT Management or the Business...  The reality is that simply promoting “better requirements” does not sell our value-add in terms that management from an IT or Business perspective understands... So how do we do this? Let me share five lessons learned based on my experience as a senior requirements management consultant. 

You see, I am a business analyst (BA), and more precisely the lesser-spotted, lazy beta alpha, the evolutionary pinnacle of my profession, at the tip of the BA spear. While the work of throwing or stabbing with the spear requires an effort by the arm that wields it, I prefer the sharp bit to do the work for me. In other words, doing as little as possible apart from…well, being sharp. While the sharp bit does all the work I am able to still the get the glory and recognition of a job well done. While the spear tossers return with painful shoulders, weary and, hopefully sometimes with a degree of success.

There are various schools of thought about how to define terms, some arising from professional terminologists and academia. But those approaches are often relatively arcane and not well-suited to everyday business practice.

Definitions with subtle IT or ‘data’ bias are an anathema to effective communication with business partners. Good business definitions are oriented to what words mean when used by real business people talking directly about real business things.

When asked what my secret for Business Analysis success is, I indicate fundamentals first. You can acquire skills related to Agile, the latest modeling language, and software development tools but you will fail if you have not mastered fundamentals.   The following fundamentals are crucial to success...

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.