Skip to main content

Tag: Communication


Contribution as a Form of Professional Development

As practitioners of change, we are probably all acutely aware that we need to continually develop. There is always more to learn, and there are countless ways of learning it. The fact that you are reading this article now, on a business analysis website, shows that you are interested in your professional development—and kudos to you for doing so! After all, it is those that develop and keep up to date that will thrive in an increasingly competitive environment.


However, professional development is often seen as a consumption-based activity. Ask a typical BA what development activities they have undertaken recently, and they’ll likely respond by telling you about articles they’ve read, training they’ve been on, webinars they’ve watched and so forth. All of these are fantastic ways of hearing different perspectives, and it is great that there are so many cost-effective (and free) options out there.


From Consumption to Competence (Through Practice)

Yet consumption alone rarely enhances a skill. I could ‘consume’ (read) a book about how to fly a passenger jet, yet you probably wouldn’t trust me to fly one if that’s the only experience I had. In fact, even if I’d been on a one-day course and we’d done some group-work simulating flying, you’d probably argue that isn’t enough. And of course you’d be right, pilots (presumably) need lots of time in the simulator, and hours flying generally, before they are qualified to fly a commercial airliner.


Although you or I are unlikely to be racing to the cockpit of an Airbus A380 any time soon, it’s likely that we will need to learn new skills, techniques and concepts. The broader point here is that just reading about them, or watching a YouTube video about them isn’t enough. Actually using them is crucial. This is where the ‘rubber meets the road’, where even more learning happens, as the technique or concept is put into practice within a particular context. It’s often the case that some adaptations are necessary—a technique that works just fine in the classroom may need some finessing to work in the real world. And that’s just fine, deliberate and selective adaptations to the nuances of the world are precisely what we should do as analysts.




From Competence to Contribution

It’s often been said that if you want to really test your knowledge of something, try and explain it to others. There is a strong element of truth in this, as anyone who has ever created a presentation or training course will tell you! Putting together an article or presentation tends to highlight any gaps in thinking, and it’s an opportunity for reflection.

This is where contribution to the BA community can become part of a deliberate professional development strategy. Perhaps there’s a technique that you’ve mastered: that would be a fantastic topic for a ‘skills exchange’ session with your colleagues. Perhaps that would involve a short presentation and a Q&A. Your colleagues would learn about the technique, within the context of your organization and by creating the presentation (and responding to the Q&A) you’d likely learn more too.  A real win/win.

It’s possible to go even further. While we may be members of a Community of Practice within our organizations, we could also consider ourselves to be members of a global Community of Practice of interested BAs. You and I are connected via this article and this website. Others are connected through social media networks such as LinkedIn.


This provides us with the opportunity to write, blog, create videos and share experiences with people outside of our organizations too. Of course, it’s crucial not to share anything confidential or commercially sensitive, but sharing ‘how to write a user story really well’ or ‘how I used use cases to clarify complex requirements’ is unlikely to be controversial! It also has the advantage that it helps us all to connect with other interested BAs around the world. Hitting the ‘publish’ button can be scary, but the act of creating something is hugely worthwhile, and others will benefit from it.

Incidentally, if you’re reading this thinking “I’m too inexperienced to write or create anything” or “I don’t have anything worth writing about”, in my experience you are probably doing yourself a disservice. BAs tend to be somewhat modest, and everyone has an interesting professional story to tell!


Take a Blended Approach

Community contribution can be part of a blended professional development plan. Alongside consumption and practice, it can be a great way of reflecting, while also sharing experiences and building BA networks.  The nature of the blend will vary depending on practitioner, but considering the options is key.

And if you do decide to create and share something, be sure to connect with me on LinkedIn and let me know about it!


A Business Analyst/Project Manager Guide to Untangling the Technical/Process Debt Mess

Usually, there would be a discussion about how only IT Business Analysts encounter technical debt as it is a Code Mess. Regardless of the industry you are working in, it may be something other than a technical debt. Still, when you are working on projects that can contribute to a similar concept or backlogs that were cleared to meet deadlines or immediate requests but weren’t cleared the right way, it is referred to as a process debt. Technical debt is specific to code, but accumulating debt from shortcuts applies to any project. Process debt refers to problems created by rushed or incomplete work outside of coding. Both technical and process debt can hinder future progress and require additional effort to resolve.


Who are the Culprits of Technical/Process Debts?

Truthfully, there isn’t one specific culprit, as fingers should be pointed at the project managers, business analysts, developers, and business stakeholders; hence, there is shared blame. By working together and understanding the long-term costs of technical/process debt, teams can make better decisions about how to build software, products, or projects.


Is Technical/Process Debt in itself a bad thing?

In some situations, technical debts can be a strategic decision to get a product or a feature out the door as quickly as possible. This might be because of need, deadlines, unclear or evolving project requirements, or even resource shortages. In this scenario, it might not be a bad thing in itself, but the key is to be aware of whatever debt accumulates and ensure a strategy to pay it down eventually. It becomes bad when it isn’t fixed and becomes the norm.


Another question would be, what is the role of Business Analysts and Project Managers in the Debt Den?

We exist as a bridge between business needs and technical realities. Why, as a bridge, most of us do not write the codes, but the individuals who do are part of our key stakeholders. We must keep them on track to slash the technical debt to its bare minimum until it is non-existent. By acknowledging that everyone can contribute to a project’s “debt,” teams can work together to prioritize quality and avoid shortcuts that create problems later.



What are some reasons for a quick fix that could lead to the accumulation of technical/process debts?

Deadlines (Realistic/Unrealistic): This is usually the primary cause of debts. Truthfully, some of these deadlines may be unrealistic, and some might even be realistic. Still, before deadlines are fixed for every task in a project, business analysts must have estimated the effort required for every feature/product/process. This estimation should have considered the complexity of such a task, possible roadblocks, stakeholders’ expectations, and risks. If this estimation isn’t done appropriately, unrealistic timelines or deadlines might be created. Another focus would be a dependence on Speed versus quality. In an ideal world with realistic deadlines and processes, there would be no need to cut corners; however, cutting corners is almost unavoidable when the pressure is on delivery by a specific date. In code writing, developers should have ample time to write clean, well-documented code that’s easy to understand and modify. But under pressure, corners are cut. Code becomes spaghetti-like, with functionality prioritized over readability and maintainability. This makes fixing bugs and adding new features later much more complex and time-consuming.


Proper time estimation and setting realistic deadlines, allocate buffer time in project schedules to account for unforeseen issues or delays, allocate dedicated technical/process debt cleanup sprints, or integrate small improvements into regular development cycles and existing business processes.


Unclear or evolving project requirements: If the requirements are ambiguous or not well-defined, this could lead to technical debts. The business analyst’s role is to ensure the requirements are clearly identified, verified, validated, and accurately prioritized based on business value and user needs (other prioritization criteria exist). Potential relationships and dependencies are also expected to be accurately identified. When this is correctly done, it ensures that the project scope is clear and the project direction is visible to all.


A proactive requirement-gathering system is recommended where early and frequent stakeholder involvement exists in the project/software development lifecycle. Different elicitation techniques can be used, but regardless of which technique is used, there must be a comprehensive understanding of needs and expectations. Also, remember that features or requests must be based on business value/user need/impact, not sentiments.


Absence of code/process reviews: This would serve as a quality check to ensure that inefficiencies and errors do not exist. Code reviews act as a safety net, catching bugs and potential issues before they become significant problems. Inexperienced developers are more likely to make mistakes that can introduce bugs into the codebase. Also, if processes aren’t documented or reviewed, they can be applied inconsistently across the team. This can lead to confusion, errors, and wasted time.


Code reviews by senior developers can catch these errors early on, preventing them from becoming more significant problems and leading to a cleaner, more maintainable codebase. This reduces bugs, improves performance, and makes future development more straightforward. For processes, reviews provide a structured way to identify bottlenecks, redundancies, and areas for improvement within workflows. This allows teams to address these issues and streamline processes.

It is essential to state that Code/Process reviews should be seen as a learning opportunity, not a blame game. A positive and collaborative review environment encourages open communication and helps team members feel comfortable asking questions.



Technical and process debt doesn’t have to be a burden. By equipping yourselves with the right tools and strategies, you, as BAs and PMs, can become champions of clean code and efficient processes. You can expose these debts, develop a plan, and work together to build a robust and sustainable foundation for your projects. Remember, a little planning today can save a lot of headaches tomorrow –  so go ahead and untangle that debt mess!


Beyond Jargon: Bridging the Gap Between Precision and Clarity

A while back, I was taking a flight from London City airport. It’s an airport I don’t fly from very often, and I was looking for a place to fill my water bottle. Unlike other airports, I couldn’t find a water fountain anywhere. The airport staff all seemed busy, so I did what any good BA would do, I took to Twitter (or is it X?) to ask the airport social media team where I could get some water.

I got a reply really quickly, with the social media team letting me know that I could get water from any food concession in the airport. So, I went to one of the food shops to grab some sandwiches and got them to refill my bottle at the same time. Problem solved.

However, another Twitter user pointed out at the time that it’s a little odd they used the term food concession and not food shops or food stalls.  I mean, what even is a concession? A little bit of digging uncovers this definition:


“A retail concession is a dedicated space within a single-brand store that is used by a non-related but complementary brand. Retail concessions are essentially shops within a shop…“ (Quote from Unibox site)

So here, the airport is technically correct. The food shops are technically concessions, they are ‘shops within a shop’, or in this case ‘shops within an airport’ (let’s face it, airports feel like one big shop these days!).

But who, outside retail, regularly uses the term ‘concession’? And in the context of my query, does it really matter that it’s technically a ‘concession’ and not a ‘shop’?


A Balance of Precision and Understandability

As it happens, I did understand what was meant, so this wasn’t an issue. But I wonder if a tourist who has a basic grasp of English would understand (this was an airport after all). It strikes me that with communication there’s a balance of precision and understandability.

Some terms will communicate things very precisely, but only to those who are within a domain. My career started in insurance: words like “cover”, “peril”, “loss’, “policyholder”, “insurable interest” have very specific meanings. Those things are important within the insurance company… but outside most people just want to “insure their car” or “protect their house”.  Of course, for all sorts of legal and regulatory reasons, there needs to be precise and formal T&Cs and policy wordings. But the way that the organization communicates needs to be in a way that’s understandable.




Does Your Internal Lingo Accidentally ‘Trickle’ To The Outside?

This is an area where BAs can help. Often, Subject Matter Experts (SMEs) will be defining the text that needs to appear on websites, letters, emails and so forth. SMEs are usually fantastic stakeholders with so much knowledge. They are great to have on board!

Yet, the challenge of having so much knowledge is they might forget what it’s like not to know so much. An SME who has worked in insurance for 30 years might not easily remember what it’s like to buy your first insurance policy. Yet, it’s likely that the solutions we define (and the communications that go out) will need to be understandable to someone completely new to insurance too.

Highlighting where internal lingo has inadvertently trickled to the outside world can be useful. Asking questions like “would an average customer understand this phrase?” or “what about someone who has never bought our products before, would they know what this means?” can help. Having a set of personas can be even more helpful.


Prototype, Test and Learn

Another stage that is often missed when defining and designing websites, emails, letters and other forms of interactions with customers is to take the time to test and learn. Showing a customer a rough prototype with the wording and seeing how they react would be a great way of getting an early steer. Prototyping a letter that is going to be sent to 150,000 subscribers and getting input from 100 might help uncover misunderstandings or ambiguities. This might save thousands of confused calls to the call center, and thousands of quizzical emails.

In summary, communication is always a balance of precision and understandability. Knowing the audience, testing and learning helps avoid miscommunication and misunderstanding. BAs are well-placed to foster these types of activities.


Key Documentation Prepared by Business Analysts

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

  1. 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.




  1. 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.

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.

  • 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.


  1. 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.



  1. 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.



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.


Unpacking BA Requirements for the Blockchain Industry

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.



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.