Concept to First Flight

I've had the rare privilege of managing an aircraft development program from early drawings on napkins through first-flight approval. During that time I had the most effective of feedback loops: living with the consequences of my choices earlier in the process.

Due to the holiday on Wednesday, today is my only post this week.

F-100-F airplane, equipped with thrust reversers, full scale wind tunnel test. Photo credit: NASA

During my time as a Program Manager and Senior Program Manager for landing gear systems, my portfolio evolved into "new military programs": new business development, proposal writing and approval, supervising engineering teams for level-of-effort contracts, and most of the military development projects after award (all of the various new product introduction efforts).

I remember one program in particular because it started as a small level-of-effort engineering project. The customer was decided to move forward with a full development program including the delivery of a handful of flight-test hardware. Later this expanded to pricing out several production options and negotiating those as well. At each phase, I remember running into issues and thinking, "What idiot agreed to these requirements?" ... And every time, the answer was, "Me."

When we were in preliminary design, we left several requirements vague or open because the landing gear and aircraft were still in flux; this is standard but requires discipline to firm up all of those requirements and document them. As is also standard, we kept finding requirements that weren't as aligned as we thought. One that's burned into my memory was a customer requirement for a certain off-the-shelf (i.e. not a new design) component. From early days everyone involved had agreed and understood that the component was, but when the vendor started struggling the Contracts teams got involved. That was when we realized that the component part number wasn't in our requirements, just its performance. Technically, we were on the hook for a performing component, NOT just supplying the component the customer asked for. Luckily, the Engineering team at the customer was able to convince Contracts that they had specified the component, and we were able to provide enough meeting notes to provide a paper trail. They modified the specification to call out whatever performance the off-the-shelf component could give. But I was astounded how few references there were in writing.

I've always been a stickler for storing information for where we can find it later, but experiences like that honed my desire for extremely clear note-taking and ensuring that the information is findable later. As soon as possible, the the contractual documents must reflect the various in-process agreements, and where they don't there must be a plan to get there. Another development program that started around the same time had a less-disciplined team: I had people approaching me 10 years later asking me what was in the contract or our pre-contract negotiating position (I'd been involved in the proposal and initial negotiations). I still had my notes and could find the answer; the team leading that program had never firmed up the contract.

I also learned not to let price negotiations drag out. We started work on the development contract under a "not to exceed" authority: the total contract would be for no more than our proposed price, and in reality a lower negotiated price. On a regular basis I would reach out to my customer and ask about negotiations to finalize the price, and they kept telling me that we weren't far apart in our negotiating positions. I believed that meant they would counter-offer maybe 10% less than our asking price and we'd negotiate from there. When we FINALLY got a counter-offer, it was closer to 50% off. We were able to scramble, push back, prove the value of our numbers, and trade some scope, but it was a rude surprise and we'd already performed a lot of the work; our leverage was a lot less than at the beginning. I was also frustrated because from my perspective we'd already done a lot for the customer: letting the contract hang out like this was a favor to them because it let us start work and keep to their schedule. Eventually, we settled somewhere that was mutually acceptable, but on future programs I'll have this story as ammunition when I tell a customer that it's time for us to finalize the contract.

Because people move around companies and development programs are rare, having that closed feedback loop where I had to live with my initial decisions was a privilege. I was able to use that knowledge during a few other programs and other complex projects, but none of them were that same "from the cradle" experience. Uncrewed aerial vehicles seem to be shortening the development cycle again; maybe I'll get another chance.