This is the seventh in a series of articles on how to go about dramatically reducing space mission cost while maintaining a high level of mission utility. This article discusses personnel elements in reducing cost. In a sense, the personnel issues associated with dramatically reducing space mission cost and schedule are pretty straightforward:
- Make it somebody’s job to get it done.
- Assign a small, preferably collocated, team to do it.
- Give the team moderate funding and a reasonable (but short) schedule to get it done, empower its members to make many of the decisions with minimal oversight, and reward both people and organizations for getting it done.
- Let the team do it and enjoy the results.
Both the government and large organizations would much prefer to depend on rules, regulations, processes and procedures, but the reality is that wars are won, inventions are made, new businesses are created, and creative ways to change how we do business in space are developed by motivated individuals who are out to get the job done. This means that individuals and small teams must be empowered to get things done and be motivated to do them.
Make It Somebody’s Job
As we argued in the first article, it is important to get started by making it somebody’s job to get it done. This lead person will need access to and strong support from senior management and the senior system engineers, but also should be outside the structure of a major program. (If he or she also has a central role in a major program, the person won’t have the time for the reducing cost task and will be pulled in multiple directions by their program, for which reducing cost is unlikely to be task No. 1.)
Select, Motivate and Empower a Small Team
A cast of thousands isn’t really a big help in this process. A small team works much better and can dig into the real issues and get the job done. Of course, it also requires that we give team members the things they need to get the job done. This means they need to have a moderate budget to get some studies under way and start some serious mission and systems engineering. They’ll need to talk to lots of people outside the organization, go to conferences, talk to a few more people, and visit other organizations that are doing similar things. At some point a set of alternatives, with risk and rewards clearly spelled out, needs to flow up to management for a decision on how to proceed. (These are decisions such as refining the team’s objectives, defining what program or problems to tackle first, and determining whether it will be done primarily internally or by making agreements with other organizations. After all, reinventing the wheel may not be the wisest choice if a compatible partner organization already has some pretty snazzy wheels in its inventory.) When this has been done, the team needs to get a realistic budget and schedule to begin to create real hardware and software.
Having set the objectives and the broad outline of the project, we need to empower the team to step out and get the job done. Once that has happened, motivation should largely take care of itself. The team has a critically important job to do and has been given the resources and authority to do it. It seems like a job that most of us would want to have. If we’ve selected the right team, the motivation is there.
It also helps to have a collocated team. The best communications are face-to-face, and having the team collocated avoids a sense of “us vs. them.” On the other hand, it’s really the communication that matters. The amateur radio satellite organization AMSAT doesn’t seem to need collocation because its members communicate essentially continuously and get to know each other well. Similarly, someone who knows the other team members well doesn’t need to be there all the time. But being in the same room from time to time does wonders for resolving differences of opinion, bonding the team and solving problems quickly.
Reward Low Cost
Personnel and groups should be rewarded for major reductions in cost and schedule. As a counter-example, the reward for not spending all of your department’s computer budget by the end of the year is typically having a smaller computer budget the following year. Amazingly, in most departments, the computer budget is always spent by the end of the year. A much better approach would be to split the savings between the organization, in order to reduce the overall budget, and the department end-of-year party fund or divide it among team members as a bonus, and not reduce the computer budget for next year.
Rewards don’t need to be money. Give whoever came up with the best idea for significantly reducing cost or schedule the parking space next to the door and let the department manager park in the back lot. (Actually, it would probably be best to give the department manager a bit of a reward as well. In the end, you want both the individuals and their managers to be pleased with the result.) Many small-satellite builders take great pride in building high-quality, low-cost satellites in a very short time. It is something they have learned how to do and that much bigger, better-funded organizations still don’t know how to do. Recognizing this excellence can be a reward in itself. The real secret to reducing space mission cost is to empower individuals and small teams, motivate them to reduce cost, get out of their way, and then reward them for achieving it.
Can it really be as simple as that? In some respects, no. There is still a lot of system and mission engineering to do and a lot of rules and procedures to undo. If we’ve selected the right team, the system and mission engineering will be challenging but workable. Changing the rules by which we do business is much harder. After all, the rules and procedures and policies and regulations were all put there for good reasons. Unfortunately, they may or may not be applicable in the current circumstances and may be getting in the way of making the dramatic progress we need to make.
This suggests a process that I’ll call “trading on procedures.” We have talked previously about the need to trade on requirements, i.e., to look at each requirement, determine why it is needed, and then determine for any given system the cost implications of that requirement and whether we need to adjust it to meet our end objectives. We need to do the same thing with our procedures and rules. First, we need to determine why those procedures and rules are what they are and where they came from. Then, for each mission, we need to ask, does that procedure make sense in this circumstance? Many procedures were put in place specifically because space projects cost billions of dollars and we wanted to be 100 percent sure they would always succeed. But these procedures may be a large part of the reason that the program cost billions in the first place, and, of course, there have been failures and errors even in the most expensive programs. It is exceptionally hard for management to do, but it’s better to trust people than to trust procedures.
The bottom line is that, yes, it really can be as simple as finding the right people, giving them the resources and the authority to get the job done, and then letting them go do it. Not every project will succeed every time, but that’s also the case with more traditional programs. If we dramatically reduce the cost and allow multiple spacecraft to be built, then we also reduce the risk by having backups available when we need them. Failures are never good, but they are much less of a problem if we have a backup available and ready to go.
The eighth article in this series will look at spacecraft technology approaches for reducing cost.
James R. Wertz is president of Microcosm Inc. He is co-author of “Reducing Space Mission Cost,” published in 1996, and has been teaching a graduate course at the University of Southern California on that topic since then. If you have questions, comments or suggestions, or simply want to discuss these issues, he can be reached at email@example.com. Information on the joint Microcosm/USC Reinventing Space Project can be found at www.smad.com/reinventingspace.html