Pha Cro Annex Interoperabilidad

DG TAXUD/B1 CONTRACT : DI 02411-00 SA106

Technical Assistance Ref: 08664-401/TI.01.01/document.doc

Interoperability Implementation Strategy - Suggested approach for the Croatian Tax Administration

INTEROPERABILITYIMPLEMENTATION STRATEGY

SUGGESTED APPROACH FOR THECROATIAN TAX ADMINISTRATION

FEB 200508664-401/TI.01.01/document.doc 23




TABLE OF CONTENT

1 INTRODUCTION 26

1.1 Background 26

1.2 Abbreviations 27

1.3 Contacts 28

1.4 National Strategy and Planning Documents 292 PROGRAMME SCOPE 30

2.1 Overview 30

2.2 Assumptions & Warnings 30

2.2.1 Assumptions 30

2.2.2 Warnings 31

2.2.3 High Level Objective – Suggested Approach 31

2.3 Overall Scope 32

2.3.1 Interfaces with DG TAXUD – Current situation 32

2.3.2 Interfaces with other systems 333 ORGANISATION 34

3.1 Suggested Overall Strategy 34

3.2 Management Structure 35

3.2.1 Introduction 35

3.2.2 Overall organisational structure 35

3.2.3 Project Generic Structure 37

3.2.4 Project Structure for CCN/CSI 39

3.2.5 Project structure for VIES 40

3.2.6 Project structure for VAT on e-Services (VES) 41

3.3 Roles and Responsibilities 42

3.3.1 Steering Committee 42

3.3.2 Interoperability Programme Director 43

3.3.3 Project Owner 43

3.3.4 Quality Manager 44

3.3.5 IT Manager 44

3.3.6 Contract Manager 45

3.3.7 Project Manager(s) 45

3.3.8 Responsibilities of the IT Project Team 46

3.3.9 Responsibilities of the Business Project Team 47

3.4 Project Phases 47

3.5 Project Deliverables 48

3.5.1 Pre-Study Phase 48

3.5.2 Tender Process Phase 49

3.5.3 System Specification Phase 50

3.5.4 Design Phase 53

3.5.5 Build and Test Phase 53

3.5.6 Running In and Maintenance Phase 54

08664-401/TI.01.01/document.doc 24




3.5.7 Main Project Deliverables and Responsibilities 55

3.6 Communication and Reporting Structure 56

3.6.1 Progress Meetings 56

3.6.2 Reports 574 INTEROPERABILITY IMPLEMENTATION PLAN 58

4.1 Dates Assumptions 58

4.1.1 Target Date (see section 2.2.1) 58

4.1.2 DG TAXUD Requirements 58

4.1.3 Decisions 58

4.1.4 Test Platform Availability 58

4.2 Time Schedule 59

4.2.1 CCN/CSI 59

4.2.2 VIES & VES 59

4.3 Ressources Estimation 60

4.3.1 CCN/CSI 61

4.3.2 VIES & VES 625 ANNEX 64

5.1 Global Planning 64

08664-401/TI.01.01/document.doc 25




1 INTRODUCTION

1.1 BACKGROUND

The overall objective of this suggested approach to developing an Interoperability Implementation Strategy (IIS) is to describe the main characteristics of the Interoperability Programme, suggest a framework and specify the requirements to achieve successful project implementations.

The specific objectives of this document are to:

Propose the scope and objectives of the Interoperability Programme;

Suggest a description of the organisation of the projects and a definition of the roles and responsibilities of the participants;

Estimate timescales and resource requirements;

Suggest/provide examples of strategies that could be developed;

Suggest ideas to assist the Tax Administration to improve its existing strategies in relation to Interoperability.

It must be clear that:

It is not DG TAXUD’s responsibility to produce the Interoperability Implementation Plan for a Candidate Country. This document is provided for information/example only (best practices, based on project management principles and techniques) and is issued to assist the Croatian Tax Administration in defining its own projects and activities but it is up to Croatia to decide on its own approach.

Preparations for EU Accession are entirely under the responsibility of the Candidate Country.

Remarks

The term “Interconnectivity” might be seen as focusing on the IT interfaces and IT requirements only while the term “Interoperability” has been used in this document to stress the following points:

The business aspects, which are sometimes essential (for example for VIES: CLO, …), have been taken into account (legislation and procedural changes, training, trade awareness, …);

The projects described are not dedicated only to the IT interfaces but also to the national business and operational requirements.

However, only the activities directly linked to the Interconnectivity Projects are described but other activities should be also envisaged:

Tax Audit System;

Audit of Traders’ computers;

…

08664-401/TI.01.01/document.doc 26




1.2 ABBREVIATIONS

Abbreviation Full description

AFIS Anti- Fraud Information System

AP Application Platform

API Application Programming Interface

CC Candidate Country

CCD Croatian Customs Directorate

CCN / CSI Common Communications Network / Common Systems Interface

CCN / TC Common Communications Network / Technical Centre

CFCU Central Financing and Contract Unit (ex PMU: Phare Management Unit)

CLO Central Liaison Office (for VAT matters)

DBA Database Administrator

DG TAXUD European Commission Directorate General responsible for Taxation and Customs Union

DDS Data Dissemination SystemSee: http://www.europa.eu.int/comm/taxation_customs/databases/database.htm

DTI Direct Trader Input

EC European Commission

EDI Electronic Data Interchange

EU European Union

FITS Fiscalis Information Technology Services

IOC Initial Operation CapabilityTerm used by DG TAXUD/A3 when one of its system is ready for operation, waiting for the first Member States readiness.

IIS Interoperability Implementation Strategy

IT Information Technology

ITT Invitation To Tender

MEI Ministry of European Integration

MoE Ministry of Economy / Trade

MoF Ministry of Finance

MS Member State

MSA Member State Administration

NETP Non Established Taxable Person (for VES)

PAA Pre-Accession Adviser (either from a Twinning or directly contracted)

PID Project Initiation Document

PM Project Manager

PPF Project Preparation FacilityEU Funds available for the preparation of Project Fiches or Terms of Reference

PQP Project Quality Plan

08664-401/TI.01.01/document.doc 27

http://www.europa.eu.int/comm/taxation_customs/databases/database.htm




QA Quality Assurance

RTA Resident Technical Adviser

SCAC Standing Committee on Administrative Co-operation (for VAT)

SCIT IT sub-committee of the SCAC

SQP Specific Quality Plan

TEMPO DG TAXUD Electronic Management of Projects Online

ToD Turnover Data (for VIES)

ToR Terms of Reference

VES VAT on e-Services

VIES VAT Information Exchange System

1.3 CONTACTS

For any information or comments on the present document please contact:Patrice Pillet, DG TAXUD Unit B1 (Phone +32 2 299 19 93, email [email protected]) orMichael Doering, DG TAXUD Unit B1 (Phone + 32 2 295 38 59, email [email protected]).

08664-401/TI.01.01/document.doc 28

mailto:[email protected]

mailto:[email protected]




1.4 NATIONAL STRATEGY AND PLANNING DOCUMENTS

A number of strategy and planning documents should already exist in the Croatian Tax Administration (light grey on the diagram) e.g.

Business and IT Strategies; Business Plan; Business Change Management Plan; CARDS or Phare Project Fiches.

The following diagram describes the relationship between the existing documents, the national Interoperability Implementation Strategy (IIS) and the following Project Initiation Documents (PID), Terms of Reference (ToR) & Project Quality Plans (PQP) for the Interoperability Projects.

08664-401/TI.01.01/document.doc 29

Business Strategy

Business Plan

Business Change Management Plan

Croatian IIS

CARDS or Phare Project Fiches

PID for VIES PID for VESPID for x

PQP for x PQP for VIES PQP for VES

IT StrategyIT Methodology &

Standards

ITT & ToR for VIES ITT & ToR for VES

EU Accession Strategy

Users Requirements Pre-Studies

ITT & ToR for x




2 PROGRAMME SCOPE

2.1 OVERVIEW

As a result of the first Interoperability Mission in Croatia, carried out by DG TAXUD B1 in October 2004, it became apparent that there was little knowledge within the Croatian Tax Administration as to the requirements for EU Interoperability and the volume of work to be undertaken to achieve Interoperability may have been underestimated.

This document has been produced in order to assist Croatia to achieve Interoperability in time for the accession to the EU. It is intended as a generic Interoperability Implementation Strategy (IIS) to be adapted by the Croatian Tax Administration to develop its own National Interoperability Implementation Strategy based on the current in-country situation and decisions. Following the development / adaptation and acceptance of the IIS by the national administration, separate projects should be established and project teams set up to implement the projects.

2.2 ASSUMPTIONS & WARNINGS

2.2.1 Assumptions

Certain assumptions have been made in the preparation of this document:

The average IT Interoperability project duration in the new EU Member States was four years. Therefore, this document considers 01/01/09 as target/working date for deploying the existing EC Taxation IT Interconnectivity systems in Croatia. This does not anticipate any target date for Croatia's accession to the EU, which has to be defined in the accession negotiations yet to be started.

The Tax Administration is fully committed to accession to the EU and has included Interoperability in its Business Plan and Business Change Management Plan.

The required financial and human resources will be made available by the senior managers of the Tax Administration, including the provision of full time personnel for the project teams.

The Implementation Plan has been drafted upon the anticipation that the Croatian Tax Administration will take the maximum advantage of the “supposed to be available” and “supposed to be requested” CARDS and Phare pre-accession funds. Should these funds not be requested or available, or should Croatia consider a (partial) financing of the listed EC co-financed activities from national funds, the suggested plan should be redrafted.In this context it needs to be highlighted that due to the strict CARDS, Phare and PRAG rules, a practical implementation of activities under CARDS 2004 is unlikely to start before September 2005. In comparison to the new EU Member States and the EU Candidate Countries 2007, it needs to be declared that significant financial envelopes for pre-accession funds in the area of Croatian Taxation IT Interoperability are lately available. Activities could start earlier if national resources or additional resources under bilateral agreements between Croatia and EU Member States (funds and/or staff) are available.

TEMPO is used as the basis for the Project Management Methodology. However, this methodology has been developed as an ideal reference for the management of IT projects being implemented within the DG TAXUD organisation itself (although this is not always strictly applied). Therefore, it is suggested that Croatia may use it as the basis for their national project management but will need to adapt it and/or extract sections to best suit their own requirements. It is, of course, Croatia prerogative to project manage their national projects as they wish.It must also be clear that Croatia will not receive any DG TAXUD support related to this methodology.

08664-401/TI.01.01/document.doc 30




2.2.2 Warnings

Whilst DG TAXUD is continually updating the systems and introducing new technology (CCN Mail 2, VIES 2, …), Croatia should maintain a close relationship with DG TAXUD to ensure that they are developing implementation plans based on the most recent system development of DG TAXUD. Participation in the Fiscalis 2007 Programme is strongly recommended (when open for Croatia).

Until the signature of the EU accession treaty, Croatia will not necessarily be invited to all working (and certainly not to policy) groups for all the systems and should maintain bilateral and multi-lateral links with Member States to ensure that they keep up to date with other national developments. In this context, Twinnings with EU Member States are priceless.

CARDS and Phare EU co-financing can only be regarded as “Additional Funds” to decrease the pressure on the national budget, by which the Candidate Country has to ensure full alignment to the “acquis communautaire” prior to EU accession.

The human and financial resources estimated in section 4.3 are extremely dependent on the actual in-country situation and the systems development path adopted. They must be adapted during the pre-study phase of each project.

2.2.3 High Level Objective – Suggested Approach

The high level objective of the Interoperability Programme can be defined as,

“The development and implementation of national systems required by the Croatian Tax Administration to connect with the EU IT systems to enable the exchange of information between the EC and EU Member States immediately upon accession to the EU.”

The suggested approach to achieve this overall objective is for Croatia to develop its own national IIS which will be relevant to the current situation and from which individual projects will be established, project teams created and project plans developed to implement the relevant systems in time for accession to the EU.

This generic IIS will assist the Croatian Tax Administration to:

Identify the projects that remain to be established;

Identify the resource requirements for each project;

Identify the funding requirements for each project;

Identify the timescales for each project;

Assist in preparing project plans for the individual projects;

Identify which current national projects should be modified to satisfy the Interoperability requirements.

08664-401/TI.01.01/document.doc 31




2.3 OVERALL SCOPE

2.3.1 Interfaces with DG TAXUD – Current situation

DG TAXUD has identified several systems that require Interoperability by the date of accession:

CCN/CSI: this gateway is mandatory for the communications between the DG TAXUD IT systems and their Member States counterparts. DG TAXUD and DG ENLARG together with the Phare Committee have so far agreed to provide and pay for the CCN/CSI gateways.For Croatia, the CCN/CSI gateway (installation and operational costs for the Community domain) will be funded by the Customs 2007 Programme.As a single (operational) gateway will be installed in Croatia, the definition of the national responsibilities is essential. The back-up gateway will be installed in Brussels.

Savings Tax System: The "savings directive" (Directive 2003/48/EC), which will enter into force on 01/07/2005 (under Council decision 2004/587/EC), has created the need for an exchange of information between Member States. This exchange should take place at least once a year. The way this exchange of information will take place in practice (through bilateral exchanges or via a Community systems like CCN-Mail) is however still undefined at this stage.

VES: The VAT on e-Services system is quite simple and independent from other Tax systems. Its functionality should be re-examined by the MS before 01/07/2006 together with its possible (likely) prolongation.

VIES: DG TAXUD recommends focusing on VIES Phase 5 (suppression of the dedicated VIES gateway and direct access to the CSI API).In all cases, an important effort is foreseen for the development of the VIES national system and even more for the related business activities (setup of the CLO, …).The VIES 2 feasibility study is expected to be submitted to the SCIT sub-committee by February 2005. Currently, there are no IT development or implementation plans for VIES 2; these will be finalised dependant on SCAC mandate (expected Q3 2005) and decision as to which aspects to proceed with and when (priority) i.e. B2B One-stop-shop, VAT on services, quality of VIES data or exchange of forms.

08664-401/TI.01.01/document.doc 32




2.3.2 Interfaces with other systems

While developing the final systems, due consideration should be given to interfacing with a number of external but related systems. These may be considered under the following headings:

Trade interfaces

When appropriate, the following trade interfaces should be developed:

Direct Trader Input (DTI);

Electronic banking;

Public Internet web sites.

Other National Systems

Tax Administration currently provides or receives information from a number of different government agencies/institutions. The intention should be, wherever feasible, to create interfaces with these bodies. Such bodies could include:

Ministry of Finance;

Customs Administration;

National Statistical Institute;

Ministry of Economics / Ministry of Trade and Industry;

Ministry of Internal Affairs;

Ministry of Transport;

National Bank;

And others.

Other EU Systems

AFIS (OLAF);

…

08664-401/TI.01.01/document.doc 33




3 ORGANISATION

3.1 SUGGESTED OVERALL STRATEGY

It is important for the success of the Interoperability programme not to underestimate the scope of work required to interoperate with the EU IT systems involved upon accession to the EU. New Member States are expected to exchange information with the EC and other Member States on day one of accession. Due to the ambitious plans of the Croatian Government to join the EU as soon as possible, a relatively short time period might only be available to develop and fully deploy the various IT Interoperability systems. Therefore, it is imperative that a proper Interoperability Programme and project management structure is established from the outset and that adequate full time human resources and financial resources are made available to enable implementation of each of the projects. The suggested overall strategy is to establish full time project teams, who will be responsible for the implementation of the projects within the Interoperability Programme.

It is suggested to establish a Steering Committee for all Interoperability projects i.e. CCN/CSI (including CCN-Mail 2), VIES & VES.

The position of the Project Owner should be established for each project and will be responsible for project co-ordination as well as for communication with the Programme Director. He should come from a User Department (usually Head of Department or Deputy Head of Department).

It is suggested to establish a Project Team for each project who will be deployed on a full time basis for the duration of the project implementation. Each project team should consist of two experienced Project Managers i.e. one IT Project Manager and one Business Project Manager who will lead two “sub” teams, one IT team and one Business Team consisting of IT and business/functional experts for the given business areas.

It is important to the success of the individual project that Project Managers and Team Members are employed full time by the project for the duration of the project implementation period. The scope of work required for each project is significant and the utilisation of internal experience is essential. Past experience has shown in many administrations that projects fail to meet timescales and deadlines if Project Managers and Project Team Members have to divide their time between project tasks and normal day-to-day duties.

08664-401/TI.01.01/document.doc 34




3.2 MANAGEMENT STRUCTURE

3.2.1 Introduction

This section of the Interoperability Implementation Strategy describes the suggested structure to be implemented to manage the planned development activities. This structure may well change during later stages of the programme, particularly as development work decreases and the systems move into a maintenance phase. It must be adapted by Croatia to meet the national situation and requirements.

3.2.2 Overall organisational structure

The diagram below depicts the overall organisational structure for the Interoperability Programme for the Tax Administration.

08664-401/TI.01.01/document.doc 35

Interoperability Programme Director

Tax Steering Committee (Chaired by DG of Tax Administration)

Ministry of Finance Central Financing and Contract Unit (CFCU)

CCN/CSIProject Owner

VIESProject Owner

VIESBusiness Team

VESProject Owner

CCN/CSIIT Team

VIESIT Team

VESIT Team

VESBusiness Team

Minister of European Integration (MEI)




Remarks

The highlighted entities are external to the Tax Administration. It is an option, in order to gain experience, that the VIES IT Teams are managed by the external Contractors (integrated teams) and therefore these entities were highlighted as well (see sections Error: Reference source not found & 3.2.5).

Both Administrations should also be involved in the CCN/CSI Project.

08664-401/TI.01.01/document.doc 36




3.2.3 Project Generic Structure

The generic structure suggested hereafter must be adapted to the specificity of each project.

Diagram

Remarks

One-way arrows () are used for hierarchical links and two-way arrows () for communication channels; the external entities are highlighted and the dashed lines are optional;

The external bodies are banks, trade associations, other Ministries, ...

The “Roles and Responsibilities” are described in section 3.3;

The responsibility of the contract management may be attributed to a separate section (Contract Manager), to the Project Owner or to the Head of IT Department;

Another solution is to create a “Co-ordination Unit” (not represented on the above diagram but selected solution for the following project-specific diagrams) working directly to the Programme Director with the overall responsibility for the horizontal issues of the programme (Contract management, Quality management, Training, ...);

The Quality Manager and IT Manager roles can be assumed by a sole person or a Quality Manager can be externally contracted;

08664-401/TI.01.01/document.doc 37


Project Owner

IT Project Manager

Head of IT Dept.

IT

Project Teams

Business Project Team

Contractor’s Project Teams

Contractor’s Project Manager

Project Adviser or RTA

Quality Manager

IT Manager

DG TAXUD

Unit A3

DG TAXUD

Test Team

Contract Manager Adviser

External Bodies

DG TAXUD

Business Project Manager

Support Team




An external Project Adviser/consultant could be appointed to provide advice and recommend actions based on his previous experience or it could be the “Resident Technical Adviser” of a Twinning Project;

Multiple project teams could be defined for the different sub-projects: on a functional basis but also on an organisational basis (hardware, training, deployment, web site, Traders Interface, ...);

The IT Project Manager must liaise with the CCN/CSI Project Manager for the configuration of the CCN/CSI gateway (or the CSI developments);

A Project Quality Manager should be appointed either as a Project Manager Deputy or as a Contractor’s Project Manager Deputy (recommended).

08664-401/TI.01.01/document.doc 38




3.2.4 Project Structure for CCN/CSI

The CCN/CSI is a ready-made (except configuration), purely technical system and therefore this project will probably not be very demanding on resources.

Past experience suggests that CCN/CSI can be installed, tested and operated within a six-month period (assuming the funding arrangements are signed).

A CCN/CSI Project Manager should be appointed and should assume the overall responsibility, in close liaison with the Customs and Tax IT Departments, the individual Project Managers (configuration of the gateway, CSI programming, …) and DG TAXUD experts for the installation of CCN/CSI gateway (Unit A3 and CCN/TC).

Diagram

Remarks

The Project Owner can liaise with DG TAXUD Unit A3 for the administrative arrangements.

It is suggested here that the responsibility of the CCN/CSI Project could be sub-contracted to GZAOP or to the contractor responsible for the network administration. However, this decision relies totally on the national administrations.It may also be decided to include experts from both Customs and Tax Administrations within the GZAOP/Contractor CCN/CSI project.

In any case, the national responsibility for the administration of the CCN/CSI gateway must be defined before the installation.

Training courses on “How to programme the CCN/CSI gateway for the VIES application” are regularly organised by DG TAXUD.

08664-401/TI.01.01/document.doc 39

CCN/CSI Project Manager

GZAOP (?)Project Owner

CCN/CSIProject Team

Tax IT Manager

Customs IT Manager

DG TAXUDUnit A3

CCN/TC

ITMS, NCTS, ...

IT Project Managers

DG TAXUDUnit B1

DG ELARG

VIESIT Project Manager




3.2.5 Project structure for VIES

VIES is a high priority project that must partly be operational from day one of EU accession (the VAT Registration Data System) and therefore, it is essential that a VIES project team is established on a full time basis for the duration of the VIES implementation.

Diagram

Remarks

It is suggested that several IT experts (developers) from the Tax Administration work directly under the Contractor’s responsibility for the duration of the Project.

The Project Owner can also assume the role of the VAT Project Manager.

The VAT Project Manager (and/or the Project Owner) will liaise with the SCAC Committee.

The VIES IT Project Manager will liaise with the SCIT Sub-Committee and FITS.

The IT Project can be divided in two sub-projects:

VAT Registration Data System (operational from day one of EU accession); VAT Turnover Data System (operational 6 months after accession). Itself divided into:

Production Application (independent of the VIES interface specification);Access Application;Dissemination Application;Processing Application (independent of the VIES interface specification).

08664-401/TI.01.01/document.doc 40


VIESProject Owner

VIES ITProject Manager

Head of IT Dept.

Business Project Team

Sub-Project Teams

Contractor’s Project Manager

Project Adviser or RTA

IT Manager

DG TAXUDUnit A3

FITS

Co-ordination Unit

External Bodies

DG TAXUD Unit D1

VIES VAT Project Manager

SCAC Committee

SCIT Committee

IT Support Team




3.2.6 Project structure for VAT on e-Services (VES)

This system is not as operationally critical as VIES (although mandatory on day one of accession) and it can be implemented as a separate project or included within the scope of the VIES Project (which is the approach selected in the attached Implementation Plan).

The development time is not that big (3 to 6 months for one or two experts) and as it is quite independent, it can probably be bought from a current MS.

Also, the future of the system is unclear as it is considered for now as a “temporary solution” that should be re-evaluated by the MS in 2006.

08664-401/TI.01.01/document.doc 41




3.3 ROLES AND RESPONSIBILITIES

The following sections provide a description of the roles and responsibilities for each suggested position in the hierarchal structure of the Interoperability Implementation Programme. It is up to the Tax Administration as to which of these positions are to be established to manage the Interoperability Implementation Programme.

3.3.1 Steering Committee

A Steering Committee can be established in the Tax Administration by the Director General and will be chaired by him. The Chairman of the Steering Committee should determine its organisation, including the participants and working arrangements.

The members of the Steering Committee may consist of:

The Deputy Director(s);

The Heads of Directorates and Functional Departments;

The Programme Director;

The Head of the IT Department;

The Project Owner;

The Project Managers (Business and IT);

A representative of GZAOP;

A representative of the Contractor(s);

A representative of the Twinning Partner(s);

A representative of the MEI / CFCU;

A representative of the EU Delegation;

A representative of the Ministry of Finance.

There should be a nucleus of participating members. Others such as Contractor(s) representatives may be invited to the Steering Committee meetings as and when required (this could be on a regular basis or may suit the administration to be on an ad hoc basis).

Additionally, the chairman can invite supplementary participants (e.g. Regional Directors, Quality Manager, Project Adviser, other Ministries, ...) according to the agenda.

Depending on the programme intensity, it is suggested that the committee meets at least once every 3 months but may need to convene extraordinary meetings to address any specific issues that may affect the progress of any of the projects.

The role of the Interoperability Programme Steering Committee is to direct, promote, monitor and review the successful execution of the Interoperability Programme and the related projects. It is the body of authority to determine priorities and take major project decisions.

08664-401/TI.01.01/document.doc 42




This role includes the following responsibilities:

To approve the national Interoperability Implementation Strategy deciding priorities;

To agree and commit the overall resources for the projects;

To endorse the resources related to each phase of the plan and delegate the specific resources commitment to the appropriate level of management;

To direct the progress of the programme in compliance with its wide objectives and with respect to the Government Policy, EU Accession requirements, Administration Standards, etc;

To make decisions concerning the Programme priorities and key issues;

To promote the Programme objectives and achievements;

To agree the starting/completing of major phases of the projects;

To approve the main deliverables;

To approve and monitor the budgets and expenditure.

3.3.2 Interoperability Programme Director

It is suggested that the Programme Director be designated at the Deputy DG level. The role of the Programme Director is to ensure that the Interoperability Programme and the related projects are progressing coherently and in accordance with the Interoperability Implementation Strategy e.g. that project timescales will meet the expected date of EU accession.

The main functions of the Programme Director are:

To monitor the progress of each project in accordance with the Business Plans, Business Change Management Plans, EU Accession Strategy and national Interoperability Implementation Strategy;

To agree on any strategic change which may affect the progress of the Programme and submit for approval to the Steering Committee e.g. re-allocation of funds between projects, redeployment of resources between projects, resolving conflicts of interest between projects, review of priorities and submission to the Steering Committee for approval;

To manage the work of the Project Owners concerning Interoperability.

3.3.3 Project Owner

The Project Owner is responsible for setting the business objectives and priorities. He allocates user resources to the work. He approves all management milestone documents during the project and commissions the new service and its accompanying organisational and procedural changes.

The Project Owner is responsible for project co-ordination as well as for communication with the Programme Director. He should come from a User Department (usually Head of Department or Deputy Head of Department) and -

Have some affinity with the IT domain (willingness to understand the IT problems);

Be a good team worker and staff motivator with good communication and reporting skills (in other words “a Manager”).

08664-401/TI.01.01/document.doc 43




The main functions of the Project Owner are:

To supervise the production of the “User Requirements”;

To supervise the production of the Project Initiation Document (define the main project phases, determine the resource requirements related to each project phase, define the quality policy, the training policy, etc);

To appoint the Project Teams and define their functions;

To manage the work of the IT Project Manager and Business Project Manager;

To oversee liaison between the different sources of project financing;

To monitor plans and reporting activities;

To solve the issues at a level above the competence of the Project Managers and below that of the Programme Director;

To notify the Programme Director of important problems encountered and of solutions adopted to solve them.

3.3.4 Quality Manager

The Quality Manager has an involvement in all of the IT projects to conduct the tasks detailed below and should not be directly involved in any of the activities or tasks required to be completed to implement the projects. It is suggested that a full time Quality Manager could be deployed to ensure that theses activities are carried out for all IT contracts under the responsibility of the Administration (Co-ordination Unit managed by the Programme Director).

The Quality Manager will have the following responsibilities:

To monitor the PQP together with the Project Manager(s);

To arrange quality assurance of all major project deliverables;

To establish and monitor change request procedures;

To participate in acceptance/integration testing of the systems;

To participate in phase end reviews and walkthroughs;

To provide support to projects in the use of methodology and best working practices;

To recommend development standards and utilities.

3.3.5 IT Manager

His responsibilities are:

To co-ordinate the definition of IT development standards, and to ensure that products (hardware and software) are within the Administration standards;

To collect, review, justify and co-ordinate the budgets of the IT projects;

To ensure adherence to the IT standards and Quality standards of the Administration;

To liaise the IT Project Manager with the IT experts of the IT Department or from GZAOP (DBA, System Engineer, Network Engineer, Office Automation Specialist, etc);

To ensure coherence and consistency with the IT Strategy.

This role could be assumed by the Head of the IT Department or the Deputy.

08664-401/TI.01.01/document.doc 44




3.3.6 Contract Manager

The Contract Manager has an involvement in all of the projects to conduct the tasks detailed below but should not be directly involved in the activities or tasks required to be completed to implement the projects. It is suggested that a Contract Manager could be deployed (at least part time) to manage all contracts for the projects of the Administration (Co-ordination Unit managed by the Programme Director).

During all phases of the project the Contract Manager will be responsible:

To manage the contracts;

To review and monitor the suppliers plans and deliverables;

To ensure progress and identify delays / slippage in these plans;

To report any breach of contract to the Steering Committee via the Programme Director with recommendations such as imposition of penalty clauses, etc.

The Contract Manager may participate in the Steering Committee meetings as an observer.

3.3.7 Project Manager(s)

It is suggested that each Project Team is sub-divided into two teams i.e. an “IT team” and a “Business team”. Each sub-team should have a Project Manager whose prime responsibility is managing the team’s activities in accordance with project plans and the PQP.

3.3.7.1 IT Project Manager

The IT Project Manager is the official appointed by the Steering Committee or the Head of the IT Dept to manage and execute the IT activities of the project according to the User Requirements and priorities established by the Project Owner.

The IT Project Manager is responsible for the management and control of the IT activities of the project as well as for the communication between the Project Team members and the Contractor(s). The IT Project Manager reports directly to the Project Owner. He should be appointed full time for the duration of the project implementation. He should have at least a basic understanding of the business domain and be familiar with the “users’ language” in order to be able to suggest suitable solutions in accordance with the User Requirements.

The specific functions of the IT Project Manager include:

To implement the IT activities identified in the project plan (initially from the PID);

To monitor and audit the IT activities;

To manage and control the project IT requirements;

To monitor progress and take any necessary corrective actions;

To monitor the execution of the IT activities in the Project Quality Plan;

To co-ordinate and control the IT activities at the different phases and levels;

To define the tasks and responsibilities of the IT Project Team members and relations between them and the Business Project Team members;

To co-operate and co-ordinate with the external Contractor’s Project Manager;

To ensure overall consistency of all sub-projects;

To maintain a close working relationship with the Contract Manager and the Quality Manager;

To maintain a close working relationship with the Business Project Manager and the Business Team members;

To prepare reports as required by the Steering Committee and liaise with the Project Owner.

08664-401/TI.01.01/document.doc 45




3.3.7.2 Business Project Manager

The Business Project Manager is the official appointed by the Steering Committee or the Head of Section (e.g. Tariff section for ITMS) to manage and execute the business and functional activities of the project according to the project plans, PQP and the priorities established by the Project Owner.

He is responsible for the communication between the Project Business Team Members and the external Contractor when discussing User Requirements and functional specifications. He is also responsible for liaison with other key stakeholders e.g. other government departments including the legal department, traders, etc. He should be appointed full time for the duration of the project implementation. Ideally, he should have a basic understanding of the IT domain and be familiar with the “technical language” in order to be able to appreciate the technical issues when discussing user and functional requirements.

The specific functions of the Business Project Manager include:

To define the business and functional activities in the PID:

Needs for new or updated laws, organisational entities, procedures, resources, job descriptions, …);

The training plans (training courses, seminars, awareness sessions, brochures, …); Etc.

To manage and co-ordinate the implementation of the business and functional activities identified in the project plan (initially from the PID);

To monitor progress and take any necessary corrective actions;

To co-ordinate and control the business and functional activities at the different phases and levels;

To define the tasks and responsibilities of the Business Project Team Members and relations between them and the IT Project Team members;

To liaise with external stakeholders e.g. trade, MoF, other Government Departments, etc;

To ensure overall consistency of all sub-projects;

To maintain a close working relationship with the Contract Manager and the Quality Manager;

To maintain a close working relationship with the IT Project Manager and the IT Project Team members;

To prepare reports as required by the Steering Committee and liaise with the Project Owner.

3.3.8 Responsibilities of the IT Project Team

In general terms the IT Project Team, reporting directly to the IT Project Manager, and working closely with the Contractor, will be responsible for the following functions:

Define together with the Business Project Team the functional specification;

Define the Technical specification;

Define the system configuration;

Develop other systems change strategy;

Define the Testing Strategy;

Define the Data conversion plan;

Define the Technical training plan;

Etc.

08664-401/TI.01.01/document.doc 46




3.3.9 Responsibilities of the Business Project Team

In general terms the Business Project Team, reporting directly to the Business Project Manager, will be responsible for the following functions:

Develop User Requirements in co-operation with the IT Project Manager and in liaison with the Users community;

Conduct reviews of legislation, existing procedures and practice and instigate changes where necessary;

Develop an organisation change strategy where necessary;

For final and all intermediate versions of the system, to define, produce and carry out acceptance tests for compliance of the system with the Functional Specification, in accordance with the agreed Testing Strategy;

To develop and effect the user functional training programme;

To take part in the development and to implement trade operators training programmes where necessary;

To report activities and progress in accordance with the Project Quality Plan;

Participation in the development of system fall-back and recovery procedures;

Loading the initial reference data into the systems databases;

Controlling, amending and maintaining such data in the operational databases (including access rights management);

In co-operation with the Contractor to assist in the production of user manuals and documentation for the system;

Provision of central day to day technical support/helpdesk to the users through a network of regional and local support staff;

Participation in the development migration/cut-over strategy from the old to the new system stages.

The Business Project Team will consult with the in house experts working in the particular field where necessary. Section heads should ensure staff availability for consultation with the project teams.

3.4 PROJECT PHASES

A Project can be divided into several phases:

Pre-Study Phase;

Tender Process Phase (CARDS, Phare or National);

Start-up Phase;

System Specification Phase;

Design Phase;

Build and Test Phase;

Running in and maintenance Phase.

08664-401/TI.01.01/document.doc 47




3.5 PROJECT DELIVERABLES

Many more details on Project Deliverables can be found in the following TEMPO documents:

TMP-REF-PMR.doc (Project Management – Reference Manual);

TMP-GDL-PRE.doc (Pre-Study Phase);

TMP-GDL-TOR.doc (Terms of Reference);

TMP-GDL-PQP.doc (Project Quality Plan);

TMP-GDL-CLA-P001.doc (System Specification Phase);

TMP-GDL-CLA-P002.doc (Design Phase);

TMP-GDL-CLA-P003.doc (Build and Test Phase);

TMP-GDL-CLA-P004.doc (Running-in Phase).

However, as already mentioned, the TEMPO methodology is dedicated to DG TAXUD and has been simplified in this document to best suit the Croatian Administrations. It is suggested that each Administration will adapt this proposed approach to fit its own requirements.

3.5.1 Pre-Study Phase

The Pre-study phase places emphasis on defining the business problems to be addressed and defining possible high-level solutions, rather than focusing on a specific technical solution. Furthermore, the main goals of the Pre-Study are to establish the feasibility of the project and (if feasible) to create clear objectives, scope and constraints to be observed by the project team and business management in carrying out subsequent solution development.

Pre-Analysis

This phase investigates the problem area and the available current systems (in the MS or in other Countries) in order to discover ways in which opportunities can be realised. The functionality and the costs of existing systems are examined, so that these might be used as a comparison with the functionality and the costs of the proposed system determined later. The output elements are:

User requirements specification: it is suggested that the User Requirements consist of both a narrative statement and a user requirements model which gives a clear view of the improvements to be realised within the problem area irrespective of what solution will be selected;

Description of the existing solutions;

Costs analysis.

Pre-Study Report

A number of alternative solutions to meet the requirements are considered and evaluated in terms of:

Costs and benefits;

Operational, technical and economic feasibility;

Business risks.

Based upon evaluation summaries on all alternatives, and advised by the Project Owner, the Steering Committee chooses one solution for further study. System requirements are then analysed and modelled, and the corresponding system architecture defined. The Project Owner is then able to assess all system implications.

The activity is concluded by drawing up and presenting the Pre-Study Report, containing all information necessary to allow the Steering Committee to decide on continuing the project.

08664-401/TI.01.01/document.doc 48




The general structure of the Pre-study report is suggested as follows:

Scope and objectives;

System requirements:

Data Model; Process Model; Description of the interfaces; Operating features; ...

Hardware considerations;

Financial evaluation;

Proposed system’s justification;

Outline Project Plan.

Project Initiation Document (PID)

The overall objective of the PID is to define the framework and the main characteristics of the project and to specify the requirements to achieve successful project implementation.

The specific objectives of this document are:

Definition of the scope, objectives and phases of the project;

Detailed description of the project organisation and definition of the roles and responsibilities of the project participants;

Definition of project timescales and project resource requirements;

Definition of management and control procedures to be applied;

Definition of project strategies that need to be developed;

Description of the risk management and control procedures to be applied.

3.5.2 Tender Process Phase

DG TAXUD is aware that tender processes have been well defined in Croatia with tender boards established to oversee the transparent, open, and fair awards of contracts to successful bidders. For CARDS or Phare funded contracts, the tender process and subsequent evaluation of tenders must be followed.

Terms of Reference (ToR)

The Terms of Reference must describe the objectives of the project, the background to the project and the detailed aim of the current phase of the project.

Requirements for the Project Quality Plan (PQP)

The purpose of a Project Quality Plan is to provide the description of the measures to be taken to meet the quality and technical requirements of the user. It must be limited to carrying out the project as contractually defined. DG TAXUD has developed a PQP template that could be used by Croatia as the basis for their national PQP. It is intended to serve as a service level agreement between the Contractor and the project owner.

Invitation To Tender (ITT)

Croatia has its own strict tendering process in place to be followed when contracts are nationally funded and must follow the tendering process of the European Commission if the contract is to be funded by the EC (e.g. the Phare programme).

08664-401/TI.01.01/document.doc 49




Generally a tender opportunity is publicly announced and potential suppliers are invited to submit an expression of interest. A shortlist of companies or consortiums who will be invited to tender is drawn up by reviewing all the expressions of interest received. A tender dossier is then forwarded to the shortlisted companies or consortiums together with a set of supporting documents including the ToR and any specific instructions to bidders. The companies or consortiums submit tenders in accordance with the instructions e.g. separate technical and financial proposals, normally within set deadlines.

Tender Evaluation Report

Tenders should be evaluated in strict accordance with tender evaluation procedures, be it national procedures where national rules govern the selection process or the EC evaluation procedures if the contract is to be funded by the EU. Openness and transparency is of critical importance to ensure contracts are awarded fairly and honestly to the winning bidder. Tender evaluation results should be documented against the evaluation criteria.

3.5.3 System Specification Phase

The objectives of the System Specification phase are to:

Provide the user with a complete functional model of the recommended system solution;

Provide technical designers with a detailed functional specification on which to base the technical design of the system;

Confirm implications on testing, conversion, implementation, organisation and training;

Confirm system configuration requirements (if any);

Re-confirm the technical, operational and economic feasibility of the system;

Be able to plan the next phase (Design) in detail.

Project Quality Plan (PQP)

This deliverable has to be provided by the Contractor but must comply with the requirements (see the TEMPO document TMP-TEM-PQP.doc).

The Project Quality Plan is the device by which the Project Managers demonstrate that they:

Understand a given project, its characteristics, peculiarities, risks, innovations and unknowns;

Have selected the most important project organisations, techniques, resources and tools to cope with the above;

Have defined the deliverables, Quality Assurance and approval responsibilities and process and also defined the extent and format of checks and reviews;

Have identified the major risk and the corresponding preventive actions.

The plan is produced in the early stages of the project and is supported by an initial analysis of the risks and unknowns. It is reviewed and revised to take account of new information and changed requirements.

Functional Specification

This deliverable contains an accurate functional description of system processes and system data. It should give both user and technical designer a detailed view on the functionality of the new system. The detailed description of process logic should refer to specific items of business data.

08664-401/TI.01.01/document.doc 50




Other Systems Change Strategy

This deliverable formally describes all functional changes to other systems (other national systems that might be impacted), needed to complement the implementation of the project:

Functional Modification Specifications;

Data Conversion/Take-on Outline;

Change Sequence.

This information might be included in the Functional Analysis document.

System Configuration

The purpose of this task is to confirm the main hardware and software items necessary for both system development and operation. These items will be refined during the design phase, when conducting the detailed sizing exercise.

The level of detail required should be sufficient only to confirm the scale of expectation and to identify potential issues.

All potential budget implications, including licences, renewals and maintenance costs, must be indicated:

System Geographic Plan;

System Capacity Estimates;

Site Configuration Items;

Preliminary Purchasing List.

Organisation Change Strategy

The objective of this task is to produce a consolidated Organisation Change Strategy, stating precisely the impact of the system's implementation on the user organisation. The Business Project Team, not the IT Contractor, should conduct this study. The resulting organisation might be based on functional, geographical or processing requirements, including:

Relationships between the Administration units;

Transferring some work to another department;

Adding / deleting business functions or responsibilities.

The following points must be considered in particular:

Are any new or altered functions clearly described ?

Are assumptions underlying organisation change reasonable?

Is there any pending conflict between the different parties involved (with the MoE for instance)?

Is there sufficient understanding and support, within the Administration, for the proposed changes?

Is the change sequence realistic?

08664-401/TI.01.01/document.doc 51




Testing Strategy

The objective of the Testing Strategy is to describe the testing process and the agreed responsibilities of the various parties in their respective testing roles.

The Testing Strategy may comprise a matrix that shows the stages of testing and the features to be tested. Possible testing stages are the following:

Unit testing (attempting to prove every logic path or option within a module/programme, including data tolerance and error trapping).

Link testing (attempting to prove programme-to-programme co-existence, by calls and data transference).

System testing (extensive and intensive series of tests aimed at proving that the whole system will operate without major fault). “Conformance Testing” with DG TAXUD should be included in this set of tests.

Acceptance testing (global tests aimed at proving that the whole system meets its requirements and the related acceptance criteria).

The Testing Strategy additionally describes any special requirements, and the rationale behind apparent overlaps between testing stages.

Following aspects should be included in the test approach:

Where will the tests take place: HQ or a special test site ?

Who will be involved in testing (DG TAXUD, HQ, Regional sites, Contractor, ...) ?

With what responsibilities (data preparation, premises, reports, ...) ?

Data Building and Conversion Plan

The strategy for building and converting data should include:

A list of all data sources and characteristics;

A detailed description of the conversion process (including any necessary controls, validation, translation, exception / rejection handling and recovery procedures);

A list of all software and hardware required to carry out data conversion and loading on the new system (including scanners, filters, translators, comparators, temporary interfaces and specific media);

An anticipated conversion sequence, taking into account milestones, staff availability and training, assistance from the IT Support Team, and computer time estimates;

Details of integration with the data take-on sequence.

Training Plan

This deliverable provides the definition of the training process for the complete system. This includes the definition of training programmes, methods and facilities.

The following points must be considered in particular:

Coherence of training programmes;

Adequacy of training methods and controls;

Availability of training facilities and resources;

Timing of the delivery of training;

Validity of the training sequence.

08664-401/TI.01.01/document.doc 52




3.5.4 Design Phase

The Design phase translates the functional specifications of the system (or sub-systems) which have been prepared from a user's point of view, into detailed specifications of a technical nature.

Technical Specification

The Technical Specification must be consistent with all aspects of the Functional Specification. It translates the Functional Specifications into meaningful, manageable and testable technical elements, taking into account the technical constraints imposed by the environment.

System Tests Plan

Because of the potentially different groups of tests within a complete system test, it is likely that each group will require its own System Test File, comprising a plan and a number of individual specifications. Any tool required to support system testing must be confirmed and its precise use must be defined in the test plan.

The System Test File must be consistent with the functional and technical design of the new system. Therefore, its links to the corresponding deliverables must be carefully assessed.

Acceptance Tests Plan

The Acceptance Test File must reflect a reasonable and realistic acceptance strategy, considering the actual resource availability and indicating any particular testing "window" or special situation e.g. a system that cannot be tested and accepted during a certain period of the year, due to peaks in workload.

Conversion Tools Specification

The objective of this deliverable is to provide for a detailed technical specification of any software, procedures and tests needed to support the data conversion process and to demonstrate the validity of converted data.

Training Specification

The Training Specification consolidates the Training Plan, describing in detail:

Individual training modules;

Related case studies and training material;

Required IT and non-IT facilities.

Specification of the content of training modules is based on precise objectives, for a given group of people, within a clearly defined educational framework.

3.5.5 Build and Test Phase

Link Test File

Because of the potentially different groups of tests within a complete series of link tests, it is likely that each group will require its own Link Test File, comprising a plan and a number of individual specifications.

08664-401/TI.01.01/document.doc 53




System Manuals File

The System Manuals File generally contains four distinct documents:

The system overview is a high-level document presenting the main system features, implications, advantages and foreseen benefits;

The users' manual provides a complete reference guide for users of the system;

The operators’ manual provides the computer-level instructions for the system;

The help text provides the required level of instant help for users of the system and will be integrated into help facilities.

Program Specifications File

The objective of this deliverable is to provide for definitive descriptions of the required functionality of each program and of its unit tests, sufficient for programmers to be able to generate and test physical code, without further reliance on the functional specification.

Conversion Development File

The Conversion Development File is very similar to the Program Development file. It contains all relevant documentation on the development and the testing of the conversion tools.

Training Material File

The Training Material File will contain documentation on all developed training material. It will also contain all information related to the execution of corresponding tests and rehearsals. It must be consistent with the training specification.

3.5.6 Running In and Maintenance Phase

Acceptance Test Execution File

The Acceptance Test Execution File will contain all information related to running and supporting the acceptance tests, including:

Test log and analysis of results;

Error correction and re-test;

Acceptance test report.

Conversion File

The Conversion File will contain all information related to running and supporting the conversion, including:

Logging and analysis of results;

Error correction and re-run of (parts of) the conversion;

Conversion report.

Training File

As a result of the training process, the Training File should demonstrate that users are:

Convinced of the usefulness of the new system and motivated to use it effectively;

Aware of their responsibilities in system operations;

Knowledgeable about and comfortable with the system's operations, and fully capable of fulfilling their operational roles;

Able to communicate effectively with other staff members who support the system.

08664-401/TI.01.01/document.doc 54




3.5.7 Main Project Deliverables and Responsibilities

Responsibility Codes

P (Participate): Provides assistance (active & advisory) E (Execute): Performs a task, brings efforts and skills V (Verify): Quality checks R (Responsible): Has the ultimate responsibility A (Approve): Approves the deliverables I (Inform): Receives copy of approved deliverable

National Interoperability Implementation Strategy A R P P V

Phase 1 – Pre-Study

User Requirements A V R P E P

Pre-Study Report A V R R I V E P P P

PID A V R R I V E P P P

Phase 2 – Tender Process

ToR A V R R I V E E P P

Requirements for the PQP A V R R I P E E

ITT A V R R I V E E

Bids Evaluation A V R R I V E E

Contract A V R P I V P P R

Phase 3 – System Specification

PQP A V V I V V V R P P E

Functional specification A R P I V E E E P P V

System configuration A V R V V E I E P V

Organisation change strategy A R E P I V P E P P V

Testing strategy A R P I V E E E V

Data build plan A R P I V E E E P P V

Training plan A R E V I V E E E P P V

Phase 4 – Design

Technical specification I I A V V R E P V

System tests Plan I I A V V R E P V

Acceptance tests Plan I A V V R E E P P V

Conversion tools specification I I A I V R E E P P V

Training specification A R R I V E E E P P V

Phase 5 – Build and test

Link Test Specification I I A V V R E P V

System manuals A R R I V E E E P P V

Programs A V R E P V

Conversion tools A V R E P V

Training material A A V E E E P P V

Phase 6 – Running-in and maintenance

Acceptance tests A R P I V E E E P P V

Data Converted A R P I V E E E P P V

Training A R R V E E E P P V

System installed A R P I V E E E P V

08664-401/TI.01.01/document.doc 55




3.6 COMMUNICATION AND REPORTING STRUCTURE

A detailed management structure has been suggested in § 3.2.2. The suggested reporting structure follows the management hierarchy and so ensures a co-ordinated approach to the overall programme implantation.

3.6.1 Progress Meetings

Meetings between Frequency Purpose of meeting Outputs

Start-up and Kick-off meetingsAll key players

Start up Becoming familiar with the problem

Preparation and organisation of the project to be carried out

Plan the project with respect to resources and time

Preparation and organisation of QA

Initialisation of the files

Introductions to team members

Roles and responsibilities agreed

Project organisation agreed

Reporting and communication lines agreed

IT Project Manager & IT Team

Daily To agree tasks as per work plan and assess progress

Tasks completed on time

Business Project Manager & Business Team.

Daily To agree tasks as per work plan and assess progress


IT Project Manager and Business Project Manager

Daily To assess progress

To solve functional questions


Contractor, Project Managers and Project teams

Daily To liase and agree daily tasks

To solve day-to-day problems


Project Managers & Project Owner

Weekly To brief the Project Owner of project progress

To agree any changes required to work plan

To agree next tasks

Short Weekly Report

Project Owner,Project Managers,Quality Manager, Contract Manager& Contractor

Monthly To review the work plans

To report any shortcoming

Monthly Progress Reports

Project Owner & Programme Director

Monthly To brief the Programme Director as to project progress

To review priorities against business strategy & EU accession strategy

Project Status Report

Contract Manager,(Contractor), & Programme Director

As required To report any contractual failure on behalf of the Contractor or necessity for Change Request and decide actions

Amended Contract

Steering Committee Quarterly or on demand

To agree quarterly work plans

To decide on resource deployment

To decide on funding issues

Timely decisions on work plans, resources and funding to allow project implementation in time for EU accession

08664-401/TI.01.01/document.doc 56




3.6.2 Reports

The table below shows the suggested formal reporting requirements at all levels throughout each project start up. A complete description must be provided in the PQP.

Name of report Author Frequency To whom

Team Progress Report Team members Weekly Project Managers

Quality Assurance Report Quality manager Monthly Project Owner

IT Project Progress Report IT Project Manager Monthly Project Owner

Business Project Progress Report Business Project Manager Monthly Project Owner

Project Status Report Project Owner Monthly Programme Director

Programme Status Report Programme Director Quarterly Steering Committee

Responsibilities

Responsibility Codes

P (Participate): Provides assistance (active & advisory) E (Execute): Performs a task, brings efforts and skills V (Verify): Quality checks R (Responsible): Has the ultimate responsibility A (Approve): Approves the deliverables I (Inform): Receives copy of approved deliverable

Team Progress Report A A R E R R

Quality Assurance Report A V I R I I I

IT Project Progress Report A I I V R I I

Business Project Progress Report A I I V I R I

Project Status Report A R I I I I I

Programme Status Report A R I I I I I I

08664-401/TI.01.01/document.doc 57




4 INTEROPERABILITY IMPLEMENTATION PLAN

4.1 DATES ASSUMPTIONS

4.1.1 Target Date (see section 2.2)

Full operation of the above-mentioned systems 01/01/09

4.1.2 DG TAXUD Requirements

National VES system operational 31/12/08

National VIES operational for VAT # Identification 31/12/08

National VIES operational for ToD 31/05/09

4.1.3 Decisions

Formal opening of the Fiscalis 2007 Programme to Croatia Done

Availability of the Fiscalis 2007 Programme Funds to Croatia Q1 2006

4.1.4 Test Platform Availability

CCN-CSI test gateway installed 30/09/06

Test platform for VES Now

Test platform for VIES Phase 5 Now

Test platform for VIES-2 ?

08664-401/TI.01.01/document.doc 58




4.2 TIME SCHEDULE

The proposed detailed times schedules are available in Annex 5.1. The funding activities have not been included. The main findings are discussed hereafter.

4.2.1 CCN/CSI

The CCN/CSI gateway installation should start 6 months before the first need for testing another project (usually NCTS in Customs). However, the problem here is more administrative (signature of the agreement with the EC) than technical. It is foreseen that the CCN/CSI gateway could be installed by September 2006 to allow testing of NCTS.

4.2.2 VIES & VES

Similarly to ITMS, it is suggested to divide the VIES development in two Projects:

The VIES functions mandatory for accession (Validation of the VAT # and exchange of Turnover Data (ToD) over the CCN/CSI gateway);

The VIES enhancements (all extra functions requested to support the CLO activities) & VES (also mandatory for accession).

The following approach is therefore suggested:

Use a “Project Preparation Facility” (PPF) in order to prepare the Phare 2005 Project Fiches and Terms of Reference for the VIES Mandatory Developments (must be ready in June 2005).

Use another PPF Framework Contract in order to establish a Gaps and Needs analysis between the Croatian & EU VAT legislation and define the global Strategy of the Tax Administration regarding the VIES implementation.

Under CARDS 2004 (start in 2005 with main activities in 2006):

A Twinning to:Support the preparation of the business changes (legislation, etc)Provide a better understanding of the VIES conceptsSetup of the CLO (job description, etc);Address the re-organisation issues;Review the administrative procedures;Prepare the ToR for the VIES Enhancement Developments Project.

Under Phare 2005 (start in 2006 with main activities in 2007):

A Twinning to provide support for Project Management

A Contract to develop the VIES IT Mandatory functions

Under Phare 2006 (start in 2007 with main activities in 2008):

A Contract for the development of the VIES Enhancement functions and VES.

Remarks

Having the CCN/CSI gateway installed at the beginning of 2007 satisfies the VIES testing requirements.

Although the IT activities are important, the business related activities are essential for the overall success of the Project: having a good system to exchange data is useless if the data send are of poor quality or if the data received are not analysed and exploited.

08664-401/TI.01.01/document.doc 59




4.3 RESSOURCES ESTIMATION

08664-401/TI.01.01/document.doc 60

WARNING

This section provides an ESTIMATION of the human and financial resource requirements for each of the suggested projects. The figures provided are based on information received from a number of sources including, MS experience, individual experts advice etc. However, there are numerous influencing factors to be considered which will affect the resource requirements.

The Croatian Tax Administration is strongly advised to review these figures based on the current situation and the current stage of system development in country. DG TAXUD accepts no responsibility as to the accuracy of these figures and provides them simply as guidelines to assist the Croatian Tax Administration in defining its own likely resource requirements for each project.




4.3.1 CCN/CSI

The following roles have been defined by DG TAXUD on the MSA side:

Administrative Project Manager(APM)

Responsible for liaison with DG TAXUD and other MSA for all CCN/CSI administrative issues.

Technical Project Manager(TPM)

Responsible for liaison with DG TAXUD and other MSA for all CCN/CSI technology issues.

Local Security Officer(LSO)

Responsible for the overall CCN/CSI-related security measures according to the CCN/CSI security policy, including user access rights.

Local System Administrator(LSYA)

Responsible for executive work on behalf of the Central System Administrator (CCN/TC) for the administration of the CCN/CSI gateway and complementary platforms (EuroDomain) hosted in the premises of the MSA, and responsible for the system management of the CSI software in the National Domain, according to the CCN/CSI Security Policy.

Local Security Administrator(LSA)

Responsible for the user profile assignment and securing the non-secure link.

Local Directory Administrator(LDA)

Responsible for the user (logical and human) registration in the local CCN/CSI directory.

Local Network Administrator(LNA)

Responsible for the network connections inside the National Domain.

It is suggested that:

The Contractor Project Owner will assume the APM role;

The Contractor Project Manager will assume the TPM and LSO roles;

The other roles (LSYA, LSA, LDA and LNA) should be distributed between one or two Team Member(s) from the Contractor;

The LDA roles can also be granted to IT experts in both the Customs and Tax IT Departments.

4.3.1.1 Human Resources

Role From Nb Duration % Man-Days1

Project Owner Head of IT Dept. 1 15M2 10% 30

Project Manager IT Dept. or Contractor 1 9M 100% 200

Team Members IT Dept. or Contractor 2 6M 50% 100

4.3.1.2 Financial Resources

The installation and operational (Community domain) costs of the CCN/CSI gateway will be supported by the Customs 2007 Programme. Croatia will therefore only be faced with little additional costs (equipment for the national domain only: workstation for the administration of the gateway, firewall, ...). In this case, 10.000 € should be sufficient.

1 Based on 20 Man-Days per Month. Figures have been rounded (rough estimations only !)2 Mainly for the administrative process with DG TAXUD

08664-401/TI.01.01/document.doc 61




4.3.2 VIES & VES

4.3.2.1 Project Preparation Facility – Framework Contract A

Duration: 3 months

Staff: 3 experts

Cost: 197.000€

Please up-date for information figures on additional framework assistance through ECD to HR for setting up HR Tax business change and overall IT strategies.

4.3.2.2 CARDS 2004 – Framework Contract B (Gap and needs analysis based upon the revised Taxation Blueprints)

Duration: 4 months

Staff: 2 experts

Cost: 190.000€

4.3.2.3 CARDS 2004 – VIES Preparation Twinning

Duration: 24 months

Staff: 1 RTA * 24 months + 8 experts * 80 days

Cost: 1.300.000€

4.3.2.4 Phare 2005 – Twinning for Project Management

Duration: 18 months


Cost: 1,000,000€

4.3.2.5 Phare 2005 – VIES Development Contract (Accession essential modules including VIES 2 B2B Services)

Duration: 20 months

Cost: 2.000.000€

4.3.2.6 Phare 2006 – Twinning for Project Management

Duration: 10 months


Cost: 500,000€

4.3.2.7 Phare 2006 – VIES Enhancements + VES – Development Contract

Duration: 20 months

Cost: 2.000.000€

08664-401/TI.01.01/document.doc 62




4.3.2.8 Human Resources

Role From Nb Duration % Man-Days

Project Owner Head of VAT Dept. 1 36M 25% 150

VAT Project Manager VAT Department 1 36M 100% 600

VAT Experts VAT Department 2 36M 50% 600

IT Project Manager IT Dept. 1 24M 100% 400

IT Support Team IT Dept. 4 24M 10% 160

Remarks

The involvement of the experts will vary during the life of the project: more VAT experts are required in the beginning of the project (Business Changes, legislations, establishment of the CLO, etc) but more IT experts are required during the IT development period.

It is suggested that the VIES Project Owner should be a senior VAT officer with at least 5 years experience in VAT administration. It should be noted that it is not necessary for the Project Owner to have experience in VAT collection or VAT control, enforcement work, etc but to have experience in the VAT registration processes and the administrative process of dealing with VAT returns. He should:

Have a good understanding of the legal base requirements of the EU (6th VAT Directive and Regulation 2003/1798/EC);

Be familiar with the VIES management structure within DG TAXUD; Be familiar with functional description of VIES as provided by DG TAXUD; Be familiar with the technical description of VIES as provided by DG TAXUD; Be familiar with the national requirements for the VIES interface as defined by

DG TAXUD; Have the ability to influence administrative changes e.g. establish the CLO.

The VAT Experts should have a minimum of three years experience in VAT, preferably dealing with VAT registration and processing of VAT returns. They should be familiar with the existing national procedures for VAT registration and deregistration, allocation of VAT registration numbers and also with the functionality of the existing VAT IT system. At least one of the team members should have a training background and experience of conducting training needs analysis and designing and delivering training courses for users from the Tax department and the trade. Previous experience of liaison with the trade would be beneficial.

Financial provision should be taken for the travelling expenses (air fares, hotels, …).

Possibility to buy (receive ?) the VES application from a current MS should be envisaged.

08664-401/TI.01.01/document.doc 63




5 ANNEX

5.1 GLOBAL PLANNING

08664-401/TI.01.01/document.doc 64

Date post:	28-Jan-2016
Category:	Documents
Upload:	miguel-angel-amoretti
View:	225 times
Download:	0 times