Release Management - Design Reviews

michael_bromley

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?

raj_Onshape

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_hess427

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_bromley

raj_Onshape said:

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.

romeograham

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!

brucebartlett

I tried to do a complete release of a project I was working on after thoroughly going through each drawing to confirm it was up to date and making sure there were no issues. I had the idea this was going to be my initial release of the project with all parts/assys and drawing using release management to drop a nice clean Rev A on my history trees. It took me at least a day to ensure the everything was updated and added on to release package, I pushed on with this process, with the goal of getting a nice clean initially release of my 30 odd drawings of my product, but unfortunately Onshape didn't work as expected with this large group and upon further consultation from the support team it was established that releases are much better done individually or in small packages and also releasing the part/assembly before the drawings.  This is different from how I have been used to working within an engineering dept where a larger group of parts assembly and drawings are sent in as a group for review and release.

I am hoping there can be some improvements in this area to help to release and reviewing a project. Michael, I think you are onto something with this request,  I am not sure how it would work but I know the current workflow doesn't come naturally for the review/release of a larger project.

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. 

tim_hess427

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_lewis118

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_bromley

brucebartlett said:

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_hess427

michael_bromley said:

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_kleinert

michael_bromley said:

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_bromley

andrew_kleinert said:

michael_bromley said:

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_hess427

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_lewis118

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_hess427

@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_lewis118

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_Bowers

+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_vlzkz

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

jon_lewis118

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!

Cary_Bettenhausen

I just dug this thread up when doing a Google search of "design review release candidate onshape". We are in the same boat as the OP, developing processes for a medical device (contract-only) manufacturer. My current solution is as follows (all within Onshape):

1. Create a "Design Review" version of the doucment to be released.
2. Create Tasks with Due Dates linked to the version created in (1) above and assign to Reviewers.
3. Compile Comments from Reviewers; act on them as necessary in the Main Workspace of the document.
4. Create a Release Candiadate from The Main Workspace of the document.

In this scenario, the Approval of the Release Candiadate is analogous to stamping drawings "FINAL" and placing them into our Document Control repository and the comments and actions made based on them after the Design Review constitute review and approval of the design.

We are still developing our processes here and trying to determine whether or not the responsible Engineer can self-release the Release Candidate or must add the initial Reviewers (as Approvers) to the Release Candidate. This point is moot for prototype releases, which by nature can be released direcly from Engineering.

Your thoughts are welcomed on this topic and thanks in advance for those who can add to the discussion.

Urs_Egger_REACT

My vote for any improvement towards ECR, ECN, ECO workflows. 
As far as I remember there was a sneak peek in this direction in Onshape Live 2021. Sneak Peak Video starting at around 18min https://www.onshape.com/en/onshape-live/2021

fnxf

I wonder what happened to that.. would make so much sense

Urs_Egger_REACT

Thanks, fnxf ;-) That's exactely what I meant. 

adrian_vlzkz

fnxf said:

I wonder what happened to that.. would make so much sense

I've forgotten about this... it would be very beneficial, but honestly we are still missing a lot of customization capability with the current Release Management that I would like to see before:

• 2-tier revision schemes (or more ways to customize)
• Automatically assign Rev Scheme per workflow
• Jump between workflows
• Custom event triggers (logic driven) in workflow
• An actual interface to customize/configure workflows
• Filters based on logic (Team, Project, Custom Prop...)
  
• "Fuse" Drawings with corresponding model (i.e. lock the ability to release assembly without the drawing)
• Customization or configuration of the Release Candidate Dialog
• Permission or setting to only show "Released" versions to selected Users or Teams (like Publications but without the need to manually generate)
• Or the automatic creation of a Publication from a Release Candidate
• Merge configurations as a single Part Number (currently configurations are treated as unique parts)

Just a few items that I can remember I've requested