Space Acquisition - Air Force Space Command

More documents

Recommendations

Info

the mission. I challenged the contractor to show me how the U-2 pilot could stay up 24/7 for a week or more. The point was made and the mission parameters were changed within the real requirement. Ensure the program has an adequate budget with program reserve and an executable schedule with margin. There will always be problems and obstacles to achieving success. Reserve and margin allow for the determination of solutions and the development of tools to implement them. A contractor's bid does not assure the quality of the baseline. The bidding organization must dig into the elements that support it. In general, experience tells us that there should be a generous financial reserve and even greater schedule slack depending on technology maturity and program phase. While there are pressures to take reserve and slack from your program, fight as hard as you can for them. You may not get management reserve, but you should always have schedule margin. Employ quality software engineers as a foundation to your systems engineering process. Software engineers are the penultimate systems engineers; they track more than 1s and 0s across your system—they track requirements and connections. Unfortunately, failure to properly engage software engineers early in the program can lead to problems, even when the hardware solutions are working nicely. Software problems can derail the best hardware engineering success, and these types of problems have been with us for decades. SBIRS and inertial upper stage programs have had serious software problems, and so have many other systems. At the end of the day, you are not always in control of the baseline. Frequently you are assigned programs that cannot close (that is, cost/schedule versus technical requirements). 24 If you are handed such a program, you have two options. You A ground-to-air view of the space shuttle Challenger during liftoff from launch complex 39A. can set up a stoplight (red, yellow, green) chart that matches the programs cost and schedule risks. Set up as many risk areas as you can. Within these risk areas, define cost, schedule, and technical risks, with dollars and schedule, and brief these at every status review. When risks become real, book them with the requisite cost and/or schedule impact. As a second option, you can make cost and schedule your primary metrics, and define the requirements that you can deliver, making the others optional or available for purchase with additional dollars and schedule. Do not just blindly accept a program that you know to be non-executable with the hope that things will change and get better in the future. 4. Control the baseline; it is your lifeblood. Changes have the potential to destroy a program—so a program manager must be vigilant against external and internal pressures to implement them. Rebaseline when executing any substantive changes. Tony Spear recommends establishing a challenging but realistic mission target, obtaining upfront agreements and maintaining them, and defining the mission scope within the constraint of resources, providing for acceptable risk and adequate reserves. 25 It is easy to fall into the trap of making changes to a program in the name of flexibility; but programs are not well-enough resourced to accept changes without impacting their baselines. Once a program is awarded and program execution has begun, various outlying players will suddenly take an interest in the capabilities that the system might provide them. As a result, the demands or suggestions for requirements tend to grow. Over the life of a long-duration program, the ultimate players—the US Congress and those in the budgeting process—will move funds and leadership priorities will change. Either any or all of these will compel the program manager to rebaseline. How should the program manager control his or her baseline First of all, do not accept increased risk. The military, civil, and commercial programs derailed by increased risk are too many to count. A classic and most tragic example of where this occurred is NASA’s Space Shuttle program. With schedule pressures to launch all DoD and civil payloads nearly exclusively on the space shuttle in accord with 1982 National Space Policy, NASA managers accepted additional risk and forced a launch outside its established weather and temperature parameters; this led to the 1986 Challenger O-ring failure and disaster. Rendleman: I was in a US Air Force meeting where the decision was made to not help NASA fund heater elements for the external boosters. We disposed of the request based on a conclusion that NASA would not fly when the weather was so cold that they would be required. While NASA’s human safety ethic and mission delays were causing scheduling problems for the US Air Force at that time, we accepted the situation because of the national policy. Who knew that NASA would take on a can-do spirit and ignore its responsibilities to its astronauts by accepting additional risk Program managers should carry prioritized sets of their program requirements with them, so they can be jettisoned or modified on a moments notice to ensure the core require- 59 High Frontier
ments are achieved. That said, managers will be challenged to investigate additions or insertions of new technologies. They must carefully appraise the need for them and the opportunities they present. These in turn must be balanced against the risks and schedule impacts they may bring. Similarly, proposals to descope and/or reduce technological complexity on a program must be evaluated. All are important. Rendleman: During the early 1980s, I worked on a program that required real and substantial improvements in the navigation capabilities of the space shuttle for mission success. This was long before the GPS system was declared fully operational. My solution to solving this technical challenge was to propose a program that employed a then-new technology—an off-theshelf F-16 GPS receiver—instead of selecting and constructing a new “space-qualified” receiver that would sit on a pallet in the shuttle bay. NASA hesitated at first; its leadership was uncertain about the US Air Force’s intentions for completing the new precision navigation and timing system’s constellation. NASA did not want to accept the risk until it could be better understood. We won NASA over and were given the green light to begin the program. What a difference a quarter century makes in attitudes regarding integrating GPS capabilities! Once underway, increased risk will emerge and can get in the way of a program’s success. Program managers must refuse to accept new requirements, cost, or schedule changes without changing the program baseline, and realigning expectations. Budget cuts should reasonably mandate a reduction in requirements. Requirement additions should reasonably result in added costs and expanded schedules. Establish correct and measurable metrics for each phase of the program. Each metric must take into account the level of program complexity involved. Analyze key metrics thoroughly to make sure you understand the implications of adverse indications to the second and third orders of consequence. Do not overburden the program with metrics of dubious utility. Then, monitor, monitor, monitor these metrics. Taverney: Later in my career, I was asked to take over a distressed program. The customer had said, “Not a dollar more, not a day later; we will use whatever you deliver in these constraints, as long as it is better than ballast.” I decided to make “Better Than Ballast” a rallying cry on the program. It forced us to think about what we were doing whenever someone thought we could do something a little better with a little more time and/ or money. It kept us focused on cost and schedule as much as capability. It became a sense of pride to deliver something far, far “Better Than Ballast.” This program was pioneering three different challenging technologies in parallel, but our rallying cry kept our eyes on delivering what could do the job. We have all heard the old adage: “Perfect is the enemy of good enough.” In the end, this program was extremely successful. While its success was the result of the great people performing the work, the rallying cry of “Better Than Ballast” turned out to be an excellent management tool for keeping the team focused on controlling the baseline and not accepting increased risk; it even helped to build a sense of pride within the team. Since money begets stability and technical success, simplify spending to achieve core requirements. Fight for program money to help ensure you can keep and control your baseline intact. Shareholders and customers will always wish you success, but you must have the money needed to achieve it. Fiscal problems will generally be resolved only if your program is perceived as important. Funding stability is critical to program success. If your program is not properly funded, you need to get additional funding, cut requirements, extend the schedule, or all of the above. Determine your real funding requirements, then firmly and persistently advocate for the added funding until you get it. If your program is not adequately funded, you may need to rebaseline or even cancel the effort. If your program does not obligate and expend on time, the money will be taken away! The government program office and its contractors have different motivations. The government program office balances cost against the product; while the contractors live from quarter to quarter and are driven to deliver profit and growth to their shareholders. 5. Manage risk; it never goes away on its own. A program manager must establish a robust and proactive risk management approach. He or she should always know the program’s risks, and—above all—take ownership of them! Again, Tony Spear had it right when he said: The project manager and team are responsible for ensuring that all elements of a project are being implemented with acceptable risk for those project elements under their control and for those outside their immediate project control.… While project risk at the outset may be high, it must be sufficiently assessed and mitigated throughout development and operations. Not having enough funding or schedule resources are never excuses for failure, and it takes a project manager with good judgment and courage to declare under pressure that the project is not doable for the available resources. This ability to judge, to walk the fine line between challenge and risk, is even more important in today’s environment.… 26 Spear recommends conducting rigorous system and subsystems engineering to establish standards; conducting continuous, rigorous risk assessment and mitigation throughout development and operations; balancing the use of available and advanced technology to achieve mission success; and establishing and maintaining metrics for mission risk and technical, cost, and schedule performance. 27 A program manager must live, breathe, and satisfy high-payoff, achievable requirements. Not all requirements are created equal. We do not build slam-dunk systems in the space community; there will always be risk (cost, technical, schedule, and programmatic) to achieving success. Eliminating risk is not feasible. In the space systems business, prudent risks must be taken. But, you need to understand the risk, and have a plan to mitigate or handle it should it materialize. Prioritize your risks, and understand their impacts to the mission. Managing (and owning) risk is critical. Program managers should review the risks and the risk mitigation plan early and often. They should do this with the contractor team and with the user representatives to ensure that risk issues get the attention they deserve. You must also prioritize the requirements that will be worked during a spiral or program increment. Make sure to work the High Frontier 60
Page 1 and 2:
INSIDE: Air Force Space Acquisitio
Page 3 and 4:
Introduction General C. Robert Kehl
Page 5 and 6:
Operationally Responsive Space In a
Page 7 and 8:
From a technical perspective, the n
Page 9 and 10: per CJCSI 3170.01, is no more than
Page 11 and 12: Space Acquisition: Space and Missil
Page 15 and 16: years late to need). It was also on
Page 17 and 18: ooks, guides, and deliverable data.
Page 21 and 22: By relentlessly pursuing continuous
Page 25 and 26: Figure 2. Template knowledge points
Page 27 and 28: The primary focus will be to levera
Page 29 and 30: e hosted on the SIV, now referred t
Page 31 and 32: difference: public policy created t
Page 33 and 34: Space Acquisition Regaining Credibi
Page 35 and 36: tions. The 526 ICBMSG provides sing
Page 37 and 38: and acquisition of space systems; e
Page 39 and 40: curement practices that had ever be
Page 41 and 42: sume that if this old computer is e
Page 43 and 44: A Brief Example of the Value-Centri
Page 45 and 46: Space Acquisition The Cyberspace-De
Page 47 and 48: These observations all involve the
Page 49 and 50: the same capabilities within a larg
Page 51 and 52: Space Acquisition Is Acquiring Spac
Page 53 and 54: • Give up on trying to get a good
Page 55 and 56: • Establish quality program basel
Page 57 and 58: Imagery Architecture (FIA) programs
Page 59: 2. Execute, or suffer execution. As
Page 63 and 64: losing. As our nation has garnered
Page 65 and 66: to the point; measurable; and empow
Page 67 and 68: Legislative Perspective Weapon Syst
Page 69 and 70: AFSPC and its acquisition arm at Sp
Page 71 and 72: Book Review Arms and Innovation: En
show all

Space Acquisition - Air Force Space Command

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?