Seven at a single blow

I still have lunches with my old chums from my days at JPL. On several occasions I've heard, "OK, we know there's problems. But what would you do to make things better?"

The question has been nagging at me. It's one thing to sit on the sidelines an take pot shots, it's quite another to take specific actions. I've been thinking...

How would you even approach the task of changing a very large, inflexible government bureaucracy to refocus its energies from a stovepiped, hardware-centric mindset to a unified software/systems-centric approach? New Leadership? A massive reorganization? A huge infusion of cash? Nah. It's all been tried with no more impact than a sand flea's assault on an elephant. Why?

Large bureaucracies are a civilization's great stabilizing force. The longest-lived civilizations, Egyptian, Chinese, Roman¹, all developed powerful bureaucratic institutions. They arise naturally around the seat of power and grow into competitive dominions that will perish if not defended. Since change threatens the division of authority, the power of its management, the livelihood of its minions, and even the bureaucracy's very existence, protective barriers emerge like great jetties against the tide of change. So while bureaucracies stabilize, they also paralyze. It is their nature. Any attempt to change the bureaucracy is a non starter.

What's needed is a strategy that would produce a change by using a bureaucracy's existing machinery.

There's no explaining why, but the story of the Valiant Little Tailor sprang to mind. If you don't remember, the little tailor is an insignificant person who was about to enjoy a lunch of bread and jam when, to his dismay, a swarm of flies lands on his jam. In a moment of pique, he grabs a piece of cloth and swats the flies. The result: 7 flies meet their maker. The little tailor takes great pride in this feat. He wants the world to know, so, he embroiders a sash with the words "seven at one blow" and sets off to make his fortune and eventually rule a kingdom. ³

The story got me thinking. What small feat might trigger the dominos of change, get the Agency out of the current rut and put the space program on a path to develop a new space system that would excite public interest and reestablish the nation's leadership in space technologies? What would disrupt the division of bureaucratic authority and trigger the survival reflex. What if there was a challenge comparable to that faced by the engineers in the Apollo program. What if the Agency decided it was going to build a new kind of system for a flagship mission with requirements that simply could not be produced by current practice? What if there were 7 requirements that would set in motion a fundamentally constructive change?!

"...almost all really new ideas have a certain aspect of
foolishness when they are first produced."⁴ A.N. Whitehead

Inspired by this challenge, I put in a good bit of careful procrastination, day dreaming, weed pulling and cloud watching. Failing any real insight or inspiration I finally sat down and dashed off 7 requirements that, if mandated, might force the development of a new type of space system--one that would set a new standard for how NASA conceived and developed its spacecraft.
Note: These are non-functional requirements; i.e. they describe how the system would be built or how it would perform. (By contrast, functional requirements describe what functions the system must perform.)

The 7 Requirements:

1. The proposed mission budget shall account for the mission's complete cost-of-ownership from formulation through operations where operations includes an extended mission phase that is three times the duration of the primary mission.

Rationale: Mission proposals typically reflect a minimum operations budget as an artificial means of reducing the cost to fit under a cap. The practice is always successful because, once the systems is flying, it becomes a valuable asset with vested interests that no seasoned bureaucratic would abandon. Consequently, extended missions are almost always funded. However, since the actual cost of lifetime operations is never reckoned in the original proposal, there is no justification for innovations that would make a spacecraft more reliable or cheaper to operate. If the full cost of ownership was taken into account, that balance would shift and it would be cost-effective to build a better spacecraft.

2. The flight and ground systems shall be unified into a architecture with a common design philosophy and shared information architecture

Rationale: A common flight/ground architecture would undo the existing stovepiped architecture that's been frozen in place by the vested institutional factions that comprise the bureaucracy. The shared information architecture would narrow the gap between systems and software engineering and eliminate the class of errors that lead to the loss of the Mars Climate Orbiter and Mars Polar Lander.⁵

3. The project shall be limited to 36 months.

Rationale: The products created in initial phase of the project are usually cast off when the 'real work' begins. A short schedule will force the team to act decisively from the onset. And, because the schedule is short, institutions will be motivated to invest new approaches before the mission development begins.

4. (a)The technical lead shall include a 'decide-by' date for every technical decision requiring management approval. (b)Managers shall respond to these decision requests with an unambiguous decision before the 'decide-by date' or be replaced.

Rationale: In a large bureaucracy, decisions are inherently risky. Managers tends to delay decisions until the options are no longer relevant or until a committee consensus has been reached. This requirement would encourage managers to assume individual responsibility. It would also provide the development teams with timely approvals.

5. Each functional requirement shall include at least one test scenario with success criteria.

Rationale: Requirements expressed as natural language shall statements are typically vague. Even modeled requirements may leave plenty of room for interpretation. By comparison, a test scenario clarifies the intent of a requirement by providing a concrete and specific instance of what the function should do. Clearer requirements help programmers build the right product and avoid costly defects from miscommunication.

6. The staff needed to complete all mission operations activities shall be limited to 5 engineers.

Rationale: Operations for a flagship mission like MSL typically require dozens of engineers and an annual budget of double-digit or triple-digit megabucks. A team this size is needed to manage trajectory change maneuvers, in situ maneuvers, science planning and recovery from system faults. However, these costs could be dramatically reduced if the system was conceived and built as a unified flight-ground system designed for autonomous flight. Without a requirement to fly with a very small team, the Agency business model coupled with the need to feed the current engineering cadre will prevent the development of an autonomous system.

7. Board members for software reviews shall be prepared to provide the development team with a detailed technical accounts of any reported findings.

Rationale: In the current process-centric, Agency culture, review boards are inclined to focus on checklists of documents without close examination of the engineering described in those documents. Board members seldom have the time or skills necessary to examine key technical design choices. If board members were knew they might have to discuss technical details, the board would prefer in-depth, engineering-focused presentations to a rehearsal of process compliance.

No doubt someone with superior engineering judgment would produce a better list. However, even this paltry list could serve to shake things up. But only if someone with authority was foolish enough to confront the giants and unicorns and insist on building a system with 7 disruptive requirements. It's an unlikely prospect— bureaucratic managers are selected because they lack those very qualities. However, if by some oversight or error, the highest levels of the Agency approved a disruptive project, I'd walk away from the joys of retirement and do my darndest to secure a spot on that team.

---

^1. The Egyptian empire lasted roughly 5,000 years. The Chinese empire roughly 3,500 years. The combined Roman State (Republic + Empire) lasted about 1,100 years.
^2. Interestingly both Roman and Chinese bureaucracies were staffed by eunuchs.
^3. Fortunate he was! The little tailor went on to outwit 3 giants, a wild boar and a unicorn on the way to win a princess and a kingdom. In this story, hubris pays off.
^4. Whitehead, A.N., Science an the Modern World. Free Press Paperback. 1925. p.47.
^5. I know of one architectural approach that meets this requirement: The Mission Data System (MDS). MDS was developed in the last decade, but never used. Perhaps there are other approaches.