Space Acquisition - Air Force Space Command

2. Execute, or suffer execution.
As noted by Mr. Anthony “Tony” Spear, 20 in his scathing yet
folksy NASA FBC Task Final Report, “The project manager is
‘Captain of the Ship.’ The buck stops with him or her.” 21 A
program manager is usually picked to lead a program because
of his or her expertise, experience, and—hopefully, moxie. 22
Unfortunately, organizations have a tendency to load up and
sometimes crush these leaders with ministerial tasks or administrative
duties that can take up to 60 percent of their valuable
time and focus. This is not done maliciously; work and activity
naturally gravitate to people who get things done—it happens.
Levying additional duties on program managers without considering
the impact to the programs, or potential alternatives,
is misguided and entails risk. It detracts from the programfocused
leadership that is vital to steer work to completion.
Program managers must push-back against non-essential tasks;
and their supervisors must wrestle with handing out additional,
non-essential, or distracting tasks to their program managers.
Treat your time like it is gold; your time is one of the key
currencies of a successful program. Your job is to deliver the
product you have been charged to build, on-time, and on-budget.
Let your people know that this is your priority. Forge a
clear understanding with your bosses; have them affirm this
priority—even though other tasks will arise. Get their buy-in
on this priority early, and use it to make decisions regarding
how you spend your time and on what you will focus. Have
the courage to say no to other demands that conflict with what
it takes to execute your program.
Of course, cut out unnecessary paperwork (and e-mails).
Again, these sentiments are fully reflected in the legendary
Battle’s Laws. Staff communications that are not directly related
to program execution and their associated coordination,
at some point, become more of a burden than a benefit. Also,
understand the value of every meeting you attend. Set a time
for a meeting, and do not let it run over. People will get the
message when you stop the meeting at its appointed time. They
will learn to focus on the issues and drive them home in the allotted
time.
Taverney: While vice commander of Air Force Space Command,
I told everyone that we would start meetings on time and
end them on time. When a meeting started, I would emphasize
that those in attendance should make sure that they told me what
they needed me to hear—early on, so that at the end of the meeting,
their key points were not left unsaid. When, in my first
meetings, I got up and walked out at the appointed end times, it
became apparent that I was serious. Within a week, the people
in these meetings got to the point quickly. I also had people
categorize meetings by their purpose. Knowing the purpose and
subject allowed me to establish a time budget for the meeting
commensurate with its value. I also asked for background information
so if the same subject were discussed in some other
meeting, I could appreciate its context.
The point here is simple. You can get help on anything except
on getting someone else to take responsibility for executing
your program. The program is yours and cannot be delegated.
You are charged with significant responsibilities and must address
a myriad of requirements; you are responsible for delivering
the program—that is job number one. There will be pressures
to do many other things—and many of those things will
have to be done; but if these activities prevent you from giving
the appropriate and necessary attention to executing your program,
you must decide when to say “stop” or “enough.”
3. Establish a solid baseline.
An improperly baselined program cannot be executed successfully—even
by the best program office. Programs that
start with a non-executable baseline can only struggle going
forward.
The poster children for these problems are the aforementioned
SBIRS and FIA fiascos. SBIRS and FIA were started
without enough money or resources to successfully execute.
The technology readiness levels for the proposed systems and
architectures were woefully inadequate. Cost estimators and
systems engineers did not stand up and say that disasters were
pending. As badly birthed programs, they continued to struggle,
despite the upgrade of the program office and contactor staffs to
the very best people available. The lesson is that even the very
best mangers, with the very best program office personnel, cannot
successfully execute a non-executable program. 23
How can one establish a solid baseline Pay special attention
to the wide spectrum of systems engineering tasks: requirements
analysis and traceability, engineering change control, interface
definition and control, system design reviews, and test
and verification planning. Unfortunately, systems engineering
talent is often not valued by management. Systems engineers
are often sent to record meeting action items and track requirements
rather than to challenge every requirement, assumption,
constraint, ground rule, and so forth, and provide real tradeoff
and cost/benefit analyses. Systems engineers must perform
these vital functions.
The program manager and project team must understand
the requirements; a space system should be built to satisfy a
particular mission need. Ensure you have a robust systems
engineering process in place to establish and refine the stated
requirements, the derived requirements, and the allocation process
to the various components of the overall system. Engage
with the user, developer, and verification team during requirements
development to ensure they are understood, achievable,
quantifiable, and verifiable.
Rendleman: Requirements matter. I worked on a program
where the contract called for the delivery of a non-standard
government furnished equipment space shuttle elliptical/polar
flight out of Vandenberg to perform intercepts with U-2 aircraft
circling over the pole. There were huge costs associated with
the planned non-standard polar orbit and the aircraft’s sorties
required significant combat search and rescue support. My team
and I looked at the program requirements and found that a standard
space shuttle 28.5 degree inclination of 150 nautical mile
orbit would work just fine. It turned out that the new orbit provided
the same number of daily intercepts as those available
over the pole, and the U-2 sorties could easily be orchestrated
and supported from existing bases from lower latitudes (e.g.,
Hawaii, Texas). Of course, the prime contractor complained,
saying we would be in breach of the contract by not providing
intercepts with the target aircraft every orbit for the duration of
High Frontier 58