In this blog, we recap a webinar discussing Requirements Traceability Benchmarking.
Requirements traceability is a core systems engineering framework, has been around for decades, is required by industry standards for complex product development, and is deployed by thousands of companies — yet no one has ever measured it…until now.
In this industry-leading webinar, Jama Software’s CEO, Marc Osofsky, and Senior Manager, Business Intelligence, Kevin Pearson, review this groundbreaking, 1st ever benchmarking study of over 40,000 complex product development projects.
You will learn:
- How to calculate a Traceability Score™
- The impact requirements traceability has on quality and cycle time
- The differences in performance among the top and bottom quartile performers
- The top five best practices of top quartile performers
- How to conduct a Traceability Diagnostic for your own organization
Below is an abbreviated transcript and a recording of our webinar.
Requirements Traceability Benchmarking
Marc Osofsky: We’re going to make this as practical as possible. So, here are the five takeaways we’re committing to offer. So, the first one is how to calculate a traceability score. So we’re going to introduce the concept of the traceability score, show you how to calculate it, then we’re going to talk about the impact traceability scores have on quality and cycle time. So, that’s the statistical work that we did. So we’ll go through that. We’ll help you understand the difference between top and bottom quartile performers on traceability score and how big that variance can be. Then we’ll dive deeper into those top performers, talk about the five best practices we found for companies that are in the top quartile for traceability score. And then lastly, we’ll talk specifically about how you can apply it at Company.
All right. So, the first question we should all be asking is why bother measuring requirements traceability at all? Why measure it? So to answer that question, let’s all try to get on the same page. We have hundreds of companies on the call right now across multiple industries, folks from very different engineering disciplines, but this diagram here generally represents what most of you are facing. So here you see the system development process and all of the different engineering disciplines that are involved. Many of you are probably experiencing some of the call outs here in terms of delays, errors, rework, a lack of visibility into what other teams are doing. This is the reality that we’re all living in.
So, most teams, most engineering disciplines have optimized the productivity of their own teams. They’ve chosen their own best breed tools within the software team or the hardware team, things work pretty you well, the challenges as you try to coordinate all of these engineering disciplines to get to positive outcomes, that’s the fundamental challenge. And so requirements traceability, if you’re not familiar with, it is the mechanism to help coordinate all of these engineering disciplines to achieve positive outcomes. And it’s also a mechanism for early detection of issues. If you can resolve issues early, they’re much less costly than finding them later.
Download the Requirements Traceability Benchmark HERE
Marc Osofsky: So if you look at this as just a typical process in the enterprise. The normal approach is to establish KPIs, try to manage this end-to-end process through data. Now, as most of that hasn’t happened. So, the question is, why? Why do we not measure the system development process?
Well, the main reason is that we’ve all been in the dark. So nobody has visibility currently into end-to-end process data. And for each engineering discipline, as you look out from your own teams, it’s very hard to see what other teams are doing and to stay in sync with them. So, this lack of transparency, this lack of process data, this lack of ability to have a consistent traceability model and sync best breed tools has led to this feeling that we’re in the dark, and we keep getting surprised by issues.
So the approach that’s been taken to manage this world up until now, without end-to-end data, how do you get at all of these different teams to coordinate and work together, if you don’t have data to measure it and coordinate it? The answer has been methodology, and this is the entire field of system engineering. The V model that many of you are familiar with. There’s been wonderful work done here obviously, INCOSE as an associate to help drive that forward. But this was really the only approach. Without data without measurement, let’s see if we can get everybody agreed to a common methodology. A lot of this comes together through a lot of meetings and often you can get a clash of methodologies. So maybe the V model approach from system engineering may clash with Agile development software. So methodology doesn’t solve everything, but it’s certainly been the really the only approach you could take without data and visibility.
Related: The Essential Guide to Requirements Management and Traceability
Marc Osofsky: So, now, this world is changing, and you can take a data-centric approach. The clouds are starting to lift. Each of you are likely at different stages in your evolution to more of a data-centric approach. Our clients are fortunate using our software that we’re able to create a common traceability model across the entire process and sync best breed tools from these various disciplines to give full visibility into end-to-end performance and actually do measurement. And so that’s what we’ll be talking about today.
So, in this world, you can measure the process, and it does reinforce the methodology that you’ve already been living. The measurement of requirements traceability is essentially measuring adherence to the traceability model that you’ve chosen to your methodology. So, they’re reinforcing for those of you who are not familiar with INCOSE or not involved, I’d certainly encourage you to get more engaged and check out these materials.
So, INCOSE is starting to shift towards more of a data-centric view now that the data’s available through systems like ours, there’s been some excellent work from the requirements working group, headed up by [Lou Wheatcraft 00:07:42], in terms of integrated data as a foundation for systems engineering and the recent handbook. And then also the measurement working group, with Paul, friends. There’s some great leading indicators and measurements here to go deeper and think about how should we measure the systems development process.
All right. So, hopefully that gives you some sense of why we’re measuring it. It’s now possible. And requirements traceability is really the only way to measure the actual end-to-end process, identify issues early, improve over time across projects and correlate to actual outcomes on quality and cycle time.
Watch the full webinar to learn more about Requirements Traceability Benchmarking
RELATED
