Introduction
In the earlier blog, we highlighted several reasons for tactical project failures related to data elements, business regulations, system prompts, and security protocols. As we synthesize these failures, one of the many reasons people contribute deliberately or inadvertently to project and product failure is the challenges with requirements. If we trace the lessons learned in historic mega failures like the Boston Big Dig project in the 1970s, the lack of formal process to validate requirements in an unbiased manner continues to emerge as a major reason (Greiman, 2013).
Similar failures, like the Denver International Airport failed baggage handling in 1995, the rollout of the US Healthcare.gov initiative in 2013, or the challenges from Boeing 737 in 2023, show that we have not moved forward adequately. These failed projects continue to emphasize the inadequacy of clear requirements, the lack of attention on risk management related to the required continuous environment scanning for changes in the enterprise environmental factors, and the organizational issues behind insufficient cross-functional team leadership. It is these factors that continue to manifest as poor stakeholder and risk management in the Boston Big Dig, lack of operational considerations in the Healthcare.gov, and fatal design validation of MCAS software to avoid stalling.
How can we increase the success of future projects, then? We must be more focused on project requirements management. The Project Management Institute highlighted the importance of requirements management as illustrated in Figure 1, claiming that“when properly implemented and supported, the critical competency of developing and managing requirements enables the organization to meet stakeholder expectations, improve project performance, meet organizational benefits, and achieve tangible business outcomes.”
Figure 1: PMI Pulse of Profession Survey on Requirements
Since 2018, there have been many major environmental forces, such as technological convergence, that has led to increased focus on regulation and standards. Some of these trends are further accelerated by the emerging sophistication of the 4IR-based technology space in hardware, firmware, and software, leading to an elevated scrutiny of software delivered. For instance, ISO31000 is emerging as a risk management standard to evaluate the product delivery life cycle. Each industry is getting its fair share of increasing regulations like the GAMP in healthcare and SOX in finance, and numerous security and privacy standards are on the rise. As a result, the practices for gathering, prioritizing, and managing requirements are pivotal to improve project success and organizational performance.
Gathering Requirements
Anyone with experience in managing requirements will agree that the requirement management process is an interactive conversation to decompose or break down the requirements for further details with the stakeholders. At each point in this collaboration, there are opportunities for commitment to the requirements by all stakeholders so that time, money, and effort provide a return on investment. This ongoing collaboration process enables stakeholders to prioritize requirements from their initial high-level stage and continuously throughout the detailed breakdown, ensuring alignment and clarity at every step. Nothing in the world stays constant for effort. Hence, managing changes to requirements emerges as the next step. As part of these changes, certain existing or future requirements may have inconsistencies. Resolving these inconsistencies may lead to new requirements.
Figure 2: Broad Stroke on Requirements Elicitation
If we sprinkle the various ways of working based on the methodologies, such as the plan-driven or change-driven, the managing of requirements requires a concerted effort from multiple stakeholders and accordingly prioritizes the requirements. To avoid focusing only on one set of biased requirements, such as revenue generating features over infusing regulatory concerns along with incremental and radical innovations, the individual accountability in traditional approaches have been distributed across the collective team accountability in adaptive and hybrid approaches. Such an approach promotes gathering both the functional requirements for the product features and also the non-functional requirements for operational considerations for scalability, manageability, and sustainability. This multifaceted approach to requirements elicitation for an online shopping business is listed in Figure 2.
Consolidating these product, business, and external requirements, a specific product delivery team such as those following adaptive approaches may approach the backlog refinement as illustrated in Figure 3. In this generic proposal, the product may consider many high level use cases and decompose them into specific scenarios with detailed use cases. Each such detailed use case may be broken down into various user stories with its own considerations for interface, data elements, rules, messages, and security. Please note that not all use cases have been decomposed in Figure 3.
Figure 3: Adaptive Approach to Requirements Breakdown
These are some of the reasons why, regardless of the product delivery framework (Agile) or project delivery framework (PMBOK, Scrum), requirements elicitation itself focuses beyond quick-win features but alignment of product with the market and client needs. Extending further from the Business Analysis Core Concept Model (BACCM), such a focus on requirements life cycle involves the capturing of customer value add (CVA), business value add (BVA), technical value add (TVA), process value add (PVA) and eliminating non-value add (NVA) (Rajagopalan, 2019).
The requirement elicitation tools continuously evolve with the technology in categorizing requirements differently from both product and business lens. Some tools focus on model-based system engineering (MBSE), which emphasizes specifications for the requirements already gathered while other tools focus on eliciting the requirements itself. For instance, Orca Intelligence’s Swiftly generates customer needs using the Plan, Analyze, and Manage (PAM) process. Relating further on the sustainable benefits from proper management of requirements life cycle, the focus of the product and program management community has shifted to explicit understanding of requirements management as part of the benefits delivery lifecycle.
Prioritizing Requirements
Once a backlog of requirements has been captured and a process for refining the product backlog has been established, the next stage involves prioritizing what requirements elevate to the top. There are many methods available to prioritize, but not all these methods always connect with strategy. As a result, if the various methods are consulted in isolation, it is possible that the product increments do not yield the value. Consequently, the return on investment is reduced and the business strategy reprioritizes the resources to work on different projects. Such directional shifts demotivate the team. So, the first approach is aligning the product strategy with business strategy.
This strategy alignment is not new and the shift in this mindset is predominant in every framework, but is not practiced as much as required. Even adaptive frameworks, such as Scrum for instance, require a goal for every iteration aligned with the product goal in the product roadmap. Therefore, the connections to value stream mapping and the business case for benefit delivery is on the rise. Organizations have placed equal importance to business agility in scaling team agility to program and portfolio level and even scaled agile frameworks like SAFe and Disciplined Agile. Organizations bring these focuses in PI Planning at the Scrum of Scrum (SoS) levels with business level ranking of requirements before the individual teams expend efforts developing the functionality.
Once there is a business alignment, the requirements can be prioritized using many methods. These include MoSCoW, RICE model, WSTF model, Weighted Priority, Kano model, etc. It is important to realize that the epicenter of all these methods is the type and nature of risks that impact the delivery of requirements and its compliance considerations (Rajagopalan, 2023a). This Risk Driven Development approach facilitates risk driven prioritization. SpiraPlan from Inflectra particularly helps in not only capturing requirements of various types and categorizing them into product and business components, but also facilitating risk driven development by prioritizing the product development process based on risks (Rajagopalan, 2023b).
Managing Requirements
As tools continuously emerge in the marketplace, only some of them can manage requirements robustly. This is because requirements management must establish bidirectional traceability from requirements, design, tasks, testing, risks, and source code, merging both the project management aspects as well as the software development lifecycle. Adding documentation interfaces to capture requirement scenarios, high-level and low-level design diagrams, and the related configuration and change management adds unique challenges to managing requirements.
Adding compliance considerations, such as SOX, HIPPA, and GDPR, along with the quality management considerations, such as the performance qualification (PQ), operational qualification (OQ), and installation qualification (IQ), further mandates requirement generation itself to focus creating requirement scenarios, edge use cases, and exploratory unscripted test considerations.
Not all tools do a good job in bringing this artifact traceability along with creating such risk-driven thinking and quality focus. Very few tools factor the required regulations impacting the product based on the markets served, nor do they automatically identify scenarios for addressing compliance considerations and promote auditability and traceability to continuously iterate on the requirements management lifecycle.
Next Step
In the next blog in the series, we will continue our discussion on the evolution of requirements through the requirements lifecycle.
References
Greiman, V.A. (2013). Megaprojects: Lessons on risk and project management from the Big Dig. Hoboken, NJ: John Wiley & Sons.
Project Management Institute (2016). Requirements Management: A Practice Guide. Newtown Square, Pennsylvania.
Rajagopalan, S. (2019). Requirements Management: A Value Mapping Exercise. https://agilesriram.blogspot.com/2019/02/requirements-management-value-mapping.html
Rajagopalan, S. (2023a). Risk Driven Prioritization: Challenges to Prioritization Techniques. https://agilesriram.blogspot.com/2023/02/risk-driven-prioritization-challenges.html
Rajagopalan, S. (2023b). Using Risk Driven Development (RDD) in Software Delivery. https://www.inflectra.com/Ideas/Whitepaper/Using-Risk-Driven-Development-in-Software-Delivery.aspx