APM Concepts & Terms

A glossary and description of key aspects of the system and terminology used.

1. Navigating Actify APM

1.1 Projects & Programs

Projects are the primary organizing vehicle in APM and provide a flexible stage-gate approach for managing key program management processes.

Projects are created from Templates for efficiency and consistency and comprise Phases, with entry/exit gates. Phases comprise Tasks and/or Milestones which are the “unit of work” in a project. and which create Outputs (the result of the Task). Multiple Projects can be associated to a Program and may have the same or different workflows (if created from different Templates).

Projects have Teams of Users - the same User may be a member of several Teams with different permissions on a per-Project basis. Users can be managed individually or via Roles.

Several Dashboards provide program and/or project visibility and status tracking, with flexible view management, personalization and user-context views.

A wide variety of documents, including part/CAD data can be associated - securely - to a Project or Program. Parts or assemblies, are version-managed by the APM Catalog which can also include translated CAD files. Non-CAD program files are version-managed and collated within APM Folders. APM is version-aware to maintain data integrity and to identify or propagate the impact of a change of a CAD or file object to “downstream” activities or users.

Within APM, users have immediate visualization capability for any related part/assembly (CAD items) using built-in web-based 3D visualization. A more powerful desktop visualization tool is also included. CAD files for parts or assemblies are managed by the APM Catalog, which provides features for CAD conversions and ensuring that related visualization files are up to date.

Users can download/check-out Folder or Catalog items for desktop interaction and check-in/upload updated versions.

Permissions control user visibility and the actions they can perform on Tasks or Projects and their visibility and access to Folders & Catalog items.

1.2 Dashboards

Several management Dashboards are provided, each of which provide interactive tailoring or personalization options.

All Programs Dashboard (Home)

• Provides searchable, hi-level visibility to Projects in the system by the Programs (Program Number) they are associated to, their overall Status (Active, Archived etc), level of Completion and a selectable array of related properties, such as associated vehicle, customer etc.

• Note: By default, this view shows project grouped by Program. Users can remove the Program grouping or use the Quick Nav feature to directly access a specific Project.

Program Dashboard

• An RYG color-coded progress and status dashboard for a program and its associated projects which highlights level of completion, upcoming milestones and milestones achievement status

• Flexible viewing options allow for different groupings to provide a flexible level of detail

Project Dashboard/Project Home

• Provides alternate detail views of a project via selectable tabs. An Assignee-selector applies across the relevant tabs to highlight Tasks assigned to that user

  • Overview tab: A progress color-coded Task status view of the Phases and Tasks/Milestones for immediate visibility to overdue items or those needing attention, or Tasks applying to specific users (“My Tasks”)
    See Task Workflow Example to better understand the tasks status indicators.

  • Workflow tab: A Phase-separated table view of the Tasks in each Phase with Status, Assignee and key Dates. Task details can be inspected/edited from here.

  • Timing tab: A flexible Gantt-like view of the project with Phase expansion and timeline “zoom” options. Project dates an be adjusted here, for example to apply delays or accelerations to downstream Project dates

  • Spinfire Web tab: Provides web-based 3D visualization of the part or assembly associated to this Project

1.3 Breadcrumbs

Users typically use the Dashboards as their primary view and then navigate from them (drill-down) into their Project or Task details, as they do the context is shown in a clickable breadcrumb, so users can go “back” to higher level views. (This is preferred over use of the browser “Back” button, which can have inconsistent behavior across platforms. A Quick Nav feature allows direct access to a specific Program by name.

2. Templates

2.1 Folders

Program or Project data, other than APM Catalog items, are collated in Folders. Folders are where Task Outputs are placed along with any related supporting materials and work product. Folders can also be used to provide a “library” for standard documents or worksheets, such as should be used to create specific Outputs from, e.g. a cost estimating worksheet.

Folder Templates

New: Admins can define a preferred folder-structure (as a Folder Template) which defines the hierarchy and folder names so that a consistent structure/naming can be used across Projects and/or Programs. Team Members cannot change this structure (but they can extend it, by adding, renaming or removing sub-folders).

2.2 Forms

A user-configurable form (defined via Configuration > Forms) may be used to interactively capture key property information from the Task Assignee in a structured manner. Forms can be populated with

2.3 Lists

A Master List is provided in the database to store common values, which would be used to fill out common Project Property fields

Lists are managed under top-left hamburger menu, APM > Configure> Lists. 

2.4 Workflow

Projects are configured from Template(s) which define the Workflow or Phase/Gate and Task structure of a Project. A summary view of the Workflow is included in the (clickable) left-side Navigation panel, with link-lines to highlight Dependencies. A detailed view of the Workflow is provided in the Project Home page (Workflow tab)

Project Workflow Templates

Admins can define (Project) Templates so that a consistent structure is followed for a set of projects, such as those in a specific program or related to a specific customer. Templates can include the Phases, Tasks, Task Outputs and their types, any Approvals required and the Dependencies for a project workflow. Tasks in a Template can have a Duration to define the (default) length of time that Task is expected to take to complete. In addition, the Roles, such as Project Manager, can be defined in the Template and used to define which Role(s) should Approve a Task Output..

Projects are created initially from a Template. Using Project Setup, Dates can then be applied to them. and the specific Team Members (users) assigned to the Roles, to specifically configure and launch the project, or to make further changes to it during its lifecycle.

See Templates & Template Editing to learn more about creating project workflow templates.

3. Project Phases and Tasks

3.1 Phases

Projects have a phase/gate structure. Phases are (auto-numbered) and nameable. A Project workflow can comprise multiple phases, which may overlap in time. Each Phase has an Entry and Exit Gate. Phase names cannot be changed once a Project is Active.

Entry/Exit Gates are automatically created and always exist in a Phase. Entry/Exit Gates provide link points for Task Dependencies, for example, so that certain Tasks in a Phase depend on the Entry Gate being Started, or so that the Phase Exit gate can only be completed when the outputs of various earlier Tasks are completed (Finished). See Dependencies

3.2 Tasks & Milestones

Tasks are the unit of work in a Project and define the activities for a Phase. A Task can be flagged as a Milestone, or checkpoint.

Task Name

Task names must be unique within a Phase in project Templates. Task names can be changed once a Project is Active.

Task Status & Legend

See Task Workflow Example to learn how tasks status indicators may be used.

See Task Status: Outputs & Approvals to learn more about setting the status.

3.3 Task Action Items

Inputs

Task inputs are categorized as three types of inputs, which can either be a Note, place for attached File(s), or use of an embedded Form.

Output Types	Type	Icon	Usage
	Notes (default)		The Task Assignee can (optionally) provide some explanatory remark or comment.
	Files		The Task Assignee is required to attach one or more files. A File Output can be populated by: uploading (from outside APM). Uploaded files are placed in a (user-selectable) APM folder associated to the project linking to an existing file in a Folder (of that project) linking to an APM Catalog (Centro) item. This can be the defining CAD file for that Catalog item (part or assembly), or a Derived Resource created from the CAD files such as the STEP verson of a visualization file (e.g. ACT3D or SFW file)
	Form		The Task Assignee must populate the associated APM Form. The Form type is defined by the Template and are created using the APM Form Designer

Outputs

Tasks can have “No Output” (Users can optionally provide a text note comment to them) or are required to have at least one specific Output. The type for an Output is defined in the Project Template.

3.4 Task Relationships / Dependencies

Dependencies and Requires Review

A Task may depend on the (outputs) of one or more earlier Tasks. For example, Task 3 in Phase 2 depends on the output of Task 2. Task Dependencies can exist across Phases, so Phase 5-Task 2 can depend on an Output of Phase 2-Task 6.

When a Task has a Dependency and its output(s) have been populated and the (depended on) item changes, this Task will be marked as Requiring Review (with an exclamation mark):

                                                               (Task Requires Review)

For example:

• Task 15 has an output of the cost estimate for a fixture which obviously depends on the fixture design itself, which is an output of Task 7. If that fixture design Output (Task 7) is changed (versioned), then Task 15 which depends on it, will be marked as Requiring Review.

Dependency Types

Effective management of project schedules is provided by modelling the timing constraints for Tasks using (optional) Dependency Types:

Finish-to-Start (F2S):

This Task cannot Start until the depended-on Output is Completed. This is the default type.

• Using this Type will “daisy-chain” the Tasks sequentially

Finish-to-Finish (F2F):

This Task cannot Complete until the depended-on Output is Completed.

• Using this Type will make the Tasks complete together (co-terminate)

Optional:

This Task’s scheduling is not impacted by the depended-on Output.

• Using this type won’t impact the relative timing of the dependent Task

Important:

• Dependency types apply to the inputs or Dependencies of) a Task, (rather than on the Task itself), which is often how other project management tools work). Accordingly, dependency types can be defined on each “input” (or Dependency) to a Task independently, i.e a Task may not be able to Start until Dependency 1 is Completed (“available”) and not able to Finish until Dependency 2 is Completed.

• Dependency types are optional, if a Type is not defined for a Dependency of a Task (i.e left as Type = Optional) , the scheduling of that Task is not impacted by the status of that Dependency.

• Dependency types can be built into Templates and/or edited for in-progress Projects. F2S is the default type for a Dependency

In this example: This Task has multiple dependencies, each of a different Type. The Task has dependencies on: the Entry Gate of the Phase - of type F2S - and therefore can't start until the Phase Starts An Output from Task 6.01 in Phase 5 - of type F2F - and therefore can’t Finish until Task 6.01’s Output is Completed An Output from Task 5.01 in Phase 5 - of type Optional - and therefore does not require that Output to be able to Start or to be able to Finish. Specifically, the scheduling algorithms will not take the status of this Dependency or “input” (from task 5.01) into account when scheduling this Task (7.01)

Timeline View

Dependency “links” are displayed in the Timeline view of a Project.

In this example: Task 4.1 is Overdue, (bordered in Red), because it should have been started before Today. Task 4.2 has an F2S dependency on an Output of Task 4.1 (and cannot Start until that Output has been Completed) - shown with an incoming arrow into the beginning of the Task bar. Task 4.3 has an F2F dependency on an Output from Task 4.2, and cannot Finish until that Output has been Completed, shown with incoming arrow to the end of the Task bar.

Non-Sequential Phases

Using the Dependency types, users can configure the Phases in a workflow Template to run sequentially, or in other arrangements.

Users can configure the dependencies of the Entry Gate of the Phase to control when that Phase beings relative to other Phases (or Outputs from Tasks in other Phases)

For example:

In a Template:

• Phase 7 can have an Entry Gate depend on (the output of) the Exit gate of the prior Phase 6 so that they run sequentially - this is the default

• Phase 8 can also depend on the Exit Gate of Phase 6, so that Phase 7 and Phase 8 will start in parallel.

• Phase 9’s Entry Gate could depend on the Output of a Task (ex. “Design Review”) in Phase 3, so that the Phase would not start until that Phase 3 Design Review Task had Completed.

Note:

• As Entry Gates do not have a Duration (ie. Start and Finish “instantaneously”), choosing an F2F versus an F2S dependency type does not impact the scheduling or completion of the Entry Gate.

  • Using F2S is recommended to best communicate purpose and readability.

• Entry gate dependencies can be changed in Templates, (not in a Project).

• Exit Gate dependencies are not modifiable.

See Task Workflow Example. The worked example illustrates the workflow lifecycle of a Task (assigned to one person) and a subsequent Milestone (assigned to someone else) that depends on it.

3.5 Task Responsibilities

Assignee

Each Task has an Assignee that is responsible for completing the Task. Tasks can be assigned to a specific named User. Re-assignment of a Task can be re-assigned by the Assignee or Users with applicable write access.

Approvals

An Output may require Approval, which can be defined by the Template. By Default, no Approval is required (i.e. the system auto-Approves the Output on behalf of the Assignee). The Assignee (or write-access Users) can add or change Approvals.

Approvals can require one or many Approvers, which can be combinations of named Users and/or Team Roles. Unless otherwise specified, Approvers are other Team Members with write access. As individual users may change from time to time, it is preferable from Templates to define Approvals in terms of Team Roles vs specific users. See Templates.

Users can see which Tasks are pending Approval on the Project Home page or when viewing a specific Output. Users are notified (via email) when a Task Output is ready for them to Approve.

Note:

• A Task is Finished when all its Outputs have been populated and (each) Approved.

• When any Output requires an Approval, the Task will be shown as Pending Approval.

3.6 Task Duration / Scheduling

Task Duration

Tasks carry Target and Actual values for both Start and Finish dates. Tasks inherit a (default) Duration from the Template (if set in the Template), which can be overridden in the Project, via Project Setup.

Note:

• The Actual Start for a Task can be back-dated (from today) to allow for in-process projects to be taken up in APM

• Actual Finish dates are set by APM when the last-remaining (latest) Output has been Finished, which would typically be the (last) Approval date). This means the Actual Finish Date of a Task can change (i.e. be updated) if for example, the Task was re-visited and its Outputs updated.

Late & Overdue

Task Target dates are used to determine if a Task is "behind" using the below terms:

4. APM Platform (Centro)

The APM solution is enabled by the APM Platform, which is built on Actify Centro. Key Platform functions, such as the Catalog, Admin and User management are accessed via the Centro sub-menu:

4.1 Catalog

The APM Catalog is a repository, version manager and coordinator of parts-defining CAD files and their “Derived Resources” for Parts and/or Assemblies, provided by the APM Platform (or Centro)

A Part in the Catalog (usually) has a defining CAD file and version. Derived Resources created by the system from this, such as Visualization files (ex ACT3D, SFW) or other (converted) CAD or interchange formats, as well as extracted physical properties and CAD attributes, are collated and versioned with it. Assemblies can exist in the Catalog by referencing other Catalog Parts so that common parts can be shared across Assemblies. Users can also associate/upload other files or documents to Catalog items.

Derived Resources can be re-generated/updated if or when the base file is versioned - the powerful Cascading Update feature will propagate such changes through Assemblies. Additional features for check-in/check-out or downloading, visualizing Catalog items and defining Assembly change comments provide a comprehensive Catalog capability for managing program Parts and Assemblies.

See Catalog documentation.