d03.01 - change management methodology (adjusted for the … · 2018. 3. 27. · the proposed...

D03.01 - Change management methodology (adjusted for the Sharing and Reuse Framework

for IT Solutions) and established change management process

Action 2016.31 Sharing and re-use phase 4

2 / 19

Disclaimer

This report was prepared for the ISA² programme by PwC EU Services.

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 report, 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.

3 / 19

TABLE OF CONTENTS

1 INTRODUCTION ...............................................................................................................................5

1.1 Objective of the document ....................................................................................................................5

1.2 Scope ......................................................................................................................................................6

1.3 Structure of this document ....................................................................................................................6

2 GOVERNANCE MECHANISM ............................................................................................................7

2.1 Governance structure ............................................................................................................................7

2.2 Public announcement ............................................................................................................................8

2.3 Issue tracker and transparency ..............................................................................................................8

2.4 Types of changes ....................................................................................................................................8

2.5 Decision mechanism ..............................................................................................................................8

2.6 Release cycle ..........................................................................................................................................9

3 CHANGE MANAGEMENT PROCESSES ............................................................................................. 10

3.1 Request handling .................................................................................................................................10

3.2 Request resolution ...............................................................................................................................11

3.3 Request resolution approval ................................................................................................................15

3.4 Release preparation and endorsement ...............................................................................................16

3.5 Release publication ..............................................................................................................................17

REFERENCES ............................................................................................................................................ 19

OVERVIEW OF TABLES

Table 1: Steps of request handling process ...................................................................................................11

Table 2: Steps of request resolution process for editorial changes...............................................................12

Table 3: Steps of request resolution process for changes on supporting instruments .................................13

Table 4: Steps of request resolution process for major changes on generic recommendations, detailed recommendations and recommended measures for central bodies ..................................................15

Table 5: Steps of request resolution approval process .................................................................................16

Table 6: Steps of release preparation and endorsement process .................................................................17

Table 7: Steps of release publication process ................................................................................................18

OVERVIEW OF FIGURES

Figure 1 Change management process .........................................................................................................10

Figure 2: Request handling ............................................................................................................................10

Figure 3: Request resolution - editorial changes ...........................................................................................12

Figure 4: Request resolution - changes on the supporting instruments .......................................................13

Figure 5: Request resolution - major changes on generic recommendations, detailed recommendations and recommended measures for central bodies .................................................................................14

Figure 6: Request resolution approval...........................................................................................................15

Figure 7: Release preparation and endorsement ..........................................................................................16

Figure 8: Release publication .........................................................................................................................17

4 / 19

5 / 19

1 INTRODUCTION

The Sharing and Reuse Action1 of the ISA2 Programme2 of the European Commission, aims at supporting and enabling public administrations to share and reuse IT solutions in order to provide electronic services to citizens. Some public administrations and governments across the EU already promote the sharing and reuse of IT solutions when deploying digital service infrastructures, by adopting new business models and promoting the use of open source software for IT services. However, there is still room for improvement, as a number of organisational, legal, technical, and communication barriers still need to be tackled.

To help EU, national, regional and local public administrations overcome these barriers, the Sharing and Reuse Action has developed the Sharing and Reuse Framework for IT Solutions (SRF) [1]. The SRF addresses EU, national, regional and local public administrations that aim at reducing costs, increasing their efficiency and fostering interoperability by reusing, sharing or jointly developing IT solutions that meet common requirements.

Public administrations should follow SRF recommendations throughout the lifecycle of each IT solution: from its inception, through design, development and maintenance. Decision-makers, legal professionals, IT architects, IT developers and communication experts should take the SRF into account when:

reusing existing software;

sharing software after it has been developed;

reusing an existing IT service;

sharing the provision of an IT service; and

collaborating on the development of a piece of software or an IT service.

Furthermore, it is important that central bodies3 support this process by creating a climate of innovation in their administrations, encouraging staff to take an active role in the process and promoting the use of information and communication technologies.

1.1 Objective of the document

This document formalises how changes to the SRF are managed and how new releases are published.

The proposed change management methodology has the following characteristics:

Openness: In order for public administrations to rely on the SRF, the openness of change

management is key. Openness is also a key assessment criterion in the Common Assessment

Method of Standards and Specifications [2]. Openness means that any stakeholder can submit

Requests For Change (RFCs) and that the analysis and decisions taken are logged transparently.

An open change management process improves the quality of the SRF.

Controlled change: Public administrations that are following the SRF recommendations

throughout the lifecycle of an IT solution must not experience a negative impact as a result of

unexpected changes to the SRF. A release schedule must be established, allowing changes to

take place in a stepwise and traceable manner. New releases should also follow a consistent

versioning approach.

1 Sharing and Reuse of IT solutions: https://joinup.ec.europa.eu/node/152008 2 ISA2 Programme: https://ec.europa.eu/isa2/home_en 3 Central bodies are entities with a coordination, governance or legislative/policymaking role, such as central or regional governments and agencies, or EU institutions

https://joinup.ec.europa.eu/node/152008

https://ec.europa.eu/isa2/home_en

6 / 19

The change management methodology relies on generic change and release management processes in ITILv3 [3] and the “Description of a change management release and publication process for structural metadata specifications developed by the ISA Programme” [4] developed under the ISA Action on Promoting Semantic Interoperability amongst the European Union Member States (SEMIC)4.

1.2 Scope

This change management methodology takes into account the different parts of the SRF (i.e.: recommendations, supporting instruments and recommended measures), and adjusts the SEMIC methodology to the needs of Sharing and Reuse Framework.

The methodology covers the management of the updates to the SRF, following an approach that would allow the European Commission to manage them in a suitable, transparent, and sustainable way.

1.3 Structure of this document

The remainder of this report is organised as follows:

Section 2 outlines the governance structure and mechanism proposed for the management of the SRF. It also includes a description of the types of changes, proposes a release cycle for these types of changes, and outlines the process phases.

Section 3 describes the processes for managing Requests for Change, for preparing releases of the SRF, and for the publication of releases.

Finally, works cited throughout the document are included in the References section.

4 SEMIC: https://ec.europa.eu/isa2/actions/improving-semantic-interoperability-european-egovernment-systems_en

https://ec.europa.eu/isa2/actions/improving-semantic-interoperability-european-egovernment-systems_en

7 / 19

2 GOVERNANCE MECHANISM

The governance mechanism is designed to implement the open change management process in order to achieve a controlled change of the SRF.

2.1 Governance structure

The following governance structure is proposed:

Steering Committee (SC) – SRF Coordination Group. The SC consists of members of the

European Commission’s services and members of other European Institutions. In addition,

representatives of Member States (MSs) will be involved. The SC performs the following

functions:

a. It ensures continuity and consistency on the basis of the general directions set by the

European Commission

b. It is aware of activities and progress

c. It endorses the new releases of the SRF

Governance Committee (GC) – SRF Programme Management. The GC is the maintenance and

supervisory organisation for the SRF. It mainly consists of members of the ISA2 Programme but

can include members of other European Commission services. In the context of this role, the GC

performs the following functions:

a. It organises the activities for the maintenance of the SRF, safeguards the proper

execution of the maintenance process and funds the Operational Team

b. It identifies the need for a revision of the SRF, based on Requests For Change (RFCs)

received from stakeholders and initial analysis of the RFCs by the Operational Team

c. It approves new releases of the SRF for endorsement by the SC and the Operational

Team (OT)

Operational Team (OT) – contractors. This is composed of a single team that carries out the

day-to-day work. In the case of the SRF, the OT usually consists of contractors, under the

guidance and responsibility of the GC. The OT performs the following functions:

a. It monitors the RFCs from stakeholders submitted on Joinup5

b. It advises the GC on the nature of the change requests, e.g. whether the change is clear and relevant for the SRF, and whether it is an editorial change, a change on supporting instruments or a major change(see section 2.4)

c. It documents the resolution of the RFCs in a new release of the SRF, either by applying an editorial change or by incorporating changes agreed and approved by the GC and the SC

d. It updates the online repository of suggested supporting instruments provided by the stakeholders

5 Joinup: https://joinup.ec.europa.eu/

https://joinup.ec.europa.eu/

8 / 19

Stakeholders – public administrations, businesses and actors involved in providing IT

solutions. Stakeholders might be implementers of the SRF or simply individuals that are

interested in its application. Stakeholders might provide their insights and recommendations on

the text and form of the SRF via Joinup in the form of issues.

2.2 Public announcement

The governance mechanism requires that all potential stakeholders be informed about the possibilities to participate, e.g. as contributors or reviewers and about the processes that govern the management of the SRF. To that end, announcements of the start of a release cycle (see section 2.6) are posted on Joinup.

2.3 Issue tracker and transparency

Information about all processed events, including RFCs and resolutions, will be made public on the Joinup platform through the issue tracker function.

The issue tracker will manage and maintain lists of all the submitted RFCs and their status in one centralised working place, providing transparency by holding all the vital information for the RFCs and the reporters (stakeholders).

2.4 Types of changes

There are three types of changes considered in the change management process:

Editorial changes

An editorial change is a correction of an error/mistake in the SRF or an additional clarification of an aspect that may not have been well specified.

Changes on the supporting instruments

A change on the supporting instruments occurs when stakeholders introduce new supporting instruments. This change comprises 2 steps:

o The online documentation of supporting instruments recommended by the stakeholders. o The official inclusion of new supporting instruments in the next release of the SRF.

Major changes on generic recommendations, detailed recommendations, and recommended measures for central bodies

This type of change occurs when fundamental aspects of the SRF are affected. For example, if a new generic recommendation or a recommended measure for central bodies is added or deleted and if existing recommendations are updated (e.g. changes to the content or the underlying message of a recommendation). Such changes typically affect the SRF as a whole and therefore a specific roll-out plan is needed to ensure that all the necessary changes are applied to the SRF.

2.5 Decision mechanism

For editorial changes, the Governance Committee (GC) takes a decision based on a proposal from the OT.

For the changes that involve more stakeholders and the Steering Committee (SC), the decision process relies on two pillars:

9 / 19

Approval: Based on majority vote, the updated SRF is approved by the SC on proposal from the

GC.

Appeal: In the specific case when a stakeholder considers that the process has not been

followed properly, or that the stakeholder’s opinions have not been taken into account properly,

the stakeholder has the possibility to lodge a formal appeal to the SC. The SC reviews its decision

taking into account the overall strategy and objectives of the ISA2 Programme.

2.6 Release cycle

The three types of changes are processed in the same release cycle, starting with the processing of the RFCs and ending with the publication of a revised version (new release) of the SRF.

Requests can be submitted by public administrations, businesses, and the wider community continuously via Joinup. As soon as RFCs are received, they are classified by the OT as one of the three types of changes.

Once per year, the submitted RFCs for all the three types of changes are collected and processed as described in section 3.2. RFCs submitted from that moment on will only be considered during the following release cycle in order to ensure careful evaluation and implementation of all requests.

The OT implements editorial changes processed along with the changes on supporting instruments and the major changes.

The resulting release is numbered (X+1).0, e.g. 2.0, 3.0 etc.

If, at the scheduled time for a particular release, only editorial requests have been submitted, a new release of the SRF can still be taken into account. If, for example, no requests for supporting instruments and major changes have been received, there may still be a release with editorial changes with release number (X+1).0, e.g. 2.0, 3.0 etc. If, in the period leading up to the planned date for a new release, no changes have been received, a new release will not take place.

Every new release cycle will be announced on Joinup.

10 / 19

3 CHANGE MANAGEMENT PROCESSES

The process of managing the SRF includes the processes for managing changes to the SRF, managing the preparation of releases of the SRF, and managing the process of publication of a new release of the SRF.

The following sections provide an outline of those processes, including the goal of the process, preconditions, actors, workflow, and triggers. The change management process comprises five phases:

Figure 1 Change management process

For the second phase (i.e. request resolution), different processes are followed for every type of change. The third phase (i.e. request resolution approval) is only applicable for the changes on the supporting instruments and the major changes. The rest of the phases follow a common process for managing the changes.

3.1 Request handling

This section describes the handling of Requests for Change (RFCs).

The Operational Team (OT) gathers the requests submitted by the stakeholders via Joinup.

The OT evaluates the requests, and accepts or discards them.

The OT classifies the accepted requests by type of change (see Section 2.4).

Requests that have been accepted and classified will be resolved according to the requests resolution process outlined in section 3.2.

Figure 2: Request handling

Request handling

Request resolution

Request resolution approval

Release preparation

and endorsement

Release publication

Receive RFCs

Operational Team

Evaluate RFCs

Operational Team

Classify RFCs

Operational Team

11 / 19

The flow consists of the following steps, executed by their corresponding actor:

Table 1: Steps of request handling process

Step Description Actor

1 Receive RFCs Operational Team

2 Evaluate RFCs Operational Team

3 Classify RFCs Operational Team

Precondition: RFCs for aspects of the SRF that is published on Joinup and is publicly available.

Trigger: Stakeholder submission of RFC.

Goal: To ensure that change requests are processed in an open yet controlled fashion.

Primary Actors:

Stakeholders: Submit RFCs.

Operational Team: Evaluates and classifies the RFCs.

Workflow:

In step 1, receive RFCs, the OT acknowledges receipt of all the requests submitted by the

stakeholders on Joinup.

In step 2, evaluate RFCs, the OT performs an eligibility check, verifying whether the RFC

describes clearly what the requirement is and which change is requested.

In step 3, classify RFCs, the OT classifies the accepted RFCs based on the type of change.

3.2 Request resolution

This section describes the resolution of RFCs for each type of change. The resolution process differs depending on the type of change. Therefore, the process is presented for each type of change.

Based on the classification of the RFCs performed at the request handling phase (see Section 3.1), the request resolution phase starts with the definition of the proposed resolution and the further enrichment of the information already provided by the submitter(s). The request resolution phase ends with the reflection of the changes and updating of the SRF. The SRF is updated and maintained offline until the scheduling of a new release, which also involves the new release’s preparation, endorsement, and publication.

3.2.1 Editorial changes

For such a change, the OT defines changes for each RFC. The OT notifies the Governance Committee (GC) and applies all the necessary updates on the SRF. Finally, the OT informs the submitters about the acceptance of their RFC and its future inclusion in the SRF.

12 / 19

The following streamlined process is applied to editorial changes.

Figure 3: Request resolution - editorial changes


Table 2: Steps of request resolution process for editorial changes


1 Define the change Operational Team

2 Notify the Governance Committee Operational Team

3 Apply change and update the SRF Operational Team

4 Notify submitters Operational Team

Trigger: RFCs that specify an editorial issue are submitted, accepted, and scheduled for release.

Goal: To ensure that small editorial changes are captured and performed once per year (release cycle).

Primary Actors:

Operational Team: Makes all the editorial changes to the SRF and notifies the submitters of the

RFCs.

Workflow:

In step 1, define the change, the OT provides a solution for every RFC.

In step 2, notify the Governance Committee, the OT notifies the GC about the editorial changes

that will be included in the SRF.

In step 3, apply change and update the SRF, the OT incorporates the editorial change in the SRF.

In step 4, notify submitters, the OT notifies all the submitters about the final decision regarding

the inclusion or rejection of their RFC in the next release of the SRF.

Define the changeOperational Team

Notify the Governance Committee

Operational Team

Apply change and update the SRF

Operational Team

Notify submittersOperational Team

13 / 19

3.2.2 Changes on the supporting instruments

For this type of changes, the OT elaborates the supporting instruments received and publishes the ones approved by the GC on Joinup. The approved supporting instruments are added to an existing list of supporting instruments on a webpage maintained under the Sharing and Reuse of IT solutions community. In addition, when evaluating the supporting instruments to be published on Joinup, the GC accepts or rejects the inclusion of the published supporting instruments in the SRF. After the review of supporting instruments by the GC and their publication on Joinup, the OT notifies the submitters about the final decision regarding the inclusion or rejection of their supporting instrument. Finally, the OT advises the Steering Committee (SC) on the inclusion of the supporting instruments in the SRF. As soon as the OT advises the SC, the process continues with the request resolution approval (see Section 3.3).

The following process is applied to changes to the supporting instruments (i.e. when a stakeholder recommends a new supporting instrument).

Figure 4: Request resolution - changes on the supporting instruments


Table 3: Steps of request resolution process for changes on supporting instruments


1 Elaborate the supporting instrument Operational Team

2 Review the supporting instrument (accept/reject) Governance Committee

3 Apply necessary changes on Joinup Operational Team

4 Notify submitters Operational Team

5 Advise on the inclusion of the supporting instrument in the SRF Operational Team

Trigger: RFCs that specify changes on the supporting instruments are submitted and accepted.

Goal: To ensure that all the changes on Joinup regarding supporting instruments are made transparently and that the GC approves or rejects their inclusion in the SRF.

Elaborate the supporting instrument

Operational Team

Review the supporting instrument

(accept/reject)

Governance Committee

Apply necessary changes on Joinup

Operational Team

Notify submitters

Operational Team

Advise on the inclusion of the supporting

instrument in the SRF

Operational Team

14 / 19

Primary Actors:

Governance Committee: Supervises the whole process and approves the publication of changes

on Joinup and their inclusion in the new release of the SRF.

Operational Team: Notifies submitters and advises the SC on the inclusion of supporting

instruments in the SRF.

Workflow:

In step 1, elaborate the supporting instrument, the OT elaborates each of the supporting

instruments for which an RFC was submitted by the stakeholders. The OT describes the

supporting instrument in order to fit the quality criteria for inclusion in the SRF.

In step 2, review the supporting instrument (accept/reject), OT notifies the GC about the

received supporting instrument that is suggested to be published on Joinup. The GC reviews the

supporting instrument and accepts or rejects its publication on Joinup and inclusion in the new

release of the SRF.

In step 3, apply necessary changes on Joinup, the OT updates the supporting instrument that is

accepted by the GC in the list of supporting instruments on Joinup.

In step 4, notify submitters, once every six months, the OT notifies all the submitters about the

final decision regarding the publication or rejection of their supporting instruments on Joinup.

In step 5, advice on the inclusion of the supporting instrument in the SRF, OT advises the SC for

the review and approval of the supporting instrument to be included in the new release of the

SRF.

3.2.3 Major changes on generic recommendations, detailed recommendations, and recommended measures for central bodies

For this type of changes, the OT elaborates the major change, and the GC reviews the RFCs. As soon as the GC reviews the RFCs, the process continues with the request resolution review (see Section 3.3).

The following process is applied to major changes on generic recommendations, detailed recommendations, and recommended measures for central bodies.

Figure 5: Request resolution - major changes on generic recommendations, detailed recommendations, and recommended measures for central bodies

Elaborate on the major change

Operational Team

Review the resolution for the major changes

(accept/reject)


15 / 19


Table 4: Steps of request resolution process for major changes on generic recommendations, detailed recommendations, and recommended measures for central bodies


1 Elaborate on the major change Operational Team

2 Review the resolution for the major changes (accept/reject) Governance Committee

Trigger: RFCs that specify major changes on generic recommendations, detailed recommendations, and recommended measures for central bodies have been submitted and accepted.

Goal: To ensure that all the changes are reviewed and approved by the GC.

Primary Actors:

Governance Committee: Supervises the whole process and approves the inclusion of the

changes in the SRF.

Operational Team: Elaborates on the major changes.

Workflow:

In step 1, elaborate on the major change, the OT elaborates on the proposed solution for the

RFC provided by the stakeholders.

In step 2, review the resolution for the major changes, the GC reviews the proposed solution

and approves it.

3.3 Request resolution approval

This section describes the approval of the resolution for the following types of change:

Changes to the supporting instruments

Major changes on generic recommendations, detailed recommendations, and recommended measures for central bodies

The editorial changes do not follow the request resolution approval phase, as for editorial changes there is only a notification to be sent to the Governance Committee (GC).

The Steering Committee (SC) reviews the resolution of the RFCs regarding the supporting instruments and the major changes. After the feedback from the SC, the Operational Team (OT) applies all the changes and updates to the SRF. As soon as the OT applies all the necessary changes, the process continues with the release preparation and endorsement (see Section 3.4).

A diagram of the request resolution approval is included below.

Figure 6: Request resolution approval

Review the resolution (accept/reject)

Steering Committee

Apply necessary changes and update the SRF

Operational Team

16 / 19


Table 5: Steps of request resolution approval process


1 Review the resolution(accept/reject) Steering Committee

2 Apply necessary changes and update the SRF Operational Team

Trigger: Resolution for RFCs to the supporting instruments (see Section 3.2.2) and major changes (see Section 3.2.3) are submitted to the SC.

Goal: To ensure that all the changes (i.e. regarding the supporting instruments and the major changes) are made transparently and provide the opportunity to the SC to comment on a new proposed release.

Primary Actors:

Steering Committee: Reviews the resolution and provides approval for the next release of SRF.

Operational Team: Applies all necessary changes to the SRF.

Workflow:

In step 1, review the resolution (accept/reject), the SC accepts or rejects the inclusion of the

supporting instruments and the major changes in the new release of the SRF.

In step 2, apply necessary changes and update the SRF, the OT incorporates the updates in the

SRF.

3.4 Release preparation and endorsement

This section describes the release preparation process. In this phase, the OT reviews the SRF and notifies the Governance Committee (GC) that the new release is ready for publication. In addition, the OT requests endorsement by the Steering Committee (SC), and the SC discusses the new release and endorses its publication.

After the verification of the release preparation and verification, the process continues with the release publication. A diagram of the release preparation process is included below.

Figure 7: Release preparation and endorsement

Review the SRF

Operational Team

Review the SRF (accept/reject)


Prepare the new release

Operational Team

Endorse the new release

(accept/reject)

Steering Committee

17 / 19


Table 6: Steps of release preparation and endorsement process


1 Review the SRF Operational Team

2 Review the SRF (accept/reject) Governance Committee

3 Prepare release Operational Team

4 Endorse the new release (accept/reject) Steering Committee

Trigger: Revised SRF is available for release.

Goal: To ensure that all relevant documents and supporting information are finalised in order for the SC to be able to endorse the release.

Primary Actors:

Governance Committee: Checks the proposed revision against strategic objectives and policies

and accepts or rejects the revision.

Operational Team: Reviews the SRF and prepares the new release.

Steering Committee: Decides on the endorsement of the new release.

Workflow:

In step 1, review the SRF, the OT reviews the SRF before handing it over to the GC for

acceptance.

In step 2, review the SRF (accept/reject), the GC decides to accept or reject the revision.

In step 3, prepare release, the OT prepares all documentation necessary for endorsement and

publication.

In step 4, endorse the new release (accept/reject), the OT submits the new release to the SC

with a request to endorse the new release. The SC accept or rejects the new release.

3.5 Release publication

This section describes the publication process depicted in the figure below.

Following endorsement by the Steering Committee (SC), the Operational Team (OT) publishes the new release and notifies the stakeholders and the wider public of its availability.

Figure 8: Release publication

Public release

Operational team

Notify stakeholders and community

Operational Team

18 / 19


Table 7: Steps of release publication process


1 Publish release Operational Team

2 Notify stakeholders and community Operational Team

Trigger: Endorsement of the new release.

Goal: To make sure that the updates are documented and published properly.

Primary Actors

Operational Team that publishes the new release of the SRF.

Secondary Actors

Stakeholders that are notified of the release.

Workflow:

In step 1, publish release, the OT makes the release available for access by the stakeholders and

the wider community.

In step 2, notify stakeholders, the OT issues a message to the stakeholders and to the wider

community with the link to the new release of the SRF.

19 / 19

REFERENCES

[1] I. P. European Commission, “The S&R Framework,” [Online]. Available:

https://joinup.ec.europa.eu/page/sharing-and-reuse-it-solutions-framework.

[2] IDABC Programme, “CAMSS Assessment Criteria,” 4 June 2012. [Online]. Available:

https://joinup.ec.europa.eu/community/camss/og_page/camss-wiki. [Accessed 27 November 2014].

[3] The Stationary Office (TSO), “The Official Introduction to the ITIL Service Lifecycle,” 2007.

[4] I. P. European Commission, “Description of a change management release,” [Online]. Available:

https://joinup.ec.europa.eu/sites/default/files/description_of_a_change_management_release_and_publicati

on_process_for_structural_metadata_specifications_developed_by_the_isa_progr.pdf.

[5] European Commission, ISA Programme, “D4.2 Methodology and tools for Metadata Governance and

Management for EU institutions and Member States,” 2014. [Online].

[6] European Commission, ISA Programme, “Process and Methodology for Core Vocabularies,” 2011. [Online].

Available: https://joinup.ec.europa.eu/node/43160.

[7] Publications Office, “Proposal for metadata governance on interinstitutional level,” 2011. [Online]. Available:

http://publications.europa.eu/mdr/resource/core-metadata/IMMC_reu3_adoption_anx3.pdf_A-2011-

764293.pdf.

d03.01 - change management methodology (adjusted for the … · 2018. 3. 27. · the proposed...

Documents