All about Deliverables when creating a Project from a Template

In this post, I'll talk about what happens to deliverables and attachments when creating a program from a template. Agile Product Portfolio Management (PPM) allows you to define a project tree along with supporting deliverables and attachments in a template format, so that projects can be rapidly created to mimic the template. Deliverables are defined as rows in the content tab that drive program execution via rules. Attachments are defined as rows in the content tab without any rules.

From release 9.2.2 onwards, it is recommended that the attachment tab be disabled for the Programs base class, and the Content tab be used to store all attachments as well. The Content tab was designed in 9.2.2 as a combination of the old Relationships, References, Attachments & Links (and Approval Items on Gates) tabs.The Content tab should be the one place where all supporting information for the project is stored. The Content tab is especially suited for this purpose since it supports user-created Views, that allow flexible organization of such information. It has a preview pane to view relevant details of any selected row, so that users can perform common tasks from this screen itself.

When the Content checkbox is checked, copies are created for all deliverables in the template. In other words, the program and all its child activities will reference the newly created copies and not the original deliverables in the template. Deliverable autonumbers for the created program are automatically selected based on the autonumber chosen for the original deliverable in the template. The Autonumber attribute on the Content tab for templates allows user to specify the autonumber used. Drop-down list for autonumbers are automatically restricted to the subclass.
E.g. if there are 2 autonumber schemes for document subclass, one having prefix DOC and the other having prefix D i.e. documents could be named DOC000001 or D000001, and the user has specified DOCxxxxxx as the value for the Autonumber attribute on the Content tab of the template, then the copy of the deliverable will be numbered according to the DOC autonumber scheme.

For deliverables that are not numbered using an autonumber scheme i.e. user has left the Autonumber field blank (by default, the Autonumber field will be blank unless the user selects another value, copies are not created. A list of all such deliverables is presented in the log file sent to the user in the Program Creation Notification.

Autonumber attribute cannot be filled in Proposed or Active Programs. If such Programs are saved as Templates, user has to fill the autonumber attribute in the Template again.
The user who creates the program from the template becomes the creator/owner of all deliverable objects created. For objects that have the owner concept, e.g. sourcing project, the owner can be changed later, using existing functionality. The create user has discover/read privileges to the objects created in this manner.

When Content checkbox is not checked during program creation from template, there are no copies of deliverables created nor links to any deliverables on the template. In other words, the Relationships tab for the program and all of its child activities and gates will not contain any deliverable objects.

In general, copies of deliverables are not created for all objects that do not have a Save As functionality. All deliverable objects for which copies cannot be automatically created are listed in the error log window as mentioned in the specification section for Rules for Error Handling.
For all classes, if the same object is a deliverable for multiple activities and / or gates in the template, the copy of the object is created for the first activity / gate that it is a deliverable for, and a link to this copy is provided for all other subsequent activities / gates that the same object is a deliverable for.

E.g. Consider a document DOC00341, which is a deliverable that is referenced 2 times in a template on Task1 and Task2. When a program is created from this template, a new copy of the original deliverable in the template will be created, say DOC00982 for Task1. This same document DOC00982 will be a deliverable for Task2 as well, following the same pattern as in the template that the program is created from.

All required fields are copied from the original deliverable to the new copy created.
For all subclasses, Cover Page, Page Two, Page Three & Attachments tabs are copied.
E.g. If an assembly is a deliverable on one of the tasks, the only tabs that are copied are Page 1, Page 2, Page 3 and Attachments. The BOM tab is NOT copied over.

When internal activities and gates in the template are used as deliverables, corresponding copies are appropriately created in the newly created program tree and referenced as deliverables in the other activities and gates as defined in the template.

When activities and gates within a template or source program are added as deliverables to later activities and gates in the template, the deliverables on a program created from the template will also reference corresponding activities on the newly created program. E.g. If Task1 is a deliverable of Task2 in the template, then for any program that is created from the template, Task1 in the program will be a deliverable of Task2 in the program. This is one approach of implementing hard exit on gates i.e. ensuring certain activities are completed or certain gates are opened before another specific activity is completed or gate is opened.

Only external root programs of template type are allowed as deliverables of activities and gates within a template. In other words, root programs of Proposed and Active type are not allowed as deliverables for activities and gates within a template.

If an external root template is a deliverable on a task of a template, a new program deliverable is created as a copy of the original template deliverable. This copy of the original program deliverable has the program tree structure in place, but no deliverables. When creating copies of external root templates, only General Info, Page 2, Page 3, Attachments, Dependencies and Schedule tabs are copied. Team and Content tabs are NOT copied. External root templates, if used as deliverables multiple times, are cloned only once similar to internal activities and gates.

If the user chooses to create a Proposed program from a Template, all templates that are deliverables of this template are created as Proposed programs that are deliverables of the newly created Proposed program. If the user chooses to create an Active program from a Template, all templates that are deliverables of this template are created as Active programs that are deliverables of the newly created Active program. For the copies, only the name of the root program will be changed, the names of the activities/gates will remain the same. The activities/gates numbers however will be system generated and unique.

Copies of external activity deliverables that are not root templates are not created due to the fact that non-root activities cannot exist by themselves. In this case, the deliverables on the program created from the template will reference the original deliverables on the template for such objects.

Attachments are meant to be used for information such as Standard Operating Procedures etc. and managed from a central location. Hence they are not cloned. All attachments will point to the original ones on the template. If you need to have unique supporting information per project, you need to make it a deliverable.

Once again, comments and suggestions are welcome!


Post a Comment:
  • HTML Syntax: NOT allowed

Hear from the community that's pioneering PLM's critical role in transforming supply chains into sustainable value chains that power profitable innovation and competitive advantage.


« April 2014