Legacy Sunset: How to Stop These Five Legacy Software Pains in Requirements Management
|
This post is part of a series. You can find Part I modern alternatives to IBM DOORS® here, Part III on enabling innovation here, Part IV on the difficulties of compliance here, Part V on moving from DOORS to Jama Connect here, and Part VI on migration solutions here.
For decades, companies building highly regulated, technically complex products and systems have relied on legacy tools like IBM® DOORS® or even Microsoft® Office® for requirements management (RM).
As software becomes more prevalent in physical products and development methodologies evolve, legacy RM tools like these have struggled to keep up with the modern speed of capturing, sharing, and managing requirements.
See how Jama Connect stacks up to legacy software tools like IBM® DOORS® in our whitepaper.
Legacy tools are powerful, but even with their complex capabilities and reputation for stability, they don’t always match the goals of teams who need to adapt, innovate, and grow.
Noticing this misalignment can surface as painful moments — like when your team struggles to get work done. Sometimes those issues are process or market related, but in some cases they are actually because of the exact software tools you’re using to make your life easier with requirements management.Here are some critical signals that your team is no longer aligned with your legacy solution for requirements management, and how you might consider a change going forward.
Painful Moment 1: You value the input of multiple roles and skillsets, but you realize only a handful of people know how to use your RM tool (or worse, they’re not allowed into it).
Why It Matters: This is a signal that the RM tool was not set up with the whole team in mind. For companies innovating quickly, this lack of visibility into what you’re working on and why is a major risk. If it were possible for only a handful of people to build complex products, teams and companies wouldn’t have the diversity of skills and thought processes they do today.
What to Do: Consider a system that supports the workflow of multiple roles with advanced, user-friendly tools for different data types and views that still all roll up to the same goals. User-friendly traceability is essential.
Are you getting the most from your requirements management? Read our best practices guide.
Painful Moment 2: You miss the deadline for feedback on a requirement because the notification was unclear. Now you have to go outside the normal channels to have your input seen.
Why It Matters: This is an instance not always appreciated by those who wrote the processes. However, with legacy software that doesn’t make the intentions of users clear (such as wanting input by a specific date), it’s hard to avoid miscommunication and lost time.
What to Do: Look for RM tools that make the next action required of you clear and sends timely notifications with clear instructions.
Painful Moment 3: You try to enter data into the system, but it’s locked, archived, or somehow just not visible.
Your decision is blocked. The person you know who provides access and training is unavailable (for example, on vacation… or no longer at the company).
Why It Matters: Having company-mission critical software that only a handful of people understand and have access to is a huge risk for many reasons – some not as obvious. On the lower end of severity, you lose a few hours trying to access the right data. However, if the trend is that fewer people have permissions and training to use your RM tool, then you’re at risk of data being lost or your system eventually needing to be replaced entirely.
What to Do: Data can get richer over time; it doesn’t have to go stale. Invest in requirements management tools that support your team’s continuous growth and capture continuous input and collaboration.
Painful Moment 4: Your team wants to upgrade its legacy software to fix issues, improve security, and access the latest features. Unfortunately, it’s so customized and patched together that you can’t update without major consequences.
Why It Matters: The products you’re building change and improve over time. The software tools you use to get your work done every day need to keep up with you, at a pace that balances change with allowing users time to learn.
What to Do: Consider the risk and costs associated with stale software, and look for options that avoid getting you locked in to unsupported versions and brittle customizations.
There’s a lot of requirements management solutions on the market. Cut through the clutter with our buyer’s guide.
Painful Moment 5: You want to change the way your team uses the legacy software to match a new process, but there are no configuration experts available.
What if you break something? You hope you can create an experiment project on the side that will ultimately integrate back into the big picture, but it’s not clear how to create this outcome.
Why It Matters: If teams are struggling to get on the same page with their requirements management process, it’s a signal that whatever your building may have misalignments as well.
What to Do: Consider RM solutions that balance each team’s need for autonomy with the need for alignment. This can be supported by software that have services experts available to adapt the tools to your needs as you change, rather than one big rollout that attempts to predict the future.
It’s tough to have to work around legacy software to get your job done. It’s also expensive. Maybe you can’t change the RM tools you use on demand, but if you start to notice these painful patterns it becomes easier to build a business case for making a change that supports the whole company’s vision.
Learn the benefits of switching from legacy software tools for requirements management with our paper, “Jama Connect: A Modern Requirements Management Alternative to IBM DOORS.”
Robin Calhoun writes about requirements traceability, drawbacks of using legacy requirements management tools (like IBM DOORS), connect data, and aligning teams with an Agile workflow design.
Latest posts by Robin Calhoun (see all)