Why Move Away from IBM® DOORS® Legacy, and Why Now?: Part 1

Examining the role legacy requirements management solutions, such as IBM DOORS, play in introducing project risk to the product development process.

Are Legacy Development Tools Putting Your Development Process at Risk?

The past few decades have ushered in a new way of working and now teams are expected to work more efficiently and collaboratively across the organization and supply chain. Companies building highly regulated and complex products often rely on legacy tools such as IBM® DOORS®, yet as product development methodologies evolve, legacy requirements management tools have not kept pace. Misalignment between what teams need vs. what legacy solutions provide can result in increased risk in the product development process, leading to inefficiencies and lack of visibility that result in missed deadlines, defects, compliance gaps, and rework. Companies that have migrated to a modern solution from IBM DOORS have achieved faster development times, greater efficiencies, and reduced expenses. As you plan your next move, we’ll cover everything you need to consider moving forward, including market challenges, how engineering teams are adapting, and why waiting to make a change will continue to expose you to greater unnecessary risks.

Market Drivers Are Pushing Engineering Teams and Technology to Evolve

WHAT HAS CHANGED?

Today’s products and software have become more complex. This complexity, combined with rapidly evolving customer and market demands, is forcing engineering teams to change the way they work. Now, far more stakeholders need to get involved in the requirements, driving the need for requirements tools to be more collaborative and have functionality that is applicable to diverse users. Organizations that successfully transform to support this new way of working understand that effective and optimized product and system development requires highly collaborative solutions and methodologies. To reduce risk in product development while still accelerating system design and delivery, teams need access to real-time data and alignment across disparate teams as well as across engineering, business, and product management lifecycles.

Leading-edge companies who are successfully supporting transformation of their engineering teams:

Invest in new technologies and agile processes to continually improve product development: Engineering teams prefer to make their own decisions about which best-of-breed solutions support their specific discipline and optimization of their activities – one single tool will not fit all users’ needs. It’s no longer possible for a Prime Contractor or OEM to mandate a single product or vendor across supply chains, and in fact, standards such as ReqIF (Requirement Interchange Format) and OSLC (Open Services for Lifecycle Collaboration) have come about to help products work better together. Modern development solutions prioritize integration across the ALM-PLM ecosystem.

Take a data-driven approach to product development: An organization’s investment in their data is far more than the investment they make in tools, and the primary focus now comes down to availability of data and how that flows across an engineering community (integration) and the value chain (exchange). What is required is a loosely coupled approach that ties together the necessary metadata across disparate tools in a way that connects the desired outcome (user and system requirements) to downstream activities – the digital thread. The digital thread is the best approach to reduce the risk of negative product outcomes while preserving engineering autonomy and productivity.

Support more formal processes to address increased regulation: As product complexity increases, so has the need for more formal processes and compliance with industry standards. Best practices for systems engineering have been prescribed in many industries. This formal process adoption started with the need to comply with aerospace standards such as DO178 or ISO 9001. Now we see engineering regulation or compliance needs increase across automotive, medical, finance, and other industries, which require the same level of rigor in their development process. Investment in tools that support the generation of the necessary proof of-process compliance to standards, most commonly: requirement validation, verification, traceability, risk assessments, and test results, are critical to supporting efficiency while reducing risk.

Why Organizations Originally Invested in a Requirements Management Tool

Requirements management (RM) has long been accepted by the engineering industry as an essential discipline, no matter which process is used, or which type of system is being produced. Organizations originally invested in a requirements tool such as IBM DOORS to establish a standard requirements management practice and process that allowed teams to align on a single source of truth for requirements. They invested in RM with the goal of:

Encouraging and motivating teams to follow common requirements practices.
Establishing a single source of truth for requirements to ensure teams were working off the same information.
Creating minimal disruption to the business with an off-the-shelf solution that allowed teams to focus on their core business.
Integrating RM into core workflows and business without impacting how people work.
Tracking the life of a requirement through development, test, and release.

We had this idea that a complete redesign of the requirements process and technology would be a game-changer — reducing the time it took for us to implement solutions for our clients and making it easier for clients to review and collaborate year-round. From the outset, we said that we’re not going to be throwing documents at our clients to mark up with their edits — there was a better way to do this.” Elizabeth Rosenberg – Alight Solutions

The Drawbacks Organizations Have Found with IBM DOORS

You may currently be using a solution which was implemented with all the intentions of producing positive business outcomes. But over time, the market has changed and, as a result, your organization’s needs have changed.

If you feel like you’ve outgrown your requirements management software, you aren’t alone. Complex systems such as IBM DOORS have inherent drawbacks and have also had trouble keeping up with the innovation occurring in highly regulated industries. Continuing to use a solution that your organization has outgrown comes with a variety of challenges, including:

A cumbersome user experience. DOORS has a complex and challenging architecture and an outdated user interface. Existing users are losing the motivation to continue to use DOORS while new users are reluctant or refuse to learn.

A system lacking robust collaboration abilities and a single source of truth for requirements. With stakeholders reluctant to work within DOORS, “librarians” must enter information into the system to keep everything up to date, while the real collaboration happens outside of DOORS in emails or conversations. As a result, organizations lack the ability to perform robust reviews or examine the audit trail for requirements evolution. Additionally, teams using DOORS often must retain dedicated staff, a cost that is unnecessary in today’s competitive market where teams are being tasked with doing more with less.

Risk is introduced due to aging technologies. DOORS 9.6 is already outside of its original support window, which raises questions about how long DOORS will continue. Inevitably, IBM will at some point discontinue support for the DOORS legacy platform, and that leaves customers in a high-risk situation trying to protect their intellectual property. Additionally, a cloud option is not available, which creates challenges with remote working.

A high cost of ownership and reliance on customization. Organizations need to focus on their core business and using a bespoken RM tool interferes with that goal. Companies often struggle to achieve the benefits promised by DOORS without complex customization, and those customizations don’t transfer to IBM DOORS Next.

For example, if a company makes cars, then their core business is to focus on cars. If, instead, they need to spend a lot of time writing customizations for a requirements tool then the focus is on creating a requirements tool and not on cars. The time spent on the creation of customizations is a detriment, moving their focus away from core business. Many customizations are also decades old, and it’s increasingly challenging to recruit or replace staff with DXL skills, once again adding risk to an organization.

Stagnant infrastructure doesn’t support change. At rest, DOORS is working and has a low IT man-power cost of ownership. Changes are constantly happening and ignoring them creates additional risk. Users oftentimes refuse to use DOORs and wind up working in Word/Excel and collaboration is done in meetings and emails leaving decisions and details lost outside of DOORs. As the IT industry faces more demanding regulations, supporting the DOORS architecture is growing increasingly difficult.

Lack of vertical frameworks to support compliance. As industries establish increased regulatory and compliance rules, new and updated industry engineering frameworks have been created (e.g., DO178 A, B & C). Legacy requirements tools made early attempts at providing engineering frameworks, but these have not kept up with industry changes and are now mostly left to users to create for themselves.

Risks and Costs Associated with Staying with IBM DOORS

Tools that are difficult or frustrating to use and require experts to operate will not only slow down development but will also breed resistance and hinder adoption. This creates fragmented processes that introduce unnecessary risks for organizations that must stay current with compliance regulations while developing integrated, complex products that sustain business and maintain market relevance.

The unintended consequences of a fragmented development process are critical functions such as requirements traceability, verification, validation, risk mitigation, product integration, and compliance can be fraught with information gaps, defects, delays, rework, recalls, missed requirements, and significant manual effort. In the complex product, systems, and software delivery lifecycle, organizations can experience negative outcomes such as:

Performance: Product fails to perform specified functions.
Quality: Product defects are discovered by customers post-launch.
Delays: Product release deadlines are missed, or costs are overrun.
Fit to requirements: Product fails to meet the needs of customers.
Compliance gaps: Gaps identified late and require extreme cost to rework and fix.
Regulatory action: Product is not approved for launch or recalled post-launch.

Considering a switch? If you want to move away from IBM DOORS, you are not constrained by a specific path to migration.

Leaders might already understand the need to switch from IBM DOORS, but they aren’t sure of the next best step. Some lean toward switching to IBM DOORS Next with the assumption that it will be easier to learn and deploy than starting from scratch with a new solution.

However, the only thing that DOORS Next shares with the original DOORS is the name; otherwise, it’s a completely different platform that takes the same level of migration effort that any migration away from DOORS legacy would take. Any expensive DXL customizations — which can sometimes add up to more than a million lines of code — cannot be migrated to DOORS Next.

As you make your decision on whether to migrate away from DOORS or not, consider the risks associated with DOORS and the benefits of choosing a different option. Risks may include:

Loss of control and employee frustration. Employees frustrated with DOORS work outside of DOORS, most often in Microsoft Word or Excel, which means that requirements are no longer maintained in a central system and a rigorous process is not followed. This leads to an inability for management to monitor key metrics for the end-to-end process to identify process risk patterns.
Increased operational costs. Continuing the existing path of using DOORS increases an organization’s risk and expense complying to ever demanding IT security regulations.
Disruption in business. New users are reluctant to pick up the antiquated user interface of DOORS, expecting software to be as intuitive as applications in their social environment. Not having the ability to move fast and scale business to meet innovative market demands will cost your business time and resources.
Missed market opportunities. Errors, defects, and omissions not found until the end of the process cause costly delays and overruns. A company’s long-term success can be hindered by delayed launches and missed market opportunities.
Increased exposure to risk in regulated markets. A requirements management tool helps you stay compliant and increase visibility in regulated markets. Limited customer and cross-functional involvement in the review and approval of requirements and a lack of stakeholder alignment create unnecessary risks. And, the absence of process exception tracking, which determines if requirements have been omitted or modified, creates additional exposure. With more stakeholders refusing to use DOORS, compliance is checked after the fact with the arduous task of tool admins importing data and then running trace analysis. Extended stakeholders who are using DOORS are only able to see any errors long after they have been introduced and eventually imported.
Distraction from the core business. An ineffective requirements management tool encourages organizations to create customizations rather than simply configuring a tool to meet process needs. Developing and maintaining ad-hoc customizations force an organization to focus on how to create requirements management functions rather than focus on core business. A modern requirements management solution enables teams to work faster and more efficiently, leading to faster time to market.

This blog is Part I – Part II is available here – of a series covering this whitepaper: Why Move Away from IBM Doors Legacy and Why Now

Author
Recent Posts

Jama Software

Subject matter experts from Jama Software provide guidance and best practices on requirements management, test management, compliance and regulation, risk management, and complex product and software development.