Project Charter Proposal PWC EU Services Version 1.0

Document Metadata

Date

2017-08-03

Status

Accepted

Version

1.0

Authors

Makx Dekkers - AMI Consult Emidio Stani - PwC EU Services Florian Barthélemy - PwC EU Services

Reviewed by

Nikolaos Loutas - PwC EU Services Natalie Muric - Publications Office of the EU

Approved by

Natalie Muric - Publications Office of the EU

This report was prepared for the Publications Office of the European Union by: PwC EU Service

Disclaimer

The views expressed in this report are purely those of the authors and may not, in any circumstances, be interpreted as stating an official position of the European Commission. The European Commission does not guarantee the accuracy of the information included in this study, nor does it accept any responsibility for any use thereof. Reference herein to any specific products, specifications, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favouring by the European Commission. All care has been taken by the author to ensure that s/he has obtained, where necessary, permission to use any parts of manuscripts including illustrations, maps, and graphs, on which intellectual property rights already exist from the titular holder(s) of such rights or from her/his or their legal representative.

Note: this Project Charter is an adaptation of the Project Charter template of PM² V2.5.

1. CONSIDERATIONS ON THE BUSINESS CASE

Public procurement represents around 20% of GDP in Europe. This large buying volume offers a high economic potential to enhance efficiency of European procurement. The EU is investing significantly in the digitalisation of the public procurement process (referred to as e-procurement). This goes beyond simply moving to electronic tools; it rethinks various pre-award and post-award phases with the aim of making them simpler for businesses to participate in and for the public sector to manage. It also allows for the integration of data-based approaches at various stages of the procurement process.

Directive 2014/24/EU on public procurement, Directive 2014/25/EU on procurement by entities operating in the water, energy, transport and postal services sectors, and Directive 2014/23/EU on the award of concession contracts, establish rules on the procedures for procurement by contracting authorities with respect to public contracts, design contests and concessions, requiring contracting authorities in the EU to publish notices above certain thresholds.

Directive 2014/55/EU on electronic invoicing in public procurement defines the requirement for a European standard for electronic invoices, while the Commission Implementing Regulation (EU) 2015/19866 specifies standard forms for the publication of notices in the Official Journal of the European Union. Article 6 of the Regulation states that either the eNotices online application, or the TED eSender systems should be used to electronically transmit notices to the Publications Office of the European Union. From a different angle, the implementation of the revised PSI directive across the EU calls for open, unobstructed access to public data to improve transparency and to boost innovation via the reuse of public data.

Procurement data has been identified as data with a high-reuse potential. Therefore, making this data available in machine-readable formats following the data as a service paradigm, is required in order to maximise its reuse. Given the increasing importance of data standards for e-procurement, a number of initiatives driven by the public sector, industry, and academia have been initiated in recent years. Some have grown organically, while others are the result of standardisation work. The vocabularies and the semantics that they are introducing, the phases of public procurement that they are covering, and the technologies that they are using, however, all differ. These differences hamper data interoperability and thus its reuse by them or by the wider public. This creates the need for a common data standard for publishing public procurement data, hence allowing data from different sources to be easily accessed and linked, and consequently reused.

In this context, the Publications Office of the EU aims to develop an e-procurement ontology. The objective of the e-procurement ontology is to act as the common standard on the conceptual level, based on consensus of the main stakeholders, and designed to encompass the major requirements of the e-procurement process in conformance with the Directives and Regulation mentioned above.

2. PROJECT DESCRIPTION

2.1. Scope

2.1.1. Includes ("IN" Scope)

The project will develop the e-procurement ontology in a collaborative effort by the main stakeholders with the overall objective to overcome the fragmentation that hinders interoperability among e-procurement systems. The result of this work will be a specification showing the conceptual model and its representation in OWL, and the deployment of the ontology and related code lists and classifications on the metadata registry.

The ontology will support the whole of the e-procurement process, from e-notification until and including e-payment as depicted in Figure 1.

2.1.2. Excludes ("OUT of" Scope)

The project described here does not include:

the practical implementation of systems that implement the ontology beyond the deployment of the ontology, related code lists, and classifications on the metadata registry.
the implementation of the change management and maintenance of the ontology after its publication (change management and maintenance will however be taken into consideration and described).
activities to create implementation guidelines; however, future implementations will be taken into consideration when developing the ontology.

2.1.3. Scope Statement

The ultimate objective of the e-procurement ontology is to put forth a commonly agreed OWL ontology that will conceptualise, formally encode, and make available in an open, structured, and machine-readable format, data about public procurement covering end-to-end procurement i.e., from notification, through tendering to awarding, ordering, invoicing and payment.

The aim of the project is to produce the final ontology within twelve months including a public review of at least two months. Comments received in the public review period will be resolved and integrated in the deliverable, which will then be published.

The development of the e-procurement ontology will take place in an open working group, as recommended in the Report on policy support for e-procurement.

2.2. Success Criteria

Commitment on the part of the working group members to participate actively in the work towards finding common ground with an objective of implementing the ontology after its publication.
Consensus in the Working Group on the conceptual model.
Expression of the conceptual model as an ontology in OWL.
Publication of the conceptual model and ontology.

2.3. Stakeholder and User Needs

In Figure 2, the various stakeholders are depicted.

The main stakeholders of the e-procurement ontology are the contracting authorities who request goods and services, and the economic operators who deliver these. The stakeholders in these two categories provide the data for the elements in the ontology, while other stakeholders use the data provided to meet their specific needs e.g., statistics.

These needs are related to three categories of use cases:

Transparency and monitoring: to enable verification that public procurement is conducted according to the rules set by the Directives and Regulation.
Innovation & value added services: to allow the emergence of new applications and services on the basis of the availability of procurement data.
Interconnection of public procurement systems: to support increased interoperability across procurement systems. The ontology needs to be able to satisfy the needs of various stakeholder categories as shown in Table 1.

Table 1. Stakeholder areas of interest and types of use cases
Stakeholder category	Type of use case
Contracting authorities	Interconnection of public procurement systems Transparency and monitoring Innovation & value added services
Economic operators	Transparency and monitoring Innovation & value added services
Procurement intermediaries and aggregators	Interconnection of public procurement systems Innovation & value added services
Academia and researchers	Innovation & value added services Transparency and monitoring
Media and (data) journalists	Transparency and monitoring
Auditors and regulators	Transparency and monitoring
Members of parliaments	Transparency and monitoring
Standardisation organisations	Interconnection of public procurement systems
NGOs	Transparency and monitoring
Citizens	Transparency and monitoring

2.4. Deliverables

The following deliverables are foreseen as results of the work.

Table 2. Deliverables
Deliverable Name	Deliverable Description
e-Procurement Conceptual Model	Conceptual model of the e-procurement ontology specifying the relevant entities, attributes and relationships. This deliverable will be developed in an incremental way, with several drafts being created and published for discussion in the working group. These drafts will be designed as Working Draft <no>. See also section 4.1.
Specification of the conceptual model	The specification will provide the definition of the concepts and relationships and eventual synonyms
e-Procurement Ontology	OWL expression of the ontology. The OWL expression will be included as an annex in D01, but also published separately at a persistent URI under the Commission’s URI Policy.

2.5. Assumptions

The following assumptions have been taken into account:

The e-procurement ontology takes into account the data standards and structures described in the document Data Structures and Standards used at the Publications Office, Version: 1.0.0 of 19 December 2016 so as to ensure seamless testing of the ontology in the environment of the Publications Office.
The e-procurement ontology is expressed in OWL2 in conformance with the conditions listed in section 2.1 of the W3C Recommendation OWL 2 Web Ontology Language Conformance (Second Edition)
The e-procurement ontology is made available on-line under the ISA Open Metadata Licence v1.111
The Working Group consists of experts in the following areas:
- e-procurement, taking into consideration the perspective of the stakeholder they represent;
- data modelling and ontology design; and
- OWL and the wider area of Linked Open Data technologies.
The members of the Working Group share an objective of reaching consensus by finding common ground across potentially different perspectives.

2.6. Risks

A number of risks have been identified. Table 3 lists these risks with an indication of the impact, the likelihood and a proposed mitigation strategy.

Table 3. Risks
	Risk	Impact	Likelihood
Mitigation strategy	No consensus can be reached	High	Medium
Strong oversight and gentle steering by Working Group chair	Insufficient participation by Working Group members	Medium	Medium
Commitment by a core set of stakeholders	Lack of relevant skills in the Working Group	High	Low
Taking care that the right experts are invited	Competition of conflicting approaches, e.g. XML-based standards	Medium	Medium
Establishing liaisons with other initiatives, explaining that the e-procurement ontology is intended to define a semantic view that should encompass other approaches.	Insufficient awareness in stakeholder community	Medium	Low

3. COST, TIMING AND RESOURCES

3.1. Cost

The project cost in financial terms is not estimated, however the human resources required is estimated.

Table 4 contains estimates of the time required for the different roles of the involved experts. These estimates are based on previous experiences with the development of other interoperability specification in the ISA/ISA2 programmes.

Table 4. Resource estimates (person days)
ID	Role	Time requirement
R1	Working Group Chair	6 days per month
R2	Editor	1-2 editors full time
R3	Working Group Member	0,5-2 days per month, depending on the level of activity that the member wishes to invest

3.2. Timing and Milestones

The overall time plan for the work is shown in Table 5. The table includes the calendar months that would result from a possible start of the project right after the summer holiday of 2017.

Table 5. Overall time plan
ID	Milestone Description	Target Delivery Date
M1	Start of the project	Month 0 - September 2017
M2	Publication of the draft deliverable for public review	Month 9 - June 2018
M3	Publication of final deliverable	Month 11 - September 2018

Given this overall time plan, a meeting plan for the Working Group and delivery of intermediate draft could look as shown in Table 6. The actual plan should be decided in the first meeting of the Working Group in Month 0. Depending on the size of the working group, the number of entities in the ontology and the occurrence of contentious issues, the plan may be revised to include more or fewer meetings and drafts, as time passes.

The mention of "meetings" in Table 6 does not imply that face-to-face meeting must be held in all cases. For most meetings, teleconference facilities will be sufficient. However, it is advisable to plan for some face-to-face meetings at crucial points in time, for example at the start of the work (E1/M1) and before issuing the draft for public review (E16/M2).

Table 6 includes the proposed activities to be carried out by the Working Group. The work preparing the items listed with the meetings two, three and four will be undertaken by the Editors between meetings.

Table 6. Provisional meeting and publication plan
ID	Event	Event date	Indicative activities
E1	First WG meeting	Month 0 - September	2017 (M1) Prioritisation of use cases Grouping them to be treated in consecutive meetings Provision of updated conceptual model and its specification Discussion on the conceptual model and its specifications
E2	First draft of conceptual model and its specification corresponding to the use cases concerned for the next meeting and incorporating the results from the iscussions of the previous meeting	Month 1 - October 2017	Prepared by editors based on discussions from the previous meeting and all corresponding input for the following meeting
E3	Second WG meeting	Month 2 - November 2017	Discussion/consensus on E2 document
E4	Second draft of conceptual model and its specification corresponding to the use cases concerned for the next meeting and incorporating the results from the discussions of the previous meeting.	Month 2 - November 2017	Prepared by editors based on discussions from the previous meeting and all corresponding input for the following meeting.
E5	Third WG meeting	Month 4 - January 2018	Discussion/consensus on E4 document
E6	Third draft of conceptual model and its specification corresponding to the use cases concerned for the next meeting and incorporating the results from the discussions of the previous meeting.	Month 4 - January 2018	Prepared by the editors based on discussions from the previous meeting and all corresponding input for the following meeting.
E7	Fourth WG meeting	Month 5 - February 2018	Discussion/consensus on E6 document
E8	Fourth draft of conceptual model and its specification corresponding to the use cases concerned for the next meeting and incorporating the results from the discussions of the previous meeting.	Month 5 - February 2018	Prepared by editors based on discussions from the previous meeting and all corresponding input for the following meeting.
E9	Fifth WG meeting	Month 6 - March 2018	Discussion/consensus on E8 document
E10	Fifth draft of conceptual model and its specification corresponding to the use cases concerned for the next meeting and incorporating the results from the discussions of the previous meeting.	Month 6 - March 2018	Prepared by editors based on discussions from the previous meeting and all corresponding input for the following meeting.
E11	Sixth WG meeting	Month 7 - April 2018	Discussion/consensus on E10 document
E12	Sixth draft of the conceptual model and its specification corresponding to all the discussions within the working group.	Month 7 - April 2018	Prepared by the editors based on discussions from the previous meeting and all corresponding input for the following meeting.
E13	Seventh WG meeting	Month 8 - May 2018	Discussion/consensus on E12 document
E14	Finalisation of conceptual model and its specification and the ontology in OWL	Month 9 - June 2018	Prepared by editors based on discussions from the previous meeting and all corresponding input for the following meeting.
E15	Eighth WG meeting	Month 9 - June 2018	Discussion/consensus on E14 document
E16	Publication of ontology for public review	Month 10 - July 2018 (M2)
E17	Proposed resolution of issues raised in public review	Month 12 - September 2018 (M3)	Prepared by editors
E18	Ninth WG meeting	Month 12 - September 2018	Discussion/consensus on E17

In Table 6, one of the activities for the first meeting is to set priorities for the use cases that were decided in the inception phase. A list of the use cases is included in Annex I.

For each of those use cases, the Editor will further develop the use case according to the methodology presented in the inception phase. In the meetings two to six, the use cases will be presented by the Editor, and the working group will come to a consensus to any changes that need to be made to the use case.

For the development of the conceptual data model Editors will derive the concepts from the use cases as described in document D02.01: “Specification of the process and methodology to develop the eProcurement ontology with initial draft of the eProcurement Ontology for 3 use case”. The Editor will document this alongside the use cases and the concepts roughly one month ahead of each working group meeting. The documentation will also include the definition of concepts, identification of subclasses or subtypes, relevant properties and relationships.

The working group will review the documentation mentioned above ahead of the meetings. Working Group members may at any time propose additional concepts to be added to the conceptual model. Such proposals will be discussed by the Working Group; the proposed concept will be added if the Working Group decides that the proposed concept is relevant and necessary.

3.3. Planned Resources

The technical tools available for this project are listed in Table 7.

Table 7. Technical infrastructure
ID	Resource Requirement	Description
RR1	Ontology development tool	Protégé, http://protege.stanford.edu/ or VocBench 3
RR2	Model visualisation tool	TBD
RR3	Conference call facility	WebEx, https://ecwacs.webex.com/ecwacs/
RR4	Mailing list	eprocurementontology@joinup.ec.europa.eu
RR5	Issue tracker	GitHub https://github.com/eprocurementontology
RR6	Publication channel	https://joinup.ec.europa.eu/asset/eprocurementontology/

4. APPROACH

The project will be based on the ISA Process and Methodology for the development of semantic agreements12 as described in section 2 of the Report on policy support for e-procurement.

4.1. Process

An important part of the process as described in the ISA Process and Methodology for the development of semantic agreements, and in particular the establishment of the Working Group, has already taken place in the preparatory phase. Therefore, the process to be followed by the Working Group in this Project consists of the following six elements:

Table 8. Process overview
Process Reaching consensus
Publish Working Drafts (Chair(s) and Editor(s)) Review Working Drafts (Working Group) Publish last call Working Draft (Chair(s) and Editor(s)) Review last call Working Draft (the Public) Gather evidence of acceptance (Chair(s) and Editor(s)) Submit for endorsement (The Publications Office)

4.2. Methodology

The methodology takes into account the step-by-step approach agreed in the preliminary phase. Building on the initial draft published at the end of the preliminary phase, the methodology involves the following five steps:

Table 9. Methodology overview
Methodology Developing the ontology
Follow the step-by-step development process from requirements to OWL ontology (Editor(s), Working Group) which involves: Step 1. Define use cases Step 2. Define requirements from the use cases Step 3. Develop a conceptual data model Step 4. Consider reusing existing ontologies Step 5. Define and implement an OWL ontology

Drafts of the specification are published on Joinup; working group members provide comments on GitHub, referencing the relevant section in the document.

4.3. Change Management

The change management of the e-procurement ontology is defined on the basis of the approach described in the document “Description of a change management release and publication process for structural metadata specifications developed by the ISA Programme”.

The main characteristics are:

Openness: In order for public administrations to rely on specifications, the openness of the change management is a key – openness is also a key assessment criterion in the Common Assessment Method of Standards and Specifications (CAMSS)14. Openness means that requests for changes can be submitted by any stakeholder and that the analysis and decisions taken are logged in a transparent manner. An open change management process improves the quality of the specification.
Controlled change: Public administrations that use structural metadata or implement specifications must not be negatively impacted by unexpected changes to these specifications. A release schedule must be established, allowing changes to take place in a stepwise and traceable manner. New releases should also be versioned consistently. The approach includes work flows for several types of changes: editorial changes, minor semantic changes and major semantic changes.

As part of the approach, a version numbering scheme and time table is defined:

Editorial changes and bug fixes Once per year, the submitted requests for this type of change are collected and processed. The resulting release is numbered X.Y.(Z+1), e.g. 1.0.1, 1.0.2 etc.
Minor semantic changes Once per year, the submitted requests for this type of change are collected and processed. At this time, also editorial changes and bug fixes are processed. The resulting release is numbered X.(Y+1).0, e.g. 1.1.0, 1.2.0 etc.
Major semantic changes Every second year, the submitted requests for this type of change are collected and processed. At that time, also editorial changes and bug fixes as well as minor semantic changes are processed. The resulting release is numbered (X+1).0.0, e.g. 2.0.0, 3.0.0 etc.

5. GOVERNANCE AND STAKEHOLDERS

5.1. Structure

The diagram in Figure 3 depicts the governance structure of the project. The roles and relationships are further detailed in section 5.2.

Figure 3: The governance structure of the project

Governance structure

5.2. Roles and Responsibilities

The roles and responsibilities of each of the groups depicted in Figure 3 are outlined in Table 10.

Table 10. Roles and responsibilities
Who	What	When
The Publications Office	Owns the project, provides oversight and supplies WG chair; endorses the final result at the end of the project	Continuously
Working Group	Provides input, reviews and validate the ontology in synergy with the active developmental propositions of editors	Continuously
Community	Participates in public review	At publication of draft for public review

6. Annex I: USE CASES TO BE DEVELOPED BY THE WORKING GROUP

e-tendering process: https://github.com/eprocurementontology/eprocurementontology/issues/8
Analysing e-procurement procedures, https://github.com/eprocurementontology/eprocurementontology/issues/11
Increase cross-domain interoperability in terms of (financial) exclusion grounds among Member States, https://github.com/eprocurementontology/eprocurementontology/issues/13
Public understandability (Use case to be derived from interviews with transparency watchdogs and similar stakeholders)
Monitor the money flow, https://github.com/eprocurementontology/eprocurementontology/issues/9
Detect fraud and compliance with procurement criteria, https://github.com/eprocurementontology/eprocurementontology/wiki/Add-a-new-use-case
Alerting services, https://github.com/eprocurementontology/eprocurementontology/issues/10
Introduce automated classification systems in public procurement (not a real use case but a set of ideas for classification systems to be gathered)
Businesses need to participate in procurement, https://github.com/eprocurementontology/eprocurementontology/issues/15
Buyers need to buy things, which means following the e-procurement phases, https://github.com/eprocurementontology/eprocurementontology/issues/15. This use case includes (and therefore could be breakdown into other use cases at a lower granular level):
- Creating new information (e.g. description of the procurement, giving points for award criteria).
- Reusing information from different databases and domains, such as
business registries (to reduce administrative burden and ensure consistency of information); and
tax, social payments, etc. systems (to verify that potential contractors meet selection criteria).
- (Sending information to other systems to ensure transparency etc. requirements are met, e.g. contract registers).
Other public entities are directly involved in the e-procurement phases, https://github.com/eprocurementontology/eprocurementontology/issues/15. This use case includes (and therefore could be breakdown into other use cases at a lower granular level):
- Creating new information (e.g. review authority freezing the procurement process, rejecting a complaint, or awarding damages).
- Exchanging data between e-procurement systems and systems used by auditors and review bodies, so that it is easier for them to check the validity of the procurement process.
- Regulators (ministries, review bodies, etc.), citizens, journalists, NGOs, academics, buyers, etc. use the data to answer policy-relevant questions, https://github.com/eprocurementontology/eprocurementontology/issues/15. This use case includes (and therefore could be breakdown into other use cases at a lower granular level):
- Accessing information created by the use cases above.
- Accessing information created specifically to be used only in this use case.
- Connecting this information with other information, in particular:
budget systems (to answer questions linked to following the money). (Note: e-invoicing is not included in this section, because it falls within the scope of "e-procurement phases described in the Project Charter", i.e. the first use cases in this list.); and
contract registers (to allow answering more sophisticated questions, e.g. linked to the full text of contracts).
Analyse the success rate of the procurement process and the reasons for failure, as well as estimate the costs associated, https://github.com/eprocurementontology/eprocurementontology/issues/16
Long term analysis about the evolution of procurement activities in the EU Institutions, https://github.com/eprocurementontology/eprocurementontology/issues/16
Providing information for Contract Registries, https://github.com/eprocurementontology/eprocurementontology/issues/18
Enable the publication of notices as linked open data to enable the exploitation of the corresponding data through the semantic web in ways yet to be envisaged, https://github.com/eprocurementontology/eprocurementontology/issues/18

Any comments on the documentation?

Click here to let us know