“schedule is more important than cost on this effort,” which signifies that the program is willing to meet a deadline at nearly any cost. Although this promise may hold true for awhile, it invariably carries an expiration date that may not always be communi- cated clearly to the engineer. (In other words, it’s true until it’s not.) The en- gineer is urged to proceed with cau- tion in these “schedule is king” situa- tions and remain cognizant that carte blanche budgets do not exist. When Things Go Wrong Design and analysis don’t always go as planned, even for the most ex- perienced senior engineers. Things can go wrong unexpectedly and delay progress, such as staffing changes and attrition, software bugs, failing computer hard drives, analysis errors not caught early on, and any other unfortunate event obeying Murphy’s law that if anything can go wrong, it will. It’s also possible that a task was legitimately underbudgeted by pro- gram management at the onset for a given schedule and scope. Regardless of reason, when things go wrong, the following remedies are suggested to minimize negative impacts on cost, schedule, and scope. First, get buy-in from a subject matter expert (SME) at the onset of a large project—with regular check- ins—to ensure that the effort is on the right track and progressing as the SME would expect regarding budget, timeline, and scope. Second, start by performing a smaller, simpler analysis that yields a reasonably accurate answer, which you can keep in your back pocket while you work to refine your answer with a simple computational simu- lation. The engineer must avoid the temptation to immediately run and build a large, complex computational model for a given analysis task. Any large analysis task can be broken down into smaller tasks that can provide an accurate answer, which requires an understanding of the rel- evant, underlying physics. In fact, a
[B]y clearly defining the work scope and requirements at the onset of a task, the engineer can focus on accomplishing the analysis task efficiently and effectively.
Conclusion Cost, schedule, and scope in pro- gram management are critical in the defense industry. The principles we’ve reviewed in this article highlight the greater significance and impact of executing assigned tasks within cost, schedule, and scope constraints. With the increased scrutiny on contract execution in the defense industry, adhering to bud- get, deadline, and scope constraints has become all the more critical. The lessons shared regarding each element will promote the engineer’s successful engineering execution of a program or individual task. LOZANO is a Senior Principal Mechanical Engi- neer at Collins Aerospace, a business unit of RTX, which he joined in 2011. His professional experience has included 12 years in thermal design and analysis, one year in engineering operations, and one year as an Integrated Product Team Lead and Control/Cost Account Manager. He holds a bachelor’s, a master’s, and a doctoral degree in Mechanical Engi- neering from the University of Texas System, and is a licensed Professional Engineer (PE) in Texas. The author can be contacted at adolfo.lozano@rtx.com . The views expressed in this article are those of the author alone and not the Department of Defense. Reproduction or reposting of articles from Defense Acquisition magazine should credit the authors and the magazine.
fallacy in engineering analysis is that model complexity is proportional to accuracy. Third, communicate in advance with program management when exceeding budget or slipping sched- ule is foreseen. The CAM or program manager may be able to reallocate budgets or adjust durations to miti- gate any negative cost and schedule impacts. This may require formally identifying the potential risk to cost or schedule in the program’s risk regis- try. The engineer may then work with the SME to mitigate the realization or severity of the risk. Fourth, as defined in a prior com- munication, the engineer should be- ware of scope creep and requirements swirl. Another example of things going wrong is the “bring me a rock” caveat. Program management tells the engi- neer, “Bring me a rock.” The engineer works in good faith to find a rock that addresses the need (based on the engineer’s experience) and brings the metaphorical rock, which here repre- sents a design or analysis. Program management reviews the rock and clarifies the request by saying, “Bring me a big rock.” The engineer takes this new feedback and again, in good faith, works to retrieve a big rock for the program. Program management then reviews again and further clari- fies with, “Bring me a big red rock,” and the cycle repeats, ad infinitum, with each iteration consuming more budget and schedule while not fully addressing the actual need. Instead, by clearly defining the work scope and requirements at the onset of a task, the engineer can focus on accom- plishing the analysis task efficiently and effectively.
DAU Resources • Engineering and Technical Management • Control Account • Understanding EV Techniques • Value Engineering
44 | DEFENSE ACQUISITION | July-August 2025
Made with FlippingBook - Online Brochure Maker