Enabling Multi-Phase Reviews Across the Aerospace and Defense Systems Lifecycle
Reduce Manual Effort and Review Gaps in Multi-Phase Reviews with Automation
Aerospace & Defense engineering teams regularly collaborate to review and approve requirements, verify designs, and ensure critical documentation is approved before development progresses. But many programs require multiple sequential review phases to ensure information is properly developed, complete, and ready for release.
In this webinar recap, Patrick Knowles, Manager of Solutions, A&D at Jama Software, explores how teams can enable efficient, low-touch multi-phase reviews. You’ll learn how to combine workflows, automations, and review methodologies to prevent gaps, reduce manual effort, and bring clarity to complex review cycles.
What you’ll learn:
- Why multi-phase reviews matter in high-assurance engineering programs
- How to update item types and workflows to support automated, sequential approvals
- Techniques track, display, and manage review status across teams
- Approaches that reduce manual effort and ensure engineers work from officially released information
- How Jama Connect® can help teams manage review cycles more efficiently
Equip your team with a scalable approach to managing reviews across the full product lifecycle.
THE VIDEO BELOW IS A PREVIEW OF THIS WEBINAR, WATCH THE ENTIRE PRESENTATION HERE
BELOW IS AN ABBREVIATED SECTION OF THIS TRANSCRIPT
Patrick Knowles: I’m excited to be here with you all and discuss something near and dear to my engineering heart. No matter what company, team, or project I’ve worked on, making sure information is reviewed effectively and ready for development has always been critical. This concept of multi-phase reviews within the system development lifecycle is a pertinent topic no matter where your team finds themselves within the lifecycle, whether it’s early on or late in the cycle. As we continue today, I really hope to illustrate practical examples as well as tangible solutions to this complex topic.
Our agenda today will cover the what, why, and how of multi-phase reviews. Additionally, I will demonstrate how user-friendly these reviews can be, as well as how accessible the data can be to users within a tool like Jama Connect. Our first topic will be centered around what a multi-phase review really is. We’re going to look at the definition. We’re going to look at some of the causality of it. We will then progress to understanding why these multi-phase reviews are both necessary and important, whether it’s standards and regulations requiring them or other reasons. This will then lead us into a discussion on how to implement them in Jama Connect and how that might improve all sorts of personas and people who operate within the tool, from engineering to program management, and improve their ability to simply understand where the data is in the design cycle. Finally, I’ll do a demonstration of the functionality live in the tool so we can truly see how effective this can be.
RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution
Knowles: But the first things first. What really is this concept of multi-phase review, and how does it differ from what we’ll call the norm or standard workflows and other processes? By definition, a multi-phase review is a series or set of reviews throughout the stages of a product’s lifecycle. These reviews are purpose-built to ensure that the data under review is effectively agreed to and approved by relevant stakeholders. The good news is we’re all super familiar with these multi-phase reviews, even though the term might be new. Nearly every engineering organization and every engineering review that exists leads to another review or is the gate to a new stage that includes more reviews. That, as a premise, is multi-phase reviews in a nutshell. This then can manifest itself into the most macro lifecycle approaches, like your system requirement review moving to preliminary design review and then onto critical design review, or even down into your more micro individual requirement approvals, and then there are associated verification closures after a verification or test event. Think something like a test readiness review, and then a closing review after the test is complete.
I want to discuss all of this in greater detail to ensure we are all on the same page before proceeding to explain why it is powerful and important to effectively manage these types of reviews. I want to narrow in on those two examples I’ve provided so far, the system requirements review and the preliminary design review, and so on, as well as the requirement and verification approach. Of course, there is the third example listed on the screen, and there are many, many more examples out there that bring up the core tenets of a multi-phase review.
The potentially most common example is that macro product lifecycle example, where you’re going from system requirement review and so on into another review. Engineers typically utilize this in one fashion or another, even if you don’t call it these different stages. Teams typically progress from system requirements review to a preliminary design review, and then to their all-important critical design review, which means you’re ready to cut metal, you’re ready to really get into that final stage of development. At each stage, engineers review requirements inside and out, but many times teams are unable to adequately display if each individual requirement or related artifact is approved at each of these stages on its own. This is just a little bit of foreshadowing for later in this conversation, where I explain the benefits of managing a multi-phase review or, in general, this multi-phase review approach. Standard reviews are siloed and individual, and they don’t follow some greater master plan, whereas a multi-phase review in this context will follow some greater plan where the data is always displayed, and users are always right at their fingertips, able to understand what’s going on.
RELATED: Vector Test Tools Integration with Jama Connect for Airborne Systems
Knowles: Additionally, teams may run into the multi-phase review approach when approving requirements just in general, where they likely will proceed through verification events and finally return to confirm that the requirement was adequately satisfied by the verification event. And there’s going to be a number of steps in there, from the requirement is approved to verification is approved to verification is live and being run and executed. And then finally, that last piece that I illustrated just a moment ago, where you approve that the verification itself met the needs of the requirement. Even if it was completed the way that the steps are written, you still need to validate and verify that it is truly meeting the needs. In scenarios like this, the phase might be spread out, but nonetheless, it is pertinent to the engineer designing the system that the requirement is approved. The verification expert and that verification needs to be completed, and they need to understand that, and they expect to be able to understand that. And then the system thinker who sees both the requirement and the verification, as well as the rest of the system, wants to see that all of that is coming together harmoniously to generate an effectively engineered product.
