Space Acquisition - Air Force Space Command

Never surprise your team or your boss. Holding your cards
close to the vest wins only in cards. Supercharge your networks.
Some people know the answers, but will not tell you
until you have made a stupid decision.
Rendleman: Of course, any boss can orchestrate information
systems in his or her own way. As a young officer, before the
“email information sharing” age, my colleagues and I would
draft correspondence to external agencies and submit these to
our boss. Not knowing better, our letters would drone on for
pages, sometimes 10 or more, detailing the problems and issues,
and setting out the points we wanted made. The colonel would
take the drafts and set to work, ending up with impressive letters
of no more than a few sentences; but his short masterpieces
said everything that needed to be said. When I found out he
was doing this, I proposed that we make the extra effort to give
him to-the-point letters as our drafts. I was told in no uncertain
terms the colonel wanted our long drafts; this was how he found
out what was going on.
Although timely, accurate reporting is critical to program
success, you must be careful not to devote so much effort to
reporting (especially by your best people) that you compromise
your ability to manage the program in the first place. Simplify
the essence and speed of reporting. Taking too much time to
tell customers or each other what you are doing does not get
your work done. Managing the program is far more critical
than reporting the program.
Taverney: In 1992, I was asked by a US Air Force customer
if I could come explain why one of its programs was a chronic
poor performer. I first went to the contractor and walked the
floor. I randomly asked people what the program is trying to accomplish,
how the individual contributes to the program’s goals
and objectives, what the individual is accountable for, what
authority the individual has to accomplish his or her job, and
with whom the individual communicates to get this job done. I
found that most of those questioned knew what the program was
trying to accomplish, but only a little more than half understood
how they fit into the program. Fewer than 10 percent knew
what his or her authority was and with whom he or she should
be communicating to get his or her job done. While some of
these problems can be resolved by applying the 10 rules spelled
out in this article, in this case, it was clear that program communication
was an issue.
10. Deliver; it is all about delivering the needed capability to
the user.
There will ultimately be users for the system that is being
built. The program team must build the system to provide a
capability or set of capabilities to the users.
Build the system for what the customer needs. Do not lose
that vision or focus. Each requirement must be tied to a concept
of operations (CONOPS) or employment. Clearly define each
requirement and understand its linkage to the CONOPS—and
always have an updated CONOPS.
Use a building block or spiral development approach, as
mentioned in rule five on managing risk. This allows the program
to field its systems early and often. While you are building
the system, talk to the users. It is invaluable that they understand
what they are getting, and that you (and the program
office) understand what they expect, and how they operate.
However, make sure that you do not accept requirements from
the users. While they may not be able to get everything they
want in the first block or spiral, encourage them to vet requirements
through the proper channels to get them in a future block
or spiral.
Getting something into the user’s hands early will help you
get the feedback necessary to define the next blocks/spirals.
The operator’s view of the system is usually different from the
engineer’s view. A program can meet every requirement documented
in the engineering specification and still leave a customer
not fully satisfied. Work hard with the user/operator to
understand and control the CONOPS; it is essential for developing
a comprehensive and consistent set of technical requirements.
At times, users do not know how to describe what they
want; using a little time and money upfront to demonstrate, prototype,
or analyze requirements will pay big dividends later in
the program.
Taverney: Another program I worked on in the old days was
the data systems modernization (DSM). The legend behind this
program is that we built a system with no user inputs or interface.
Yep—you guessed it—that was not a good thing. The
government program manager prohibited the contractor team
from any kind of communication with the user. The colonel’s
point of view was that, since the team knew computer technology
and capability far better than the users, we could build a
modern marvel and the users would be happy. I suspect this was
just one of the many programs throughout history that was begun
and executed based on this fallacy. When DSM was delivered,
it was indeed a marvel of technology; but the users found
it far too different from the way in which they currently operated.
Fortunately, within the next few years, with many userfriendly
modifications, the system lived up to its promise—but
those first few years were painful for all involved.
Concluding Thoughts
Studies and panels have documented many problems in
space acquisition caused by factors outside the control of program
managers. These have not really told a program manager
how to better acquire a space system. Without adequate resources,
national space institutions have all tried varied coping
strategies to achieve mission success in spite of limitations and
evolving priority environments. We cannot depend on institutional
and resource changes to complete the hard work of effectively
building and deploying space systems. Space systems
still have to be engineered, built, and delivered. The 10 rules
for common sense space acquisition spelled out in this article
are derived from lessons passed down from great mentors and
years of experience and observation. They are intended to provide
the program manager with the tools needed to better manage
and engineer space programs for success.
The 10 rules may indeed be more like guidelines than rules,
but careful consideration of these with respect to your programs
will allow you to perform the critical thinking necessary to
have control of your program. While some people may call it
sandbagging, under-promising, or just being more conservative
in setting expectations, these guidelines can allow a program
manager to surpass some of the limitations inherent in the current
space acquisition environment. The rules are actionable;
63 High Frontier