Tag: Training

Key Documentation Prepared by Business Analysts

Written by Sushmala Sabala Ravindrnath Reddy on June 8, 2024. Posted in Articles.

Documentation is the core part of the business analysis process that provides clarity, standards, and process details that help organizations in decision-making. The documentation provides information about the guidelines, requirements specifications, roadmaps, communications, blueprints, and solutions that are crucial for the execution of the project.

Business analysts create various documents to translate complex requirements into accessible language that can be understood both by the technical and non-technical staff of the team. Business analysts bridge the gap between the business stakeholders and the technical team by creating various documentation that provides clear, concise information on the problem statement, business objectives, key requirements, restrictions, exclusions, and solutions that help in the alignment of the team.

A well-crafted document by the business analyst helps the organization secure the budget required for the execution of the project and forecast any risks during the implementation of the project. Documentation also helps to align the project with the overall organization goal and describes the value added to the organization goal by the execution of the project.

Key Documentation Prepared by The Business Analyst

Business Requirements Document (BRD):

The business requirements document is one of the most common documents that is prepared by a business analyst. BRD captures the big picture of the project and stakeholders’ business needs. It provides detailed information on the project goals, objectives, and approved solutions, along with the key deliverables that define the scope and associated benefits of the project’s execution.

Although the fields in the BRD change from organization to organization, here are the key fields in the BRD document:

Project details

The project details section includes information such as project name, project number (if applicable), organization department details, business sponsor details, key stakeholder information, project manager, architects, and details of the technical team members working on the project.

Project Overview

The project overview provides high-level project objectives and their benefits. This is the section one would read to get the complete summary of the project.

Project scope and out-of-scope items

The project scope lists the deliverables of the project; this helps both business stakeholders and the technical team be on the same page and provides clarity on requirements.

Project out-of-scope lists all the items that are identified as outside of the project scope. Identifying the out-of-scope during the initiation of the project helps to avoid any scope creep during the execution of the project.

Assumptions

The assumptions section provides a complete list of assumptions relative to the scope of work. These assumptions are agreed upon and approved by the business stakeholders.

Current and future state business processes

The current state of the of the business process depicts a snapshot of the current state of the organization, and the future state highlights the deliverables of the project.

This section helps to have a side-by-side comparison of the enhanced functionality that will be achieved by the project.

Business requirement

The business requirement is the main section of the BRD. This section lists all the action items that are required to achieve the project scope.

Along with the action items, it is important to assign priority to each item, as it helps the technical team identify which task they need to pick first.

For projects where the implementation of the business requirements is divided into multiple releases, it is important to include release details in the business requirements section.

Business rules

The business rules section consists of all the project-relevant business rules that were agreed upon and approved by the stakeholders. Business rules usually trace back to business requirements.

Project risks

The project risks section includes all the risks identified and mitigation measures for the risks. Identifying the risks ahead helps the team focus on their tasks and reduces uncertainty during the execution of the project. Identifying risks earlier also helps to make better business decisions.

Cost-benefit analysis

Cost-benefit analysis is the last section of the BRD. In this section, you describe how the project objectives will make a profit for the organization and estimate the ROI that can be achieved with the execution of the project.

Functional Requirements Document (FRD):

The Functional Requirements document provides information about the business problem and approved solutions for the problem. FRD is the contract between the business and the technical team to deliver the accepted solution. It provides information about key functionality that a solution system needs to have and the performance of the system. FRD captures all the nitty-gritty information about the solution product.

The FRD document is different from the BRD , as FRD focuses more on the nitty-gritty details of the solution and BRD focuses on the broader view of the overall project.

The style and fields of the FRD document change from project to project. Here are the key fields of the FRD document:

Project details

The Project Details section includes detailed information about the project, such as project name, project unique number, organization department details, business sponsor details, key stakeholder information, project manager, architects, and details of the technical team members working on the project.

Project Description

An overview of the project, its benefits, and the approved solution. This is the section one would read to get a complete overview of the project.

Project Background

The project background describes the problem statement of the project and the purpose of the project.

Project scope and out-of-scope items

The project scope lists all the deliverables of the project, including the technical details of the solution system. This section helps both business stakeholders and the technical team be on the same page and provides clarity on requirements.

Assumptions

The assumptions section provides a complete list of assumptions relative to the scope of work. These assumptions are agreed upon and approved by the business stakeholders.

Functional requirements

The functional requirements section describes what the system must do. Functional requirements must be drafted in a way that provides complete information about the business needs and specifications needed in the solution system.

Operational requirements

The operation requirements section describes how the system must operate, i.e., how fast the system should respond, how many responses the system needs to provide in the given time, etc.

Requirement Traceability Matrix

The requirement traceability matrix is described in detail in the section below.

The requirement traceability matrix is used to track the implementation of the functional requirements. The RTM is updated throughout the project to show the progress made in the implementation of the functional requirements.

Glossary

List all the business terms and their definitions.

Non-Functional Requirements Document

The non-functional requirements document defines how the system must behave. This section is crucial for the execution of the project; it describes the capabilities of the system operation and its constraints. Non-functional requirements provide information about system users, scalability, operation, hardware and software, performance, retention and capacity, accessibility, and security.

The solution system can still operate by just executing the functional requirements, but it might not meet all the business expectations in terms of security, performance, scalability, etc.

Below are the fields that are going to be part of the Non-Functional Requirements document:

Security

Security is the most important section of the non-functional requirements document. This section captures all the security guidance that needs to be incorporated by the project execution team during the implementation of the project. It captures security architecture guidance, authentication, data security, risk management, and technology development guidance.

Users

This section provides information about the business expectations for the number of users that will use the system. And a number of concurrent users that the system can support without letting the system performance degrade.

Scalability

This section captures business expectations for the data volume that the system must support. It also captures the volume that the system can support during peak and non-peak times.

Operational

The operational section is different from organization to organization; this is the section that captures the Tier 1, Tier 2, Tier 3… (Severity 1, Severity 2, Severity 3…) incidents that arise and the action plan to resolve the incidents. Based on the severity of the incident, a recovery strategy is defined to get the system back up and running.

Hardware and software

This section includes information about any new hardware components required for the execution of the project and the specifications of the hardware components.

It also captures any new software installation or software configuration required for the completion of the project.

Performance

The performance section answers questions such as how fast the system needs to perform. What should be the response time of the system?

Retention and capacity

The retention and capacity section captures data types that need to be stored in the database and the data retention time frame required for the data. It also talks about the capacity of the database and the various logs that will be available.

Accessibility

This section captures information about who can access the system and the minimum requirements for accessing it.

Requirement Traceability Matrix

The Requirement Traceability Matrix is the document used during the implementation of the project to trace the requirements to its test cases and further to any defects. The main purpose of this document is to prove that all the requirements have been successfully executed and tested by the project execution team.

The requirement The traceability matrix generally consists of the following fields:

Requirement Number

The requirement number is the business requirement or the functional requirement number that is captured in either the BRD or FRD document based on organization standards. All the requirements for the project are listed in this column.

Requirement description

A brief description of the requirement.

Test case number

The test case number is the unique number used to identify the test case for a particular requirement.

Testcase description

A brief description of the test case and its scenarios.

Test execution result

This section captures if the test case was a ‘Pass’ or Fail’ during the execution of the test case.

Defect number

If the test case execution fails, then a corresponding defect is created, and this section captures the defect’s unique number.

Defect Status

This section is used to capture defect status such as ‘Open’ or ‘Complete’. This helps to know if the defect was successfully fixed and tested.

Conclusion

Throughout this paper, we have discussed various documents prepared by a business analyst that play a crucial role in the project’s success, driving communication and streamlining the process. From the initiation of the project to the implementation and final deployment of the product, these key documents guide the team through the project lifecycle and ensure the team is aligned with business objectives at every step of the project.

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!

“BREAKING THE FRAME”: A Paradigm Shift in Problem-Solving

Written by Neethu Nair on March 21, 2024. Posted in Articles.

In the realm of business analysis, problem-solving isn’t just a task; it’s a craft. We’re constantly challenged to find solutions to complex issues that impact our organizations’ success. Let us explore a transformative concept in problem-solving: “Breaking the Frame”!

At its core, breaking the frame is about challenging the status quo and approaching problems from a fresh perspective. It’s about stepping outside the boundaries of conventional thinking to uncover hidden opportunities and drive meaningful change.

Consider the “Slow Elevator Story.” Tenants in a building complained about the sluggishness of the elevator, prompting the manager to seek solutions. Traditional problem-solving methods would have led to expensive elevator upgrades. However, by thinking outside the box, a simple yet effective solution was found: installing a mirror in the elevator. This small change altered the perception of time, reducing complaints without the need for costly renovations.

So, how can we apply this concept of breaking the frame to our own problem-solving endeavours?

Reframing the problem: Instead of accepting the problem as presented, dig deeper to uncover its root causes and underlying assumptions.
Diverse Perspectives: Embrace diverse viewpoints and collaborate with colleagues from various backgrounds to gain fresh insights into the problem.
Creative Solutions: Be open to unconventional ideas and approaches that may lead to innovative solutions beyond traditional boundaries.
Holistic Analysis: Consider the broader context surrounding the problem, including external factors, stakeholders’ perspectives, and long-term implications.
Iterative Approach: Adopt an iterative problem-solving approach, where solutions are continuously refined based on feedback and new insights.
Experimentation: Embrace a culture of experimentation, where hypotheses are tested, and failures are viewed as learning opportunities.
Data-Driven Decision Making: Utilize data and analytics to inform problem-solving, ensuring decisions are grounded in evidence and insights.
User-Centric Design: Place the end-user at the centre of problem-solving efforts, empathizing with their needs and preferences.

The elevator may or may not be slow, but the point here is “Is there a better or smarter way to solve the problem?” . By reframing our approach to problem-solving, we can uncover hidden opportunities and propel our organizations forward.

In the realm of business analysis, breaking the frame isn’t just about solving problems; it’s about driving innovation and creating value. By reframing our approach to problem-solving, we can uncover hidden opportunities and propel our organizations forward.

“If I had a hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 mins thinking about solutions” – Albert Einstein

Therefore, let’s never simply acknowledge the problem as it’s presented. Instead, let’s break free from conventional thinking, explore beyond the established boundaries, and rephrase the given problem to uncover its underlying root causes. By doing so, we can avoid solving the wrong problems and focus on addressing the correct ones.

The key to effective problem-solving lies in embracing creativity, diversity, and a willingness to challenge the norm. Let’s embark on this journey of breaking the frame and revolutionize our approach to problem-solving in business analysis.

What’s The Point of Peer Review?

Written by Christina Lovelock on February 15, 2024. Posted in Articles.

When time is tight and the pressure is on, it feels like ‘peer’ review is a luxury we cannot afford, but what’s the cost of this decision?

What Is Peer Review?

Sharing our analysis outputs (whether this is documents, models, presentation slides or feature tickets) with other business analysts before they are shared with any other stakeholders is the essence of peer review. BA peer reviewers should be able to share useful observations and insights about the output, whether or not they have specific business domain knowledge. If something is not clear to a fellow BA, there is a good chance it will not be understood by customers, suppliers, stakeholders and other recipients.

Why is Peer Review Valuable?

Many business analysts have a tendency towards perfectionism, and the longer we work on something without feedback, the more disappointing it is to receive any feedback, however constructive. It is much harder to accept and incorporate feedback on a polished final draft than an early rough draft. We need to share our work early in the process to be able to influence our own thinking and approach, and prevent us making significant errors or omissions.

Why is Peer Review Valuable?

Peer review is valuable from multiple perspectives.

#1 The producer

The person who created the output. We all bring assumptions to our work, whether this is a single piece of acceptance criteria, complex model or large document. The producer gets the benefits of a fresh perspective and the opportunity to catch errors and drive out assumptions. A peer review should be a way to improve quality without any worry of reputational or relationship risk. It also provides the opportunity for increased consistency across BA products and to learn lessons from other business areas.

#2 The peer reviewer

There is always something to gain from seeing how someone else works, whether they have more or less experience than us, and wherever they sit in the organisational hierarchy. So as well as making a valuable contribution to our colleague’s work we are likely to learn something through peer reviewing.

#3 Stakeholders

Any business, dev team or project stakeholders that will also be asked to review/validate/approve the deliverable will benefit greatly if a peer review has already taken place. Some errors and ambiguities will have been addressed, saving them time and increasing their confidence in the quality of the output.

The Review Triangle

This model reminds us that the highest number of errors should be spotted and rectified by the person creating the output, as part of a specific review phase.

Self-Review

The model emphasises the need for self-review, which is a separate activity to creating the analysis output, and involves:

Standards check (adherences to templates, branding and guidelines)
Assumptions check (provide key, glossary etc.)
Accessibility check (e.g. readability, compatibility with assistive tech, alt text for pictures)
Sense check
Error check
Spelling and grammar check.

Moving from a ‘creating’ to ‘reviewing’ mindset can be achieved by taking a break, and switching to reviewing when we return, or moving to a different device as this often forces us to look at something differently.

Peer Review

Peer review is also about adherence to standards, and is valuable even when the reviewer does not have relevant subject matter knowledge. They should be able to identify and challenge assumptions made, spot logic knots and highlight the use of acronyms and jargon. They can also share insights and observations from their own experience, such as level of detail and formats preferred by different internal audiences.

Stakeholder Review

Stakeholders should not be faced with errors that we could have easily caught through self or peer review. This does not mean we should only share perfect and complete outputs, but that we give stakeholders the best chance of spotting significant gaps and fundamental errors by removing low level distractions.

Many stakeholders find it difficult to simply ‘ignore’ spelling and other small errors. This level of error can undermine their confidence in our analysis.

Depending on the number of stakeholders and the complexity of the output, it is often better to do a group review exercise (synchronous) rather than a comments based (asynchronous) review. This is for several reasons:

Confidence everyone has actually seen what is being reviewed/validated/agreed
Prevents multiple stakeholders making the same (or conflicting) observations
Changes can be discussed and agreed.

Conclusion

The benefits of peer review, to individual BAs, the internal BA community and to our stakeholders and customers is significant. Attempting to ‘save time’ by avoiding this activity is a false economy. Organisations that aspire to be a truly ‘learning organisation’ encourage and enable effective peer reviews. Where organisations don’t place emphasis on this, BAs can choose to role model this commitment to quality and learning, and lead by example.

Further reading

Delivering Business Analysis: The BA Service Handbook, D Paul & C Lovelock, 2019

Don’t Just Break the Mold, Shatter It: Rebel Recipes for the Business Analyst Maverick

Written by Paul Benn on November 16, 2023. Posted in Articles.

Photo by Nik on Unsplash

Picture this: You’re sailing on the vast ocean of the business world, navigating the wild waves of change. As a business analyst, you’re the captain of your ship, and your map? It’s pre-skilling – the compass that keeps you not just afloat but steering ahead of the storm. Gone are the days of up-skilling after the fact or re-skilling in the wake of a career hurricane. We’re talking about getting your sea legs “before” the tides turn. Ready to dive in? Let’s set sail!

Why Fit In When You Can Stand Out?

In the high-speed freeway of today’s business, being market fit isn’t just about keeping pace – it’s about setting the pace. As a business analyst, you’re not just in the driver’s seat; you’re also the navigator, the pit crew, and the spark plug all in one. Your adaptability isn’t just a cool party trick; it’s your bread and butter.

Pre-skilling is like having a crystal ball. It’s about harnessing your inner oracle to forecast the skills of tomorrow and training in them today. You don’t just react to change; you dance with it, two steps ahead, making waves rather than riding them.

Talent and Skill Development: The Game’s Changing, Are You?

If you think of your career as a video game, pre-skilling is the cheat code that helps you level up “before” the boss fight. The digital domain is like a game that updates overnight – new rules, new players, new goals. Traditional skill development is playing catch-up, but pre-skilling? It’s got you downloading the updates before they even hit the main server.

Pre-skilling: Not Just Another Buzzword

You see, pre-skilling isn’t a band-aid; it’s a blueprint. It’s not learning to fix a leak; it’s engineering a ship that rides the waves like a pro. It’s the difference between retrofitting your armor mid-battle and showing up with an indestructible suit.

Sailing the Pre-skilling Seas: How to Do It Right

So, you’re convinced pre-skilling is the way to go. But how do you sail these uncharted waters? Here’s your treasure map:

1. Potential Over Past Glory

Forget what you were; what you “can be” is the real gold. Cultivate a mindset that treasures soft skills – the ability to learn, adapt, and bounce back like a superhero.

2. Feedback is Your North Star

Steer by the stars of feedback and career guidance. Have real talks with the crew – managers, mentors, peers – to chart a course that aligns with the future, not just the now.

3. Broaden the Horizon

Your skill set is an ocean – vast and deep. Don’t swim in the kiddie pool. Dive into new knowledge areas, and you’ll find yourself swimming with the dolphins instead of the goldfish.

4. Captain Skills

In the AI-cohabited world, leadership is your sword. Sharpen it. Guide your crew with vision, inspire them with your cause, and lead them through the foggy seas of change.

5. All Hands on Deck for Diversity

Steer clear of the Sirens of sameness. Champion cognitive diversity and inclusive leadership. Different minds on deck make for a robust and innovative ship.

6. Spyglass on Trends

Keep your spyglass fixed on industry winds and currents. Trend analysis isn’t just fancy talk; it’s how you predict the next big wave and ride it like a pro.

7. Market Maps for Skills

Use market analysis to spot uncharted islands of opportunity. Customize your skill set to be the first to plant your flag and claim the land.

8. Bridging Skill Gaps

Perform a gap analysis like you’re checking for leaks. Find where you’re lacking and patch it up before it’s time to face the kraken.

9. Strategic Pre-skilling

Combine all these tools, and you’ve got yourself a pre-skilling compass that points true north. Use it to not just stay on course but to discover new worlds.

Conclusion: Charting Your Course to Market Fitness

So, what’s the final word for our intrepid business analysts navigating the shifting sands of the corporate landscape?

The key takeaway is that the art of pre-skilling is not just a strategy; it’s a dynamic, forward-thinking mindset. It’s about embracing the power of foresight and the excitement of what’s yet to come. In a world that’s racing towards an unknown future, pre-skilling is your secret superpower. It’s the equivalent of giving your career a jetpack, where others might settle for a safety net.

Remember, the sea of business is as merciless as it is magnificent. The winds of change are relentless, and the tides of technology wait for no one. By embracing pre-skilling, you become the captain of your destiny, navigating through the gales with grace and gusto.

To thrive as a market-fit business analyst, you must treat change like it’s your best friend. Why? Because it is! Change is the one constant you can rely on to bring you new opportunities, insights, and paths to personal and professional growth. When you pre-skill, you’re not just keeping pace; you’re setting the pace, transforming from a player to a game-changer in your industry.

By investing in pre-skilling, you’re not just enhancing your resume; you’re forging a professional identity that’s as resilient as it is versatile. This identity becomes your brand, signaling to employers and colleagues alike that you’re not only equipped to handle the challenges of today but also the revolutions of tomorrow.