Tag Archive for: modern requirements management Page 2
Tag Archive for: modern requirements management
Looking for a new way to manage your requirements in 2021 but not sure where to start? Selecting a modern requirements management tool might be the right next step. A growing number of organizations are exploring and adopting product development solutions that manage the complexity that comes with designing connected systems.
Requirements are the foundation of a smooth-running process and are the essential inputs to your mission-critical projects. Effectively managing the flow of changes and refinements early in your lifecycle will significantly reduce both quality issues downstream and the volatility that plagues so many projects – and the right requirements management solution can make all the difference.
The right requirements management solution can help manage the complexity of product, systems, and software development, but it also allows teams to:
Build higher-quality products with fewer defects and rework
Get to market more efficiently with fewer people and spending less money
Capitalize on opportunity faster through earlier launch dates and a prolonged market window
Another thing to consider when selecting a requirements management solution, is whether it allows for living requirements. Living requirements are becoming a competitive advantage in the innovation economy. If your requirements management solution doesn’t allow for living requirements, it’s like that your team will fall behind.
Differences between static and living requirements
Living requirements address the root causes to deliver increased productivity, faster speed of delivery, and risk reduction. This includes all areas of the complex product, systems, and software delivery lifecycle that can experience negative outcomes and should be actively managed to reduce the likelihood of occurrence.
Performance | Product fails to perform specified functions
Quality | Product defects are discovered by customers post-launch
Delays | Product release deadlines are missed
Fit to Requirements | Product fails to meet the needs of customers
Compliance Gap | Gap identified late and extreme cost to rework and fix
Regulatory Action | Product is not approved for launch or recalled post-launch
Whether you’re building products, systems, or software, check out this handy checklist to make sure you’re getting everything you need in a requirements management solution in order to improve efficiencies, cut down on costly rework, and mitigate negative product development outcomes.
Have confidence that you’re selecting the right requirements management solution by downloading our checklist for essential features and functionality.
What is the truth?” can sound like an abstract philosophical question with no definitive answer. But for teams developing complex products like medical devices and connected cars, it’s a much more practical concern – as in, the truth about the current state of the project’s requirements, risks, and tests is often unclear. This is where centralizing your requirements, test, and risk in one place is key.
This uncertainty stems mostly from inefficient tools and processes for requirements management, rather than from anything that someone did wrong. More specifically, the widespread reliance on emailed documents and on general-purpose software such as Microsoft Word and Excel limits collaboration and results in miscommunications, silos, and rework.
The silver lining of this situation is that it’s possible to find the truth, once better tools are in place. A requirements, risk, and test management platform that centralizes everything into one system of record can provide the single source of truth missing from many product development processes.
The Problem with Having Multiple Versions of the Truth
When project activities are spread across different documents and communications channels, it becomes difficult for teams to coordinate their workflows and gather, author, and ultimately move forward with agreed-upon requirements – i.e., “the truth.” Instead, multiple disparate versions fill the vacuum, meaning outdated or flawed requirements make it too far into development.
The annual Project Management Institute (PMI) Pulse of the Profession survey has, over the years, flagged this particular issue as a common impediment to project management success. For example, the 2017 edition found that inaccurate requirements gathering, along with poor communication and problems managing frequent changes in priorities, was among the most cited challenges in project management.
The 2020 edition also highlighted the growing strategic importance of using modern technologies to support complex projects. Respondents thought that selecting the right tools and improving organizational agility were the biggest determinants of project success. In other words, relying on manual processes and aging platforms will hold organizations back by making it more challenging to find a single version of the truth and use it to respond to change.
Looking at these results, it becomes apparent both how multiple versions of the truth can arise and how legacy tools worsen the issue:
As projects evolve, key updates are manually circulated in lengthy documents that can get lost in inboxes. This communication process complicates the tracking of requirements and the changes to them, leading to different versions of the truth plus long review cycles.
Given the pace and complexity of development, it may also never be clear if a document is the latest one, or if it accounts for all risks. Teams may end up in silos, while attempts at reconciling various documents begin too late or are just too time-consuming to succeed.
Since Word and Excel are not specifically built for managing requirements, they require a lot of extra manual work for this purpose. For example, teams have to create their own ad hoc processes for adhering to industry standards when using documents and spreadsheets.
Similar problems exist with legacy requirements management (RM) platforms like IBM® DOORS®, which make difficult to integrate with other tools while also constraining users with outdated and cumbersome capabilities for change management, impact analysis, and requirements traceability.
Making the Upgrade: How Centralization Benefits Product Development
Creating a single source of truth, one that’s both authoritative and easy for contributors to access, is essential when building complex products. To see why, consider the case of electric vehicle manufacturer Rimac Automobili, which had previously recorded most of its requirements in Word and Excel.
Decentralized vs Centralized RM
Under this old, decentralized way of managing requirements, siloed teams often moved forward with key changes without consistently communicating the details and effects of these decisions to others. Sending an email describing the update did not guarantee that someone would really know what was going on, or it could get buried beneath many other messages.
Although the company also used OneNote to create a list of numbered requirements, those identifiers often became quickly outdated. Multiple versions of the truth emerged from the confusion of using different applications and numbering systems to manage requirements
As a result, review processes became cumbersome as teams struggled to stay in sync. But Rimac saw comprehensive improvement in its RM processes once it implemented Jama Connect, a single platform for managing requirements, risks, and tests.
The Advantages of Centralizing Your Requirements in One Place
By making the switch, the company established a unified system of record (i.e., one version of the truth), in which project contributors could reliably see current requirements along with their historical contexts and how they connect to tests.
The more specific benefits of implementing a requirements management platform like Jama Connect include:
Real-Time Collaboration
Not only does everything product development related live in the same platform, but any changes to items can be efficiently communicated to contributors for quick, informed action. After being notified, team members can collaborate in real time in a shared system, with up-to-date statuses, rather than asynchronously over email.
Simplified Compliance
When multiple versions of the truth are in play, it becomes much more challenging for teams to ensure that everyone’s different processes have been aligned around specific industry standards and will meet compliance requirements. A centralizing your requirements in one platform eliminates this doubt while also saving time, with guided workflows and frameworks. The end result is a more straightforward way to prove compliance with industry-specific regulations and standards.
End to End Traceability
Traceability is difficult when managing requirements across multiple systems and manual processes. In contrast, centralizing your requirements in one solution like Jama Connect automatically saves user inputs, allows you to view the impact of change before the change is made, and ensure product quality with complete coverage. Traceability in Jama Connect ultimately allows you to view related product data to make better decisions throughout the development lifecycle.
Jama Connect can help you create one version of the truth for your product development processes. Learn more by connecting with us today.
To learn more on the topic of requirements management, we’ve curated some of our best resources for you here.
Being a former McKinsey consultant, I have spent too much time immersed in frameworks, maturity models and methodologies. As I age, and my pragmatism grows, I find that manymaturity models aretoo high level and vague and do not reflect the actual progression companies go through as they mature a given business function.
What I do find extremely usefulare empirical maturity models since they categorize what companies are ACTUALLY doing TODAY in response to given challenges and pressures.Unfortunately, most models, rather than providing empirical data, are often just theory. The reason for this is becausefrequently, the author does not have access to large numbers of relevant companies willing to share their experience.
At Jama Software, we are quite fortunate to be working with hundreds of organizations immersed in maturing their requirements management approach within a broader product development process. Some are motivated to mature their requirements management process to reach compliance with relevant standards, others have experienced significant delays, cost overruns, or defects and are looking to improve process performance while the most advanced are able to measure end-end process performance and benchmark themselves against others.
The table below shows the key dimensions of requirements managementandthe five maturity levelswe observe within our customer base.
Requirements Management Maturity Model
Let me start by describing the key dimensions:
Change Control –The process by which requirements are documented, versioned, reviewed, approved, tracked, centralized, access controlled, updated, and referenced post–decomposition into development.
Compliance Reporting – The generation of the necessary proof of process compliance to standards, most commonly: requirement validation, verification, traceability, risk assessments and test results.
Live Traceability™ – Visibility and traceability of the state of each requirement and its downstream decomposition, development, and testing at any time from requirement draft through to product release. Requirements that are static and trapped in documents have no system linkage to the entire product development process. Live Traceability reduces common product development risks ofdelays, missed requirements, rework, compliance gaps, limited reuse, defects, and recalls.
Process Improvement– Manage the product development process through data with the end-to-end visibility provided by live requirements traceability. Cycle time targets at various stages, rework percentages, process exception reporting, etc.
Benchmark – Once the end-to-end product development process can be measured, it can then be compared to peer organizations to determine areas to focus on for further process performance gains.
Organizations are at different levels of requirements management maturity across these dimensions. Here are descriptions of each level:
(0) No Formal Requirements – No documentation exists for user or system requirements. Instead, development operates off user stories with no clear distinction between the functionality of the system being built and the expected user experience.
(1) Document-Based Requirements – Static requirements documents are created and most often maintained by each author on his/her desktop with various emails, Slack comments, etc. containing more information.
(2) Siloed Requirements Tool – A standalone tool is in place to draft, review, track comments, version, and store static requirements documents.
(3) System-Based Compliance – Compliance is the forcing function to shift to live requirements traceability to meet standards for requirement validation, verification, and traceability in a single end-to-end system.
(4) Product Risk Reduction – A process-centric focus to reduce the likelihood of all forms of product risk via system–enabled Live Traceability. This requires detection and alerts for specification and functional changes, process exceptions, and test failures with the resulting impact analyses. The risks mitigated include:
(a) Failure to meet the needs of customers
(b) Failure to perform specified functions
(c) Delays
(d) Cost overruns
(e) Defects
(f) Compliance and regulatory gaps, delays, fines
(g) Recalls
(5) Development Process Improvement – Moving past compliance and risk and into the spirit of the standards based on quality management and process control. A focus on measuring, managing, and improving the product development process.
Current Level of Maturity
Now that the model has been described, the first question is: Which maturity level best describes your organization today?Before working with us, most companies we speak with are either using Microsoft Word/Excelandat level 1 or frustrated with their current tool and struggling to move much past level 2.Our top customers are at level 4 and moving to level 5.
Desired Level of Maturity
Once you have made an honest assessment of what level your organization is currently at, the next step is to determine your desired maturity level and gain organizational support for the change. We generally donot recommend jumping more than 2 levels for the first stage of a process change.
Next Step
Once you have completed your self-assessment of current and desired maturity levels, we would encourage you to reach out to us to speak with one of our consultants. We will listen to understand your organization’s unique needs and provide some guidance on best practices based on years of clients’ success.
To learn more on the topic of requirements management, we’ve curated some of our best resources for you here.
My first job out of college I worked for a large agri-business in Russia and toured all types of food processing facilities. The saying that you do not want to see sausage being made definitely holds true. What may surprise many of you is that the behind-the-scenes process to make the newest, shiniest tech, can be equally messy.
At Jama Software, we are fortunate to be working with leading companies, in the most innovative sectors of the economy, and are deeply immersed with our clients on state-of-the-art approaches to product development. So, we “see the sausage being made.”
Common Symptoms
When we begin working with a new client, the described symptoms of the product development process are often not pretty: business stakeholders are frustrated, requirements are not validated nor verified, requirements are missed, there is limited reuse, defects are too prevalent, costly delays, after the fact compliance that is heavily manual, no requirements traceability, significant rework, no real-time visibility and much more. After articulating these symptoms, most companies do not have a clear understanding of what the root causes are that are the origin of the symptoms.
Two Fundamental Causes
Our perspective, after working with over 600 companies, is that most organizations face two fundamental root causes that must be addressed to resolve these symptoms and reduce product development risk:
The end-to-end process to deliver product is fragmented into siloed teams, activities, and tools
The requirements that specify necessary dependencies and outcomes are trapped in static documents
As a result of these two key issues, the costs and risks of product delays, defects, omissions, regulatory gaps, and failures continues to run much too high.
As with most organizational challenges, there is a good reason for the fragmentation of the product development process – engineers. Engineers have been (and continue to be) enabled to choose their own tooling that best enables their productivity within their field of responsibility. As a result, end-to-end process data is siloed in numerous tools — within software, hardware, electrical, embedded systems, testing, etc.
Nearly every other business process has resolved this problem by forcing everyone on a common platform (think ERP, CRM, etc.). That approach will not work for the product development process given the complexity and diversity of engineering disciplines. The answer lies in somehow connecting static requirements to downstream activity – but how is that possible with requirements stuck in documents and little to no integration among the fragmented engineering silos?
Our top-performing clients are all taking the same approach. They have moved away from static requirements documents and have implemented LIVING REQUIREMENTS™ that form the common thread through all downstream activity to link each requirement to its decomposed user stories, dev status across engineering teams, change impact analysis, risk analysis, test results, defects, rework, launch and market feedback. The table below highlights the main differences between STATIC and LIVING requirements:
STATIC
Requirements
LIVING
Requirements
Item-level thread to all downstream process states
Differences between STATIC and LIVING Requirements
In short, Living Requirements address the root causes (identified above) to deliver increased productivity, faster speed of delivery, and risk reduction. This includes all areas of the complex product, systems, and software delivery lifecycle that can experience negative outcomes and should be actively managed to reduce the likelihood of occurrence.
Performance | Product fails to perform specified functions
Quality | Product defects are discovered by customers post-launch
Delays | Product release deadlines are missed
Fit to Requirements | Product fails to meet the needs of customers
Compliance Gap | Gap identified late and extreme cost to rework and fix
Regulatory Action | Product is not approved for launch or recalled post-launch
LIVING REQUIREMENTS are clearly becoming a competitive advantage in the innovation economy. If your requirements are still STATIC, you are falling behind. We encourage you to reach out to our team of experts and learn more about joining the LIVING.
Jama Connect’s Requirements Management Enables Live Traceability™ Across Your Development Process.
Bridge engineering siloes across development, test, and risk activities. Provide end-to-end compliance, risk mitigation, and process improvement with our intuitive, award-winning requirements management platform. Learn more!
To learn more on the topic of requirements management, we’ve curated some of our best resources for you here.
Why should you consider changing out your documents-based workflows for real-time collaboration tools? As product development processes become more complex, traditional document-based requirements management is showing its age and limitations.
Document-based requirements management (RM) is still widely used in highly regulated industries like healthcare, automotive, industrial manufacturing, aerospace and defense. As these industries progressively shift toward increasingly complicated products and systems, they must fulfill numerous software and hardware requirements before safely reaching market.
But many organizations haven’t upgraded their requirements and risk management tools and processes to keep pace with this innovation, putting themselves at risk of protracted development cycles, costly late-stage changes, and regulatory recalls.
Solving the Challenge of Document-Based Requirements Management (RM)
More specifically, outdated document-based requirements management workflows centered on Microsoft Word and Excel are too fragmented for efficient product development. Multiple conflicting versions of requirements documents may be in play at any time, while stakeholders struggle to consistently connect on feedback and conduct timely reviews and approvals.
According to IT research firm Gartner, only 55% of product launches happen on time, with product development issues such as missed bugs and feature creep being major causes of setbacks. Fortunately, better collaboration is possible with solutions that enable real-time interactions, shorter review cycles, and a consolidated system of record.
Let’s explore some of the challenges with document-based requirements management solutions in particular, and how to overcome them through a more modern approach.
What You Miss Out on With Document-Based Workflows
At a high level, document-based requirements management – i.e., RM that involves authoring requirements, traceability and risk matrices, and other items, all managed within discrete files such as Word documents and Excel sheets – isn’t scalable to the demands of modern product development. A single requirements document can be hundreds of pages long, or (if a spreadsheet) have an overwhelming number of rows. Plus, it will inevitably change throughout the product lifecycle.
When the unwieldiness of these documents meets the complexity of continually gathering, authoring, testing, and tracing requirements, the result is often something like the following:
Person A emails a requirements document to their entire team.
Persons B, C, and D each update it with their own feedback.
Those various updates get re-distributed among the team for another look.
Person A tracks the changes in Word and tries to manually maintain an agreed-upon version of the truth
The entire team participates in lengthy meetings to align on the final version or changes
Ongoing rework, within that complicated and detailed document, is required to keep everything up to date.
This highly manual type of collaboration can consume many hours. Ultimately, the product team ends up managing documents more so than the actual requirements within them, which leads to miscommunications and delays, on top of wasted time.
Beyond the time-related workflow issues outlined in the above hypothetical, channeling all RM through individual documents creates additional problems. With document-based RM solutions, teams miss out on the convenient collaboration and standardized, consolidated processes available with modern RM tools. Accordingly, they’re left with problems including greater difficulty in implementing and adhering to industry standards, inability to efficiently manage change, crucial feedback not making it through cross-functional and distributed teams, and often costly rework leading to slower time to market,
Standards Adherence
Product development has become much more complicated over time. As a result, so has product risk—and the accompanying regulatory compliance required.
When teams build products and systems that must meet functional safety and compliance standards during development (such as ISO 26262, IEC 61508, Automotive SPICE, CMMI, ISO 14971, and more), they introduce risk into the development process when they take a document-based approach to RM. Without an easily accessible source for RM information, teams are essentially starting from scratch each time, with no built-in mechanisms (e.g., industry-specific templates or reuse functionality) for baselining or aligning the work of cross-functional teams around the necessary standards.
Traceability of Requirements
Given that document-based requirements are often very lengthy and increasingly complex, and the workflows for updating and circulating them are inefficient, it is easy to see how risks can be overlooked during product development. To go back to our hypothetical example, it’s possible that Person A sends out a revised version of their document that integrates feedback from Person B and C, but not Person D. That oversight could result in missing test coverage or a critical defect being identified too late. Moreover, tests would become tougher to trace back to requirements, in part because there’s uncertainty about whether all risks have been accurately captured at any point in time. Additionally, when Person A needs change a requirement, it is difficult to accurately assess the impact of that change (i.e. perform impact analysis) to understand what other requirements or tests may be impacted.
Although many team members from different departments are involved in product development, coordinating all of them is nearly impossible without the right requirements management platform. Lengthy cross-functional team meetings are often held for the sole purpose of updating just a few contributors on recent changes made to a key RM document. With people often being out of the loop on changes in disparate documents, last-minute adjustments become problematic, as do reviews and approvals requiring input from specific individuals. All of these issues lead to late stage changes and rework that ultimately lead to product delays.
Real-Time Collaboration as a Replacement for Document-Based Requirements Management
To successfully move on from document-based processes, a particular type of RM solution is needed – one that can:
Enable real-time collaboration with full context and conversations around requirements, risks and tests.
Simplify the process for pulling in contributors and connecting them in real time.
Provide out-of-the-box templates for adherence to industry standards from the start.
Support risk analysis throughout the development process
Easily export reports for proving compliance and passing audits.
In Jama Connect, real-time collaboration in one convenient place replaces the fragmented workflows spread across multiple documents and communication channels. Rather than emailing collaborators with new changes and requests or leaving them comments in Word or Google Docs that could easily be missed, contributors can manage requirements and risks in real time in the same system, providing a single source of truth.
To see the difference, consider how risk impact analysis changes when using a modern RM platform. Items downstream from modified requirement get automatically flagged as “suspect,” and specific individuals can be quickly notified and given context on what action is required. Once they make updates in Jama Connect, their inputs are automatically saved and can be viewed by others with the confidence that the data is the latest available. This process is much more straightforward than playing email tag or reconciling static documents.
Watch this recent webinar to learn more about moving away from document-based design control and risk management and how a modern platform can improve team collaboration and streamline processes.
Being a former McKinsey consultant, 
