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.

Through the use of contract terms and conditions, this article provides insight on managing risk on outsourced projects beyond just transferring work to a contractor. Training courses on risk management typically cover transferring risk at a high level, but that is just a start. Read this article for the follow-ups on managing risk via contract terms and conditions.

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!

There’s a high premium on knowing how to craft great definitions. Every business analyst should know how. To get you started, here are some basic criteria for great business definitions:

• It should be easy to give examples for the thing defined, but there should be no counterexamples.
• Each definition should communicate the essence of what a thing is, not what it does, how it’s used, or why it’s important.
• The definition of a thing should focus on its unique characteristics.
• Each thing you define should be distinguishable from every other thing you define using the definition alone.
• Each definition should be concise and as short as possible without loss of meaning. A definition should be readable.

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.

The causes of chaos are unpredictable behaviors that arise from individuals, teams, or systems. Behaviors portrayed by the mentioned three components affect how an organization is able to handle challenges and problems. By allowing individuals and teams to portray their own behaviors in the working environment, different components of an organization may either work properly or experience failure. In the subsequent sections, we will elaborate on some mechanisms that trigger chaos in an organizational context.

I always see people go gaga over agile development methodologies. While I agree that agile has its own advantages, I disagree on the fact agile is an all-powerful and does it all kind of methodology. However, if executed right, agile does have the capability to be an all-powerful methodology. Although the advantages outweigh the perils of agile, the perils if not properly addressed can put the business value and relevance of the solution at risk.

Let’s face it, there are just some conversations that you don’t want to have. There are some people you simply don’t want to talk to, but what happens when we don’t have these conversations? Everyone loses! It is perfectly natural for us to avoid difficult conversations. We fear rejection, retaliation, emotional outbreaks, the dismissal of our ideas, and of course those incredibly awkward moments where everyone around you stares at their feet thinking “God I am glad that’s not me.” However, these conversations need to be had and the Badass Business Analyst will have them. If we want healthy, productive teams and projects, crucial conversations must be had frequently. You can’t just keep ranting, raving, complaining and avoiding, you need to start having meaningful, persuasive conversations that make an impact. You need your ideas to be heard, and more importantly you need behaviors to change. Don’t you think its time you and I have a crucial conversation? Suddenly I feel like I have turned into my father. Sigh. For the record, all of his crucial conversations were always too late, which is maybe why I am so passionate about this particular chapter in my book (the longest chapter by far - okay, moving away from from therapy now).

Is your team struggling with the transition to modern requirements practices? As many teams explore and experiment with modern practices and agile, they often jump to apply tactical methods and techniques. But does anything really change?

 

Most teams work really hard and don’t see results. Or they find a few early benefits, but get stuck on a low plateau. They often give up and slide back into their old habits. Why? Because they’ve modified surface-level tactics, but haven’t modified mindsets.

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.

Many business analysts fail to achieve top performance while starting to work on a new domain simply because of their fear of making mistakes. I’ve heard analysts freely admit that looking less than competent is what they fear most. “I don’t know what I don’t know” they will tell me, “and in particular in a domain I’m not very familiar with, I’m always afraid I will miss an assumption or an avenue I must address.”