General Business Analysis

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.

A business event is something that happens, and when it happens it causes a pre-planned response by the business, or as we shall call it here, “the work”. One category of business events are the things that happen inside an adjacent system. The work is made aware that the business event has happened because each happening produces a flow of data to the work. A business event is a significant happening – it is not just a mouse click. It is often a request for a service that your business provides, and the outcome is the provision of the service or product.

Have you ever imagined a situation wherein your vocabulary is missing all of a sudden? What would happen if words weren’t there? Or our vocabulary shrank like ‘Honey I Shrunk the Kids’?

Next to silence, words are a very important part of our conversations :-). When it comes to Business Analysis, there are many challenges around definitions. The project Glossary should contain all key business terms. It is such a straight forward thing but we may assume those things. We may put a little less emphasis on creating a rich project Glossary. Let us zoom in a bit into the common challenges of glossaries and also discuss how to overcome them.

Someone recently asked me “What does a typical day for a Business Analyst look like?” and my response was that if you do find someone who can articulately answer that question, they are probably a very good Business Analyst to start with. No two days look the same in this profession. A person in this role must have many facets to their personality in order for them to be a confident and a strong Business Analyst. I really like the business analysis profession because there are multiple dimensions to the various roles we may be asked to fulfil.

Being a Business Analyst has largely shaped my career and it has also played a big part in shaping my personality. What’s it about this role that has the potential to make a professional grow into a strong and a confident character? The purpose of this article is to talk about these aspects and show how a Business Analyst can use these aspects to their advantage to not only become the best Business Analyst that they can be but also to be a strong and confident personality that will help them at any turn of life; professional or personal.

Agile projects, due to the short cycles of delivery, require a collaborative team, substantial leadership support, and a robust, agile culture to be in place to be called as working and successful.

The two key pillars for a successful agile project are the product owner and the business analyst.

The product owner works almost like the director of a movie, envisioning the macro and micro-level details for the product. At the same time, the business analyst ensures smooth execution of the sprint and manages the epics and stories' details.