Articles Archives - Page 5 of 423 - Business Analyst Articles, Webinars, Templates, Jobs

How to Prevent Project Burnout Before It Strikes

Written by Adrian Reed on June 1, 2024. Posted in Articles.

I suspect many people reading this work on projects pretty continuously. It’s normal to jump from one project straight to the next, often without much time for reflection and decompression. In fact, you might be balancing multiple smaller projects at the same time. That’s a hard gig: typically each project has its own set of deadlines, and Project A’s sponsor doesn’t care that Project B has suddenly put extra demands on your time…

In situations like this, it’s easy to get into the vicious cycle of working longer and longer hours. Sometimes, for a very short and defined period of time, this might be OK. But when it becomes the norm, it can become unhealthy. When weekends become the ‘mop up’ time for all the emails you couldn’t clear during the week, and Monday is filled with a sense of dread, something is probably wrong. If you’re there at the moment, I feel for you. I’ve been there. I suspect we’ve all been there.

In this blog, I wanted to share some tips that can help avoid situations like this. Of course, we are all individuals and we all have different working patterns, so what works for me might not work for you. Certainly, you’ll want to adapt the tips below, but hopefully they’ll provide you with a useful starting point:

Say “No” Effectively

There is rarely a lack of work to be done, there is a lack of time and attention to do it effectively. Say “yes” to unrealistic deadlines and there’s a risk that everything will be rushed and everything will be late.

Yet saying “no” sounds career-limiting, doesn’t it? Who would dare say “no” to a senior leader? Perhaps it’s all about how the message is given. For example:

Say “yes, and here’s the impact”: Imagine you’re stretched and another task comes in. A way of responding might be to say: “I can absolutely do that, by that date. However, this will impact tasks B and C. Are you happy for this new task to take priority?”.
Say “Thanks for thinking of me, let me introduce you to someone that can help”: It’s easy to inadvertently take on the work that others might be able to do more effectively. Perhaps someone is asking you to pick up a support issue on a project that launched months ago and is now in ‘Business as Usual’ (BAU). A response might be “Thanks, it’s always really interesting to hear how things are going on that system! I’m somewhat out of the loop with that now, as the support team took over. It’s really important that these issues are logged with them, so they can track trends. Shall I send you over a link to the defect logging form? If you don’t get any response, feel free to follow up with me and I’ll connect you with my contact there”.
Say “No, but here’s what I can do (and offer options)”: Imagine a completely unrealistic deadline has been given. Saying yes will save short term pain, but will cause long term issues when the deadline is missed. A better option may be to say “I can’t hit that deadline (for the following reasons), however here’s an estimate of what can be done. Alternatively, with additional resource we could achieve this…”
Finally, a flat out “no” is fine sometimes: Not everyone agrees with this, but in my view, particularly when something is optional, it’s fine to say a flat out no. “Would you like to help organize the summer BBQ?”. “No thanks, I’ve got a lot on right now, so that’s not something I’m interested in”. Of course, this needs to be delivered with rapport, empathy and respect.

There are many other ways, and it’s important to be aware of context and culture. What works in one situation will not work in others.

Find Ways of Recharging (And Make Time For Them)

We all have things that replenish our energy. For me, it’s exercise (whether that’s walking or going to the gym), reading and other hobbies. It will be different for you. The irony is that when things get hectic, often these are the very things that we jettison. Don’t! Build them into your routine and make them non-negotiable.

Celebrate Successes

It’s so easy to jump from sprint to sprint, delivery to delivery without actually reflecting on what was achieved. Celebrating even small successes is worthwhile. This doesn’t have to be a major event, just a lunch with the team, or some other kind of social event can help mark the milestone.

Watch for Warning Signs

Finally, it’s important that we all look out for warning signs—in ourselves and others. I remember friend and fellow BA Times author Christina Lovelock talking about ‘digital distress signals’. Is someone emailing at 6am and then again at 10pm? Might that be an indication that they are overwhelmed? If the person has an unusual work pattern (perhaps working before the kids go to school, and catching up in the evening) it might be totally fine. But if this isn’t the case, they might be pulling 14 hour days, and that’s got to be impacting them.

We all feel and experience overwhelm differently, and a little bit of stress is not unusual. There’s even a theory that a little bit of stress is good for you. But continuous stress is an issue, and it’s worth watching out for.

Of course, this article has only scratched the surface of this topic, but I hope you’ve found the ideas thought-provoking. I’d love to hear how you avoid burnout on projects. Be sure to connect with me on LinkedIn and let’s keep the conversation going!

Unpacking BA Requirements for the Blockchain Industry

Written by Esther Folorunso on May 30, 2024. Posted in Articles.

When the word blockchain is heard, cryptocurrency comes to mind next. Some need to realize that cryptocurrency is just digital money and other digital monies, such as stablecoins, exist.

What exactly does blockchain mean?

A blockchain is a shared or decentralized digital ledger of public, private, or hybrid transactions. It relies heavily on the flow of information and, in this case, the flow of transactions across many computers in a business network. This specifies that the blockchain wouldn’t have any core function without information or data. A blockchain network provides a shared, simple, single view of transactions, signifying that transparency is a strength and a win in this industry. Blockchain can potentially revolutionize how enterprises transact business and solve problems creatively.

What makes blockchain, blockchain?

The presence of a distributed ledger, which is the shared database in the network that stores the transactions; smart contracts, which are used to self-manage business contracts without the need for 3rd parties, which means they are triggered automatically when certain conditions are met; public key cryptography, which is used to identify the members in the business network; and permissions necessary to ensure that all transactions are secure, authenticated, and verifiable.

Is there a future for business analysis in this delicate but ever-evolving industry?

As business analysts, we have the strength to feature in any industry or organization and play an integral and delicate role in bridging the gap between the present and the future. Remember, business analysts need to understand that they exist to drive change while still understanding the capabilities and competencies of every shift (Read, Business Analysis, how and why I need to evolve).

Taking a deep dive into the future of business analysis in this industry, business analysts must have at least a basic understanding of how this industry works and the specific details related to the company in which they work. This will help you understand details that would help you identify the business needs and vision, understand the potential of this technology, and align it with the organization’s objectives—understanding how the industry works can be a solid requirement for benchmarking and market analysis in an event where this becomes necessary.

Secondly, the blockchain industry would thrive on the practical and right adoption and application of use cases, which is where business analysis comes in. This is necessary to identify specific use cases that highlight value to the enterprise or company and even the industry as a whole. Business analysts are crucial to determining the context in which blockchain helps attain value or change. Furthermore, this will be useful in communicating diverse use cases for blockchain technology to various audiences with differing levels of technology understanding and divergent business needs. This remains a critical gap; thus, there is a need to ensure and manage stakeholder collaboration, involvement, and engagement.

Thirdly, stakeholders, top management, process owners, and project sponsors need to understand and assess the potential value blockchain would bring, possibly a solution to an identified problem, and determine if it meets their standards. Value assessment could be performed using a SWOT analysis, feasibility studies, cost-benefit analysis, market mapping, decision analysis, modeling, etc. An analysis of possible weaknesses and challenges this technology is prone to is an essential task all business analysts must perform, some of which include security concerns, as there is a possibility that distributed ledgers and smart contracts could introduce security concerns, data access, and storage issues based on the decentralized/consensus mechanisms (proof of work), and the evolving regulatory landscape surrounding blockchain can significantly impact and influence business requirements. It is pertinent to note that regulatory requirements always prevail to avoid costs and penalties in requirement prioritization. For example, the Nigerian government initially placed a ban on cryptocurrency but lifted this ban in December 2023. In this situation, business analysts would need to assess the viability with due consideration of the unstable regulatory requirements.

Fourth, when translating business requirements, there is a need for business analysts to walk closely with the stakeholders, both internal and external, to critically understand the business requirements and correctly translate them to technical specifications through functional decomposition. Suppose the requirements are not adequately broken down into functional and non-functional requirements. In that case, being able to develop use cases might be a challenge, hence the need for a business analyst. However, it is essential to mention that the role of a business analyst extends beyond developing use cases; they also play a vital role in all the business analysis knowledge areas such as planning and monitoring, elicitation and collaboration, requirements life cycle management, requirements analysis, design definition, strategy analysis, and solution evaluation.

Conclusion

Business analysts working with blockchain must be adaptable and embrace continuous learning. There is a need to master new skills while adapting existing BA practices and their skills to this evolving technology. Armed with the knowledge that the future holds exciting possibilities for BA professionals who embrace the transformative potential of blockchain, business analysts need to take the necessary steps to ensure that they will be well-positioned to navigate this dynamic and transformative landscape.

Mapping Success Together: Tips for Inclusive Process Maps

Written by Adam Pearson on May 29, 2024. Posted in Articles.

There are numerous things that we can do to make process maps more inclusive; however, while they tend to go against established practices, they offer a range of benefits to making maps more inclusive for all.

A process map should be standardized within a business to map out the steps to achieve a business goal and show sequential steps, tasks, and gateways. There are a few established standards (UML, BPMN, etc.). My aim is not to advocate methods but to encourage inclusive standardization. Consistency is key, as it enables comparison and evaluation and can also assist colleagues with neurodiversities.

Typically, there are two sight-loss personas: low vision and no vision. Low vision is when a colleague has a combination of: fields—the amount of sight you have (half-close your eyes to see top and bottom field loss). The other is acuity, which is how sharp it can be seen (almost fully closing your eyes until the words go fuzzy can demonstrate acuity loss). The huge amount of variation between fields and acuity loss means that it is very hard to get a one-size-fits-all solution to sight loss.

The second persona has no vision. This is typically what you think of when you think of the word “blind.” No vision means no useful vision—you may be able to see something, but you cannot understand it without third-party intervention. Only a small percentage of vision-impaired people have no vision, but it is crucial to ensure inclusivity for them.

Process maps are inherently visual, so the following tips are mostly based on low vision. Low-vision users, with some tweaks, can read process maps if care is taken by the business analysts to make them as inclusive as possible.

Firstly, some whole-map tips. Use a clear font, classified as “sans serif.” These are simple, non-fancy stroke fonts that are easy to read, e.g., Arial and Calibri. Bad examples are brush script, harlow solid, and monotype cursive. Another consideration is the font size. Typically, it is best to produce it in large print, size 14, or giant print, size 18. This is not just helpful for those with low vision but will also reduce eye strain for fully sighted users. San-serif fonts are also dyslexia-friendly.

Secondly, make the connectors, or the lines between process steps, consistent in both thickness and color. The thicker the better, as there is more chance of seeing them, but they must also be in proportion to the other objects, or else it will look so odd that few people will engage seriously with the map. This is the balance between usability and accessibility.

Thirdly, low-vision users will zoom in a lot more than they are used to, sometimes only having a few letters on screen. With this in mind, there are two things that must be considered: Navigation: ID codes. By coding every step, data object, or note, you allow a low-vision user to navigate quicker using metadata instead of engaging with the full object. Each object class should be different; typically, I use process steps as numbers, notes as N1, N2, etc., and data objects as D1, D2, etc. Depending on which software you use to map your process, this can also assist any user in searching quickly and efficiently.

Screen real estate is also an important consideration. The more you zoom in, the less you can see the bigger picture. So, if objects are spaced far apart, it’s harder to understand the map. I recommend placing objects close together. Where you have multiple connectors coming out of an object, line them up so they overlap, looking like one connector, and have them branch off with the connector text as close to the break as possible, allowing someone who is zoomed in to be able to follow with ease.

Fourthly, color is important. There are several vision-impaired color schemes, such as yellow on black, white on black, etc. These are all highly subjective but share one common feature: they are high-contrast colors. My advice then is not to use similar colors, such as black and grey, white and silver, or white and yellow, as these types of pairings are very hard to see and can be easily missed or unreadable. Neon colors are highly effective, as most accessible technology offers color inversion, and when you invert a neon color, it stays the exact same shade, meaning there can be no misunderstanding in color coding like RAG systems. I advise only using one color scheme, or at most, in the case of impact assessing a process, a RAG for change size and blue for new—all in neon colors.

Finally, for all users, but specifically No Vision users, think about object semantics. By this, I specifically mean connector lines. Accepted practice means that we have no arrow heads on lines, and a double arrow head is assumed. This is presumably to make it look nice. A screen reader, though, has no context for this as there is no semantic instruction to relay to the user. Therefore, adding doule arrow heads will allow the semantic meaning to go through the connector. This is because a screen reader will consider the connector itself, not the thing it is connected to, which is what a person with sight will do. All a screen reader will visualize is a line, and a sighted user will see the line and the objects connected.

To summarize, process maps are visual. We can make them inclusive of low- and no-vision users by adapting our frameworks and standards. Specifically, by looking at font type and size, object layout and identification, color schemes, and the semantic meanings of diagram objects, we can minimize the risk of low- or no-vision users not understanding, thus making the business more inclusive and effective.

These tips are by no means exhaustive nor gospel, so please feel free to use them as a starter for ten, and hopefully they will help you kickstart your own inclusive process map designs!

Learning to Love Compliance

Written by Adrian Reed on May 20, 2024. Posted in Articles.

OK, I’m going to let you into a secret here. I genuinely like compliance projects. You know the ones, those projects that people think are really boring because they relate to a change in regulation or legislation? The ones that it’s really hard to get people excited about? The ones that few BAs volunteer for? Yep, those ones!

Framed differently, there’s often a real opportunity to shape and scope things in a way that isn’t always the case with other (seemingly more exciting) projects. These projects can be career-enhancing, provide more autonomy and really don’t have to be boring. Or, at the very least, they don’t have to be as boring as they first appear! Let me explain…

Pain Reliever or Vitamin

I remember reading somewhere that one question that some Silicon Valley venture capitalists will ask startups when they are pitching for funding is:

“Is your product a pain reliever or a vitamin?”

You might think it is better to be a vitamin. Yet, apparently, the answer that investors are looking for is ‘pain killer’. Sure, we might take vitamins some days, but it’s easy to forget. But if you’re in pain, you will soon remember to reach for the pain reliever. So, solving a pain point will likely get people to reach into their wallet.

Think about a change in regulation or legislation. Most people who are part of the core business know they need to comply, but if we’re brutally honest, they probably aren’t that interested. A change in (say) data protection legislation is just a distraction to them. They probably don’t care how it’s solved, as long as it doesn’t disrupt them too much, and as long as it doesn’t cost too much. In fact, they might even be worried that the legal & compliance team are going to be ‘heavy handed’ and create all sorts of bureaucracy for them.

This is an area where BAs can act as a real pain reliever. By working with the relevant business areas and the legal and compliance team, by working with stakeholders to understand enough about the business operations, the solution landscape and the legislation or regulation we can co-create innovative solutions. We can find a balance that works for the different stakeholders, and rather than just achieving compliance, might actually improve things for them too. Imagine that, a compliance project actually leading to improvements! It is totally possible.

Crucially, we take away a distraction for them. We get far more autonomy and leeway to shape things precisely because they just want the pain to go away.

Understanding The Problem

One of the things I love about compliance problems is the fact that business people usually haven’t pre-determined a solution. Other projects often come with an assumed solution attached (e.g. “Oh, we’re going to implement XYZ system, so we need you to write a couple of user stories”, leading to us having to work backwards to understand the problem). Usually the brief is really broad (e.g. “Comply with the new Data Protection Act).

This leaves the BA with a significant amount of autonomy and latitude. There will be many ways of solving that problem, and defining the problem space is usually really fun and makes a huge difference to the success. The biggest challenge is people will often think that the impact is small, when actually it is actually far wider ranging. It’s therefore necessary to bring stakeholders along on the journey.

Although every compliance project is different, I typically find starting by identifying and having an understanding of the legislation or regulation is key. Of course, the BA does not need to be a legal expert, but we need to know enough to ask sensible questions and challenge. In many jurisdictions, legislation is written in (fairly) plain language, and you can even start to imagine some of the business rules/impacts that might be implied by it as you read it.

However, an important next step is to work with the relevant business and compliance stakeholders to determine the company’s interpretation of the legislation or regulation. Rarely are these things completely prescriptive. You’ll find words like “appropriate” and “from time to time” and other phrases that show the intent without prescribing solutions. Particularly with new regulations this can be tricky, as there’s no existing convention or regulator judgements to base things on. Ultimately this is often a balancing act, and an area where good facilitation is key.

Ultimately, all of this leads us to a position where we can judge the impact on existing processes, applications, data and more. This is where the requirements or stories get written, but they will trace neatly back to an interpretation of a piece of the legislation or regulation. In many ways scoping can be easier on regulatory projects… a requirement either maps to a piece of the regulation or it doesn’t! (OK, it’s never quite that binary, but it is close).

Fringe Benefits

There’s still the challenge of selling regulatory projects to stakeholders. If we can’t get them excited about them, then there’s a chance their attention will wane and they won’t give us the input we need.

This is where our pain reliever/vitamin analogy comes in useful again. In fact, a good compliance project can be both. A (hypothetical) project to comply with new data protection legislation might ensure we avoid million dollar fines (pain killer) while also providing us the opportunity to cleanse our existing data, so reports are more accurate (pain killer) and we have more flexibility on how we capture future data (vitamin). This is just an example, but I am sure you get the gist.

So, have I changed your view of compliance projects? Either way, connect with me on LinkedIn and let me know. I’d love to hear your views!

Business Analysis: How and Why Do I Need To Evolve?

Written by Esther Folorunso on May 15, 2024. Posted in Articles.

Without a doubt, artificial intelligence (AI) is here to stay and is not going anywhere. Still, it would and has even started disrupting the status quo of many industries and organizations. Well, this is an undisputable, crucial innovation. Still, I would gladly refute Elon Musk’s’ claim that “We will have for the first time something smarter than the smartest human. It’s hard to say exactly what that moment is, but there will come a point where no job is needed” (Marr,2023).

The human factor must be considered in every career path or industry; however, professionals in every space and sphere must evolve with the dynamic and changing environment.

Why do we need to evolve?

Regarding my specialization as a Business Analyst, how and why do I need to evolve?

Recently, there has been a surge in the search for business analysts. This is not because this is a new field; instead, it has existed since the Middle of the Old Stone Age, when the ancestors were able to effectively adapt to the changing natural environment, identify their needs, problems, and opportunities, and develop solutions to make their abode livable and habitable.

What is Business Analysis?

According to the BABOK Guide V3, Business analysis enables change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change and design and describe solutions that deliver value.

The business analysis field has undergone several nomenclature changes and could be referred to by different names in different industries. Some famous names include Business systems analysis, business process analysis, functional analysis, product ownership, systems architecture, project management, usability analysis, user experience consulting, operations assessment, and technical writing.

Business Analysis Requirements

The BABOK Guide v3 views requirements as a usable representation of a need and a design as the usable requirement of a solution. Still, both concepts can be used interchangeably and primarily depend on the context of being used or adopted. Requirements need to be identified, collected, modeled, analyzed, validated, verified, traced, prioritized, managed, and maintained in the lifecycle of a project (Pre and post-project stages). Still, they are all related to a business problem that requires a solution. It could be in the form of an organizational objective that must be met, a business process that needs to be optimized, and an existing solution that needs to be improved or even retired. The BABOK guide v3 defines a Context as the circumstances that influence or are influenced and provide an understanding of a required change. This explains that requirements are broad and depend on the context, such as industry, regulation, project, weather, attitudes, behaviors, etc.

Unpacking BA requirements for Artificial Intelligence

Business analysts should not view themselves as AI experts but understand that they exist to drive change while still understanding the capabilities that AI provides and its complexities. Business analysts must see themselves as a bridge between business needs and AI capabilities.

Understanding the complexities of AI algorithms may and may not be a hard nut to crack; however, with a fundamental understanding of Natural language processing/ machine learning and knowing that most AI tools have been embedded with the critical technology to understand human language, as well as the ability to sieve through large data sets and establish a pattern or relationships, could serve as helpful information. Business Analysis could also establish broader knowledge of AI capabilities.

Also, the core of business analysis is need identification and solution generation. Both are valuable, but the most critical is correctly and efficiently identifying existing needs or problems, thus providing room for developing requirements and generating solutions.

This brings us to the question: can AI help in need identification or problem assessment? Realistically, with established data and available documentation, AI could help identify a need, but Hey, that need would be missing users’ humanity. Whatever solution is generated should provide or enhance satisfaction. However, can AI understand the complexity of the human emotion? With AI, we could develop the goals, desired outcomes, and key performance indicators (KPIs) and define roles and responsibilities, but how can usability be assessed?

With AI in business analysis requirements comes data quality, security, and privacy requirements. Every requirement generated for BA activities must answer these 3 data prongs. How reliable is the requirement gathered? If a requirement is trustworthy, it could speak to its quality. Was the requirement confirmed, verified by necessary stakeholders, and validated to align with identified needs?

To achieve these three tasks, the requirements must be specified and modeled to fit the organization’s environment with due consideration of the stakeholders involved. The modeling can be in the form of matrices or even diagrams, for which AI could be beneficial. Still, the prompts must be correct, which reflects the data quality and reliability. Using AI to generate, specify, or even model requirements (inexhaustive) would lead to data security and privacy prongs.

Privacy and security are critical issues in the professional world, not just business analysis. Before every BA task, how AI should be adopted and what data should be provided as AI prompts need to be addressed. There is a need to protect user privacy and define adequate security measures, as IT systems are susceptible to attacks. Privately owned AI tools can still be attacked; strict security and privacy rules must be strictly followed.

This is also very important as some requirements can serve as Unique selling points for a specific business or even a trade secret. In this situation, the use of AI might be optional.

Conclusion

Knowing that the Business analysis role will continue to evolve as a context evolves or dictates or even as a business dictates while putting Artificial intelligence as an addition in a context, it is recommended that the requirements generated in previous contexts be adequately managed and maintained for reuse. When done correctly, this would enhance knowledge sharing as AI could help create a central repository for past project requirements, thus making it easier for business analysts to learn from past experiences and build on existing knowledge, which could lead to overall project success.