Why track issues?

No engineering design is perfect. As mechanical engineers, this means we will be dealing with a steady stream of issues during design, build, and test activities. The level of integration in modern hardware products makes it increasingly difficult to triage issues, find the root cause, and design corrective actions. In this article, we’ll look at best practices for mechanical engineering issue tracking. All of these best practices rest on one central claim that is important to understand:

“The teams that discover and resolve more issues per iteration get to market faster and deliver better products.”

Iterative issue discovery and resolution

Because of this, it’s important that engineering teams develop a shared conception of the best practices necessary to deal with engineering issues they encounter during development.

Where to start and what’s important

Issues represent the core work of any engineering team during development, and managing the issues that the team is tackling is an essential function. For mechanical engineering in particular, issues should be properly triaged.

Triage

Issue triage involves a few key steps:

Gather information. Issues should be written with a level of detail that enables anyone on the team to understand the problem at a basic level. For example, avoid general issue titles like “replace bolt with shorter one.” This kind of issue brings up more questions than it answers. Which bolt exactly? How much shorter? What is it interfering with? We will cover this in more depth later in this article when we look at the elements of a well written issue.
Assignment. Unless absolutely necessary, issues should be assigned to an individual engineer. Work never happens without establishing roles and responsibilities first and having multiple assignees can make it unclear who is ultimately responsible for delivering a solution. If you feel like an issue needs to have multiple assignees, you probably need to break it down into multiple issues assigned to individuals.
Prioritize. Prioritizing the right issues during development is the difference between success (meeting performance requirements while staying on time and on budget) and failure (delays and cost overruns, continuous late stage design changes after tool releases, or never even making it to market). But how should you prioritize? At Five Flute, we are advocates for risk-first engineering. Engineering teams should tackle the highest risk and highest impact issues first. These issues should be directly linked to the most important product requirements. This approach ensures that the most critical design requirements are de-risked before concurrent engineering and design integration increase the cost of design changes by orders of magnitude. Put simply - tackle risk before inertia builds.

Elements of a well written issue and best practices

In this section we’ll focus on how to write engineering issues that:

Make it easy for anyone on the team to understand the issue
Foster asynchronous collaboration
Make it clear what aspects of the design are impacted
Help you build a clear design history

Engineers should write their own issues

It’s the job of every engineer on the team to write good issues. If you discover an issue, you have the most information so you are the person best suited to communicate that issue to your team.

Share visual information

Mechanical engineers deal with parts and assemblies. Many issues involve geometric problems related to the interactions between connected design elements. Because of this, the best way to communicate issues is through visual information. CAD files, screenshots, and markups all communicate much more information than text alone, with less effort. The best teams figure out efficient ways to share rich visual information across the engineering organization. Your goal should be to eliminate meetings that consist solely of explaining issues to your team.

Build your design history by connecting issues to your design source of truth

Designs evolve through iterative development. A part may have 6 revisions before it is released in production. The best engineering teams figure out how to connect their engineering issues to the parts and assemblies they impact, at the revision level the issues are associated with. This might be the hardest part of mechanical engineering issue tracking in complex projects, but it is also the foundation of your design history.

An auditable design history is an emergent property of proper issue tracking. In other words, when you connect issues to a snapshot of your design during your development timeline, you are building your design history. This design history represents the who (responsible parties), what (engineering and design changes) and why (engineering rationale, analysis, etc…) of every key engineering decision made during development. The teams that don’t know why or how the design has evolved are much more likely to deliver inferior products.

Track issues as you designs evolve - link issues to revisions

Managing issues

Invariably, you will discover a host of issues throughout development. This ‘long tail’ of problems needs to be managed. Here are some best practices that you can apply on your projects:

Match your issue tracking methods to your stage of development

Early product development requires rapid iteration to efficiently de-risk development. Your issue tracking methods need to be light weight enough to keep work flowing smoothly through the team. As you get closer to production, prototypes become higher fidelity and the importance of tracking issues with more rigor becomes increasingly important. The best teams develop approaches that allow the rigor of their issue tracking and design reviews to match the fidelity of their designs at any given time. As designs mature, you will eventually start to trade development speed for design control.

Tradeoff between development velocity and design control

Group issues into blocks

At Five Flute, we like to group engineering issues into blocks. Blocks are groups of issues centered around team level activities during iterative development. The goal here is to allow your team to focus on the issues that matter to their current work, without getting overwhelmed by a laundry list of to-do items. For example, we might make a block of issues to track design review feedback during the development of a works-like ‘alpha’ prototype. After this design phase is complete, we might make a separate block to manage issues during the build and bring-up phase of this same prototype. Zooming out, the history of your blocks should tell a clear development story.

Pro Tip: Early in development these blocks may be related to prototypes, but in production your issue blocks may be directly linked to ECOs or other sustaining engineering milestones. If you can’t explain how issues are grouped in a single sentence, it’s probably worth creating separate blocks to track your work. One of the hardest parts of hardware product development is impedance matching your issue tracking methods to your design maturity.

Close issues with comments

Any good issue should be a source of truth that explains the problem, captures root causes, proposed solutions and any related discussion, and explains what aspects of the design will be changing when the issue is resolved. The best way to ensure this is by closing all issues with a comment summarizing the above items. This simple practice establishes a clear engineering rationale for every design choice made throughout development. This is the foundation of your design history.

In addition to closing comments, issues should also include (where applicable):

links to engineering analysis: CAE, spreadsheets, code, sketches, etc..
clear indications of part and assembly revisions that are impacted.

Pro Tip: If you think you’re already doing a pretty good job explaining issue resolution, try stress testing your current system. Try going back to an issue from several months (or longer!) ago and see if you can understand what the issue was about, what parts were impacted (and at what revision!) and how it was resolved. A good issue tracking system should make it easy to retro-actively inspect your design decisions and understand why your team made the choices it did.

Keep a record of all blocks and issues, this is your design history

Beyond helping the team efficiently manage work, issue tracking is about building a design history. Issues become an asset that can educate your engineering and development teams during subsequent product development efforts. With that in mind, you should plan to keep an archive of your issues. By organizing you issues into blocks, you can answer the who, what, and why of your engineering development throughout the entire product life cycle.

Closing Thoughts

Design, manufacturing, and refinement of hardware products is complex. To tame this complexity you need to develop your own methods for issue tracking best suited to your team. There is no one size fits all solution, so figuring out the right tools, techniques, and organizational structure that match the products you are developing will take some iteration. If you nail this part of collaborative development, not only will you develop better products, but you’ll feel more in control of your engineering process at every level - from initial napkin sketch to production.

Five Flute - Next generation collaboration for hardware product development

If you are a design engineer or technical project manager and you want to design better products in less time, consider Five Flute. It’s the fastest way to share, review, and improve your engineering designs. From engineering drawing reviews to 3D design reviews of complex parts and assemblies, Five Flute is built for modern engineering teams that want to move faster without making mistakes.