Back to Top
Academy Interview: TDRS K Project Manager Jeff Gramling

An artist’s concept of the TDRS-K communication satellite. Image Credit: NASA/ Goddard Space Flight Center

December 22, 2011 Vol. 4, Issue 10


TDRS K project manager Jeff Gramling shared some thoughts with ASK the Academy on managing a communications satellite project.

An artist’s concept of the TDRS-K communication satellite.

An artist’s concept of the TDRS-K communication satellite.
Image Credit: NASA/ Goddard Space Flight Center

ASK the Academy: TDRS K and L are using a commercial satellite bus and a firm-fixed price contract. What are some of the project management challenges associated with this approach?

Jeff Gramling: Id say the primary challenges are fundamentally the same for any spacecraft build, which is to ensure you have the right set of requirements, a robust test program, and that ultimately the government launches a quality product. For out-of-house acquisitions, the type of contract defines the government’s ability to influence the process. The current TDRS contract is fixed price–incentive, but the main differences from the last two Goddard fixed price satellite procurements are the addition of the GOLD Rules, the General Environmental Verification Specification (GEVS), and a Mission Assurance Requirements Specification. The TDRS H,I,J and GOES fixed price acquisitions 10 years ago were commercial best practices, which were coupled with substantial penalties for failure to meet performance requirements on orbit. There were lessons learned with regard to quality during the ‘90s, and perhaps we had gotten too far away from government quality requirements. So we’ve tried to address any shortcomings with respect to quality in our contract, and are constantly trying to leverage the corporate knowledge that exists within the Goddard and White Sands teams to achieve mission success, and to do so within the constraints of a fixed price contract.

ATA: What kinds of lessons from the operations of TDRS H/I/J have been incorporated into the design of TDRS K/L?

Gramling: In terms of what we learned specifically from flight operations

on H,I,J, the most significant example is that we have folded in lessons from the TDRS-F9 on-orbit anomaly in 2008 into our approach for the K series spacecraft. (Note: This anomaly involved a temporary inability to get commands into the spacecraft.) Many of the lessons are not strictly implemented in the satellite design, but in ground designs, operating procedures, and training. The other documents I mentioned, such as the GOLD Rules and GEVS (both Goddard documents), contain global lessons learned and good design practices, so there are improvements coming in though those documents. But in addition to specs, we’ve turned bright people loose in areas such as our fault protection and safehold designs, flight software changes from H,I,J, and looking farther down on the fault tree in general to ensure our designs and contingency procedures are robust. We’re also beefing up the mission rehearsal training plan from H,I,J for the launch and transfer orbit teams to get more experience with off-nominal situations. So across the waterfront, we’re trying to undertake smart, focused activities to incorporate lessons learned, not just from TDRS, to ensure we’re successful.

ATA: How does the requirements development process for a communications satellite project differ from that of a science project? Who are the primary stakeholders that play a role?

Academy Interview: TDRS K

Three TDRS satellites, the International Space Station (ISS), and the Hubble Space Telescope orbit a blue-green Earth in this artist’s concept. The TDRS network facilitates around the clock communication access between ground stations and other satellite and the ISS.
Image Credit: NASA/ Goddard Space Flight Center

Gramling: The TDRS payload design is complex.

Perhaps not in the sense that we are pushing the state of the art technically, but it is a complex engineering payload to build, integrate, and test. Of course we fold in lessons learned from previous missions in terms of designs that worked well or that we had problems with. Due largely to obsolescence, the payload on TDRS K had to be completely redesigned from H,I,J. But to your point, we receive requirements from the Headquarters Program Office and we have interaction with users, including users from outside the agency. In many cases, use of the system has evolved to take advantage of the capabilities and flexibility in the TDRS system design. We try to ensure that what we do doesn’t preclude innovative uses. On the K/L program we’re building now, we explicitly changed the design for the Multiple Access Return system to do beamforming on the ground at White Sands rather than on-board, as we did on H,I,J. This was an example of where the use of the system had evolved while we were designing and building H,I,J. While we were off doing what engineers do—optimizing the spacecraft design to save weight and power by putting beamforming on the spacecraft (as counter intuitive as that may sound) —folks had come up with some neat ways to use the system based on the F1-7 ground-based architecture. So we’re going back to the original F1-7 spacecraft architecture for the K-series spacecraft.

An example of a powerful stakeholder whose buy-in we need might be in the COMSEC (Communications Security) domain. In this area we operate under direction from the NSA (National Security Agency), and they have the latitude to direct our design and implementation. So we’ve learned over the years that it is important to work very closely with them to make sure we’re converging, rather than diverging. And we brought them in on the ground floor when we were preparing the specification for K back in 2006. Then we had them participate on our Source Evaluation Board, and they’ve been with us along the way ever since. Their voices are always heard, and as a result, we received our system certification on schedule and without incident.

But every project, at one time or another, has had to deal with stakeholders who are relatively unfettered by project cost and schedule constraints. Dealing with those situations can be challenging.

ATA: What impact do requirements for orbital debris mitigation plans have on the project management of a communications satellite with a long life cycle?

Gramling: There are two pieces to this story: one is the upper stage of the launch vehicle, and the other is the ultimate disposal of the spacecraft. We factored sets of requirements in at the beginning, and they were evolving in 2006 when we were preparing our specifications. The Atlas IIA we launched H,I,J on was no longer available, and we ended up on an Atlas V, so we had launch vehicle performance margin to work with which allowed us to comply by putting the upper stage into a disposal orbit. As far as the spacecraft mission debris requirements, we folded recent lessons learned from the retirement of F1 spacecraft into the designs and required end of mission plans for the disposal of the K series spacecraft. Of course it is difficult to nail the procedures today for a spacecraft we’re looking to de-orbit in 15, 20, or 25+ years (as was the case with F1), as it is hard to predict the state of the spacecraft at that time.

ATA: What should young professionals who are new to NASA understand about TDRSS?

Gramling: Going from roughly 15% real-time communications coverage of a low-Earth orbiting mission to 100% allows us to solve data latency problems and also mitigate quite a bit of risk in terms of recognizing and responding to user spacecraft problems. It has proven to be a pretty flexible and robust system, which clever engineers will continue to find new applications for. We’ve always viewed the system in terms of what is has enabled for the agency’s other missions.

About the Author

Share With Your Colleagues