Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:

  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. Be respectful, on topic and if you see a problem, Flag it.

If you would like to contact our Community Manager personally, feel free to send a private message or an email.

Release Management - Design Reviews

We are using the release management process with decent success, however one area we struggle with is conducting a proper design review prior to release.  Typically we will host a design review in the model prior to detailing that is informal. After some further work the detailed model is submitted for release in a release package.  If there are any errors found the release package must then be either discard or rejected, the changes made, and then resubmitted for release.  Any commentary made in the release package stays with that package and does not carry through in the document.  In some of our larger releases it can be tedious to put together the release package.

I propose a design review package that would travel within the document across versions.  Essentially a release package, but not fixed at a current version of the document, it would move across versions until it is changed to a release package.  This would allow commentary/feedback to be tracked, the package updated and modified as necessary, and changes made to the models.  Then when the reviewer and designer are satisfied with it, the package could be switched to a release package which would fix the version and go through the normal release process.

Would anyone else find this beneficial?

Comments

  • raj_Onshaperaj_Onshape Onshape Employees Posts: 76
    Would you ability to create a release package from a rejected candidate with comments carried over and all items updated to the current workspace meet your needs ? If so please create and vote on a improvement request for the same
  • tim_hess427tim_hess427 Member Posts: 96 PRO
    As someone working in the medical device field with a need to capture design history (changes made, rationale for changes, etc.) for regulatory purposes, I think this would be helpful functionality. I haven't thought about his enough yet to be able to offer more detailed suggestions for what I would like to see or how I would use it. But, I wanted to express my support for development in this area. 

    All of that said, it seems like being able to create a release package from a previous candidate would have some value too. 
  • michael_bromleymichael_bromley Member Posts: 64 PRO
    edited December 2018
    Would you ability to create a release package from a rejected candidate with comments carried over and all items updated to the current workspace meet your needs ? If so please create and vote on a improvement request for the same
    That would certainly be an improvement.  There are two main issues as it exists today:

    1. Having to recreate the entire release package with each rejection
    2. Flow through of commentary including feedback and corrections made

    That improvement would target both of those.  The only additional benefit to a design review package would be that it would carry through intermediate versions (between the rejection and the recreation of the release package) of the document and be a central repository for all commentary.  In addition there could be multiple stages of the package.  For example Initial Design Review -> Critical Design Review -> Release.  A real pipe dream would be to set up the standards for who needs to be involved in this gated process review.
  • romeograhamromeograham Member Posts: 151 PRO
    This would also be useful for larger releases (say more than 10 parts / drawings) without the rejected candidate issue. If you add / select all the items you want to release, and there's an issue with any ONE of them (Feature List in Rollback state, Errors in Feature List, Drawing needs to be refreshed etc) you have to discard the whole thing as well. Then remember all the items that you wanted to release, once you fixed all the issues....however, you need to make note of them while the Release Candidate window is open.

    This is a good suggestion!


  • tim_hess427tim_hess427 Member Posts: 96 PRO
    Also outside of this discussion, but I'll mention it here anyway, my biggest release management issue at the moment is finding the latest releases, I wish there was a way to group/show latest released drawings for a product into the one workspace, rather than scouring through the history tree or using a list outside of Onshape linking to Onshape URL's. 

    @brucebartlett - I thought that the search functionality would solve this, but it looks like its still an incomplete solution. By searching for "type:drawing state:RELEASED foundin:v when:latest" I am able to find the latest releases of my drawings. However, I don't see a way to sort or filter by folder or tag, so I can't focus on one specific product or project. I also wish I could see part numbers in search results, since those are the actual unique identifiers for my items.

    Also, back on the topic of the design review package, I'm not sure what my ideal workflow would look like, but I do think having some sort of version controlled record of comments and notes could be useful. I'm thinking something analogous to comments embedded in software code, or even just the ability to directly edit a text document within an onshape document (like a readme file).
  • jon_lewis118jon_lewis118 Member Posts: 5 PRO
    edited January 8
    We also have issues integrating release management into our design review work flow due to the reasons mentioned by Michael. Our current method is to work through the review process outside of Onshape using a product called Asana. Asana is billed as project management software but it allows us to readily create review tasks based around release candidates. Tasks are created for the reviewer(s), and the reviewer can approve the candidate, or create a follow on task to revise the design. Release candidate tasks are based on PDF exports of the drawings, proper release candidates are only created in Onshape when the design review is complete. It's a messy process but it gives us a stationary history of the design review, and allows for richer dialog and collaboration than Onshape can offer. We can also add additional meta data to the process beyond just design review, for example we can create ECR's which preclude and lead into the next revision cycle. The downside is the design process lives in two disparate environments, we basically create a shadow review tree in Asana which parallels the design tree in Onshape. The workflow requires many manual operation that could be automated in Onshape, but Onshape doesn't have tools to properly track the review process, let alone the design process.

    We also find the way releases are presented to be opaque. One example of this is when we wish to review the revision history and revision notes for a particular part or assembly we must use the history tree and manually track down individual releases. With the workflow mentioned above we have a single place to review the entire design and review process for a particular design.
  • michael_bromleymichael_bromley Member Posts: 64 PRO

    Also outside of this discussion, but I'll mention it here anyway, my biggest release management issue at the moment is finding the latest releases, I wish there was a way to group/show latest released drawings for a product into the one workspace, rather than scouring through the history tree or using a list outside of Onshape linking to Onshape URL's. 
    Yes! we struggle with this as well.  It is very difficult to dig through the version tree and try to figure out what was released when.  In addition, unless the user waits for the release to be approved and then goes back into the document and updates the version of the part to the released version in an assembly you could very easily release a new revision of a part that is exactly the same as the previous.  I'm not sure what the exact solution is, but we need a way to see on a higher level the status of parts, assemblies, and drawings within a document.
  • tim_hess427tim_hess427 Member Posts: 96 PRO

    In addition, unless the user waits for the release to be approved and then goes back into the document and updates the version of the part to the released version in an assembly you could very easily release a new revision of a part that is exactly the same as the previous.  I'm not sure what the exact solution is, but we need a way to see on a higher level the status of parts, assemblies, and drawings within a document.
    Very well said. Couldn't agree more. I don't have very much stuff in Onshape, yet, since we're still early in our use with it. I love that version and release management is built into the system. But I'm dreading the day I have have more than two people in the company working on my project and I have to go try to figure out what everybody has accomplished and the current state of all the parts.

    This is confused even more by having the version tree at a document level. In some cases I have a single part in each document. In other cases, I have multiple parts in a document. Then in other places, I have a part in one document linked to an assembly in another document. I'm doing my best to keep some rigor in how things are organized and released, but the current search functionality falls short in providing useful information about anything (outside of its location).
  • andrew_kleinertandrew_kleinert Member Posts: 16 PRO
    We are using the release management process with decent success, however one area we struggle with is conducting a proper design review prior to release.  Typically we will host a design review in the model prior to detailing that is informal. After some further work the detailed model is submitted for release in a release package.  If there are any errors found the release package must then be either discard or rejected, the changes made, and then resubmitted for release.  Any commentary made in the release package stays with that package and does not carry through in the document.  In some of our larger releases it can be tedious to put together the release package.

    I propose a design review package that would travel within the document across versions.  Essentially a release package, but not fixed at a current version of the document, it would move across versions until it is changed to a release package.  This would allow commentary/feedback to be tracked, the package updated and modified as necessary, and changes made to the models.  Then when the reviewer and designer are satisfied with it, the package could be switched to a release package which would fix the version and go through the normal release process.

    Would anyone else find this beneficial?
    Could this be expanded? ...

    ... a suggestion to add a 'Review' step to the Release process workflow that captures the review history you're describing.

    A company's QMS release management process is typically broken up into two distinct steps of 'Review' and "Approval'.  (The standard Onshape drawing templates refer to the terms 'Checked' and 'Approved').

    Onshape currently (version 1.91.22740.156ccba314a3  ... 22nd Jan 2019) seems to have a simplified process that just has the latter step, the 'Approval' step.  Maybe the typical reasons why an Approval would be rejected in practice ("Company review procedures were not followed correctly", "No budget to release this part to production", "Client not proceeding with ECR", etc, etc) probably wouldn't trigger the type of ongoing papertrail within a CAD environment that you're describing, however a 'Review' step in the process certainly would (as you've described).
  • michael_bromleymichael_bromley Member Posts: 64 PRO
    We are using the release management process with decent success, however one area we struggle with is conducting a proper design review prior to release.  Typically we will host a design review in the model prior to detailing that is informal. After some further work the detailed model is submitted for release in a release package.  If there are any errors found the release package must then be either discard or rejected, the changes made, and then resubmitted for release.  Any commentary made in the release package stays with that package and does not carry through in the document.  In some of our larger releases it can be tedious to put together the release package.

    I propose a design review package that would travel within the document across versions.  Essentially a release package, but not fixed at a current version of the document, it would move across versions until it is changed to a release package.  This would allow commentary/feedback to be tracked, the package updated and modified as necessary, and changes made to the models.  Then when the reviewer and designer are satisfied with it, the package could be switched to a release package which would fix the version and go through the normal release process.

    Would anyone else find this beneficial?
    Could this be expanded? ...

    ... a suggestion to add a 'Review' step to the Release process workflow that captures the review history you're describing.

    A company's QMS release management process is typically broken up into two distinct steps of 'Review' and "Approval'.  (The standard Onshape drawing templates refer to the terms 'Checked' and 'Approved').

    Onshape currently (version 1.91.22740.156ccba314a3  ... 22nd Jan 2019) seems to have a simplified process that just has the latter step, the 'Approval' step.  Maybe the typical reasons why an Approval would be rejected in practice ("Company review procedures were not followed correctly", "No budget to release this part to production", "Client not proceeding with ECR", etc, etc) probably wouldn't trigger the type of ongoing papertrail within a CAD environment that you're describing, however a 'Review' step in the process certainly would (as you've described).
    I will do my best to explain in more detail.

    You are correct that those are valid reasons as to why a design release may be rejected.  I'm more referring of a way to automate and track the review or "check" process.  Due to the dynamic nature of Onshape the design is always in progress therefore even if a SME checks the design over there is no guarantee that a change gets made during or prior to generating the release package.  In addition, the SME will typically have some input on the design.  Using the comment system built into Onshape to tag entities is very helfpul, but it gets locked into a single version of the document.  You may also only be checking a handful of components/assemblies in the document and not the whole document.  Therefore a review package would make sense.

    Ultimately what I am suggesting is a workflow such that something such as a critical design review (CDR) could be tracked within Onshape and ultimately end up as a release package.  This workflow would allow comments to be made, changes implemented, responses to comments, etc. all contained in a single place.  Therefore in the future another designer could understand the feedback and the reasoning for changes.  
  • tim_hess427tim_hess427 Member Posts: 96 PRO
    Building on what @michael_bromley said - since the comments have 'tasks' that can be assigned to people, it would be great if we could then reference one or more "changes" in the history list that were made in response to that task. 
  • jon_lewis118jon_lewis118 Member Posts: 5 PRO
    My company had to find another way to track design review, release management is terrible for collaboration and information tracking. As I mentioned above we use a project management tool called Asana. Our method is manually driven and can't store data in OnShape but it address the critical issues of, tracking discussions between engineers through review cycles, and giving out tasks. Here's an example of the workflow we developed:
    • A task is created for a part or assembly (screen shot 1). Here we organize design revisions, each one being a sub task that has its own organizations
    • Inside each revision sub task there is a list of release candidates (screen shot 2). Each RC has two phases in the form of a review and release sub task. The engineer exports the design drawing set to be reviewed and puts them in the review sub task. The sub task is then assigned to the person responsible for overseeing the design.
    • The reviewer looks over the package and creates another subtask called "Revise". They assign it to the engineer responsible for the design revisions, create a list of issues that require attention, and mark the Review task complete.
    • The engineer works through the list of issues, checking them off as they go (screen shot 3). When the updates are complete they mark the Revise task complete and create another release candidate in the form of a review task and assigns it to the reviewer. 
    • The process continues till the reviewer approves the design, then a "Release" task is created. An actual release candidate is made in OnShape (up until now RC's were just pdf's of the drawings), and the release is executed.
    In all honesty we hate taking the review process out of OnShape, but the collaboration tools are practically useless, and the comments stored are difficult to reference. Clunky as it is, our method allows us to easily unfold the design process history and see the whole thing as it evolved candidate to candidate, and revision to revision. It also allows for better integration with the life cycle process. For example, we may kick off a new revision with a discussion of an ECR, then when the following RC is created its all available in one interface. I'm not sure if OnShape has aspirations to get to this level, the process may be so specific to each customer that its not worth making a generic collaboration tool. If not, perhaps there's room for a 3rd party plugin to add collaboration to the existing release management infrastructure?





  • tim_hess427tim_hess427 Member Posts: 96 PRO
    @jon_lewis118 ; - do you use any of the premium Asana features for this workflow, or do you have the free version? This looks pretty good!
  • jon_lewis118jon_lewis118 Member Posts: 5 PRO
    We’re just using the free version, there’s nothing in the paid version we need. This comes with it’s own problems, I’m sure this company is VC backed so they’re gladly giving away services at a loss while they attempt grow at all costs. It’s only a matter of time before the other shoe drops and we’ll find out what it really costs to be a member. 
  • Cris_BowersCris_Bowers Member Posts: 173 PRO
    +1 to Asana for managing workflows. I implemented it for project management at my last employer, initially just for the engineering department, but it worked so well for us, we rolled it out through the whole company. However, I couldn't get them to try out Onshape. I'm having the opposite issue with my current employer. I convinced them to try out Onshape, but can't get them to give Asana a go.
  • adrian_vlzkzadrian_vlzkz Member Posts: 106 PRO
    edited January 30
    Platforms like Asana, Monday, Jira are gaining a lot of popularity, a future Onshape integration with those, would make it a hard to beat Complete Solution
    Adrian V.
    CAD Administrator
  • jon_lewis118jon_lewis118 Member Posts: 5 PRO
    edited January 30
    The problem with 3rd party integration is your only happy when your service of choice is adopted. For this reason I assume OnShape is reticent to pick a horse and develop for one platform alone, integration would need to come from out side vendors, not within OnShape. Think of BOM as an example, OnShape built a product that lets you get manage a basic set of information and put it in your drawings. Users may need an ERP system to properly manage their BOM, but OnShape would be crazy to try and fulfill this need, since they can't, nor should they try to be everything to everyone. 

    I don't think they should aspire to a complete solution for managing product life cycle, but like BOMs I feel they should take it to a level where it provides great functionality for many of their users. Like the BOM they can arrange their API to allow 3rd parties to take advantage of their foundation and layer on top all the bells and whistles one could want. I *think* what I'd like to see is a middleware SaaS that uses [PM tool of your choice] as a front end for OnShape's release management data, and other meta data particular to lifecycle management (ECN's, project schedules, task assignments, etc.). This middle layer can then automate workflows, i.e. make prescriptive actions happen in OnShape, and your PM front end. As one example, a button click in the PM tool causes a RC to be made in OnShape, some further action approves or rejects that RC, and places hotlinks to that version in the PM tool along side the discussion surrounding that action.

    Maybe OnShape can make the complete solution approach work, to me their technical accomplishments dwarf any of this silicon valley fluff floating around (Slack is valued at >$7B, WTF!), but I'm concerned they can never get there due to the particular needs of each customer. Specialization is generally a winning strategy, but I always have a hard time finding that line between bolstering a core product with features, and biting off more than I can chew!
Sign In or Register to comment.