Flying High

Hello and welcome back! Glad you are here! So we came off a great year, transitioned to a new role; Project Engineer for Systems Engineering team of a clean sheet aircraft. How cool is that, right? This was going to be big, multiyear, development, and implementation of new system. We needed some organization.

The team was about 10 or so system engineers, each with various strengths. Novel idea, have them oversee the domains that related to their strengths. Background, here is how things typically were organized back then. Systems Engineering was responsible for capturing all the high-level requirements from the customer. Those were then decomposed into various domains, such as displays, flight controls, flight management system, etc. For the overall program, there was a Technical Project Manager (responsible for all of engineering), Program Manager (responsible and accountable for the entire program, profit and loss, all components of support, etc.), and Chief Engineer (primary customer liaison and smoozer representing engineering expertise, typically Principal System Engineer; I mean these people are really, really smart.)

Our program was a follow-on program. This meant we were taking the base system and modifying it to specific capabilities tailored for this aircraft. So, there were a few external dependencies for us to track. By a few I mean every single part of the system. My brilliant TPM, one of the best project managers I have ever met, suggested we put all our dependencies at the top of the schedule and link them as appropriate to our effort. Such a simple and genius thing. Additionally, to keep communication flowing in the team, each engineer from my team was assigned as liaison to a domain, or multiple in the case of the Chief Engineer.

This style of organization was critical. One of the biggest challenges in developing these systems where the domains not fully understanding what the requirements from systems engineering really meant. By providing a go-to representative we could be more responsive to the domains and our Chief Engineer could gain some bandwidth. In addition to domains, some of the team had additional responsibilities for leading, such as requirements, system testing, integration, and so forth.

A funny thing happened, our team was able to essentially catch up with the programs that were supposed to be before us so we had to pace ourselves to not get in front of lead programs. Another tactic employed is that I met on a very frequent basis with the leads from a few of the more critical domains; displays, flight controls, flight management system, etc. It was a wonderfully engaging experience. Communication was key to us being able to accelerate the program the way it did.

A less fun aspect was when all the programs underway at that particular moment, had to present their project plan to engineering leadership. One of the key assumptions when going after the program was that there would be significant reuse of what was developed prior to a program. We were lined up like a train, staggered to deliver the cool new thing to multiple customers. One problem, reality laughed at that assumption and so there was not as much reuse as assumed. So, the programs presented, and yes, ours was an outlier. Way above the other programs. Such a good time.

We began digging into our forecast. We had detailed out our assumptions based on what we learned as the program was getting set up. Visited the lead programs to get a feel for how things were playing out in reality. Based on the input of actuals, and careful examination of the team we had, a fully detailed work breakdown structure was created. The method we used will be subject of another post.

Once the schedule was laid out, assigned resources, etc, we could provide a forecast that was as accurate as could be created based on available information. It was not an easy message for leadership to hear, but the evidence addressed the questions raised. Spoiler alert, we were eventually proven right in our estimation. Several other programs were underestimated and were sent back to validate.

Things were going along, all was great. Then September came. What is it about September? Lehmen Brothers melted down, and the financial crisis that had been building reached a point of no return. Our customer was leveraging the financial arm of their business to fund the development of this new aircraft.

The program was cancelled. Good news, the team was reassigned to other areas where there was a need of engineers. Bad news, someone thought that an engineer is an engineer and interchangeable regardless of domain.

Where was I headed? Oh, just you wait.

Thanks for reading!