Transition team
following the conference 23rd May 2011
Proposal for the future Forum/GME
(or production level)-V2
Inserting « business » or « domain »
expertise
JPH (May 26rd 2011)
1) Diagram for the future Forum
Steering plenary
To be defined
Management
or Steering
Production
PDA 1 coordination
structure/team
PDA 2 coordination
Structure/team
Domain group g
Project P
Project A
Project manager
and team
Resources
PDA n coordination
structure/team
Roster of experts
Proposed by HoDs on
demand per project
Domain group a
Proposes projects
Nominates project manager
Reporting/steering within PDA
Nominates experts for transverse projects
Abides to rules (e.g. ODP)
Experts designated by HoDs
Assigned to groups on a
permanent basis
Note: the above diagram is a tentative to represent how the principles (Steering by PDAs and Project
based management) might apply
2) Explanatory notes
• Project teams and Domain groups are proposed on a same level in
the organisation
• Leadership of projects
• Remit and working out of deliverables
• In principle assigned to one PDA
• Additionnally, Domain groups:
• Can propose simple projects (involving few domains)
– If agreed, listed in the CEFACT Program
– Nominate project managers and take reponsibilty of work, including coordination
with other domain groups
• Nominate experts for transverse projects as required
• Will lead standing tasks (maintenance, market watch, support to new
experts) and insure the continuity of on-going work
• As a whole all Domain groups may be seen a « structured » part of
the roster of experts
• Diagram should be detailed for some « support » PDAs (e.g.
Harmonisation, Methodolgy, Operations)
• On May 26th, this point was a sort of a suggestion from JPH side. If the TT
feels that these PDAs are defined, JPH has nothing more to suggest.
Steering plenary
To be defined
Management
or Steering
PDA n coordination
structure/team
PDA 2 coordination
Structure/team
Domain group g
Project P
Domain group a
Proposes projects
Nominates project manager
Reporting/steering within PDA
Nominates experts for transverse projects
Abides to rules (e.g. ODP)
Project A
Project manager
and team
production/cooperation/coordination
governance/programme
Production
PDA 1 coordination
structure/team
3) Issues of conformance with the guidelines
•
Respect the cross domain/ transverse approach:
• The proposal is made assuming that:
» Each Domain group is related to a PDA
» When projects are proposed by domain groups they are subject to reviewed as all
others; this review should result in identifying the links with other projects Whoever is
the project manage, this should be included in his mandate/mission.
» All project managers report to the PDA to which the project is assigned
•
Respect ODP
• As far as I could see some draft diagrams describing the future ODP process:
» There is no difference proposed between project groups
» As regards the tasks delegated to a domain group (maintenance, watch, external
coordination, etc), the Domain group could be assimilated to a project group for the
purpose of steering as requested by the VC or PDA correspondent.
•
Base the structure on a project approach
• This may be a key and blocking issue pending upon how we handle it.:
» Some consider that the structure must be based only on project teams. One issue is
then to know and define what is really a roster of experts.
» The proposal assumes that a standing structure (and the “fidelity” of experts contributing
in it) needs a more classical presentation enabling experts and sponsors to identify how
and for what purpose they can join the structure.
» Experience has proven that the difficulties in the Forum where not in the activity of sector
TBGs
•
Limit the number of layers
• This issue was relevant as regards the obvious lack of capacity of the FMG to really
manage and arbitrate. The fact that the VCs will take charge of this steering is solving
this issue provided we find the proper persons to take the VC jobs
• I am not sure this is really relevant within the structure which should be based on
practical experience of technical management. But, if required, one may consider the
proposal in the “ODP” point here above.
•
Respect the PDA-based management of the CEFACT program :
• PDA management should mainly aim at governance of the whole program
• The structure of the production level should serve the needs of work organisation and
coordination (illustrated in diagram).
4) Helping to solve some issues
•
Continuity of activities
• One advantage of the proposal is to facilitate the continuation of present activities when
the change over to the future structure will be decided
•
Readability of the structure
• In comparison with other standardisation bodies (official or not) who keep the technical
structure and develop new ways of management and of coordination as needed;
•
Experts and sponsors acceptance
• This should be seen as one of the reasons at the origin of the “letter” sent recently. At
least these experts are lost and may not maintain confidence in CEFACT.
•
Involving proactively actors and contributors
• Several actors were considering that a participation in CEFACT and TBG was part of a
common effort where they could also push some of their ideas or priorities. (this is the
way standardisation can work based on voluntary involvement)
• As described till now, the future organisation is silent and does not offer any opportunity
(also one reason of the “letter”.) The proposal includes the possibility for domain groups
to originate project proposal and have more than a passive role.
•
Keeping flexibility for future evolutions:
• The proposal enables to “disconnect” the strict correspondence between the PDA
description and the forum structure.
• There is no reason why these two levels should evolve in the future in the same
conditions and calendar.
•
Taking account of technical work constraint
• See several points above
•
Easing the task of VCs or PDAs correspondents
• Some of the tasks (a majority if one looks at the present projects in the program) can
be delegated to Domain groups
• One issue is still open as it will rather not be simple for one person to steer and
coordinate many projects, which require a minimum of detailed knowledge.