For the past year the COVID-19 virus has forced us to limit our exposure to the outside world. This virus has given us a need to find a home activity to entertain ourselves and our families. One of the activities I have pursued is assembling jigsaw puzzles. As you may know, a jigsaw puzzle is a challenge in assembling picture pieces into a single image. They come in various shapes and sizes. After doing a number of these puzzles, I noticed the similarity between this fun activity and executing a project.

Business is rarely 100% smooth sailing. Regardless of the industry or sector, there are always challenges to overcome and obstacles that must be faced on the pathway to success.

Some organizations aren’t strong enough to ride the waves. Others, however, are, and the reason for their strength is that they’re not navigating the murky waters alone - they’re supported by an ambitious, results-driven business analyst. Research even shows that business projects are more likely to succeed with the help of a great BA.

At their core, business analysts are part problem solvers, part change-makers. The core responsibility of a business analyst, or BA, is to work with organizations to identify a sticking point that’s standing in the way of them achieving their goals, introduce a solution to this problem, and help the business to adapt in a way that makes it easy to implement the solution into the business environment.

Typically, a great business analyst is someone that’s confident enough to think outside the box, who’s solution-oriented and innovative. But today these skills alone aren’t enough, especially as the role of the BA is changing.

     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.

Despite significant investments of time and well-intended stakeholder effort, many business process models still end up being not very useful for their intended purposes. Too many do not reflect the business accurately enough to be useful, do not have sufficient key stakeholders’ buy-in for real decision making, or do not include the kinds of process information that the model’s readers are looking for. Some even confuse their readers with complex or incongruous graphical notation.

"You teach best what you most need to learn". I love this quote by Richard Bach and firmly believe in it. It is the teacher or trainer who needs to keep himself or herself updated and learning so that one can give back the best. As BABOK® also has identified, a business analyst needs to have and develop teaching skills as well.

There’s so much buzz and interest about concept models these days, we asked Ron to summarize what they are, who they’re for, and why you need them. Here’s his response, short and readable. He’ll also touches on how you can get started, and where to find more information.

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.

Writing functional specifications as a business analyst (BA) in an agile ecosystem is a challenge of a different kind. You no longer have the luxury of time (unlike bigger waterfall projects). You no longer can be sure with a specification version as the final document (because of the iterative philosophy). You are not sure how comprehensive the functional specification should be (Agile manifesto: working software over comprehensive documentation).

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.

This article discusses extensions to commercially-available requirements management (RM) and application lifecycle management (ALM) tools. These extensions are intended to support the concepts presented in the Requirements In Context (RIC) series of articles. End-to-end requirement examples based on those concepts can be seen in the Trips-R-You Web-based Flight Reservation System Case Study... All RM/ALM tools, ‘out of the box’, should support the concept of Requirement. The typical form of support involves a textual requirement Description, accompanied by properties such as Priority and Status. It’s left to users of the tool to manage the description content (and quality).

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.

Dynamic shifts in consumer behaviour prompted organizations to gain a deeper and faster understanding of their data to guide decision making and, in some sectors, accelerated digital transformations. In particular, IIBA has identified some key areas where business analysis has developed a critical voice in response to the rapidly changing landscape. That voice and the impact business analysis professionals will continue to provide will play an important role in helping organizations navigate trends, uncertainty, and opportunities in 2021.

The intention of this article is to identify and specify the artifacts listed in the BABOK. These artifacts are listed within the Outputs section of the BABOK tasks. Outputs are described by a paragraph of text within each task. In this article I attempted to expand on these descriptions by adding detail to their content.

It is assumed that each activity produces a tangible output^[2] which is consistent with the layout of the BABOK. Those outputs are classed as artifacts with attributes. Each artifact’s attribute description is taken from the element description of the tasks that output that artifact. The BABOK element descriptions provide guidelines for activity that produces the attribute, without necessarily defining the information contained in the attribute.That information has been derived from the element description.

Artifacts are derived from the BABOK Output sections. Artifact attributes are derived from the BABOK Element sections. A useful addition to the BABOK might be examples or templates of the outputs.