“How Building Psyche is like Making a Movie…”

If you’re from Hollywood, you’re familiar with the stages of making a movie from conception to final release. NASA has its own not-so-original names for the stages of a flight project starting with “Pre-Phase A — Concept Studies” and ending with “Phase E — Operations.” The analogy isn’t perfect — you can certainly do a lot more in post-production on a movie than you can on a spacecraft — but you get the idea. And like a spacecraft, once a movie is launched, there’s little you can do to change it.

A film starts with an idea that’s developed into a storyboard and pitched to producers to get the “green light.” Psyche began with an idea that was developed into a “Concept Study Report” at the end of Phase A that served the same purpose. The engineering objective was to prove feasibility: find a design good enough to show that the mission could be done. Optimizing and working out the details was left for later. For Psyche, Phase A ended in January 2017.

Today, we are in the middle of Phase B, a stage analogous to the pre-production phase of a movie. Phase B is about taking the concept study and turning it into the thing we will actually build. During the first part of Phase B, the team was staffing up, checking assumptions, modifying the design (for a new launch date!), and optimizing to get to the best overall architecture for our mission. That was all in the lead up to Project Mission System Review.

The second part of Phase B is about figuring out exactly what we are going to build. In that sense, it’s like finishing off the script before we go shoot the movie. That’s why it’s time to make Technical Decisions that Count.

The advantage we have in Phase B is that a much larger team has much more expertise available to look at designs at a detailed level. Ironically, a key challenge for the systems engineers is to keep the design stable with a team that is growing rapidly. Last August, the Psyche team was running at the equivalent of about 20 full time people* at JPL in addition to the staff at ASU, SSL, APL and the other partners. Between August and December, the number of people at JPL doubled to 40. Between December and today it doubled again to 80. The number of people on the project continues to grow geometrically, and that’s just at JPL: all the partners are going through similar growth.

What used to be a small, tight group is now expanding into a large team. So how do the systems engineers keep up?

As Bill Hart described in his blog entry, requirements are a big part of this. Requirements provide the structure needed to give people coming on to the project a clear definition of what to do. Good requirements break the design into bite-size pieces that individuals can work on and define exactly what needs to be done so everything works when it comes together. This is known as “functional decomposition”.

Configuration control is also part of this. Official documents that record design decisions are placed in a library accessible to the whole team where changes go through an approval process so modifications are communicated clearly and those affected get a chance to approve or complain before the change is accepted.

Good technical communication is key. A once-flat organization has turned into a hierarchy. Each element is bringing in new people, getting them up to speed, finding problems and figuring out how to communicate information up and down and across the project. This places a premium on the personal element of systems engineering: finding ways that people with excellent technical skills can work together, collaborate, and communicate effectively. To encourage communication within JPL, we’ve co-located much of the project team onto a single floor in a single building and set up status meetings that span the organization. We also travel frequently between facilities — especially JPL and SSL — so we can meet and communicate face to face instead of via phone. Finally, each subsystem goes through a series of presentations: a baseline kickoff, an inheritance review, and a preliminary design review, that provide overviews of what they are doing and give experts from inside and outside the project a chance to interact with the designers.

Finally, we are building teams and processes that can work together for the long haul. The volume of information to be communicated and speed at which it travels rises dramatically as a project approaches launch. The plans and processes and relationships built now make it dramatically easier (or harder!) to do the job later, when even more people are involved. For example, now is the time to figure out how to divide the many elements of the design between the responsible parties. To this end, we created a “responsibilities matrix” that clearly delineates which organizations are “responsible, accountable, consulted, supporting or informed” for each of the major systems engineering functions and products. The time spent developing and negotiating the matrix today is worth it later. The clear delineation of responsibilities reduces conflicts down the road and helps everyone do their job more efficiently in the long run.

The design decisions made now are soon going to turn into real hardware. Our first flight thruster has already arrived at SSL, and if all goes according to plan, we could be starting to “cut metal” early next year. That’s why our Technical Decisions are starting to really Count.

The art of systems engineering is to combine requirements, processes, analysis and rigor with the human elements that makes it possible to ensure that the whole thing will work when it comes together in Phase D. What we are doing today is building the foundation on which our future work rests. And as with a movie, once production starts, there’s no turning back!