Loading...

The Engineering Productivity Crisis

The average engineer spends just 41% of their time on productive, innovative work. ⏱️


Introduction

Modern engineering teams are facing a productivity crisis. Research commissioned by Dassault Systèmes shows that, on average, engineers spend just 51% [1] of their time on innovation and design work. It also shows that they are typically working with outdated information 20% [1] of the time, meaning that engineers are able to dedicate just 41% of their time to innovative, productive work with up-to-date input data.

Derived from [1]

Drawing office challenges of this nature are adversely affecting both product quality and time-to-market for product businesses, with Autodesk research indicating that 35% [2] of engineers report missing due dates during the design process. These challenges are also recognised by engineering leaders, with more than 94% [3] of engineering executives shown to recognise the need for improved mechanical engineering productivity.

Reproduced from [3]

The Cause

A Fragmented Approach to Information Management

Dassault's research [1] permits further breakdown of engineer time demands. It shows that 25% of all 'non-value-added' engineer time is consumed by simply searching for information, with significant time also spent collecting data for other stakeholders, and repeating work when information could not be found.

Considering why this may be the case, an engineering practices and procedures survey [4] provides some indication, with results demonstrating that e-mail, meetings, and telephone remain the dominant mechanisms for communication and collaboration in contemporary engineering teams. These channels are private by design, with participants having to take active, post-hoc steps to share outcomes with team members. Important technical information shared via these routes is also frequently rendered undiscoverable; hidden from other team members, exempted from version control, and put beyond the ready reach of any new hire.

Drawn from the results of [4].
'Issue Tracking System' refers to software development-focused products: JIRA, GitHub, GitLab etc.

Design Review Procedures: A Persistent Threat

Checking and approval procedures are a key component of engineering best practice. Many organisations run a stage-gate process, typically with at least two review stages, but often with more. In general, there are two broad categories of review and approval procedures involved in physical system design and development:

  1. A high-level concept review, typically completed earlier in the design process. This review assesses the design concept against broad objectives, and does not address minor design or manufacturing details.
  2. A detailed checking and approval procedure for finalised drawings, completed prior to system components being formally released via an ECN or ECO procedure.

The results of [4] tell a story of inadequate tooling, with in-person meetings and e-mailed screenshots dominating the approaches taken by modern engineering teams. In both cases, these methods offer very poor visibility—typically failing to capture topics discussed, decisions taken, and action items agreed.

However, the latter approach is considered particularly pernicious: it places vast time demands on the engineer requesting review. They are obligated to manually select and annotate salient views of their design, then distribute these to a wider set of stakeholders. This set of stakeholders then returns the documents with their own annotations, and the engineer initiating the review must collate and address multiple possibly conflicting comments from disparate sources.†

Drawn from the results of [4].

†Though Anneal currently has no robust data to support a quantitative assessment of the impact of the screenshot and e-mail based design review process, it is a topic frequently encountered during customer conversations, with the typical procedure involving the assembly of a multiple page PowerPoint presentation of salient views which is then e-mailed to a number of reviewers for comment.


The Cost

The damaging consequences of poor visibility and discoverability of technical information are clear to see: engineers must spend more time looking for information, they must repeat previously completed tasks, and they must complete remedial rework in the wake of design progressing with out-of-date values. Dassault's research [1] provides values for the most frequently reported consequences of bottlenecks in collaboration and shortcomings in information discoverability that result in outdated information feeding into the design process.

Recreated from [1].

Further considering the impact of outdated information in design, survey results indicate that more than half of engineering organisations [4] have encountered problems arising from out-of-date values persisting through design iterations, with these ranging from time-pressured and costly late-stage rework of a given design, through to catastrophic failure of a large-scale product prototype.

All considered, the prevailing approach to managing the design and development of complex hardware systems appears to be failing for many teams. Engineers are bogged down in non-technical workload, and their tools are not providing adequate support. With engineers spending just 41% of their time—two days per week—on productive, innovative work, individual companies are spending hundreds of thousands of dollars on misdirected engineering resource, and could be losing millions in the marketplace through degraded product quality, stretched development cycles, and delayed product introductions.


The Solution

For most teams, the best mitigation for this productivity crisis will require two things: modified behaviour, and modified tools.

On behaviour, engineering teams must adopt more open, collaboration-centric mechanisms for communication. They should consider reducing task scope, mixing disciplines, and assigning ownership to all work. More importantly, they should prioritise seeding a writing culture, take steps to make engineering decision making readily interrogable, and champion visibility and transparency amongst their team.

On tools, software should be sought or developed to support the behavioural change. Engineering teams should seek access to software that enables both real-time and asynchronous peer review of drawings, CAD files, and technical reports. They should seek software that allows engineering topics to be discussed in context, that allows them to view task progression and workload distribution across a project, and that allows them to leverage modern web application technology to accelerate product development and improve product quality—wherever the team is.



To learn more about the Anneal view for the future of collaborative, connected engineering, read our engineering playbook:

Top