cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

We are happy to announce the new Windchill Customization board! Learn more.

ProjectLink - Revision capability?

kpritchard
4-Participant

ProjectLink - Revision capability?

Hi All,


Has anyone been able to implement versioning (i.e. Revision capability) in ProjectLink through a customization? Any other frustrated community members want to get together to share cost on getting this done?


PTC - any chance you're willing to look at the enhancement requests submitted on this issue?

16 REPLIES 16

I would actually vote strongly to keep it as is. Not having Revisioning in ProjectLink is one of the key dividing lines about whether data goes in PDM or Project. It sort of forces work in Projects to be just a sandbox, not "the real thing."
kpritchard
4-Participant
(To:kpritchard)

Mike - with all due respect we'll have to agree to disagree on this one...


What we're trying to use Project for is "early real" where the majority of design iteration would occur. PDM side Change Management is somewhat stickier than Project side review andapprove mechanisms, and rightfully so. We've adopted a State-centric approach to"real" or not regardless of Context.


I do agree that at some point most data needs tobe sent to PDM assuming you're a design it and make it (or get someone to make it) company. I also suspect that I'm a bit more maniacal than most when it comes to revisions (Iuse them to "freeze" concepts).


Maybe there is some middle ground by making this behaviour a Site or Org level preference which would allow users to use ProjectLink in the way that best suits their business needs.

Most likely the key element of this discussion is whether a single-phase or two-phase lifecycle / versioning approach is used.

If single-phase, then likely Revisions in PJL are very necessary.
If two-phase (as we have it), the PDM side accommodates two very different sets of business processes for each single item, progressing from very informal and flexible to very controlled.

Unfortunately, the two-phase approach is only 10% documented as provided. It takes quite a bit of digging to understand what is actually there and how to take full advantage of it.

Keir,

You could also make simpler ecn workflows for early design states like prototype and make the process more involved as the design states mature.

We have four different ecn processes.
- Prototype - must have chief eng . approve and optionally any affected competency approvers
- PreProduction - configuration management is involved, must have at least one competency approved then the chief eng.
- Initial Release - used to flip from PreProduction to Production uses ootb ecn process slightly modified to allow an electronic change control board if desired.
- Production Changes - initiated from an ECR again close to the OOTB ecn process.

I think something along these lines would be a better fit than to customize PJL to do something it wasn't designed to do.

HTH,
Steve D.

Sent from my iPhone

kpritchard
4-Participant
(To:kpritchard)

Does anyone use ProjectLink Routings? if so, how? Maybe this is the source of my confusion/frustration...


It would seem that ifyou can "Approve" something through aRouting, you might need also to "Approve" the something slightly different and be able to have a visible difference marker between the two. I have issues with the result in ProjectLink where you can have multiple "real" iterations of an object as a result of routings


What about deliverables and Action Items? being able tofreeze and force Revision would begreat friction for scope creep! Having a frozen action that is accepted by a resource would generate greater ownership and accountability within a Project Team.


Any good references on how to use ProjectLink effectively as intended? I'm having a hard time selling the benefits of ProjectLink to internal users. Why buy Project if you could just add a "Sandbox" State PDM side?

Control it via a Preference.


Win/Win

It took me a long time to understand what was happening for ProjectLink Document Routing.

User selects Route. System presents a number of choices, radio buttons. Turns out it presents the current list of enabled "process type" Routing Lifecycles, with their Descriptions as the Text.

User selects one. System assigns this Lifecycle to the Document, starting with the first state, to which a workflow process is mapped. The workflow process starts.

During routing, the workflow process generally sets the state of the Document.

After routing, one can Route again, providing the user has MODIFY permission at the Document's current state.

A given Document can have a variety of Routings at the same Iteration and/or have a new Routing at several Iterations. It's the ProjectLink way of allowing things to get to Approved, then edited, then again getting to Approved if needed.

We've played with Routing quite a bit but don't in fact use it much so far.


Action Items are also fairly helpful Rascals. They can be created alone, or tied to a Meeting, or tied to a Document (in both Projects and in PDM). They can be manipulated various ways in Excel also that are pretty nice.
ks-2
3-Visitor
(To:kpritchard)

Hi,

Maybe the attached document will be of useful to enable document revision in
projectlink. But before deploying to production machine, access all the business
usecase impact which you have deployed earlier.

Kumarappan.S


sm
1-Newbie
1-Newbie
(To:kpritchard)

Hi,


Just found this thread while doing a search on the topic of supporting Revise in ProjectLink. It has been proposed as a new Idea on the PTC Windchill Community, but does not have a lot of traction, similar to this thread.


Curious how critical the ability to Revise an item in a Project is for people? If it is, what are the use cases and requirements you have? What types of items should be supported; documents, CAD, parts, all?


Personally, I would like to support it for items that originate in the Project only and their revision history would be lost if the item were "Sent to PDM" since it woudl be assigned a new lifecycle and revision scheme when created in PDM. I also like Joe's idea of controlling it via preference, but might need to be a configuration of the project like sharing to other projects and identifying out-of-date shared objects. The open issue is whether or not this could be changed once the project is created. It might need to be an initialzation option like linked deliverables and execution control that cannot be changed later.


Happy to hear any thoughts or ideas on this one.


-Scott

Copied from the PTC Community comment I left there:

It would be of great benefit to us. We typically leave CAD Documents in the Project until they go through our release process, then they are sent to PDM. So all of our prototypes are created and tracked with a manual revision level on the drawing since we cannot revise in ProjectLink.
There have been internal efforts to get the engineer to move the item to PDM sooner to take advantage of the revision control but those have all failed. The engineers have their reasons for not wanting to have the object available in PDM until it is released.

In general, ProjectLink should just be a sandboxed area of PDMLink, without some of these artificial differences. The users don't understand and it just ends up slowing them down.

The release process isn't really functional as well. Sure you can route something in ProjectLink in order to collaborate effectively with them and other outside/internal parties but when you do a PDM Checkin...it just resets the LC state...no options there. I certainly don't want to do the general promotion process again (simplistic stuff) just to get it to released. I can't include the external entity in my Product Promotion either as I don't want to give them any access to my Product. I'm hoping I'm missing something simple here though.





[cid:image001.gif@01CF7046.C96AB930]

Stephen Vinyard
Business Development Manager/Solution Architect

Using statebased versioning and a two phase lifecycle (numbered Revs, then Letter Rev's) solves a lot of the fundamental problem of allowing free development and then more formal production.

With a two phase lifecycle, while the object (always in PDM) is at a Numbered Rev, Engineers / Designers can have all the needed flexibility that Project provides, but with the advantage of normal Revision processes. A cardboard box of Rev 3 Parts is traceable to Rev 3. This requires setting up different transitions in the lifecycle for Numbered vs. Letter Rev's.

At some point each object is "A Released" and then much more formal change management can be used to go to Rev B, etc. This also aligns well with prototype vs. production tooling, production worker training, normal receiving inspection, etc.

I'm good with that Mike, its more related to the external entities. They never get access into PDMLink...only ProjectLink. Still need an easy way to get stuff generally released with the external entities input/work etc AND then maintain that released nature (maybe not fully released) when pushing into PDMLink. People get frustrated with having to do a "double released" for some basic stuff that was done and vetted in ProjectLink.



[cid:image001.gif@01CF7046.C96AB930]

Stephen Vinyard
Business Development Manager/Solution Architect
cc-2
6-Contributor
(To:kpritchard)

Hi,


I agree with Steve. I first believed it was fine not to be able to revise for the reasons Mike explained a few years ago in this post.


However, when using ProjectLink with external users such as customers or suppliers, Some of the documents could get approved/released for them to be able to know it is ready for them to do whatever they need. But if during the project we realise the document must be amended, then it gets tricky. of course PJL does offer versionning, so any change is still captured but it is not the same (I can still checked out an approved/released document in PJL). I could also set the state back to In Work but if a Route has been trigger, this mess up the states at least with 9.1. There is a fault there.



Anyway, I believed that with 10.1 or 10.2, one can now revised in PJL. We have 10.1 in production but have not had a chance to look at this yet.



In other words. While using PJL to support PDMLink to create new data, I believe revising is not really required, However, if we use PJL with people who do not have access to PDMLink, revising can help a lot.



My thoughts.



Best regards

MGleason_1983
6-Contributor
(To:cc-2)

Vote here...

Just added the request back to PTC. The last one was archived.

Again, I am resonating with those on this channel who are seeing value in the ability to revise from ProjectLink to PDM. I love the idea of sharing something released to a project and playing with some potential ideas without disturbing the released content. If the development is showing promise and we want to move that development to PDM, I wish I could create a revision in PDM and then share the project items back to PDM in the new revision. Obviously, the new items would have to go through an ECN to be released, but you could fully experiment without disturbing the released content till something looked viable. 

Hi @MGleason_1983 

I guess the idea is archived because your idea post does not include required information.

I saw it many times. If you do not provide this information in will be archived. 

PetrH


1. What product and version are you running
2. What is the problem?
3. Are you using a workaround? If yes, please describe it.
4. What is the use case for your organization? Describe how your idea would work in context or how it would apply to a practical situation.
5. What impact does this problem currently have on your organization? (Number of users affected, hours of lost productivity, etc.)

Top Tags