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.