{"id":2943,"date":"2019-09-09T20:41:12","date_gmt":"2019-09-09T20:41:12","guid":{"rendered":"https:\/\/durolabs.co\/?p=2943"},"modified":"2024-06-13T20:22:16","modified_gmt":"2024-06-13T20:22:16","slug":"hardware-revision-management","status":"publish","type":"post","link":"https:\/\/durolabs.co\/blog\/hardware-revision-management\/","title":{"rendered":"A Simple Guide To Revision Management For Hardware Companies"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

A fundamental requirement of good product development is revision management. Change is inevitable, but it should be managed. Properly.<\/p>

Software developers have the luxury of powerful (and free) revision management tools like git<\/a>. The choices aren\u2019t as clear cut, nor efficient for hardware developers. Most hardware file revisioning workflows have some level of manual intervention \u2013 specifically on revision labeling.<\/p>

Proper revision management labeling policies are critical and often under appreciated. The key is to remove ambiguity and subjectivity. There are several different revision management systems in use in the industry today, many of which unfortunately don\u2019t follow these guidelines.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

What\u2019s the risk?<\/h4>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Here\u2019s the fundamental contributing risk in hardware product development<\/a>: The team that designs a product is not the same team that manufacturers it. So, documentation during revision management should be clear and concise.<\/p>

When a design team makes a change to a product, they are much closer to the problem being resolved, so understand the context of the change. The manufacturers do not. To them, a change is a change. It\u2019s not their responsibility to know the criticality of the change. Their job is to implement the change and deliver the finished good to the quality specified.<\/p>

So, when teams devise complicated revision labeling, it serves no purpose in the grand scheme of things, and only results in adding risk for mistakes and delays.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Don\u2019t introduce uncertainty\n<\/h4>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Revision labels should be simple, single number or letter values. No decimals, sub-level values, or major \u2013 minor values. These multi-level revision labels only lead to confusion or a dependency on some complicated ruleset.<\/p>

If your team follows a major.minor revision management scheme (e.g. Rev 2.4), how do you decide if a change constitutes a minor revision or major revision bump? Should the next revision be Rev 2.5 or Rev 3.0? Some changes will be obvious, but many will not. Why introduce uncertainty?<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

K.I.S.S.<\/h4>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

The right solution is to keep it simple, and use only positive integers and single character letters. (Rev. 1,2,3,\u2026, A,B,C\u2026Z). More explicitly, I promote the adoption of the following Revision labeling policy:<\/p>

  • If the part\/assembly is in a\u00a0Prototype<\/strong>\u00a0state, it has a\u00a0positive integer<\/strong>\u00a0revision label (1,2,3,\u2026n).<\/li>
  • If the part\/assemble is in a\u00a0Production<\/strong>\u00a0state, it has a single character\u00a0letter<\/strong>\u00a0revision label (A,B,C,\u2026Z).<\/li>
  • Skip letters\u00a0I,J,O,Q,S<\/strong>\u00a0\u2013 these characters can too easily be misread and interpreted for numbers.<\/li><\/ul>

    Why is this a good policy?<\/p>

    1. There\u2019s no ambiguity. Any changes that constitute a revision bump get the next logical value. There\u2019s no thought or debate whether the change is a major or minor one.<\/li>
    2. Suppliers often have different procedures and costs associated with prototype vs production runs. Using a clear differentiator in the revision label quickly routes the change to the right team and workflows, with no ambiguity or additional explanation required.<\/li>
    3. It\u2019s common to have many more revisions while prototyping vs in production, so using integers allows for infinite values.<\/li>
    4. Production revisions are much fewer, so using single character letters doesn\u2019t limit you, in practice.\u00a0Note<\/em><\/strong>: If you get up to revision Z in production, then there is something seriously wrong with your QA processes!<\/li><\/ol>

      \u00a0<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

      \n\t\t\t\t
      \n\t\t\t\t\t

      A change is a change<\/h4>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t\t

      The only valid argument I hear for having a major.minor revision labeling scheme (e.g. C1, C2, D1, D2, D3, \u2026) is to identify relationships between revisions. In some cases this is necessary for compatibility or interoperability reasons. For example, one might say that any subassembly with revision Cx is interchangeable but revisions D or higher are not.<\/p>

      But I question whether this ruleset is worth the effort? One still has to document the compatibility rules, so why add the complexity? These rules are often only for internal use only \u2013 the supplier doesn\u2019t care. A change is a change.<\/p><\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"

      A fundamental requirement of good product development is revision management. Change is inevitable, but it should be managed. Properly. Software developers have the luxury of powerful (and free) revision management tools like git. The choices aren\u2019t as clear cut, nor efficient for hardware developers. Most hardware file revisioning workflows have some level of manual intervention […]<\/p>\n","protected":false},"author":3,"featured_media":2944,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_seopress_robots_primary_cat":"","_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","footnotes":""},"categories":[93],"tags":[],"resource-tag":[79],"class_list":["post-2943","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","resource-tag-hardware-engineering"],"acf":[],"_links":{"self":[{"href":"https:\/\/durolabs.co\/wp-json\/wp\/v2\/posts\/2943","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/durolabs.co\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/durolabs.co\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/durolabs.co\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/durolabs.co\/wp-json\/wp\/v2\/comments?post=2943"}],"version-history":[{"count":6,"href":"https:\/\/durolabs.co\/wp-json\/wp\/v2\/posts\/2943\/revisions"}],"predecessor-version":[{"id":2951,"href":"https:\/\/durolabs.co\/wp-json\/wp\/v2\/posts\/2943\/revisions\/2951"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/durolabs.co\/wp-json\/wp\/v2\/media\/2944"}],"wp:attachment":[{"href":"https:\/\/durolabs.co\/wp-json\/wp\/v2\/media?parent=2943"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/durolabs.co\/wp-json\/wp\/v2\/categories?post=2943"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/durolabs.co\/wp-json\/wp\/v2\/tags?post=2943"},{"taxonomy":"resource-tag","embeddable":true,"href":"https:\/\/durolabs.co\/wp-json\/wp\/v2\/resource-tag?post=2943"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}