General Business Analysis

The practical applications of data science are multiplying. From predicting if a delivery will arrive late to recommending how much herbicide to use to save money and protect the ecosystem, there are endless examples of organizations harnessing data science solutions to improve the efficiency and quality of business decisions.

Is there something called as Agile BA or DevOps BA? Or is there a dedicated role such as ‘BA in DevOps’? How are Agile and DevOps related? How does BA role change or goes through metamorphosis, when it comes to DevOps?

One day, I got a corporate training enquiry and that is when I heard the term ‘Agile BA’ for the first time. At that time, I had already worked on Agile projects yet nobody had referred to my role particularly as Agile BA. A thought came to my mind, what if there was a job post saying “looking for a ‘Waterfall BA’?” I even heard once: “With DevOps there is hardly any role a need for BA or PM”.

As BA's our fundamental job is to understand the business problems proactively, determine the consequences of not solving them, and then define a solution that eliminates or alleviates the problem. When given our directives: (i) a problem exists- define it (ii) provide a solution to that problem- describe it (iii) a change is required in the business to solve the problem- realise it. We must have effective tools in our arsenal, and a sure way to see beyond the bars on the window is to understand the fundamental truth of the situation and reason up from there. A first principles mindset could be that dominant tool to understand the seed to reap the fruits, enabling us to be the change agents that improve business processes and add value.

In a previous organization I worked for, I formed a Business Analysis team by bringing 7 business analysis professionals together for the first time.  There were no templates, no standards, everyone was doing work their own way.  I don’t believe in standards for the sake of everyone doing work the same way, but I do believe in embracing what works best in an organization and striving to use that to achieve repeatable success.  I introduced the concept of a Business Analysis Center of Excellence (CoE) to the organization. 

Several years ago, I had the opportunity to manage a group of project managers and business analysts. This article reminisces about what shaped my thoughts on managing such a group and hopefully gives you some considerations given the opportunity.

Past Experience

Perhaps negative experiences impress us more than positive ones. What does not kill you, makes you stronger. In the area of managing a group of project managers and business analysts, two negative experiences stand out for me. I was a project manager engaged in a conversation with my boss on my development. I had worked for this person several years. I asked him if he had heard about a group called the “Project Management Institute.” He said “yes” and maybe he should expose the organization to the group. Maybe? I asked the question since I had been working as a project manager without guidance and frankly was a bit upset over the lack of leadership and development. I told myself, “isn’t that the role of management - to develop people.”

Analytical techniques in process discovery and improvement, including process mining and simulation, have been available for many years. In the past, however, they were used primarily by people with a technical analytical background. The current business environment and technological advances have pushed these analytical tools into the mainstream, where they are being recognized as essential for all levels of business analysts.

One of the biggest challenges now facing business analysts is this: how do we successfully engage with stakeholders, elicit requirements, and have productive workshops and meetings, without actually meeting in person? The tried-and-tested methods of getting together in a collaborative space, using sticky notes and whiteboards, and bribing attendees with baked goods, are no longer quite so straightforward in a world where some or all of the stakeholders are on the far end of an internet connection.

There are several factors to consider when moving out of the purely physical realm as a business analyst.

It is true that a structural element of the conceptual framework of the BABOK knowledge areas is tailoring. The philosophy that a specific sequential approach does not fit in all circumstances is clear across all the knowledge areas and techniques presented. A business analyst has to critically filter and pick up the most useful techniques and approaches given the specific circumstances.

I was teaching a business analysis course recently and noted that few students had used a Fishbone Diagram along with the Five Whys for root cause analysis. This motivated me to write an article on root cause analysis using the combo method along with a short example.

This article covers examples of how tools are becoming extremely important in today’s world for Business Systems Analysts; continuous learning and exploration of various tools are becoming indispensable to work efficiently and contribute towards the team success.  As more and more new technologies/tools arrive in the market, from a BSA perspective being able to appropriately understand and use them will not only emphasize the value of the BSA role, but also the force the change in mindset to align more towards the Agile way which is the common forte nowadays.

I realized that this is something that we business analysts need to constantly show the value add of a business analyst to the project sponsor / client.  Business analyst as a role exists to solve business problems, create a positive change, design and describe solutions that deliver value and enhance the return on investment.  Following are 10 definite ways Business Analysts add value to their organizations.      

Software handovers between teams and individuals in any ecosystem can be a minefield, often threatening to disrupt continuity and harmony across teams and organizations. In most cases, handovers result in knowledge loss, which in turn leads to chaos and time wastage when a critical issue hits the system. As a business analyst (BA), you will invariably be a part of the process, both at a junior and senior level. It is better to be fully aware of the complexities and pitfalls associated with taking part in a handover. You’ll eventually be able to apply some best practices to navigate around it (some of mine i hope and some of yours based on your context and area of operation).

My experience taught me that the Scrum process framework is not the complete story. Scrum does not identify roles for the business analyst, system architect, tester, UI designer or deployment engineers. Instead, the work normally performed by these roles is performed by the development team or the product owner. It is possible that the Scrum development team includes people with all of these skills, but the problem is that all the development team work is performed within a sprint cycle. The only activity that Scrum identifies outside a sprint cycle is maintenance of a product backlog (and even then it is not documented as an activity in the Scrum framework).

     Continuity planning can occur at many levels including at the project, department, organizational, or enterprise level. At the project level, a business analyst considers what will happen if a project solution fails or underperforms. This is usually documented in the form of transition requirements. At the higher levels, a business analyst collaborates with organizational leaders in key areas to determine the steps that need to be taken in the occurrence of major events that significantly disrupt business operations. With that said, I’ll be discussing the role a business analyst can play in developing an effective continuity plan.

     First, let’s discuss what a business continuity plan is. Essentially, this is a comprehensive plan to make operational changes that will allow an organization to continue business or services through a crisis, disaster, or operational disruption. The process of developing and maintaining this plan is known as business continuity planning. Typically, business continuity consists of the following three key areas...

If you are offered a role as a software business analyst (BA) to look after software/products/projects (let’s call them products for future use) in maintenance mode, don’t freak out. Why would you freak out? Because someone would tell you that the best thing to be is a BA for a project which is about to start or is in motion — not a product which is implemented, go-live done, champagne bottles popped and currently in maintenance. What's the glory in that?

OK, let’s clear some confusion first. Maintenance means looking after a product while it is earning you money, while it is being used by actual users, while it is facing the test of users trying all the straightforward and alternate scenarios, and while it is being run through real performance tests. So it is pretty damn important. You need a smart BA, with good customer handling skills and sometimes with good fire-fighting skills to deal with the role.