(Note: Due to the nature of my work with Ford/Lincoln future products, I cannot reveal any information about specific projects on which I worked while in this position)

Position Description

After graduating from Northwestern University, I accepted a job in the Vehicle Architecture group within the Product Development arm of Ford Motor Company. My role as a Vehicle Architecture Engineer is to find homes for vehicle components. To do this, I collaborate with members of my team as well as the owners of each individual part. I balance the vehicle and component level requirements to identify an acceptable layout. In essence, my job is like playing Tetris with all the vehicle components with the added twist that where each piece physically resides impacts performance of both the part and the entire vehicle.

Takeaways and Skills Developed

  • Working on a cross-functional team
  • Benchmarking and target setting
  • Developing and presenting engineering proposals
  • Managing multiple projects at once
  • CATIA V5, Siemens Teamcenter, and Siemens Visualization Mockup,/crossovers/mkx/content/gallery/gallery-overlay-35,/crossovers/mkx/content/gallery/gallery-overlay-35


Benchmarking and Target Setting

The initial stage of any architecture work involves studying competitive executions of the part I am packaging. This is done by gathering data from manufacturer websites, third party websites, pictures from benchmarking databases, and physically inspecting the vehicles in our garage. One of the most notable benchmarking opportunities occurs at the North American International Auto Show in Detroit. From this information, I can then identify what our product needs to achieve to be competitive with similar vehicles from other manufacturers.

Identifying Alternatives

Once the target is set, I use Siemens Teamcenter and CATIA V5 to identify multiple alternatives for the placement of the component on which I am working. Each alternative is assessed against selection criteria which range from geometric compatibility to component functionality to vehicle assembly and everything in between. In this stage, it is vital to have ongoing working level discussions with the larger team. This means working closely with the design and release engineers for the component as well as members of other related organizations that have a stake in the part.

Alternatives Matrix.jpg

Reviewing and Narrowing Alternatives

In this step, I create a formal presentation to present the alternatives to my supervisor and the larger, working level team to identify the most promising alternatives. In this forum, each alternative is discussed and next steps are identified to help guide the iterative process. This step is repeated multiple times as we eliminate certain alternatives and add others until the only remaining alternatives have been heavily vetted and are equally viable.

Engineering Recommendation

The final stage of my work comes as I provide a formal engineering recommendation to the decision makers. These individuals consist of my organization's upper management and chief engineers. Rarely does a recommendation get enacted in the first review with the chiefs. Rather, even more detailed questions are asked and next steps are taken away to further refine the chosen alternative. After iterating through the process a number of times, the recommendation is accepted and cascaded to the entire team as the new concept baseline assumption.

Final Product

In my role, I am in charge of the architecture of a certain section of the vehicle. The final product of my work is not only a single component package, rather it is the completed layout of all the components that must be placed in the area of the vehicle for which I am responsible. Changes occur every day that impact package layouts so the final product is a moving target. My work begins before the program official starts and ends when the entire vehicle is finished.