Leaderboard

Deep has provided the best answer to this question as it covers broader aspects of the question. Michael's answer was a close second as it focusses primarily on security and data breach aspects. However, it is a must read answer.

Let’s first understand what a BRD is. BRD in short stands for Business Requirement Document. What is the purpose of a BRD? Business Requirement Documents are used extensively to do the groundwork before building a new application. They are used to gather all business requirements and hence it also outlines the objectives and expectations of a project from a business perspective. Now let us see what are the basic components of a BRD? A basic BRD will need to contain some of the below mentioned., 1. Project Overview & Objectives 2. Project Scope & Constraints 3. High Level Architecture 4. Stakeholder Identification 5. Identifying Roles and Responsibilities 6. Business requirements | Security & Compliance 7. Defining Success Criteria and KPI’s 8. Quality control measures 9. Cost-benefit analysis All the above if documented correctly will ensure the success of the project. Each component by itself is a key to the project’s success. Next, what is the importance of a BRD? BRD’s ensures that there is alignment on business goals, it ensures that there is clear communication of what needs to be done between the stakeholders and the technical teams, and it also covers the Risk mitigation elements which helps to identify potential challenges and allows for proactive solutioning for the project’s success. So, in-short from a Tech product or a Tech Tool perspective, BRD is the starting point for any software project or business solution design and development. Now that we understand what a BRD is and what are the components and what is the importance of a BRD for a project, let us address the main question “Is it correct to say that most failures in a Tech Product or Tech Tool can be traced back to a flaw in the Business Requirement Document (BRD)?” The Answer is YES. Most Tech Product or Tech Tool failures can be traced back to a flaw in the BRD. Sometimes even design and development failures are influence by a BRD to an extent. Let us look at an example’s situation. 1. Failure Example of Data breach: Company A developed a product (HIYE – How Is Your Experience) that ensure that all in-patient feedback is collected in an app which will help assess the experience during hospitalization. This Product will collect real time data from the patients, analyse data and deliver insights on experience. These reports will be released to the hospital administration. From this data set hospitals will be able to understand patient sentiments, staff responsiveness, facility rating and other services provided that have influenced the overall satisfaction rating. What happened: Personal data of patients was exposed due to security breach Cause of Failure: Inadequate Data Protection Policies and Procedures Impact on Company A: Multiple lawsuits levied against them leading to hefty fines leading to huge expenses impacting financials and margin in adding to loss of reputation. How could have this been avoided: A BRD must clearly state and capture all data protection policies and procedures followed as per the industry standards to ensure that there cannot be a breach of any sort of security or data leakage. All stakeholders must sign off on this and the regulatory boards consent is required before the product is placed on the market. All this can be done during the testing stage itself using ethical hackers to hack into the system and see how strong the product is. From time to time after the product has gone live, the team must ensure that the latest policies and procedures are rolled out based on the evolving statuary standard. ISO standards must be followed. 2. Failure Example of User Privacy and Data Ethics: Company A developed a product (HIYE – How Is Your Experience) that ensure that all in-patient feedback is collected in an app which will help assess the experience during hospitalization. This Product will collect real time data from the patients, analyse data and deliver insights on experience. These reports will be released to the hospital administration. From this data set hospitals will be able to understand patient sentiments, staff responsiveness, facility rating and other services provided that have influenced the overall satisfaction rating. What happened: Company A shared patients’ sensitive data for research to a third-party consultancy Cause of Failure: Inadequate Data handling practices and failure to obtain user consent Impact on Company A: Regulatory fines levied | Trust factor impacted and hospitals refused to adopt the app leading to lower customer base and business loss How could have this been avoided: A BRD must clearly state and capture all data handling practices must maintain user privacy and cannot be used without user consent. Ethical handling and consent mechanism are vital to maintain user trust and comply with laws. GDPR standards must be followed to comply with privacy laws. How do we ensure that these kinds of failures do not happen. There are some key best practices that we can follow to avoid these major setbacks. They are listed below., a. Clarity & Precision – Use clear language to define technical and compliance terms. Avoid ambiguity and use standard terms that are consistent throughout the document b. Stakeholder Management – Ensure a collaborative effort is done in requirement gathering phase. Ensure that the stakeholders needs are balanced, and a regular communication channel is always open to address updates and realignments c. Document Organization – A proper hierarchical structure needs to be followed in document organization. Hence structure is key to success. Usage of templates signed off by all parties is a way of standardizing documentation which allows ease of understanding. Usage of visual aids like flowcharts and diagrams should be encouraged. d. Documenting Ethical considerations – Explicit ethical requirements need to be captured. Bias mitigation strategies should be employed. Transparency and explain-ability are key to behaviour and decision-making process. e. User Privacy and Data Ethics – Data handling practices need to be defined to maintain privacy. Compliance with privacy laws such ad GDPR are mandatory f. Governance Framework – Clear governance and accountability structures that define how the company manages user information/content. Policies and Procedures that are essential for data governance and security. Oversight mechanisms to ensure safety and compliance. g. Regulatory Compliance – Addressing Legal requirements during planning. Employing compliance strategies for legal and financial sustainability. h. Security Requirements – Ensuring strong security standards and protocols (ISO). Threat modelling or having a team work on hacking the system internally that can proactively identify and mitigate security threats. Having an incident response plan that ensures rapid detection to security incidents. If all the above recommended practices are followed, BRD creation will turn out robust and reduce if not prevent tech product or tech tool failures.

In real life scenarios we witness many such failures in a Tech Product or Tech Tool where root cause can be linked to a flaw in the Business Requirement Document (BRD). BRD is a document that articulates product or tool requirement to solve business problem or improve business performance and this document is taken as a guidebook by supplier to develop Tech product or Tech tool. BRD generally consists of the feature, functionality, performance expectation of the product and also the constraints of the project. Thus, it's clear that any ambiguity or inaccuracy may result in potential failure in product or tool. There can be multiple reasons for this: 1. Lack of Articulation: Articulating the exact requirement in BRD is a tough task. Generally, the user has dream Tech product conceptualization in mind but articulating that in exactly the same way can play significant role in success or failure of Tech product or Tech tool. Example: Apple's BRD on Maps could not convey the requirement of precise location with accuracy that resulted in significant map errors, improper navigations and low quality satellite images. 2. Lack of Prioritization: In many cases people want it all in BRD and give all the possible features in Tech product or Tech tool which may result in lack of prioritization to unique and most valuable features. Example: Windows Vista is a perfect example for this where BRD listed so many features without clear prioritization on performance focus. Ultimately, it failed due to frequent crashes and compatibility problems and had to be replaced with Windows 7. 3. Misinterpretation of Business Needs: In many BRDs specificity is missing which may create misinterpretation. Example: If requirement is on support with multiple payment options for e-business application, then developer might miss one of the important integrations (exp-Bit Coin payment option) which may result in loss of potential sales. 4. Poor Definition of Success Criteria: This, I believe is the most important reason as Success Criteria for the Tech product or Tool must be defined with respect to performance, quality, durability and cost effectiveness. Example: JioChat where despite so many Jio Users the app could not succussed as it was lacking success criteria like target for user adoption, engagement and market spread. Thus, it is important to articulate 360deg angle on Business Requirement in BRD so there is zero misalignment.