AnsweredAssumed Answered

Thoughts on Project Deliverables

Question asked by Dale_Stockman Champion on May 22, 2013
Latest reply on Apr 28, 2017 by Christopher Yardin
Have had a recent request to produce a report that looks like "X" (an Excel) document. Examination of the document reveals that it is basically a categorized list of Project Deliverables, with text, status, owner and due date.

So, the question becomes, "Do this as attributes of a Task, or as a Deliverable sub-object hanging off the Project object?"

1 - Implement as a "Deliverables" Subobject
- Pros: Provides a simple Sub-page link on the Project Properties Main\General page, with a simple list of the deliverables - easy for user to find, create and edit deliverables, easy to build portlets
- Cons: Shares some of the same attributes that are already defined in our tasks (Out of the box date, baseline features, plus a custom "Task Owner" attribute) - two subojects doing similar, things

2 - Implement as attributes of Task Object
- Pros: Utilizing OTB subobject and date, baseline features and some of our existing custom attributes
- Cons: Can't get a simple, clean list view of the deliverables within a project, harder to find tasks that have deliverables associated with tasks, edit them

There are additional pros and cons for both options, and yes, I know one can create a portlet for displaying deliverables from task attributes and display the portlet on the project's dashboard tab. For now, I want to avoid 'deep diving' this topic.

Before deep diving, I want to ask if anyone has actually implemented either approach, or perhaps one I haven't thought of. And if so, what have been your results and what would you recommend to someone considering this topic?

I'm currently leaning toward recommending the following:

Implement as a "Deliverables" Subobject
- Let the deliverable subobject record include
- name
- id
- categorization
- priority (red/yellow/green)
- Description (text)
- Current Actions (text)
- Task ID (lookup)
- Task Name (read-only)
- Owner (read-only)
- Finish Date (read-only)
- Baseline Finish Date (read-only)
- Status (read-only)
- Late to Plan (calculated, Baseline Finish - Finish)
- Late to Today (calculated, Now() - Finish) [value results if Baselne doesn't exist; also comparison to "Late to Plan" shows whether plan is being managed or not]

where the read-only fields are populated by a process that pulls the corresponding content from the associated task (yes, I know that for NSQL portlets and reports, I don't need to copy the Task Metadata to the Deliverables subobject - I want the task metadata available for viewing in this subobject's list/edit views and any object based portlets - no editing - date changes should be done on the WBS, utlizing the scheduler).

With this solution, I provide the manager with the simple, easy to access list from the Project Properties Main\General page, but also insist on usage of the OTB task/scheduling features, with the flexibility of being able to associate the deliverable with different tasks/milestones, or change the association (another "pro" I just thought of).

These are my thoughts, at the moment. Comments on these thoughts and best practice recommendations, welcomed.

Thank you,

Dale

Outcomes