Skip to main content

Tag: Requirements

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.

Advertisement

 

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.

Solution:

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.

Solution:

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.

Solution:

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.

 

Conclusion

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!

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.

 

Advertisement

 

  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.

 

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.

How to Prevent Project Burnout Before It Strikes

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:

 

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

 

Advertisement

 

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

 

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

 

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

 

Overcoming 3 Common Challenges of Business Process Modelling

Identifying and depicting business processes is the first step towards understanding the current state and developing a plan for the future. Business analysis activities are often oriented towards enabling and supporting change. The most important aspect of having a process model is that it enables a business to quickly see how well all the different aspects of the business are aligned to achieve common goals. When there is misalignment, it becomes evident very quickly in the model, and the business can plan how it will deal with getting properly aligned again.

Business analysts, using primarily elicitation and modelling techniques, try to find out the means by which an organization carries out its internal operations and delivers its products and services to its customers.

 

However, process modelling and analysis can be tricky. Below are some challenges:

 

  1. Figuring out the tasks

It’s difficult to obtain information about the complete process when there are many engaged departments. Usually every part of the process is aware of the specific tasks and activities in which they’re involved, but they miss the whole picture. Frequently, after the process modelling has been finalized, the engaged actors can holistically understand the end-to-end process.

  • Trying to figure out first who is involved and the starting and ending points of the process is crucial in order to drill down and find the details for each step. It may be a good idea to begin with the most experienced actors or those who have a helicopter view. It is more than important, however, to validate your insights against other sources of information to be sure that you have captured accurate information.
  • Having information about the industry context may be helpful, as the basic business processes among organizations in the same industry have things in common. This, of course, does not mean that the specific organization’s parameters should not be taken into consideration.

 

Advertisement

 

  1. Systems Thinking

Consistency, It’s a necessary verification criteria in process identification and modeling. The steps and tasks involved in the process should make sense as parts that form wholeness, not as independent elements. In order to meet deadlines and get immediate results, business analysts frequently reduce the amount of time spent understanding the context. Delivery of value through a process modelling initiative will be limited, as long as we think analysis is about figuring out just specific characteristics of a solution that are already predefined in their minds. Systems thinking is a vital mindset that allows a business analyst to understand the as-is state and communicate it in a way that will be commonly understood by all stakeholders. This is an essential step in defining the future state.

 

 

  1. Understand how the process fits into its environment.

If a model doesn’t define how it fits into its environment, it will struggle, and its likelihood of resounding success is greatly diminished. Understanding the fit of a process within its internal and external environment is a complex, multi-faceted exercise. A business analyst needs to understand who the actors are, what their needs are, and how they can be reached. The business also needs to know who its suppliers are. Only when all relationships between the internal and external environment are understood can the business analyst ensure it is shaping an effective process model.

 

Identifying misalignment issues and understanding problems and opportunities for the business can be triggered by process analysis via modeling. Through effective process modelling, the following questions can be answered:

  • What processes does the business currently maintain?
  • How do the processes fit within their environment?
  • How do the processes create and maintain value in the external and internal environments?
  • What is the gap between the as-is and to-be states?

Become a Better BA: Study History

As a business analyst or someone aspiring to be a business analyst, do you seek out better understanding in your daily life as well as at work—exploring the angles and the what-ifs?

I think many business analysts have a mindset to explore and uncover truths that others might not.

Let me share a recent related experience.

 

During a trip to France several months ago, I crowded into the museums amid the other tourists. Despite the bustling, I re-connected with the beauty, the feeling of inspiration, and the magnificent presence of the best works of art in the Musee d’Orsay, the Claude Monet House in Giverny, and the Dali Museum.

I noticed something was different this time.

Moving mindlessly with the flow of the other tourists from one piece to another felt flat and meaningless. Most tourists approached each piece with a camera first, skimming the surface with a click and a view, posting to social media, and then turning attention to the next piece.

I wedged myself in to get closer as I listened to the audio guide. Skimming was not what I was here for this time. I was hungry for the history of each piece: the background of the artist and the details of the time and place in which the piece was created. Give me history, context, and the human perspective.

 

Learning and embracing history has quite a few benefits for building on context, scope, and possibilities.

  • It fosters knowledge and deeper understanding, contributing to a broader perspective.
  • It exposes multiple details associated with an event, which helps improve understanding.
  • It establishes connections between events (even seemingly unrelated events).
  • When expressed like a story with characters and settings, it improves comprehension and retention.
  • It can provide a base for drawing conclusions and, therefore, applying learning.

That trip to France has ended. The journey to apply the art of historical understanding to the challenge of business analysis is ongoing.

As CBAPs, we look to BABOK for guidance in our work. We use it to provide the pillars of understanding needed to do what we do in the best possible way.

Wouldn’t it be cool if we could tap into a fresh methodology that has the power to augment the resources in BABOK?

…and in walks history. You thought you wouldn’t need it after college, probably even after high school, right? Let’s explore this.

To study history effectively, one needs to engage in most of the following tasks:

  1. Take a chronological account of events and tie them together with other events.
  2. Be able to distinguish what events lead to other events to establish cause and effect.
  3. Be able to make connections between seemingly disconnected pieces of information.
  4. Keep track of the players and how they affect the events.
  5. Identify and extract the key information.
  6. Gather related information to fill in the blanks to build a more complete picture.
  7. Apply critical thinking to assess your own understanding.
  8. Be able to apply and project your own understanding based on the facts.
  9. Do not be afraid of research or large quantities of information.

 

An effective business analyst needs to be able to:

  • take in a tonne of seemingly disparate information.
  • research and uncover additional information.
  • Talk to many different people.
  • synthesise all the information.
  • put it into context (many times we have to build an entirely new context from all the information!)
  • …and then be able to express it in a way that multiple groups of people will understand it and be able to draw conclusions from it.

We look to BABOK for guidelines on how to approach this process.

If you study history, you are honing skills that BABOK teaches. In effect, you have another tool to become a better analyst.

History is usually presented as a set of sometimes-chronological facts that you need to piece together and tie to other facts. From this, you can determine cause and effect to get a bigger picture of how different events are related (represented by #1 and #2 stated above).

 

Advertisement

 

Think about the BABOK task “Conduct Elicitation.” The purpose of this task is “to draw out, explore, and identify information relevant to the change.” The task has three types: collaborative, research, and experiments, all of which rely on gathering and organising usable information and facts.

The BABOK task “Analyse Current State” contributes in a similar way. This task’s purpose is “to understand the reasons why an enterprise needs to change some aspect of how it operates and what would be directly or indirectly affected by the change.” The inputs to this task are elicitation results, and they include elements of external influencers, organisational structure, and culture to support the analysis.

Another parallel I find interesting is between #7 and #8 above and the BABOK tasks “Analyse Potential Value” and “Recommend Solution and Recommend Actions to Increase Solution Value.” You must be able to absorb and synthesise the information and come up with your own understanding, so you can use that understanding to build context and perspective for future understanding. In the two BABOK tasks, the purpose is to “estimate the value” of multiple options (or courses of action, in the case of the “Recommend Solution” and “Recommend Actions to Increase Solution Value” tasks) and determine which best meets the requirements of the enterprise based on the information available.

 

Finally, I find a parallel between gaining a deep understanding of the players in history and the need to know our stakeholders in business analysis (represented by #4 above). A deep understanding of the stakeholders is so important in business analysis that it is a core concept in the Business Analysis Core Concept Model, integral to every knowledge area in the BABOK. You cannot completely understand your project and cannot design a solid solution if you don’t have a strong handle on who the stakeholders are, how they are connected, and what they need.

Same in history. You understand the Impressionist era much less if you don’t know that Monet, Renoir, and other painters during that time period actually worked and played together.

For the passionate and effective business analyst—as well as for any history buffs reading this—I think it comes down to being curious, being structured, and doing your research.