PTC - Big Picture

An overview of PTC requirements for communication paths and roles is show below.

PTC Big Picture communication paths and roles

PTC communication paths and roles

The figure is self-explanatory, but a few strengthening remarks should be added.

Explanation of procedure types

  • Long procedure projects typically have long implementation completion times, make large resource requests on many DATA groups, and may have additional requirements such as safety.
  • Short procedure projects typically have short implementation completion times due to making fewer resource requests on fewer DATA groups.
  • The long and short definitions additionally avoid using external and internal to classify procedures, which inherently imply a bias that is not intended.

Additional statements regarding roles

  • Procedure Entry Points (PEPs) are the working partner of PTC. Each procedure has at least one PEP.
  • Long PEPs pass all organization and work requests through PTC. This avoids punch through where non-DATA group personnel approach DATA personnel w/o the knowledge of the DATA GLs, TLs, or PTC and, consequently, receive information which is meaningless.
  • Long procedure managers, probably the PEPs, manage their procedure.
  • Long PEPs see the PTC as the DATA resource manager who maintains DATA’s view of the procedure concerned.
  • Short PEPs see the PTC mostly as an observer, i.e. they are expected to run their procedure efficiently. The procedure view exposed to PTC must comply with PTC requirements.

Fine tune rather than change

Products that make things easier are an enormous benefit and designing a product for identical robots is simply a question of logic. Fortunately people are not robots and people must see the benefits for a product to be a success. The view of project management at EuXFEL reveals no clear path taken and no significant drive to address the issue on a large scale. Perhaps it is fairer to say that tools are available, but their usage is scattered and not coordinated beyond individual or group requirements. Mandating PTC represents a move towards cost aware resource planning by DATA. However, its startup is difficult because no consistent approach exists between different procedures and the tools used.

The approach followed is fine tune rather than change:

  • discuss with procedure workflow owners how their systems work, identify requirements and identify useful PTC interface components.
  • with the procedure managers produce dry-run environments of the derived PTC interface and test these with owners and DATA group resource holders.
  • align test feedback and implement the PTC interface followed by periodic reviews and modifications.

Completiuon of these items is necessary to allow an understanding of DATA resource capacity and usage which should enable resource scheduling.

The aimed for solution

PTC creates and manages for each long procedure a Redmine project container where project implementation workflows (of FTE tasks) specified in DATA cost-estimates are placed. As the Redmine container belongs to PTC it automatically satisfies the PTC interface requirement.

PTC uses the ERD and CRD short procedure Redmine project containers to perform work with the implementation projects. PTC does not own the container, but the owners must comply with the PTC interface requirements.

PEPs work with PTC to ensure knowledge equality and efficient project scheduling.

PTC tooling aims at satisfying PTC work actions and reducing PEP management load by automating repetitive and error prone operations.

PTC project scheduling should be visible, which may require additional Web tooling if it cannot be provided by Redmine directly.