Deliverables
Any object against which progress is measured. There are two types of deliverables:
-
Design deliverable
-
Activity deliverable
Design deliverables are any items (such as design documents and tags) that can be registered for progress. The item is registered as a single object, and its progress is tracked linearly (it has sequential steps). Typically, design deliverables are processed internally.
Activity progress tracks groups of objects. Activity items (such as Vendor documents or tags) relate to a parent deliverable. Typically, these would be documents that get sent to and received from external suppliers (or possibly between different departments in an organization). Each time a deliverable is returned, it is allocated a status code which corresponds with a step in its workpack. Activity deliverables are progressed dynamically, and items can move forwards and backwards through the steps as the status changes.
Reporting hierarchy
The progress hierarchy is used to provide the project structure for which deliverables are grouped (into workpacks), and forms the levels to which progress is calculated, rolled up, and viewed. Progress can be monitored at any level in the hierarchy. Configurations may require differing reporting structures; hence, a system-wide structure is inappropriate. Therefore, it is necessary to be able to define a reporting hierarchy for any configuration, such as for each plant. The hierarchy in any given configuration applies to both design and activity workpacks.
Workpack
Workpacks group deliverables by common reporting hierarchy attributes against which workpack steps are configured and planning information recorded (for example, man hours).
Workpack templates
Workpack templates are a set of workpack structures that can be used to create actual workpacks. They are independent of the workpack reporting hierarchy. Workpack templates allow for the creation of multiple workpacks with many of the same settings, steps, and other details.
Workpack template hierarchy
This can be used to categorize templates within a sub section of the reporting hierarchy (and default the workpack hierarchy properties).
Workpack step
A workpack step represents a milestone in a deliverable’s lifecycle. Typical deliverable milestones could be the fact that a particular lifecycle status has been reached, or that the deliverable was issued on a transmittal for a specific reason for issue or at a specific revision.
-
All deliverables associated to a workpack go through the same set of steps in their lifecycle.
-
Each workpack step is assigned a weighting which defines the percentage deliverable progress attributable to completion of that step relative to the other steps in the deliverable’s lifecycle.
-
Deliverables can be progressed through their workpack’s steps automatically or manually.
Workpack sub steps
A production step may be divided into sub steps. Each sub step is assigned a weighting which defines the percentage deliverable progress attributable to that step.
For example, a production step might have weighting of 20% of the workpack and have two sub steps with weightings of 5% and 15%.
Activity workpacks
Activity workpacks are a generic solution for monitoring the overall progress for a group of deliverables, which includes support for basic supplier progress reporting functionality, onto which project implementations can build more complex functionality.
Return and review periods
A review period is the expected duration that a deliverable of a given type will need for its internal and external review.
A return period is the expected duration that a deliverable will take to be returned from the originator once it has been issued back to them.
These periods are used to automate the setting of due dates on activity workpacks.
Return status codes
Return status codes (or status codes) only apply to activity workpacks. Every step on an activity workpack (except the first step) is assigned a return status code. When an activity deliverable completes a step, it is manually allocated a status code, which is matched against the step status codes to determine its progress. (A deliverable with no status code would be on the first workpack step.)
Design workpacks
Design workpacks allow the monitoring of progress for individual design deliverables. Actual progress accrued for a design deliverable can be automatically calculated based upon key stages in its lifecycle.
Design deliverable progress can be said to be forecast biased. Although it provides an accurate view of the actual progress accrued for design deliverables, its strength is in the ability to provide accurate forecasting.
Time strings
Time strings are only used by design workpacks and design workpack templates. One or more time strings can be defined for a design workpack. The time strings manage the estimated effort (in man days) required to complete each production step for the workpack and are used to calculate the plan and forecast dates for deliverable production steps. Each deliverable must be assigned one of the workpack’s time strings.