Project Management | Purchasing | Mechatronic Systems Development | Business Partnerships Development
I do believe that the APQP as a main frame and this approach cumulated are compatible and would deliver the best results. Indeed APQP is more designed for high mass production, though this is a good frame in all configurations (as it finally simply describe how to plan and manage a good application of the V development cycle), the idea would be to repeat the first mockups and prototypes phases to be more close to this agile project management
SpaceX's secret weapon is it's Systems Engineering culture. The SpaceX mafia is real (Vardra, Impulse, Relativity, STOKE, Radiant, Apex) and they are taking a wildly different approach. Here's 5 lessons you can take from SpaceX: 1. Every Engineer is a Systems Engineer SpaceX doesn't have traditional systems engineers. At SpaceX, engineers are called RE's, or responsible engineers. REs are domain engineers who take a systems eng mindset - taking ownership of both design and requirements to ensure integration across teams. The core realisation here is that either everyone is a systems engineer, or no one is. 2. Fundamentally Different Collaboration Model The core principle of the iterative approach is that It’s faster to get something wrong quickly 3 times and then right the 4th, than it is to get it perfectly right the first time, and take 20 years to do so. This requires a great systems team to be networked not siloed. You need REs negotiating requirements directly, fostering a deeper understanding of the entire system among all engineers, and accelerates changes and improvements. This will lead to chaos, which is why you need stage gates and to draw a line on what goes in this iteration vs the next iteration. Teams must adapt to late-stage changes, with rework likely. Constant change is the norm… 3. Every Problem is a Systems Problem Which system/team does reusability fit in? What about self-driving/cruise control? In order to solve really hard problems, every engineer needs to put the mission first and optimise their own system second. They must be willing to make sacrifices in their area (make a worse system, or delete it) for the overall benefit of the system. While this sounds simple, it's incredibly challenging to put into practice. 4. Systems Engineers Are Called “Design Reliability Engineers” In a world of RE's, what becomes of the systems engineer? They transition from writing requirements to guiding responsible engineers in their approach, spotting cross-functional hurdles, and foreseeing second and third order impacts that local engineers might miss. Systems engineers graduate from execution monkeys to the leaders and advocates of the systems mindset and process, aiding faster and more reliable synchronization among cross-functional teams. 5. Rename Internal Requirements to "Design Criteria" SpaceX distinguishes external requirements from internal design criteria. Why? It's about the mindset. The terminology encourages engineers to challenge and refine internal constraints. This is what you want to inspire. Engineers to push back on requirements and kill systems rather than add requirements, more systems, and complexity. Disclaimer: All information is public and non-confidential. This post is not affiliated with or endorsed by SpaceX.
