One thing I have noticed over my years as a practicing principal systems engineer is that when program managers and technical leads can’t tell their story clearly, it’s because they aren’t clear about what they’re trying to accomplish.
Let me back up for a moment and introduce myself, since I’m a new blogger on these pages. I’m Fran McCafferty. I’ve recently joined Vitech as a Principal Systems Engineer. Although I’m new to Vitech, having just started on Nov. 28, I’m not new to systems engineering. My first systems engineering project was for GE Aerospace on the Strategic Defense Initiative program 30 years ago. In that role, I served as a subsystem lead systems engineer and as the program requirements manager, where I led the program effort in applying what we now know as model-based systems engineering.
As a program leader, I discovered a shortcut to finding out if a given project manager had a good handle on the project they were charged with overseeing: I asked them to tell me the story of their project. The story I was looking for was the technical approach they were taking and how they planned to execute it. Teams that couldn’t clearly tell their story were always problem programs. When program managers and technical leaders couldn’t easily tell me the narrative of their project, it was because they didn’t clearly know what they were trying to accomplish. At this point, I would ask to see their Systems Engineering Plan (SEP). While most of them had an SEP, it was obvious that they really only cared about checking a box and not actually doing the prescribed work.
But that’s where we can get into trouble as systems engineers. Telling a story forces one to think through who the actors are, which character does what, what the obstacles are that the hero has to overcome, and how the plot progresses. Being a good systems engineer forces us to think through our project and look at how we expect it to unfold. When you can articulate this, you’re well on your way. When you can’t, it’s time to take a step back and think through things until you can.
In the not too distant past, I was reviewing a program in preparation for its kickoff. The review included understanding the Basis of Estimates (BOE) to determine if the hours bid were adequate to perform the work at a profit. When the team began presenting the estimates, I noticed the leads listed a series of disjointed tasks and had no deliverables in terms of analysis, specifications, or products. When we asked why a specific trade study was in the plan, what the intention of the study was, and what the team expected to learn when it was completed, the team said they would know that when they were done. Red flags were abundant. A story line was not.
On a more positive note, another project I consulted on was identified as being about 10 percent underbid. The systems engineering team took an unusual tack that would most certainly bring a high level of senior management visibility. The systems engineering team had decided it would not allow the design engineering team to start work. No work translates into no progress which translates into schedule pressure later in the project. The systems engineering team knew that if they executed the flawed proposal, they couldn’t meet financial objectives. So the systems engineering team re-planned the project, looking at alternatives, especially ones that corporate wisdom would normally frown upon.
When the team completed their analysis – determining “what” the project had to do, instead of “how” – they chose an approach that was completely new to the organization. This team looked at all of the barriers to success and the major cost drivers. They eliminated the barriers and avoided doing work the way it had always been done in favor of a new approach. Three years later, that program successfully completed design, manufacture, and test, and returned a profit to the organization. They met every program milestone on schedule. If the engineering and program leadership hadn’t halted the project, the design would have continued the way it was initially proposed and lost money. The team found a better way forward by telling a new and different story.
My job as a system engineer at Vitech is to help organizations perform systems engineering better. Whether you are designing a satellite or producing a form, systems engineering applies. Where I can help organizations is to leverage my 30 years of experience, my model-based systems engineering expertise, and a mastery of systems engineering tools.
So tell me your story. I might be able to help.
