Published on February 28, 2021

Moving from Student to Engineer: Part 2

By Robert Lyons, Technical and Management Consultant, and Nancy Barr, PhD

On top of their day jobs, engineers are often called on to work on the proposals to win business that keeps the company alive. Engineering students are probably familiar with the requirements of proposals for senior design projects or proposals for theses or dissertations. Not much about them will help in a normal corporate proposal for products or services for a demanding customer. 

In an industrial setting, engineers are likely to be called on to work on various parts of a proposal response due to the customer at a specific date and time defined in a Request for Proposal (RFP) for a product not available off the shelf. This is also true for employees from finance, master scheduling, supply chain, manufacturing, product support, contracting, legal, and program management. Proposals are a team sport!

Engineers from many specialties usually have heavy roles in writing the Statement of Work (SOW) and the product specifications that will become contractually binding, if the company’s RFP response is acceptable. They will have to fit the work to be done during program execution inside a Master Phasing Schedule (MPS), likely provided by the customer. That work also has to be priced to meet both the customer’s available funds phased over the MPS and the company’s profit margin requirements, and yet remain competitive with other proposing companies’ unknown prices. To meet the company’s profit margin for the resultant contract, all costs are estimated and justified with Bases of Estimate (BOEs) reviewed first by company leadership, and many times also by the customer as part of the required proposal package. Guess who writes these documents?

On most  proposals, engineers and other functionals need to write SOWs, specifications, budgets, BOEs, Bills of Material (BOM), required delivery quantities and schedules, and top line estimated prices for subcontracted work required to meet the overall proposal to the end customer. Engineers will sometimes have seats at the table with supply chain personnel in negotiations with the subcontractors, all while trying to do their day jobs and produce parts of the proposal to the end customer on a schedule provided by the Proposal Manager.  

To the  Proposal Manager, the only job that counts is developing and producing an RFP-compliant and company-compliant winning proposal to be delivered on time to the end customer.

Proposal development and production projects have their own schedules and budgets to perform all of the work of defining a technical baseline that includes necessary new product capabilities, all of the documents discussed previously, and a set of in-process reviews of proposal storyboards and graphics, first drafts, final drafts, and final deliverable proposal artifacts. Each company has its preferred ways of managing proposals and proposal teams, but they all have common elements affecting engineers. In all cases, engineers must perform alien tasks on a very tight schedule, with constraints not set by nature but by demanding people from other company functions, the end customer, and even suppliers and subcontractors.  Engineers may never have met the end customer or suppliers and subcontractors, all of which have their own agendas and business needs. Oh, and the engineers still have to maintain responsibilities for their normal day jobs.

Some of the necessary survival skills for engineers, especially new ones, include:

  • Learning about business generally, and their company’s specific command media.
  • Taking whatever formal classes their company provides on all aspects of their technical jobs.
  • Learning the culture, the informal structure beyond what the written policies and procedures say about how work gets done. A trusted mentor is essential. 
  • Practicing active listening.
  • Getting comfortable with public speaking.
  • Learning to negotiate with peers, superiors, and subordinates.
  • Learning how cost estimating and writing BOEs is done.
  • Learning how to write SOWs and Specifications.
  • Learning about the other business functions, such as R&D labs, Supply Chain, Manufacturing, Finance, Contracting, etc. 

All of these skills are essential for an engineer’s growth and development. They will also reduce the shock when engineers are assigned to a proposal team. In addition to the skills enumerated above, proposals will be more tolerable and successful if engineers do the following:

  • Pay attention to and follow the proposal training and direction provided by the Proposal Manager and the other senior members of the proposal team.
  • Own the technical baseline, as it evolves, since it’s easier to estimate the costs in hours and dollars of something firm or at the margins when a change occurs. When the technical baseline is clear, it’s also easier to write correct proposal and contract artifacts, such as complaint responses to specific RFP instructions, SOWs, Specifications, BOEs for the products and work to be done to make those products, task durations on the MPS, etc.   
  • Meet the proposal schedule milestones, to reduce the risk of the whole team missing the required proposal delivery date.
  • Get used to being pulled in different directions by the proposal leadership and the day job supervisor. Let the proposal leadership argue with the day job supervisor. 

Dr. Nancy Barr developed a multi-faceted engineering communications program in the Mechanical Engineering-Engineering Mechanics Department at Michigan Technological University. Her current research focuses on equity and inclusion issues in engineering management and portfolio assessment practices. A former newspaper reporter and editor and the author of the Page One mystery trilogy and an award-winning short story, Barr currently serves as secretary to the IEEE Professional Communication Society Board of Governors and as Campus Representative for the ASEE North Midwest Section.

Bob Lyons thought he’d be doing math, physics and electrical engineering right out of graduate school, so he only took one technical writing class; big mistake! He’s been paying for that mistake for the past 50ish years, learning to understand, avoid or fix failures to communicate between and among small and large groups of people charged with solving militarily and industrially critical problems.