Why Are Engineers Still Copying and Pasting Between Word, Excel, PowerPoint, and Jira?

A requirement is approved in Word.

Then someone copies it into an Excel traceability matrix. A shortened version appears in a PowerPoint design review. Another copy is pasted into Jira for the software team. The test engineer carries it into a test procedure, and months later, somebody pastes the result into a verification report.

Then the requirement changes.

The Word document is updated. The spreadsheet is not. Jira contains the old acceptance criteria. The review deck is now historical fiction, but nobody has labelled it that way. During verification, the team discovers it has been testing the wrong threshold.

Nobody was careless. The workflow was designed around copying information—and then trusting people to keep every copy synchronized.

We Have Digital Tools, but a Document-Based Process

Word, Excel, PowerPoint, and Jira are not bad tools. Each is useful for a particular job.

The problem is that engineering information does not naturally belong to one document or one department. A requirement may originate from a stakeholder need, constrain an architectural component, introduce a technical risk, generate implementation work, and eventually require verification evidence.

Yet most organizations divide that chain across files and applications.

The systems engineer owns the specification. The project manager owns the schedule. Software works in Jira. Verification maintains an Excel matrix. Management sees PowerPoint. Configuration management controls the released PDFs.

Each team has a view of the system. Nobody has the whole thread.

Copy and Paste Breaks More Than Formatting

The real damage occurs when an engineering object becomes a collection of sentences.

Consider a requirement such as:

The system shall detect loss of track within five seconds.

Inside a connected engineering environment, that requirement should have an identity. It should have a source, rationale, owner, revision history, verification method, architectural allocation, associated risks, implementation status, and test evidence.

When the sentence is copied into six places, its identity is lost. Those copies may look identical, but the relationships between them are now maintained by memory, meetings, filenames, and spreadsheet formulas.

That is not traceability. It is administrative optimism.

NASA’s Systems Engineering Handbook calls for bidirectional traceability among stakeholder expectations, requirements, design information, and test plans and procedures. It also calls for consistency among requirements, the concept of operations, and the architecture—not merely a well-formatted specification. [1]

The problem is therefore not that engineers need better copying discipline. The problem is that copying has become the integration layer.

Why Has This Survived for So Long?

Because documents remain convenient.

They are easy to email, review, sign, archive, and deliver contractually. A PowerPoint slide is often the fastest way to explain a problem to leadership. Jira is effective for managing implementation work. Excel can answer a question in ten minutes that a formal tool might take a week to configure.

The mistake is assuming that a connected workflow requires eliminating these formats.

It does not.

The goal is to separate the engineering information from the views used to communicate it. A specification, review deck, verification matrix, ticket, and report can remain—but they should be generated from, or linked back to, controlled engineering objects.

This distinction matters. Even NIST has identified persistent identifiers as essential for tracking engineering requirements throughout a product’s life—and concluded that widely used standards and commercial tools still do not adequately support them. [2]

Fragmentation is not a trivial problem with an obvious technical fix. It is embedded in tools, contracts, responsibilities, and organizational habits.

What a Connected Workflow Looks Like

Imagine changing that five-second detection requirement to three seconds.

A connected workflow should immediately show:

Which architectural elements implement the behaviour

Which interfaces and performance budgets may be affected

Which risks need reassessment

Which Jira tasks depend on the old threshold

Which test procedures contain the five-second criterion

Which verification results are no longer applicable

Which controlled documents must be regenerated

The change is still reviewed and approved by engineers. The system simply makes the consequences visible.

This is the practical purpose of a digital thread. NIST describes it as integrated information supporting automated artifact creation, collaboration, and full-process traceability. [3] The U.S. Department of Defense similarly calls for current, consistent, enduring, and authoritative sources of system data that remain configuration-controlled throughout the lifecycle. [4]

Where Ngenaire Fits

Ngenaire is designed around this connected model.

Requirements, architecture, risks, schedules, issues, test procedures, executions, and verification evidence can exist within one traceable engineering workspace. Instead of manually reconstructing an RVTM before every review, verification status can roll up from linked test cases and their latest results. [5]

Its AI assistant can help draft, audit, trace, and report on those artifacts, while engineers remain responsible for approving technical decisions. Reports and familiar deliverables can still be produced—but they become outputs of the engineering record rather than competing versions of it. [6]

The objective is not to prevent an engineer from ever opening Word or Excel again.

It is to ensure that when someone asks, “Which version is correct?” the answer does not depend on who updated their spreadsheet last.

Copy and paste will always have a place.

It just should not be holding the system together.

References

[1] National Aeronautics and Space Administration, NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev. 2, Washington, DC, 2016.

[2] T. Thurman et al., “Research Results and Recommendations for Universally Unique Identifiers in Product Data Standards,” NIST Advanced Manufacturing Series 300-12, Jul. 2024.

[3] T. D. Hedberg, J. Lubell, L. Fischer, L. Maggiano, and A. Barnard Feeney, “Testing the Digital Thread in Support of Model-Based Manufacturing and Inspection,” Journal of Computing and Information Science in Engineering, vol. 16, no. 2, 2016.

[4] U.S. Department of Defense, Digital Engineering, DoD Instruction 5000.97, Dec. 2023.

[5] Ngenaire, “RVTM: Requirements Verification Traceability Matrix,” Ngenaire Documentation, accessed Sep. 9, 2026.

[6] Ngenaire, “We Solve Hard Engineering Problems,” accessed Sep. 9, 2026.