The Requirements Bill of Rights for Software Customers: Lessons from Failed Projects ??
Right #1: To Expect BAs to Speak Your Language
Before: A customer explains their business process using industry-specific terms, but the BA responds with technical jargon, leaving the customer confused.
After: The BA uses a glossary of business terms provided by the customer, ensuring clear communication and understanding.
Famous Failure: Healthcare.gov (2013) The U.S. government’s healthcare website launch was a disaster. One of the key issues was the lack of clear communication between technical teams and stakeholders. The developers used technical jargon, while the stakeholders (government officials) didn’t understand the complexities. This led to a website that crashed on launch day, costing millions to fix.
For BAs: “Always align your language with the customer’s business vocabulary to avoid misunderstandings.”
For Customers: “Provide a glossary of terms to help BAs understand your business language.”
Important Words: Glossary, Business Vocabulary, Clear Communication.
Right #2: To Expect BAs to Learn About Your Business and Objectives
Before: The BA assumes they understand the customer’s business without observing their workflow, leading to a misaligned solution.
After: The BA spends time observing the customer’s daily operations, gaining a deep understanding of their needs.
Famous Failure: Knight Capital Group (2012) Knight Capital lost $440 million in 45 minutes due to a software glitch in their trading system. The root cause? The developers didn’t fully understand the trading environment and how their software would interact with it. A lack of understanding of the business context led to catastrophic consequences.
For BAs: “Immerse yourself in the customer’s business to truly understand their objectives.”
For Customers: “Invite BAs to observe your workflow to ensure they grasp your business context.”
Important Words: Observation, Business Context, Deep Understanding.
Right #3: To Expect BAs to Record Requirements in an Appropriate Form
Before: Requirements are documented in a technical format that customers can’t understand, leading to misinterpretation.
After: The BA uses a clear, customer-friendly format, such as visual models or simple text, to document requirements.
Famous Failure: Denver International Airport Baggage System (1995) The automated baggage system at Denver Airport was a $560 million failure. One of the main issues was that the requirements were documented in a highly technical manner, and the stakeholders (airport officials) didn’t fully understand them. This led to a system that couldn’t handle the airport’s needs, causing massive delays.
For BAs: “Document requirements in a way that’s easy for customers to review and understand.”
For Customers: “Review the documented requirements to ensure they accurately reflect your needs.”
Important Words: Clear Documentation, Customer-Friendly, Accurate Representation.
Right #4: To Receive Explanations of Requirements Practices and Deliverables
Before: The BA presents complex diagrams without explanation, leaving the customer unsure of their meaning.
After: The BA explains each diagram and deliverable, ensuring the customer understands their purpose.
Famous Failure: Ariane 5 Rocket Explosion (1996) The Ariane 5 rocket exploded 40 seconds after launch due to a software error. The problem? The software requirements were not clearly explained to the developers, leading to a misunderstanding of the system’s limitations. This failure cost $370 million.
For BAs: “Always explain the purpose and meaning of your deliverables to the customer.”
For Customers: “Ask for explanations if you don’t understand a deliverable or diagram.”
Important Words: Explanation, Transparency, Understanding.
Right #5: To Change Your Requirements
Before: The customer is told that requirements can’t be changed after the initial phase, leading to a product that doesn’t meet evolving needs.
After: The BA implements a flexible change management process, allowing the customer to modify requirements as needed.
Famous Failure: FBI’s Virtual Case File System (2005) The FBI’s Virtual Case File system was a $170 million failure. One of the main issues was that the FBI’s requirements kept changing, but the development team didn’t have a flexible process to accommodate these changes. The system was eventually scrapped.
For BAs: “Establish a clear process for handling requirement changes.”
For Customers: “Understand that changes may impact the timeline or budget, but they are possible.”
Important Words: Flexibility, Change Management, Adaptability.
Right #6: To Expect an Environment of Mutual Respect
Before: The customer and BA have a tense relationship, with both sides feeling misunderstood.
After: Both parties collaborate respectfully, fostering a positive and productive environment.
Famous Failure: Boeing 737 MAX Crashes (2018-2019) The Boeing 737 MAX crashes were partly due to a lack of respect between Boeing and its customers (airlines). Boeing didn’t fully listen to the concerns of pilots and airlines, leading to a flawed design that caused two fatal crashes.
For BAs: “Treat customers with respect and appreciate their time and input.”
For Customers: “Respect the expertise and effort of the development team.”
Important Words: Respect, Collaboration, Positive Environment.
领英推荐
Right #7: To Hear Ideas and Alternatives for Your Requirements
Before: The BA implements the customer’s requirements without suggesting improvements, leading to inefficient processes.
After: The BA proposes innovative solutions that enhance the customer’s business processes.
Famous Failure: London Ambulance Service System (1992) The London Ambulance Service’s new dispatch system failed on its first day, causing chaos. One of the issues was that the developers didn’t propose alternatives to the customer’s requirements, leading to a system that couldn’t handle real-world scenarios.
For BAs: “Offer creative solutions that go beyond the customer’s initial requirements.”
For Customers: “Be open to suggestions that could improve your business processes.”
Important Words: Innovation, Creative Solutions, Process Improvement.
Right #8: To Describe Characteristics That Make the Product Easy to Use
Before: The customer asks for a “user-friendly” product, but the BA doesn’t clarify what that means, leading to a disappointing result.
After: The BA asks specific questions about usability, ensuring the product meets the customer’s expectations.
Famous Failure: Microsoft Zune (2006) Microsoft’s Zune music player failed to compete with the iPod partly because it wasn’t as user-friendly. Microsoft didn’t fully understand what “user-friendly” meant to its customers, leading to a product that was difficult to use.
For BAs: “Ask detailed questions to understand what ‘user-friendly’ means to the customer.”
For Customers: “Provide specific examples of what makes a product easy to use for you.”
Important Words: Usability, Specificity, User Experience.
Right #9: To Hear About Ways to Adjust Requirements for Reuse
Before: The BA insists on custom development for every requirement, increasing costs and delays.
After: The BA suggests reusing existing components, saving time and money.
Famous Failure: UK NHS IT System (2002-2011) The UK’s National Health Service (NHS) IT system was a ￡10 billion failure. One of the issues was that the developers didn’t reuse existing components, leading to a highly customized system that was expensive and difficult to maintain.
For BAs: “Look for opportunities to reuse existing components to save time and resources.”
For Customers: “Be open to adjusting requirements when reuse is possible.”
Important Words: Reuse, Efficiency, Cost Savings.
Right #10: To Receive a System That Meets Your Functional Needs and Quality Expectations
Before: The final product doesn’t meet the customer’s expectations because assumptions were not clarified.
After: The BA and customer validate all assumptions, ensuring the product meets all functional and quality needs.
Famous Failure: Target Canada (2013-2015) Target’s expansion into Canada failed partly because the IT system didn’t meet the company’s needs. The developers didn’t validate assumptions about inventory management, leading to empty shelves and a $7 billion loss.
For BAs: “Validate all assumptions with the customer to ensure the product meets their expectations.”
For Customers: “Clearly communicate all your expectations and assumptions.”
Important Words: Validation, Expectations, Quality Assurance.
Key Insights
How Much Are These Rights Ignored?
Unfortunately, these rights are often overlooked, especially in agile environments where speed is prioritized over thoroughness. In traditional projects, lack of communication and documentation can also lead to ignored rights.
Impacts of Ignoring Rights and Responsibilities
Ignoring these rights can lead to:
Guidelines for Each Right
Each right can be supported by best practices:
Best Practices
Conclusion
The Requirements Bill of Rights for Software Customers is not just a list of expectations; it’s a roadmap to successful software development. By respecting these rights, BAs and customers can work together to deliver products that truly meet business needs. Ignoring them, on the other hand, can lead to frustration, delays, and costly mistakes.
?? Pro Tip: Always validate assumptions, communicate clearly, and foster a culture of mutual respect. These practices ensure that both parties are aligned and working toward a common goal.
What’s your experience with these rights? Have you seen them ignored or respected in your projects? Share your thoughts below! ??
#SoftwareDevelopment #RequirementsEngineering #BusinessAnalysis #SDLC #CustomerRights #ProjectManagement #StakeholderEngagement
M.Eng Student at Amirkabir University of Technology | Software Engineer at Behpardaz Hamrah Samaneh Aval (Behsa) | Passionate about Software Development & Technology Innovation
2 周Very helpful