Transition team following the conference 23rd May 2011

1. Transition teamfollowing theconference 23rd May 2011 Proposal for the future Forum/GME (or production level)-V2 Inserting « business » or « domain » expertise JPH (May 26rd 2011)

2. 1) Diagram for the future Forum Steering plenary To be defined Management or Steering PDA 1 coordination structure/team PDA 2 coordination Structure/team PDA n coordination structure/team Production 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 Resources Roster of experts Proposed by HoDs on demand per project 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

3. 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.

4. PDA 2 coordination Structure/team Project A Project manager and team Domain group a Proposes projects Nominates project manager Reporting/steering within PDA Nominates experts for transverse projects Abides to rules (e.g. ODP) Steering plenary To be defined Management or Steering PDA 1 coordination structure/team PDA n coordination structure/team Domain group g Production Project P governance/programme production/cooperation/coordination

5. 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).

6. 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.