AnsweredAssumed Answered

Revision scheme and lifecycle suggestions?

Question asked by Jory S on Jan 22, 2016

This may be a question for another forum, but I thought I would start here.  I'm working on organizing a revision scheme for my company since it really hasn't been utilized at all.  It's an obvious hole in our procedures and data management so I am hoping to find a good solution that works for us.  I realize that what may work well for one company may not work for another, but I'm just hoping to get some ideas from you guys.  Lately we've managed to nail down a file naming scheme that has works well for us with WPDM, so a revision scheme is next on this list.  First, a little background on what kind of work we do:


We are a small R&D (mostly aerospace) company (~30 employees, ~10 SW users) which means we do a lot of concept CAD work for proposals and contracts as well as one-off prototyping.  Most projects and contracts we have move pretty quickly, as most R&D work does.  The farthest most projects get is prototyping, but we do have a handful of products that have been manufactured and sold to customers (very low quantities).  While not having a revision scheme is okay for concept work, we're asking for trouble by not having it in place for parts we're actually building and even selling.


I've done some searching around for ideas about revision schemes as well as thinking about how a revision scheme would fit in with the workflow around here.  Because a lot of our work moves so quickly I think keeping the revision scheme as simple as possible will have the best chance for success (i.e. people will actually use it).  My thought is to just have a simple pre-release scheme and a scheme for once the part has been released for manufacturing.  Some ideas/examples that I've run across that all basically do the same thing:


Scheme A

Development: -.01 thru -.99, e.g. -.01, -.02, -.03.  (dash in primary indicates development status)

Release: A thru Z.99, e.g. A, A.01, A.02, B, B.01. (alpha primary indicates major release, numeric secondary indicates minor change to release)


Scheme B

Development: 00-A thru 00-Z, e.g. 00-A, 00-B, 00-C.  (00 in primary indicates development status)

Release: 01 thru 99-Z, e.g. 01, 01-A, 01-B, 02, 02-A, 02-B. (numeric primary indicates major release, alpha secondary indicates minor change to release)


Scheme C

Development: 1.01 thru 99.99, e.g. 1.01, 1.02, 1.03, 2.01, 2.02, 3.01. (primary indicates major development revision, secondary for minor development change)

Release: A thru Z.99, e.g. A, A.01, A.02, A.03, B, B.01, C. (same as scheme A)


So all are similar, with scheme C allowing for major and minor revisions in the development stage (which I think is overkill for our needs).  Also, I think having a working copy ( + ) would be beneficial at least in the development stage.


At first I was thinking we didn't need to deal with lifecycles, but after further thought having some simple rules might help with revision control.  Maybe just having "Development", "Released", and "Obsolete", with rules to keep users from accidentally using a revision letter/number for the wrong status.  No need to control document access or change owners with status changes.  Also, having lifecyles enabled will give us more metadata if we want to utilize it.


Sorry for the wall of text, but if anyone is willing to share their experience that would be very helpful, especially if you have similar workflow (concept work, prototyping, etc).  I'm sure I'll have some more questions but let's start with this