Session
Poster Session 3
Location
Salt Palace Convention Center, Salt Lake City, UT
Abstract
When a program starts, there's a tendency for management or leadership to want to get things moving, to get going, to start doing things. It makes a lot of sense to push forward, but only if everybody understands what "doing things" means. A lot of the time, there's a lack of initial process or clarity about where in a specific process we're starting. Sometimes goals, expectations, and processes don’t reach every member of the team.
In a time when efficiency is being leveraged as a weapon to defund existing efforts, all programs are immediately operating at risk. Programs desperately require a clear vision of their current state, their end goals, and a path that takes them there with minimal detours. The mantra of "new space" is heard across the industry, but it's currently being used as a shield to do less of the detailed work and "hope" more. This isn't the answer. Given the historical tools at our disposal, there is an opportunity to avoid reinventing the wheel while encouraging the kind of innovation that is driving new development in this industry.
The systems engineering lifecycle is often considered a paper exercise. Programs throw less experienced engineers at the requirements lifecycle, then wonder why requirements are hard to design or develop against. Verification takes a standing army. Organizations develop "standards" that are thrust upon programs without context or a clear understanding of what needs to be done from within those standards. These are choices optimizing for the nearest milestone, but they don't serve the lifecycle of the program, the organization's long-term goals, or our customers' needs.
There are no shortcuts for repeatable success. There are no magic bullets to solve hard problems. The secret is that we don't need shortcuts or magic bullets. We have processes that can be scaled up or down based on programmatic resources and risk posture. The underlying approach doesn't change regardless of the cost profile of a given satellite or constellation. The lifecycle and definitions don't change, even if their scale does. Hard problems still demand effort, but a consistent lifecycle framework enables teams to do amazing things.
Engineering leadership needs to provide clear definition and guidance across the board. Management needs to support the team and encourage the use of best practices. Establishing a clear path without reinventing the wheel should be step one for any program that hasn't already done so. This paper discusses actionable lessons learned across the entire systems engineering lifecycle from clear initial requirements elaboration and decomposition, through design, development, integration, verification, and operations. It is meant to serve as a reference.
Document Type
Event
Efficiency Starts With Lifecycle Planning, Management, and Right-Sizing Process
Salt Palace Convention Center, Salt Lake City, UT
When a program starts, there's a tendency for management or leadership to want to get things moving, to get going, to start doing things. It makes a lot of sense to push forward, but only if everybody understands what "doing things" means. A lot of the time, there's a lack of initial process or clarity about where in a specific process we're starting. Sometimes goals, expectations, and processes don’t reach every member of the team.
In a time when efficiency is being leveraged as a weapon to defund existing efforts, all programs are immediately operating at risk. Programs desperately require a clear vision of their current state, their end goals, and a path that takes them there with minimal detours. The mantra of "new space" is heard across the industry, but it's currently being used as a shield to do less of the detailed work and "hope" more. This isn't the answer. Given the historical tools at our disposal, there is an opportunity to avoid reinventing the wheel while encouraging the kind of innovation that is driving new development in this industry.
The systems engineering lifecycle is often considered a paper exercise. Programs throw less experienced engineers at the requirements lifecycle, then wonder why requirements are hard to design or develop against. Verification takes a standing army. Organizations develop "standards" that are thrust upon programs without context or a clear understanding of what needs to be done from within those standards. These are choices optimizing for the nearest milestone, but they don't serve the lifecycle of the program, the organization's long-term goals, or our customers' needs.
There are no shortcuts for repeatable success. There are no magic bullets to solve hard problems. The secret is that we don't need shortcuts or magic bullets. We have processes that can be scaled up or down based on programmatic resources and risk posture. The underlying approach doesn't change regardless of the cost profile of a given satellite or constellation. The lifecycle and definitions don't change, even if their scale does. Hard problems still demand effort, but a consistent lifecycle framework enables teams to do amazing things.
Engineering leadership needs to provide clear definition and guidance across the board. Management needs to support the team and encourage the use of best practices. Establishing a clear path without reinventing the wheel should be step one for any program that hasn't already done so. This paper discusses actionable lessons learned across the entire systems engineering lifecycle from clear initial requirements elaboration and decomposition, through design, development, integration, verification, and operations. It is meant to serve as a reference.
