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