A common challenge of enterprise Business Analysts is the discovery, understanding, and description of requirements in the context of implementing packaged solutions. Management assigns us to projects with a predefined solution, and we struggle to figure our role when there seems to be no significant build activity. What are we supposed to do in this situation when there seems to be no need to produce standard requirement deliverables?

 

Put a typical Business Analyst in this environment and do not be surprised to hear the phrase “I’m not sure of my role.” Why do packaged solution projects cause discomfort?

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.

Watching the speed by which Information Technology (I.T.) has changed over the last forty years has been amazing. Hardly a day goes by without some new twist or invention. In particular, my interest is in how I.T. can be applied to support the systems needed to operate a business, such as for manufacturing, inventory, order processing, customer service, accounting, human resources, and much more. I have seen a lot during the last four decades, perhaps too much.

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).