IBM Doors Archives

Tag Archive for: IBM Doors

In this blog, we recap our “The Inside Story: Data-Model Diagnostic for IBM® DOORS®” webinar.

Organizations make investments in software tools to improve their product development process, but they often forget to invest in their data. A consistent data model is the best way to maximize the benefits of software tooling, but this can only be achieved by spending time on analysis.

Jama Software is well documented on the benefits of a common engineering data-model and the use of diagnostics to understand the true nature of your engineering data.

In this session, we will discuss the production of a return on investment (ROI) for cleaning your IBM® DOORS® data.

You’ll learn more about:

Why a common engineering data-model is important
The aims of a diagnostic tool
The breakdown of the IBM DOORS data-model diagnostic in terms of the measures that can be taken
Calculating the financial impact of cleaning your engineering data

Below is an abbreviated transcript and a recording of our webinar.

The Inside Story: Data-Model Diagnostic for IBM® DOORS®

Richard Watson: Thanks very much. Yeah, I’m excited to be here today. As was said, previously, before Jama Software, I’ve been working with DOORS for a huge amount of time as the product manager for a long time, and I’ve moved to Jama Software. One of the main activities I’ve been working with in Jama is “How do we transform DOOR’s data into a new requirements tool of Jama Connect?” And this presentation is all about trying to understand the diagnostics or understand some diagnostics from your data to be able to understand data shape and size so that we can help see the business case and also help understand how we would transform it to improve the situation.

Let’s start at a very high level. I’ve presented a slide like this repeatedly for all of those 30 whatever years. We know that the earlier in the life cycle that we find a defect or a problem, the cheaper it is to resolve, but in Jama Software, we firmly believe that this is related to traceability. If we have traceability between the artifacts in our engineering process, then we have the ability of finding the information that has an error. For example, if you’ve been working on your needs analysis, and then you start to decompose your requirements, at that stage, if there is a traceability between the requirements definition and the needs analysis, you’ll start to see the errors in the needs at that stage, rather than having to wait all the way around to validation, and then finding out that mistake. And if you wait until the end, we all know that it’s been proven that it’s much more expensive, and there are many sources of this information, but you’ll see a link on the slides to INCOSE.

If we look at the reality of this V model, though, even with tools in place and some integrations in place, we find that there are many different types of silos of information in organizations, and this integration of framework between those different silos is just not established. As you’re documenting the requirements or the system design or the implementation, because you don’t have a viable connection back to the previous assets, you’re not encouraged to find the errors in those previous assets. And so if you work in different silos in this way, you don’t fix those errors. And by the time then you go through to verification, validation, and up that side of the V, then you’ll perhaps start uncovering those problems and it’ll be expensive. Even worse, you won’t find those problems; you’ll go into deployment, and you’ll find it in production, and that’s terribly expensive.

Related: Requirements Traceability – Does My Data Model Matter?

Richard Watson: Here in Jama Software, we believe that our live traceability model has resolved this. Jama Software provides an environment that keeps all of those different assets connected. Requirements actually are the common denominator. Everybody works against some form of specification. Maybe the name changes, maybe it’s a work instruction or a requirement or a project need, or a user expectation, but everybody’s working to something, everybody’s conforming to something. And here in Jama Software, we provide an environment to create your engineering data in something called a model-based framework. You have a model-based systems engineering framework for all of your engineering data, and we keep that data connected directly from the beginning. So rather than waiting to comply or give some sort of statement to say everything’s been covered and creating traceability, later on, we encourage this traceability to be established right from the very beginning.

And we do that in a way that does not force people out of their preferred environments. And so they work in their existing environments establishing traceability, but then we can see the end to traceability in a commonplace. And we can make sure that all the engineering assets are consistent. Jama Connect offers this environment. It offers a way of defining a model-based systems engineering data model over your engineering data and then facilitating which applications should be contributing to those bits of information. Be it Jama Connect for requirements or test and risk, or some other system for defect tracking and other assets in that way.

Great, we’ve got this understanding that information needs to be connected together from the get-go and not at some later stage. And so that would give you a perfect environment, right? But there’s a big but. This data model that we’ve been describing, we can describe it in something like a language. Your engineering data model is the language of your engineers. It’s the way that they create your systems, though the way they specify it, et cetera. But you want to be able to facilitate a common language. If you’ve got separate teams using a different way to engineer your systems, then they can’t communicate between each other effectively. They can’t move between teams effectively. And the cost of integration across that life cycle becomes more and more expensive.

Related: Considering DOORS® for requirements management? There is a more modern solution.

Richard Watson: And so this language needs to become common, but it’s quite difficult because in traditional environments, so if we move the conversation to talk about some of the IBM tooling, so IBM DOORS or IBM DOORS Next, for example, we find that there aren’t many of these silos. IBM DOORS, for example, specifies requirements in what it calls DOORS modules. Each DOORS module stands on its own. Unless your organization have taken steps to try and rigorously make modules consistent with each other, each of those modules would end up being a silo of information. Multiple different sets of user requirements, for example, could be easily inconsistent with each other.

DOORS Next is the same. DOORS Next uses a component model, and each component stands on its own as a silo, and keeping the components consistent with each other is also difficult. Although we’ve got this wish to have a common language across our organization, it’s very easy and quite convenient to end up with lots of silos of organizations, each doing their own particular thing and not being able to communicate. Then that big question. The big question is if you have these silos, how do you move from having a silo-based organization to having a common language or a common engineering data model? And that’s when we should start talking about data-model diagnostics…

To watch the full webinar, visit: The Inside Story: Data-Model Diagnostics for IBM® DOORS®

What does DOORS^® stand for?

DOORS is an acronym that stands for Rational Dynamic Object Oriented Requirements System.

What is DOORS?

IBM DOORS, formerly known as Telelogic DOORS, is a legacy requirements management tool originally created in 1991 and is part of the IBM Engineering Requirements Management DOORS Family.

Why was IBM ^® DOORS ^® originally built?

Requirements management tools started to evolve more than 30 years ago when it became clear that document-based tools such as Microsoft Office did not offer the capabilities able to manage and analyze requirements traceability.

There was initially a limited choice of requirements tools including QSS DOORS^® (now IBM), Rational Requisite Pro (end of life), Borland Calibre RM (now Microfocus), as well as a few others.

Legacy requirements solutions may have been sufficient to handle managing requirements in the past but are failing to keep pace over time due to increasing engineering complexity and the need for modern software to be far easier to use.

Why did teams originally invest in IBM DOORS?

Requirements management 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. IBM DOORS was typically selected as choices were limited. Organizations originally invested in a requirements tool 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 DOORS software 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 requirements into core workflows and business without impacting how people work.
Tracking the life of a requirement through development, test, and release.

Related: Is There Life After DOORS®?

Why does IBM DOORS fall short for requirements management?

The past few decades have ushered in a new way of working — 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 introduce increased risk in the product development process, leading to inefficiencies and lack of visibility that often 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.

The Drawbacks of DOORS Software

You may currently be using a solution that was implemented with the intention 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. 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.

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.

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. 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.

Related: Migrating from IBM DOORS: Why and How Rockwell Automation Made the Switch

Risks and Costs Associated with Staying with DOORS Software

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. As is the case with DOORS software. 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 when using DOORS software, 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.

Interested in making a change in your requirements management tool? There are a lot of solutions on the market, check out our requirements management buyer’s guide to cut through the clutter, Selecting the Right Requirements Management Tool

In this blog, we recap the “Moving from Modules to Models – Is it finally time to leave IBM® DOORS® behind?” webinar.

As products grow increasingly complex, many teams are asking themselves if they have become complacent in how we approach requirements management and the value it delivers.

Regardless of the industry, requirements are critical to a shared understanding of the solution. They provide the foundation for traceability and regulatory compliance across the product or software’s lifecycle. Many companies are finding that using IBM® DOORS® for requirements management limits their ability to lay that common foundation.

In this webinar, experts from Persistent Systems and Jama Software® will discuss issues and challenges around the continued use of IBM® DOORS® and show how adopting a model-based requirements approach enables best practices to realize greater value from your engineering initiatives.

In this session, we will cover:

An overview of why requirements management is critical
Common challenges and pitfalls companies face
Best practices enabled by a model-based engineering approach
The path to successful adoption, reducing migration uncertainty and risk
How to start your migration journey

Below is an abbreviated transcript and a recording of our webinar.

Moving from Modules to Models – Is it finally time to leave IBM® DOORS® behind?

Richard Watson: Hi folks, my name is Richard Watson. I work with Jama Software. I’m a practice director with Jama. My history is around systems engineering. I’ve been a systems engineer, I guess, for about 30 odd years, mostly with DOORS and DOORS Next. So my previous role was the product manager of DOORS before I moved into Jama Software. I’m thrilled today to be joined by Kathryn Fryer. Kathryn works for Persistent Systems and she too has got about 30 years of systems engineering experience. And she and I worked for a long time together inside of IBM, working on both DOORS and DOORS Next Generation. We’re here today to talk about data model consistency, and perhaps migrating your data to a consistent data model. So we’re going to start with Kathryn. So Kathryn, over to you.

Related: Jama Connect® Solution for IBM® DOORS®

Kathryn Fryer: Okay. Thanks, Richard. So I just wanted to start, for those of you who might not be familiar with Persistent Systems, we are a global company, been around for actually about 30 years, over 700 million in revenue and that was a huge increase year over year. And if you move to the next slide, we cover many different industries and solutions, and we partner with many different companies, everyone from Salesforce to Microsoft, to IBM and Jama.

So with that brief introduction, let’s move on to the topic at hand and talk about requirements management and model-based engineering. So these quotes might be familiar to you, certainly, the sentiment that they convey is familiar, requirements management is key to the success of software and systems projects, and poor requirements management is the single largest reason for project failure. And the costs of failure can be billions of dollars or pounds or euros, the cost of product recalls, of missing regulatory compliance, and never mind as we get into some of these industries, the cost affecting human life. So I know you’re all familiar with that and you know how important requirements management is, or you wouldn’t be here today. So if we move to the next slide, Richard?

Related: The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering (MBSE)

Kathryn Fryer: So what makes it hard? Why are we still talking about it? And there’s four CS here, I think I refer to them in the past as well. And I don’t think these are new, this list is familiar. This has been true for a number of years now, and it continues to be true. Solutions become increasingly complex. We have more components, more moving pieces, more integrations, more dependencies. We have more contributors involved in delivering the solutions. So we need to collaborate, not even just within your organization, across the teams in your organization, but across different suppliers and then their suppliers. We have these diverse engineering teams, diverse tools, diverse processes, and we need that collaboration, the handshakes, the clear handoffs, and the understanding of the context, there’s another C I didn’t put on the slide, and how all the things must work together.

We need to manage change. Change is the only constant, right? So we need to stay on top, not just of changes in our project, but also changes in technologies and changes in standards and compliance. Compliance seems to be growing and evolving all the time. The specifics are going to vary by your industry and by your geography, but compliance is necessary in almost every industry now, I think, and that’s only going to grow with things like AI and autonomous capabilities and all that fun stuff. So there’s lots of things that we need to deal with.

Watch the full webinar to learn more: Moving from Modules to Models – Is it finally time to leave IBM® DOORS® behind?

The Limitations, Drawbacks, and Risks of Using Legacy Requirements Management Tools

Current market dynamics include disruptors that put innovation at the heart of your product development process. Organizations must be able to navigate these disruptions to remain competitive and sustain business growth.

Why organizations move away from legacy tools, the benefits of making the switch, and how to successfully migrate.

Requirements management (RM) tools started to evolve more than 25 years ago when it became clear that document-based tools such as Microsoft Office did not offer capabilities able to manage and analyze requirements traceability. Early requirements tools included QSS DOORS® (now IBM), Rational Requisite Pro (end of life), Borland Calibre RM (now Microfocus), and a couple of others. Legacy requirements solutions may have handled managing requirements in the past but are failing to keep pace over time due to increasing engineering complexity and the need for modern software to be far easier to use.

We will explore topics relevant to legacy requirements management tools, why organizations elect to move away from them, what benefits are realized after making the switch, and how to successfully migrate. We’ll also touch on how to navigate the data migration path from a legacy system to a new platform, and how innovation is realized in product development lifecycles with a modern requirements management solution.

5 Common Migration Myths Debunked

Transitioning to a new solution doesn’t have to be challenging; however, there are some assumptions that mislead us into thinking that difficulty is inevitable. Consider the following myths:

MYTH 1: Migrating away from IBM solutions will be more expensive. The amount of work that goes into upgrading to IBM DOORS Next or transitioning to a new RM solution is the same, differentiated only by the quality of the tool and services available to help with migration. An option other than the DOORS family is most often a better fit for your organization.

MYTH 2: Customization will carry over to DOORS Next. You spent a lot of time customizing IBM DOORS and may believe those customizations will transition seamlessly to DOORS Next. However, this isn’t the case and is the reason selecting a different solution doesn’t involve more work.

MYTH 3: DOORS is already deployed and cheap to maintain. Continuing the current path with IBM DOORS is an expensive option in the long term, and often requires dedicated personnel. Switching to an alternative RM solution can improve efficiency while saving money.

MYTH 4: Business disruption is too difficult. The right RM tool will empower teams to effectively hit deadlines, collaborate, and improve business outcomes.

MYTH 5: The user experience will suffer. Many people refuse to use DOORS due to a challenging user experience. DOORS Next is a completely new tool with a new user experience. Adopting a user-friendly solution allows teams to collaborate far more effectively as team members can accelerate concepts, designs, and validations for faster times to market.

The fact is, IBM® DOORS® is extremely outdated, and at some point, updates and support will inevitably end.

If you’re currently using DOORS, you likely know that moving to a different solution is necessary, and you might be considering DOORS Next. However, fast-shifting market dynamics require a new approach to accelerate innovation. As a modern alternative to traditional legacy platforms, Jama Connect® enables digital transformation with a more efficient and user-friendly approach to managing risk and compliance.

Customers agree, naming Jama Connect the overall leader (#1) in requirements management software on G2, outranking IBM DOORS Next for implementation time, adoption, ROI, and market presence.

Jama Connect is a proven IBM DOORS alternative with flexible and reliable solutions, including:

Operation in an IBM DOORS supply chain.“Innovative companies leverage Jama Connect to get up and running fast with a modern requirements management process that tightly aligns with industry standards and practices that support regulatory compliance. Organizations can connect to customers and suppliers that use IBM DOORS through Data Exchange for Jama Connect.”
Integration services. Jama Connect provides integration with key product development lifecycle tools.
Coexists with IBM DOORS. IBM DOORS is embedded in many organizations and may take some time to migrate completely. Progressive teams and divisions can get started on Jama Connect quickly while the larger organization works toward replacing existing programs over time. This approach is supported through a mix of integration, migration, and exchange services.

“Jama Connect lowers the complexity and burden of having to manually keep requirements, architecture and specifications all in sync and traced to each other. It’s a formidable problem that is virtually eliminated courtesy of Jama without the hassle of having to learn a clunky UI (IBM DOORS).” Alan M., Chief Product Officer

Jama Connect® created Live Traceability™ management which reduces project development risk by forming a digital thread through siloed development, test, and risk activities. The flexible platform is designed to support the end-to-end product development process with:

A simple, single repository so it’s easy for remote teams to gather, review and execute on requirements.
Structured reviews and collaboration — teams can elicit feedback, review product features in real-time with stakeholders and track critical decisions across teams and locations.
Change management throughout product development — end-to-end traceability and real-time collaboration improve visibility and make it easier to adapt to changes and track their impact.
Integrations across the ALM-PLM ecosystem.

Moving from IBM® DOORS® Next to Jama Connect® for Requirements Management

To adapt to shifting and ever-increasing challenges and complexities and keep pace with the competition, innovative organizations are now requiring best-in-class software to scale development, reduce risk, save time, and ensure compliance to quality and safety regulations.

Download this paper to learn how Jama Connect stands out above DOORS Next in the G2 Summer 2021 report for requirements management in the following areas:

Overall satisfaction
Implementation
User adoption
ROI

Go live with Jama Connect 2.7x faster than IBM® DOORS Next®

In Conclusion

Products, systems, and software development are only getting more complex and not modernizing your requirements management process will increase the probability of negative outcomes in your product development process.

As your team requires the ability to adapt, innovate, and grow, continuing to use IBM DOORS will become more difficult and will introduce significantly more risk in your product development process. Think about DOORS as a landline rotary phone that stopped being on the receiving end of upgrades after the industry switched to marketing push-button touchtone phones. (And now there are smartphones available, which are mobile and make you even more connected and productive.)

Transitioning to new technology provides your teams with the tools required to innovate, meet deadlines, and succeed. A modern requirements solution can help you to define, manage, and validate complex systems requirements while eliminating the risks and inefficiencies associated with documents and legacy systems.

Hear about the experiences of the more than 50 companies that have made the switch from IBM DOORS to Jama Connect.

Connect with us today to learn how you can enable end-to-end compliance, risk mitigation, and process improvement with our intuitive, award-winning requirements management platform.

To read this series in its entirety, visit this whitepaper: Why Move Away from IBM Doors Legacy and Why Now

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.

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.

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.

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

Product development teams face many challenges in today’s fast-moving and increasingly regulated environment. Potential missteps, however, can create an expensive ripple effect throughout the product development cycle, with the potential for missed deadlines, compliance issues and more.

Real-time collaboration and the need for a single source of truth are critical to product development teams. Outdated tools often don’t deliver on these needs, and a misalignment between what a team needs and what a tool provides can hinder success. Requirements management tools that keep pace with your team’s evolving needs can help mitigate potential risks, improve efficiency and achieve faster results.

If you’re currently using IBM DOORS, understanding the difference between the existing solution and more modern options can help you to determine the best next steps for your organization.

Requirements Management and IBM DOORS

Many organizations adopted IBM DOORS because they needed a requirements management tool for their teams and, at the time, it seemed like the best option. But much has changed since the creation of IBM DOORS, and the tool has quickly become outdated. Today’s teams need the ability to not only collaborate in real time but also to do so remotely. They also need to:

Follow a consistent and common requirements practice.

Create a single source of truth for requirements, ensuring that everyone on the team is working from the same information.
Have easy integration so that requirements management is integrated into both core workflows and business to improve productivity.
Be able to track requirements to develop, test and release new products.

Development teams and critical stakeholders expect the tools they use to be as intuitive as the technology in other areas of their lives. Users of IBM DOORS, however, struggle with usability issues, leading many to not use the solution and opt instead to use outside programs, such as Word or Excel. This creates challenges within workflows, productivity and efficiency, and it introduces potential risks, eliminating the ability to have a single source of truth. But how did IBM DOORS become outdated, and what does it lack?

The Advantages and Disadvantages of IBM DOORS

Organizations are often tempted to maintain an outdated solution, even if it’s underperforming. Why? Because fear and worry exist when it comes to switching to a new solution, users often stay with the existing solution or upgrade to the next offering within the same organization (such as IBM DOORS Next).

The advantage of staying with IBM DOORS is that you don’t need to invest in a new solution and undergo the adoption process that comes with transition. But delaying the switch to a new RM tool only delays the inevitable, because IBM DOORS will eventually go out of support, which will create many challenges, including potential security issues.

A few common misconceptions around the advantages of IBM DOORS include:

Upgrading to IBM DOORS Next is a less-expensive option. IBM DOORS Next is not IBM DOORS, it’s an entirely new tool with a new approach to requirements. In fact, the only thing the two have in common is in the name. Migrating to IBM DOORS Next might seem like the less-expensive option. However, the work that goes into upgrading to IBM DOORS Next and transitioning to an entirely new RM tool is the same. Moreover, selecting a different solution may help you improve efficiency and achieve ROI faster.
Customizations will carry over to IBM DOORS Next. Organizations invested money and resources in IBM DOORS customizations (DXL), and you might believe that you can take these innovations with you when you move on to IBM DOORS Next. However, this isn’t the case, and selecting a different solution could allow for you to use fewer customizations.

Business disruption is more significant with a different RM solution. Eventually, you’ll need to move away from IBM DOORS after the support is discontinued. The right RM solution will help teams more effectively hit deadlines, collaborate with greater ease and improve business outcomes, offsetting any upfront business transition.
The user experience will suffer. Many people refuse to use IBM DOORS due to a challenging user experience; switching to a new RM tool may accelerate concept, design and validation processes, leading to faster times to market.

If you’re considering making a switch, comparing various options can help determine which RM tool is best aligned with your needs. An innovative tool has the potential to reduce risk for project rework, expensive errors and compliance risks.

What is the best alternative to IBM DOORS?

If you want to move away from IBM DOORS, you aren’t constrained by a specific path to migration. So, what is the best alternative to IBM DOORS?

The answer is found in examining both what your team needs most right now and what they may need in the future.

Collaboration is a critical part of the workflow, especially with the increasing number of people working remotely. Organizations need a tool that supports digital transformation, has greater efficiency and is user-friendly enough that people will use it.

Jama Connect is a modern alternative to traditional legacy platforms, such as IBM DOORS, and was named the overall leader (No. 1) in requirements management software on G2, outranking IBM DOORS Next for implementation, time adoption, ROI and market presence. The tool offers users a reliable solution with:

Simplicity. Jama Connect provides an intuitive and modern user experience. Requirements management software supports multiple development methodologies and engineering disciplines to drive cross-team collaboration and alignment.

Flexibility. Customization is a critical factor to product development teams, which ensures that they get the functionality they need most. Jama Connect provides customization, security development and a licensing model that delivers a lower total cost to ownership.

Open. A poor experience is created when an RM tool doesn’t integrate with other tools that your team wants to use. Jama Connect allows for seamless integration with the most commonly used tools across the product development life cycle. You’ll have access to a powerful network of options to get the right technology stack aligned to your unique business needs.

Simplicity, flexibility and the ability to easily integrate with other tools give your team the resources they need to create greater success in all of their projects. As you consider adopting RM tools such as Jama Connect, it helps to have a quick comparison to help guide your decision.

RELATED: Q&A with a Former IBM® DOORS® Evangelist

IBM DOORS vs. Jama Connect — A quick comparison

Adopting a new RM tool involves asking many questions, including the following: What is the implementation process? What are the costs and ROI? How easy is the tool to use? Consider the following as you weigh the advantages and disadvantages of IBM DOORS Next and Jama Connect.

Adoption. Organizations worry that adopting a new solution will take too much time and money, so they often gravitate to a solution such as IBM DOORS Next, primarily because they assume adoption is easier. However, Jama Connect is actually 2.7x faster to adopt than IBM DOORS Next. Additionally, Jama Connect rated 80% in ease of administration, compared with IBM DOORS Next, which rated 71%.

Return on investment. How fast will your investment pay off? This is a critical question for any new solution, and it’s important to note that ROI is achieved 45% faster with Jama Connect compared with IBM DOORS Next.

Usability. Usability is a key reason many people refuse to use IBM DOORS and instead use email communication, Word, Excel or other outside applications. Users expect their RM experience to be as intuitive as applications in their social environment. Jama Connect rated 85% in “ease of doing business,” compared with IBM DOORS Next, which rated 74%.

Supports remote working. The remote working trend is only expected to grow in the future. IBM DOORS lacks cloud capabilities, creating challenges with working anywhere, anytime. IBM Jama Connect creates a single repository so it’s easy for remote teams to gather, review and execute on requirements. Structured reviews and collaboration enable teams to elicit feedback, review product features in real-time with stakeholders, and track critical decisions across teams and locations.

Moving forward with greater confidence

Products, systems and software development are only getting more complex; so not modernizing your requirements management tool creates potential risks, such as negative outcomes in your product development process.

As your team increasingly requires the ability to adopt, innovate and grow, continuing to use IBM DOORS will only become more difficult and potentially introduce risk into your product development process.

Transitioning to a new requirements management tool provides your team with the resources required to innovate, meet deadlines and succeed. You can more effectively define, manage and validate complex system requirements, all while eliminating the risk and inefficiencies associated with outside documents and legacy systems.

Founded in 2017 in Los Angeles, California, Auto Motive Power (AMP) has been dedicated to the evolution of e-mobility. With innovative, industry-leading software and hardware, AMP is the world leader in connected battery management, charging, and cloud technology that empowers electric mobility.

The market for electric vehicles is growing at an exponential rate — and not just cars — scooters, airplanes, drones, helicopter markets are all moving toward electrification. As this demand increases, companies like Auto Motive Power (AMP) are tasked with designing, building and monitoring batteries and charging solutions that can withstand this transition away from fossil fuels.

Batteries aren’t cheap, either. It’s estimated that a battery in an electric vehicle can cost as much as 30-40% of the total cost. And given this great expense, companies like AMP are being challenged to find a way to bring down the cost — and AMP is leading the charge.

As an innovator and leader in the battery management industry, AMP is refusing to work within the confines of traditional approaches and instead designing for the needs of today and tomorrow.

After Initially Selecting Intland Codebeamer, AMP Reevaluates and Moves to Jama Connect

As part of their innovative approach to developing vehicle subcomponents, the AMP team began the search for a modern requirements management solution that could help them address the following challenges and objectives:

Getting users up and running quickly to support their pace of growth
Managing unique requirement IDs across multiple projects
Maintaining traceability as things change
Enforcing efficient processes and workflows in development

Initially, as a new startup, the AMP team was using Atlassian Confluence and Microsoft Word for requirements management. But as the team grew and their processes matured, it became clear that in order to continue pushing the boundaries of innovation, the team needed to move away from static requirements trapped in disparate documents and move towards a modern requirements management platform that enables Living Requirements™ which create a common thread through all downstream activity

“It’s so important to implement a proper requirements management process and solution as part of the DNA of a startup,” said Jana Fernando, Vice President of Technology at AMP. “Making great products starts with having good product definition – and requirements are a prerequisite to that. Having a good RM solution and process means that all stakeholders agree from the very beginning.”

After briefly evaluating IBM DOORS and Siemens Polarion, the team focused on Intland codebeamber for their application lifecycle management (ALM) tool. After just a short 2-3 weeks, the team realized it was, in fact, not the right tool for them and so continued in their search for a requirements management solution that would better meet their needs.

“It’s so important to implement a proper requirements management process and solution as part of the DNA of a startup… Making great products starts with having good product definition—and requirements are a prerequisite to that. Having a good RM solution and process means that all stakeholders agree from the very beginning.” – Jana F, VP of Technology, AMP

Why Jama Connect Was Chosen Over Other RM Tools

After the trials and limitations experienced with other solutions, AMP’s search for the right modern requirements management platform led the team to select Jama Connect for the following qualities:

Proven performance and industry credibility
Powerful yet easy-to-use platform
Quick implementation
Premium customer support and industry-specific knowledge

To see how the team is now leveraging Jama Connect and the great results they’ve already seen, read the full customer story here.

As a modern alternative to traditional legacy platforms like IBM DOORS®, Jama Connect® enables digital transformation with a more efficient and user-friendly approach to managing risk and compliance. And although the benefits are innumerable, some organizations hesitate to migrate to a modern platform because they believe it’s a painful, slow process.

In our recent webinar, attendees heard directly from one of our customers, Rockwell Automation, about why they decided to migrate from IBM DOORS and how they were able to successfully move to Jama Connect.

In this session, the Rockwell Automation team answered the following questions, and more:

Why was now the right time to switch tools?
How easy was it to switch environments while preserving IP?
How did the Jama Software team assist you in making the migration process as smooth as possible?
What are the drivers for continued and expanded use of Jama Connect?
What are the key benefits you have realized since the migration?

Below you’ll find a recording of the webinar and an abbreviated transcript.

Sheila King:

Sheila King: Rockwell Automation has some business units that have functional safety products with the 61508. And although it’s not widely used Rockwell teams have solved their traceability and requirements management at the business unit level using Classic DOORS. Other teams were using homegrown requirements tools and traceabilities including Doxygen and yet other teams were using Word documents and Excel spreadsheets and doing the manual brute force way of doing traceability in requirements.

Sheila King: But then when the security landscape changed and we realized the vulnerabilities of industrial automation, the 62443 cybersecurity specification was invented and we decided that we needed to use it. Qw needed a site certification and in the process we adopted the IBM CLM product with the DOORS Next, RTC for planning, and RQM for test management.

Richard Watson: What led you to consider making a switch away from the tools that you were using and why was that change needed?

Sheila King: Well, we were already in the throws of adopting the CLM D and D tools and developing our product life cycles in order to meet the 62443 certification. And we decided in that process that we really needed to up our game. We needed better tools for planning tools, for our test integration and continuous integration and delivery and we needed better tools for requirements management that included the ability to move data widely between products because that’s real life. And in the current tools, the DOORS Next tools we needed to use the ReqIF which was really an administrative thing as opposed to people being able to move their own data.

Sheila King: We also had the solution for DNG and RQM and RTC and we hired a third party, or we contracted a third party vendor to manage that and we decided we needed a better integration for that for our vendor. We also, for the tools themselves, we needed variant and configuration management and native real-time traceability.

Richard Watson: Can we spend a few minutes looking at the primary considerations you have for selecting Jama Connect as opposed to DOORS Next Generation?

Sheila King: We actually created a grassroots working group to evaluate tools and we evaluated several. Our top two were of course, Jama Connect and Helix, the tiebreakers where these. Jama Connect had functional safety-ready certification, and anybody who goes through functional safety knows how much value that is for your audit. We needed a strong review center and Jama Connect has that. We needed baselines in order to be able to not have to use SAP for saving our documents. We like the rational database and the ability to configure different item types.

Sheila King: We not only use Jama Connect for our requirements but we use it for our threat models and our fault models. And we also like a lot the structure, the permission structure that allows you to specify all the way down to requirement if you need to how you’re going to protect your data in the tools, and with our fault and models are designed for security and threat models, that is our business risk or business restricted setting.

Richard Watson: Thank you. We know that the value of an organization’s environment is their data. You spend a lot of money buying tools and maintaining tools but the real value is the data that you have inside the tools. Can you share some of the concerns Rockwell had going into migration?

Sheila King: Yeah. First of all, we were going to having all our data in the cloud. And so we had our CISO team get involved in that and they did an evaluation because not only were we now putting requirements in the cloud, we were putting our source in the cloud. We were putting our planning, our tests in the clouds, our anomalies in the cloud, some kind of scary stuff to have in a cloud, and so we had a CISO audit and they decided that it was very safe to do that. Secondly, when it comes to actually keeping our data safe, the truth is we asked Jama Software to explain to us how they were going to keep it safe and they convinced us that they could and so they’ll tell you that they kept our data safe.

Richard Watson: Maybe that’s a good transition to the next question. This is just a discussion around were there any specific steps you took to protect your data and IP?

Sheila King: Yeah. Because we had such a short window for moving all the content over, we made backups as it was in our current tools and then moved them into the tools and we use the ReqIFs, the collections and all that stuff from DNG and just about every other way you can export data out of that and backed it all up. And then once we moved it into Jama Connect, actually just handed it over to the Jama Software team, Alisa and the Jama Software team, and they imported it and then we migrated the data once we had it inside.

Richard Watson: Maybe we can bring Alisa into this as well. And so can you and Alisa share some of the details around the migration approach?

Sheila King: Just as I mentioned we had six months to do it, so we had three phases that we started with. We worked with our stakeholders to identify all the content to be migrated and then we again had the extremely tight window. We elected, like I mentioned, to adopt to bring it over into Jama Connect as is. So we had everything brought in in the format that it was in DNG and then Alisa was on site within a week of our purchase to help us with the migration.

Alisa Eikanas: I remember that I arrived in Ohio on April 1st and I remember hoping that it wasn’t a bad omen, which of course it wasn’t, this wound up being one of the most rewarding and enjoyable projects I’ve ever had the pleasure of supporting. The sign that’s being presented now basically illustrates the standard migration approach utilized by the solutions team here at Jama. Every migration is going to have unique elements, needs, but in the case of Rockwell’s migration this template married very well, as Sheila is taking care of the planning and we transitioned seamlessly into analysis and discovery.

Alisa Eikanas: During the discovery and proof of concept stages we did come across a few issues that required some customized tool development, but once we had validated the integration tools and approach the execution of the final stages was a fairly straightforward process. Sheila was generating all of the extracts from the legacy systems. She would transfer those files to me and then I would load them into Jama.

Alisa Eikanas: And as Sheila said, in some cases we go through a cleaning of the data prior to migration but again given the short window we elected just to bring all of the data from DNG, which in some cases we had some modules that had over 170 attributes. But again with a short timeframe we just elected to bring everything in as is and clean it up afterwards because at the end of our migration window Rockwell was losing to their DOORS instance, so really for us a critical item was making sure that we got done on time.

Richard Watson: That sounds pretty comprehensive. Sheila, now that you’re at the other end, how would you rate your experience around migration and user satisfaction?

Sheila King: Well, the team was just great to work with. Again, Alisa, she just worked really hard to integrate and migrate our data. Anytime we ran into an issue we would tell the software group and they’d come in and they would write some code to add to their data exchange to manage the data that was coming out of the tools and it just worked really very well. And she worked with our team, like she mentioned, the classic DOORS group had 100 and I can’t remember seven fields and we were able to talk them down into just, I think it’s 10 now. Is that right, Alisa?

Alisa Eikanas: Yes, it is. Yeah, from 170 to 10.

Richard Watson: Wow. Is there any advice for teams hesitating making a similar move due to migration concerns?

Sheila King: No. I think it’s the water is warm, just hop in. And let me add to this, because we’ve been giving teams the ability to decide when they switch over to the tools, find a perfect time or find a space between projects and stuff like that. And the truth is there’s never a good space to migrate. And so we’re actually encouraging people to just go ahead and start because they will see efficiencies right away. And so it’s not just to get involved and to find a good spot because you won’t but you will find efficiencies right away.

Today’s guest post is from Kemi Lewis (aka Rico Tubbs), senior consultant at Jama Software. Kemi has 21 years of experience in systems engineering in the aerospace industry and considers himself a recovering IBM® DOORS® evangelist.

Q: What are some cool things about yourself?

A: I am lucky enough to train Brazilian Jiujitsu under direct lineage to the original creator, Helio Gracie. The physics geek in me loves how body mechanics and leverage apply in BJJ.

Q: Why are you “aka Rico Tubbs”?

A: I loved Miami Vice as a kid and thought it was a funny stress reliever during the pandemic signing into Zoom meetings to see if anyone got the 80’s pop culture reference, whether it was internal with the CEO/executives or external with a customer – 80% of the time it worked 😉 other 20% of having to explain still made people recall their childhood.

Q: What are some challenges you have experienced in your career?

A: Getting people to listen to your technical recommendations or getting others who are at a lower level to be heard in the same respect. This has been due to several factors, everything from what your “title” is, to me looking youthful, to being of West Indian/African American descent, to my calm friendly personality which leads to my input not being taken seriously since I am not yelling my point across. I never understood why executive leadership or program management would throw their engineering teams “under the bus” to save face with the customer. We win as a team and we lose as a team, so why would I go above-and-beyond for anyone who displayed that negative characteristic. Product development only gets better when you incorporate insight from all parties involved, no matter their title.

This stereotyping has also been associated with being the “IBM DOORS guy” vs being a subject matter expert in systems engineering for a given product, where your technical acumen has been dumbed down to a tool or that systems engineering is just IBM DOORS.

Q What led you to your position here at Jama Software?

A: I have been a huge fan of Jama Software ever since discovering it while looking for an alternative to DOORS for a new product development launch. I championed its use at a small engineering company, and then when the small company was acquired by a conglomerate engineering company. When the career opportunity at Jama Software became available via LinkedIn, I jumped at the chance to be able to help other companies be successful using Jama Connect. I only wish Jama Connect had been available to me when I first started working in engineering. From the impact of COVID-19, most teams are requested to do more with less without being provided with ways to enable/empower them to do more with less. Utilizing Jama Connect is an effortless way to increase that efficiency and effectiveness; don’t expect higher product development productivity to magically happen using pixie dust.

Q: What was your first week like at Jama Software?

A: My first week at Jama Software was like drinking from a fire hydrant. The thing I love most about working at Jama Software is the mentality of if you win, I win, and we all win – which is very refreshing.

Q What’s a common myth about (Traditional/Classic) DOORS and can you debunk it?

A: That it is a bad requirements management tool, which it is not. A good analogy – IBM DOORS is like a land-line rotary phone which stopped upgrading after switching to a push-button touch-tone phone and now there are smartphones available, like Jama Connect, which are mobile and make you more productive.

Q: Is (Traditional/Classic) DOORS required by the DoD (Department of Defense)?

A: No. Any DoD contract just requires what tools will be used to manage requirements for the duration of the program.

Q What advice would you give someone thinking about using DOORS for a new project?

A: Will you get FULL collaboration & engagement from your product development team by this tool selection? Well, (Traditional/Classic) DOORS does allow teams to to collaborate – it’s just not modern as one would expect. DOORS is exceedingly difficult to use (in my experience, we had 12 weeks of training only to fumble around in the tool) and administrative intensive with extremely high maintenance costs, e.g., as a small engineering company, IBM DOORS’s licenses and the yearly support and services costs are VERY expensive compared to its competitors, thus this was the driving factor in me looking for a tool with a better ROI, given no one in our product development teams was using it.

Will this tool choice make their productivity better or worse? Jama Connect is much easier to collaborate successfully in product development compared to DOORS, but here are the difference makers you will get with Jama Connect: It’s a web-based tool that works on any OS platform. Social media based actionable comments allow people to resolve the issue just by replying to the comment notification via email without even having to be in the tool. Jama Connect Review Center allows light weight users to engage in and provide feedback only on data relevant to them.

Q What do you wish you had known when you started out?

A: Even if you love IBM DOORS, always keep an open mind as there are other alternatives out there that can make you more productive and not keep your data hostage in a tool.

Q: Can you recall any “bad times” when using IBM DOORS?

A: It amazes me how much time I used to spend hacking/debugging (Traditional/Classic) DOORS DXL scripts just to “TRY” to export some information out of DOORs correctly since the option of using Report/Telelogic Publishing Engine (RPE/TPE) was an expensive product add-on that was not purchased. The hacker engineer in me always liked the debug challenge of getting it to work, but from a productivity standpoint it was terribly inefficient.

Q: In your opinion, what are the best features in Jama Connect?

A: Ease of use. Jama Connect is a simple, intuitive, web-based tool that makes product development teams more collaborative and efficient, since everyone is working from the same source of truth.

Q: How does Jama Connect create new ways of working?

A: Jama Connect provides a more data-centric POV with Living Requirements™ that create end-to-end project traceability, visibility, and reuse where there is a real time system of record for the active product development process while providing a flexible platform with integrations that support multiple solutions across the ALM-PLM ecosystem.

Here is a Living Requirements dashboard in Jama Connect that now enables you to see what previously was hidden until too late using (Traditional/Classic) DOORS or a document-based solution. By showing process exceptions, risks can be found early and mitigated at the lowest cost.

Q: Does the collaboration in Jama Connect make product development easier for you?

A: 100 times easier. Getting any specification reviewed and approved was painstakingly long in legacy or document-based solutions. You had to export it to Word/Excel then send a chain email which led to a rat’s nest of emails and different versions that were all uncoordinated due to updates being made by each reviewer. And thus, you are constantly merging and resending out the same doc to make sure everyone is reviewing the latest version, in addition to making all the reviewers cognizant of each other’s inputs. So much time was saved not having to constantly merge 10 different versions of a Word document or Excel spreadsheet over multiple iterations. This legacy/document approach taken in the past was the main factor in losing new business via customer RFP bids repeatedly, given the amount of time wasted versus utilizing Jama Connect’s data-centric solution. Jama Connect Review Center made a 70% reduction in engineering hours spent on non-value-added work, review, and approval time.

Q: Are there any resources or advice you can share that has helped you on your journey?

Be humble. The most success I have had in my career is by treating people how I would want to be treated.Think and act collaboratively.
Ego can get in the way of excellence. I have personally experience this where if the idea did come from them, it wasn’t an innovative idea thus several years and millions of dollars wasted trying to “recreate the wheel” when a COTs scalable “wheel” solution was already available and an industry standard.
The bitterness of mediocre quality lingers long after the sweetness of the low price is forgotten.Always look at things for the expected lifecycle duration of their use and do not be shocked when it does last. This has occurred in my career time after time where ONLY the initial cost is considered, yet there is surprise and panic when things start failing and customers are unhappy. It’s just like the three little pigs – a cheap/wooden straw house will not survive the hurricane forces of Mr. Big Bad Wolf! Pay for the bricks!