PJL Documents / Deliverables

[MikeLockwood]

Just starting to use PJL in depth.

We have a Deliverable with a Document in the same project as its Subject. We iterated the Document. The Deliverable still points to the previous Iteration of the Document. Is this intended behavior? Seems like it would be far more useful for the Deliverable to float to the latest Iteration of it's Subject Document.

[ddemay]

I would actually expect the opposite, Deliverable is like the PJL equivalent
to a PDM baseline or configuration. PJL tends to be more fluid, so I don't
see Revise rules being the same, hence a pointer to a specific iteration and
also a relationship to a specific action item or milestone. What does the
help say for it when you click the question mark button/icon?

[MikeLockwood]

Tech supported asked if we had PJL Enhanced Project Planning installed. We don't - I just installed it on a test system. We'll see if that changes the behavior.

Anyone know?

I couldn't find anything from the Help on how this is supposed to work (which Iteration of a Subject Document the Deliverable points to).

[kpritchard]

We're starting to do something similar... we have Word Documents that define "Work Packages" (that would amount to a major Activity Roll-Up). We're using Libraries on PDM side in order to leverage Revsion control. Iteration is fine as long as Project "Suppliers" and "Customers" all play nice, but in reality conflict arises when the deliverable changes but with no analaysis of impact to budget and/or schedule (leaving front line resources with their feet held to the fire for late delivery without visibility to the radical change to the definition of the deliverable halfway through the Project). We're starting to use these "Work Packages" which are enabled with Advanced Lifecycles and Review/Approval Workflows PDM side to act as some level of Project Change Control.

To me, it seems dumb to have to create and store a Document PDM side and SHare it to the Project to establish the relationship to the Project andmake visible to the Project Team. I'm on the side of tighterVersion (Revbision) control for Project data..."Freezing" an agreed upon version by setting to a non-editable state with the need for any modifications forcing a new Revsision is hugely powerful but does not need to have as much friction as Product Change Management (PTC - if you're listening I'd love to see Project Change Management as well as Revisions [via preference] enabled in PJL)

Thanks.