How to Get Management to Understand Technical Concerns

“Cost, Schedule, and Risk are the three items foremost in a decision-maker’s mind.” — Eric C. Stasiunas, How to Educate Decision Makers on the Value and Necessity of Modal Testing and Model Correlation: Tips for Young Engineers, NASA Technical Reports Server, NASA Engineering and Safety Center, 2021

Changing requirements are not necessarily evidence of poor engineering; they often result from learning more about the problem, customer, technology, or operating environment.

The engineering challenge is to manage change deliberately rather than allowing it to become uncontrolled requirements creep. NASA NASA Science

Consider the following three ways to get management to understand technical concerns:

Evaluate the Impact Before Accepting the Change

When a requirement changes, you should resist the temptation to immediately redesign the system.

First determine what the proposed change affects—architecture, interfaces, performance, reliability, safety, testing, documentation, and other requirements.

Translate those technical consequences into cost, schedule, resources, and risk so management can see the complete tradeoff.

NASA’s systems-engineering guidance specifically recommends assessing proposed changes before approval and examining their cost, schedule, technical, and programmatic impacts. SWEHB

Use requirements traceability to determine where the change propagates through the system.

Bidirectional traceability connects stakeholder needs to system requirements, lower-level requirements, designs, and verification activities, making hidden downstream consequences easier to identify. NASA

One way to get management to understand technical concerns is to evaluate the impact before accepting the change.

Another is to establish a disciplined change control process.

Establish a Disciplined Change Control Process

Establish a clear process for requesting, analyzing, approving, documenting, and implementing requirement changes.

Significant changes should not quietly enter the project through an email, meeting comment, or someone’s “small request.”

Baseline the agreed requirements and record each proposed change, including who requested it, why it is needed, what it affects, and whether it was approved.

NASA recommends formal procedures and, where appropriate, a change or configuration control board to evaluate proposed modifications. SWEHB

This discipline also helps distinguish a genuine requirement from requirements creep—incremental enhancements that gradually make the system larger, more expensive, and more complex than originally intended.

A useful engineering question is: “Is this necessary to achieve the project’s objective, or is it simply desirable?”

Two ways to get management to understand technical concerns are to evaluate the impact before accepting the change and establish a disciplined change control process.

A third way is to communicate the tradeoffs, not just the technical change.

Communicate the Tradeoffs, Not Just the Technical Change

You should explain changing requirements in terms decision-makers can act upon: “If we make this change, here is what we gain—and here is what it will cost.”

Present alternatives such as accepting the change now, deferring it to a later release, modifying it, or retaining the current requirement.

Avoid simply telling management, “The customer changed the requirements again.”

Instead, quantify the consequences: “This change improves capability X, but requires three additional weeks, additional testing, and modifications to interfaces A and B.”

Once a decision is made, communicate the approved requirement quickly to everyone affected and update specifications, designs, test procedures, schedules, and traceability records.

NASA emphasizes disseminating approved changes and ensuring affected documentation and project information remain current. Nodis3

Three ways to get management to understand technical concerns are to (1) evaluate the impact before accepting the change, (2) establish a disciplined change control process, and (3) communicate the tradeoffs, not just the technical change.

You can get management to understand technical concerns.

Follow the three ways outlined in this article and you will be successful.

Call to Action

• Translate those technical consequences into cost, schedule, resources, and risk so management can see the complete tradeoff.

• Establish a clear process for requesting, analyzing, approving, documenting, and implementing requirement changes.

• Present alternatives such as accepting the change now, deferring it to a later release, modifying it, or retaining the current requirement.

“If you can’t communicate, you can really understand your technical domain, but if you can’t communicate it, it’s like a tool that you can’t use.” — Kramer White, NASA Engineering Directorate, Marshall Space Flight Center, NASA podcast interview on engineering best practices.

References

• NASA, NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev. 2, Section 6.2, Requirements Management. Discusses evaluating requirement changes for effects on cost, schedule, architecture, design, interfaces, technical requirements, and other system elements. NASA NASA Systems Engineering Handbook

• NASA, “6.2 Requirements Management.” Describes baselining requirements, managing changes throughout the product life cycle, maintaining bidirectional traceability, evaluating change requests, and maintaining consistency among requirements and system design. NASA

  NASA Requirements Management guidance

• NASA Software Engineering Handbook, SWE-053, “Manage Requirements Changes.” Provides detailed guidance on capturing proposed changes and analyzing their cost, schedule, technical, stakeholder, safety, testing, and rework implications before implementation. SWEHB

  NASA Software Engineering Handbook — Requirements Changes

• NASA Procedural Requirements NPR 7123.1B, NASA Systems Engineering Processes and Requirements. Specifies formal requirements-management activities including change procedures, traceability, review of engineering change proposals, documentation, and dissemination of approved changes. Nodis3 NASA Systems Engineering Processes and Requirements

• NASA Systems Engineering Handbook, “Requirements Creep.” Defines requirements creep as incremental growth in requirements that can produce a system more costly and complex than originally intended, emphasizing the importance of disciplined change management. NASA Science

Being a confident, engaging, and effective STEM speaker is a vital personal and professional asset. With more than 40 years of engineering experience and more than 30 years of award-winning public speaking experience, I can help you reduce your presentation preparatory time by 50%, overcome your fear of public speaking and be completely at ease, deliver your presentations effectively, develop your personal presence with your audience; and apply an innovative way to handle audience questions deftly.

Working closely with you, I provide a customized protocol employing the critical skills and tools you need to create, practice, and deliver excellent STEM speeches and presentations. Let’s connect and explore how I can help you become the exceptional speaker you were meant to be. Please reach out to me at fr***@*****************ed.com or 703-509-4424 for a complimentary consultation. Schedule a meeting with me at calendly.com/frankdibartolomeospeaks

©2026 DiBartolomeo Consulting International (DCI), LLC. All Rights Reserved. May not be used without permission.