EN Official Journal of the European Union C 32/1

Report on the audit of the operational efficiency of the management of the European Central Bank for the 2007 financial year together with the replies of the European Central Bank

2010/C 32/01

TABLE OF CONTENTS

List of abbreviations and glossary

Introduction

Audit scope and approach

Observations

Did the ECB have an appropriate governance framework for the management of its IT projects in place?

Did the ECB have a multiannual IT strategy which is aligned with its overall organisational goals and objectives?

Did the ECB plan its IT project-related activities on an annual basis?

Was the process of selecting IT projects for implementation based on sound criteria?

Were appropriate procedures established for the management of the IT projects?

Was the governance framework established for the management of the IT projects applied as intended?

Were individual projects adequately planned?

Were the projects properly implemented?

Were the projects properly monitored?

Was a formal assessment of the projects carried out at completion?

Conclusions and recommendations

Did the ECB have an appropriate governance framework for the management of its IT projects in place?

Was the governance framework established for the management of the IT projects applied as intended?

Annex — Overview of the projects examined by the European Court of Auditors

LIST OF ABBREVIATIONS AND GLOSSARY

COBIT Control Objectives for Information and related Technology DG-H Directorate-General Human Resources, Budget and Organisation DG-IS Directorate-General Information Systems ECB European Central Bank EER ECBLAN Eurotower Refresh ESCB European System of Central Banks IT Information Technology KPI Key Performance Indicator MAU Main computer rooms Area Upgrade at the Eurotower building MDP Market Data Provision MPIDS Monetary Policy Implementation Decision Support System PCR Project Closure Report PMBOK Project Management Body of Knowledge PMI Project Management Institute POCP Project Organisation and Control Procedures PSD Project Submission Document PSG Project Steering Group PSR Project Status Report SLA Service Level Agreement Target 2 SSP Target 2 Single Shared Platform TCERTO Teleconference, CoreNet, ESCB-Net enlargement to Bulgaria and Romania

INTRODUCTION

1. The European Central Bank (ECB, ‘the bank’) and the national central banks of all EU Member States together constitute the European System of Central Banks (ESCB). The primary objective of the ESCB is to maintain price stability. The ESCB also supports general economic policies in the Union with a view to contributing to the achievement of the Union objectives (1). To this end, the ECB carries out the tasks specified in its Statute (2) and is responsible for managing its activities and finances.

2. The Court’s audit of the operational efficiency of the ECB is based on Article 27.2 of the Protocol on the Statute of the ESCB and of the ECB (3). The audit subject was the ECB’s management of IT projects for both the 2007 and the 2008 financial years. Developments in the ECB’s practices in the first quarter of 2009 were also taken into account.

3. The ECB’s budget is divided into two main parts: activities aiming at ‘running the bank’ (the ECB’s Business Areas’ operational expenditure (4) and activities aiming at ‘changing/building the bank’. The latter part is made up of two main groups of activities: (i) project activities, consisting of major ECB and ESCB projects, other projects, small developments and centralised IT investments; and (ii) banknote activities, consisting mainly of banknote research and development.

4. ECB expenditure on IT projects (5) in 2007 amounted to approximately 20 million euro out of a total of 31 million euro spent by the ECB on all project activities.

AUDIT SCOPE AND APPROACH

5. The main objective of the Court’s audit was to assess the ECB’s management of IT projects by addressing the following two audit questions: — Did the ECB have an appropriate governance framework for the management of its IT projects in place? — Was the governance framework established for the management of the IT projects applied as intended?

6. The audit comprised an assessement of the ECB’s rules and procedures applicable to the different stages of managing the IT projects, as well as an examination of their application.

7. The Court’s assessment of whether the ECB had established an appropriate governance framework included consideration of all main documents and procedures relating to the management of IT projects. The principal document used in the management of projects is the Project Organisation and Control Procedures (POCP) (6). For assessing the appropriateness of the IT governance framework, internationally recognised standards and best practice, such as the Project Management Body of Knowledge (PMBOK (7) of the Project Management Institute (PMI) and the Control Objectives for Information and related Technology (COBIT) of the IT Governance Institute were also considered.

8. In order to assess whether the rules and procedures were being applied as intended at project level, six IT projects were audited in detail. The audit of the selected projects was based on interviews with project managers, project teams and end-users and an examination of relevant project documentation.

9. The basis for the sample was the ECB’s budget line concerning ‘major ECB projects’. For the 2007 financial year, this comprised 16 major projects, 14 of which were IT-related. The selection was based on the following criteria: i) the type of project, ii) its budget and iii) its stage of completion. A summary description of each project together with information on project duration and costs is provided in Annex .

OBSERVATIONS

Did the ECB have an appropriate governance framework for the management of its IT projects in place?

10. In auditing the governance framework for IT projects, the Court examined whether the ECB: — had a multiannual IT strategy which was alligned with its overall organisational goals and objectives, — planned its IT project-related activities effectivelly on an annual basis, — used sound criteria for selecting IT projects for implementation, and — established appropriate procedures for the management of its IT projects.

Did the ECB have a multiannual IT strategy which is aligned with its overall organisational goals and objectives?

11. To make effective use of resources, a multiannual IT strategy aligned with overall organisational goals and objectives should be established. This strategy should be formulated in a way which provides guidance for planning and undertaking IT activities over a number of years, allowing IT expenditure to be set at an appropriate level and be concentrated where it is most needed. It should be based on a global assessment of IT needs leading to informed decision-making regarding the prioritisation of the areas of intervention.

12. The Court found that the ECB did not have in place a multiannual IT strategy in which it defined and presented its strategic goals and medium-term objectives for IT. There was also no formalised global assessment of needs carried out for the prioritisation of areas of intervention with a medium-term perspective. Notwithstanding the above, both the President’s letter and the Business Areas’ ‘strategic/operational outlines’ are used as a basis to identify new IT projects which are then prioritised in the annual update of the project portfolio (see paragraphs 19-21).

13. In 2008, the Directorate General Information Systems (DG-IS) and the Directorate General Human Resources, Budget and Organisation (DG-H) initiated a strategic review of the ECB’s IT activities in close cooperation with the other ECB Business Areas. This review was not yet complete at the time of the Court’s audit (first quarter of 2009). The first phase of the review aimed to look in detail at the Business Areas’ goals and objectives and to identify their strategic business requirements in terms of new IT systems, projects and services over the next five years (2009-2013). It was finalised in December 2008. This is expected to result in the formulation of an IT strategy for all DG-IS functions (including IT projects).

Did the ECB plan its IT project-related activities on an annual basis?

14. An annual planning cycle for IT projects requires the setting of annual objectives, the definition of actions to be implemented to attain these objectives and the establishment of Key Performance Indicators (KPIs) to measure performance.

15. In 2007, DG-IS prepared a ‘2007 strategic/operational outline’ document which listed a number of broad aims, some of which related to the management of IT projects (8). However, these were not transposed into specific objectives and actions, nor were the expected results defined.

16. In 2008, two planning documents were prepared by DG-IS: a high level ‘2008 strategic/operational outline’; and a ‘2008 work programme’. The 2008 strategic/operational outline included a summary section on the main challenges faced by DG-IS in 2008 and an overview of the objectives, and KPIs for 2008. Some of these objectives related to the management of IT projects (9). Achievement of these objectives was to be measured by specific quantifiable KPIs for which targets were set for the second and fourth quarters of 2008.

17. The 2008 work programme provided more details by defining the expected actions to be carried out for the attainment of each of them. This represents an improvement on the situation in 2007 and is a positive development which enhances the quality of the planning process. It was noted, though, that the 2008 work programme contained significantly more objectives than the 2008 strategic/operational outline document above. The work programme was not set up to develop and provide details on how the objectives selected in the ‘strategic/operational outline’ could be attained and not to introduce new ones.

18. Finally, neither of the 2008 planning documents are sufficiently detailed to be used as effective planning documents. In addition, there is no indication of the financial resources needed for the attainment of each objective and for the implementation of each selected action.

Was the process of selecting IT projects for implementation based on sound criteria?

19. There are not sufficient resources available to finance all possible projects each year. A process is therefore required to make a selection of the highest priority projects and thereby make best use of the resources available.

20. The 2007 project prioritisation and selection process was based on a three-year medium-term project portfolio plan. Each year, the ECB reassesses all projects (ongoing, already registered in the project system but not yet started and newly registered) in the light of the ECB overall objectives. This medium-term plan is updated twice a year in order to take into account newly registered projects and other developments.The project assessment is based on the project business cases put forward and on their forecast consumption of resources. Clear prioritisation criteria were not set. This made project selection less objective, thus increasing the risk that the best use might not be made of the available resources.

21. In 2008 an improved project prioritisation methodology was introduced. This was based on a ‘three pillar concept’ (10). The methodology consisted of domain (11) specific assessments, followed by a consolidation of these assessments at ECB level. The IT project management system established in 2008 provided sufficient information for decisions to be made.

Were appropriate procedures established for the management of the IT projects?

Procedures for IT project management

22. The ECB established the Project Organisation and Control Procedures (POCP) document to which the management of all projects, including the IT ones, must conform (12). The POCP includes a detailed definition of what constitutes a project and clearly sets out its field of application. It also determines the organisational structure to be set up for projects, including the roles and responsibilities of the relevant participating entities.

23. A project’s lifecycle, as defined in the POCP, sets the structure for effective control over projects by dividing the project lifecycle into logical phases and by setting precise decision-making points (see Diagram 1 ). A comparison of the POCP with the PMBOK showed that the POCP was to a large extent in line with this best practice. Two areas in which the POCP could be improved include: stakeholder analysis and post-assessment of the project’s impact. The current weaknesses and their impact are detailed in the following paragraphs.

Diagram 1 — Project lifecycle phases

Source: European Central Bank.

24. The POCP does not require the formal preparation and documentation of a stakeholder analysis. This means that the project team does not have to formally identify the stakeholders and determine their specific project requirements (13). The absence of the formal identification of all stakeholders and their needs could have a negative impact on the success of a project. It should be noted that in the case of the specific projects examined, user needs were considered (see paragraphs 33 and 36).

25. No post-assessment of a project’s results and impact is foreseen when a project has been in operation for a certain period of time. Such an assessment would, amongst other things, provide a formal judgement on the achievement of the expected qualitative and quantitative benefits set out in the project approval documents and thereby help the planning of future projects (see paragraph 53). A recent positive development in this area was the new template which requires an annual customer feedback on IT projects with the aim of surveying the end-user satisfaction with the quality of the service provided.

Allocation of responsibilities and decision-making structure

26. To ensure that projects are implemented efficiently and effectively it is necessary to establish a framework for managing them setting out clear reporting lines and responsibilities of the bodies and functions involved in the process.

27. The POCP document established the organisational structure to be set up for the management of the ECB projects, including the roles and responsibilities as well as the composition of the relevant participating entities (see Diagram 2 ).

Diagram 2 — Overview of ECB’s project management framework

Source: European Central Bank.

28. Clear reporting lines are set in the POCP between the bodies and functions engaged in the project management process. The Project Steering Committee is the main ECB internal decision-making body for project prioritisation, planning, approval, and monitoring. The structure created by the POCP encompasses all the necessary functions and provides clear decision-making procedures with pre-defined roles and responsibilities.

Was the governance framework established for the management of the IT projects applied as intended?

29. In auditing the application of the governance framework for IT projects, the Court examined whether the ECB: — planned individual projects adequately by assessing the project’s objectives and the proposed solution and by considering the resources needed, — implemented individual projects properly by ensuring that resources were made available on a timely basis and by sufficiently testing each project deliverable, — monitored project implementation by establishing systems which produce frequent reports summarising all relevant project data for informed decision making to be made, and — formally assessed the project’s deliverables and resources used at project completion.

Were individual projects adequately planned?

The Project Submission Document (PSD)

30. Project planning is adequate when the following are addressed: (i) the overall project objectives and scope; (ii) the proposed solution; (iii) the project milestones and deliverables; (iv) the financial and human resources; and (v) the project team.

31. The main planning document is the Project Submission Document (PSD) (see Diagram 1 ). This document serves as the basis for a decision as to whether the selected project solution should be implemented. In the case of all six projects examined, the content of this document was comprehensive and it addressed all main issues which should be considered at the time of project’s approval.

Project authorisation and selection

32. All projects were authorised in accordance with the procedures foreseen in the POCP. Before each of the three project phases (14), a formal decision to go ahead was taken by the Project Steering Committee. Three projects (15) were considered as ‘must-do’ projects to comply with ESCB or other required standards. The others (16) were selected on the basis of the project prioritisation methodology. All projects were consistent with either the DG-IS ‘strategic/operational outline’ or the general strategies of the Business Areas concerned.

User demands and project specifications

33. In the case of three of the projects (17) examined, the user requirements were assessed and documented at the planning phase. As the other three were just an extension of an existing network (TCERTO) or an upgrade of existing infrastructure (EER and MAU), users were not involved at the planning stage. In the case of MPIDS, the project specifications were developed using an iterative testing approach. This approach was not applied in the best possible way. This resulted in delays and the test versions were not as sufficiently developed as expected.

Risk assessment

34. Risks of the non-achievement of project objectives should be identified to a sufficient level of detail, and should be structured and thoroughly assessed during the planning phase in terms of their probability and their potential impact on the achievement of the project’s objectives.

35. There is a specific section on risk analysis in the templates for each of the three planning documents (18). This section was completed for all project PSDs. Nevertheless, there was no common approach to the identification of the risks faced by projects, and to the assessment of their probability and impact. The assessment was based on each project manager’s own experience. The MDP’s initial risk assessment considered only risks in relation to external contractors. During project implementation, internal risks also materialised, such as resource constraints. As these issues were not recognised as risks, no corrective action was foreseen at the planning stage. In the case of MPIDS other risks could have also been foreseen but were not mentioned in the PSD, such as the complexity of the business processes within the scope of the project.

Were the projects properly implemented?

Resource management and user participation

36. For three of the projects (19) examined, the resources and skills allocated to implement the project were sufficient. The other three faced a problem of specialised resources, not enough of which were made available on time. For MDP the users were not always available as a similar project had to be finalised at the same time. This led to delays in project implementation. In MPIDS, no business analyst was assigned to the team and staff from DG-IS were not always available when needed. The procurement of an external developer caused a three-month delay. After being contracted, the developer changed frequently, causing problems in the project implementation. Due to its complexity the project was implemented in different phases (20). The knowledge transfer from phase 2 to phase 3 did not occur as planned, as most of the main former project team members including the project manager did not continue in phase 3.

37. For all projects selected, the users were regularly informed during project implementation. For most of the projects, users were represented in the PSG and/or the project team meetings and they were also informed by the monthly project status reports.

External contractors

38. For the MDP project an exemption was given from the ECB’s procurement rules on the basis that the procurement could not have been separated from the previous choice of the data supplier. However, software development and support were not the core business of this supplier. This made the development part of the maintenance release more expensive than foreseen.

Testing and acceptance of the project deliverables during implementation

39. Testing of a new or changed IT deliverable forms part of the ECB’s procedures, to be carried out before each deliverable is made operational. All six projects were tested before release. Tests were designed by the project team. However, end-users were not always involved in the development of the tests with the consequence that improvements needed were not identified in time.

Were the projects properly monitored?

Management information systems and monitoring reports

40. Project managers should have sufficient and reliable information to effectively monitor projects during implementation so that problems can be identified in good time and resolved.

41. The ECB uses several tools in its monitoring of its IT projects. The time spent on projects together with the financial data and information on the project’s main achievements and progress made is reflected in the monthly Project Status Report (PSR). PSRs containing sufficient information were regularly produced for all six projects during their implementation. It was noted, though, that in the case of Target 2 SSP some reports were not prepared due to a lack of human resources.

42. Notwithstanding the above, time spent on projects is only recorded for DG-IS staff. The time spent by staff from the Business Areas and national central banks is only estimated. Furthermore, overtime is generally not recorded consistently, or not at all. Therefore, monitoring is not based on complete and accurate time information.

Was a formal assessment of the projects carried out at completion?

43. At project closure a formal assessment of the achievement of the project objectives and resources consumed should be carried out. The POCP provides for a Project Closure Report (PCR) to be produced once all deliverables of the implementation phase have been successfully achieved and the project end-product has been accepted by the Business Area(s) concerned, by the system owner and by DG-IS/Operations. The PCR thus serves as the document with which the approval to formally close a project is given.

44. This document is comprehensive as it addresses all the main issues which should be considered at the time of the closure of a project. Its main sections are: (i) assessment of achievement of approved project scope and objectives; (ii) assessment of the use of human and financial resources; (iii) quantitative and qualitative benefits assessment; and (iv) lessons learned report.

45. Up to 15 April 2009 a PCR was issued and approved for five out of the six projects examined (see Annex ). As a general rule, the POCP provides that a project is to be closed within three months of the acceptance of the final project deliverables. In the case of Target 2 SSP, operations commenced in May 2008 and the project was closed on 15 April 2009. This was because DG-IS and the system owner could not agree on the contents of the Service Level Agreement (SLA). In the PSG meeting in October 2007 it was mentioned that ‘the SLA needs to be in place before the go-live of Target 2 SSP. This needs to be started early as clear presentation of expectations/services and communication between operations and the different users are key’. Similarly, in the case of MPIDS, this project was not closed as the signature of the SLA was significantly delayed.

Assessment of achievement of approved project scope and objectives

46. At project closure, an assessment should be carried out of the actual project results compared with its approved scope and objectives. The assessment should consider the main project milestones and deliverables providing justification for any significant deviations.

47. The Court examined the assessments which were carried out of each of the four projects for which a PCR had been approved by the end of March 2009. The assessments made compared the initial plan in the Project Submission Document with what was achieved. They addressed each planned milestone and deliverable providing explanations for all main deviations. It was noted though that two of the projects (21) faced time delays over the initial plan (see Annex ). The two main reasons provided were: (i) the increase in the scope of the work; and (ii) the unavailability of human resources.

48. In the case of MAU, although the technical infrastructure was apparently available and in use much earlier than indicated in the PCR, the formal acceptance and handover faced a six month delay.

Assessment of the use of human and financial resources

49. The PCR prescribes that a comparison between the planned and actual human and financial resources should be carried out. The PCR of all four projects included such a comparison and provided explanations of most significant variations.

50. The actual human and financial resources used for each of the four projects were below the budgeted ones. Actual expenditure ranged from 3 % to 23 % below the budget (see Annex ). A number of project-specific reasons were provided justifying this underspend.

51. The issue of budget underspending in projects was also raised by the ECB’s Budget Committee in its evaluation report on the ECB’s 2008 year-end budget monitoring report. There it was mentioned that the Committee noted underspending of 18 million euro (28,8 %). The Committee considered that this was mainly due to delays in some projects and that there was ‘room for improvement in the planning and running of projects’. The Court noted that delays in project execution exist (see Annex ) and do have an effect on budget implementation. Considering, though, that resources provided in the initial plans were more than was needed, this indicates that initial budgets are not set as precisely as they should be. This leads to budgetary resources being committed and thus, not being available for more mature projects.

Qualitative and quantitative benefits assessment

52. At project closure an assessment of the qualitative and quantitative benefits to be achieved during the operation of the end-product is carried out. Deviations from the information provided in the Project Submission Document and therefore used in the project prioritisation and selection procedure should be explained.

53. In the case of all four projects it was stated in the PCR that the benefits presented in the PSD either remained valid or had been achieved. A number of these benefits though, can only be properly assessed following a period of operation (see paragraph 25).

54. In the case of MDP, the project went beyond just confirming the initial assessment included in the PSD. Another assessment was carried out using a different methodology. It evaluated the benefits of the end-product against the four dimensions set out in a balanced scorecard, which included positive and negative indicators. It therefore aimed to provide a fair assessment of the project outcome. This was a positive initiative and could be considered as a good practice in other future projects. Extracts from this assessment are presented in Box 1:

Box 1 — MDP’s qualitative and quantitative benefits assessment at project closure (extracts)

— Financial: (positive) the project has been implemented within budget; (negative) the cost of the consultancy fees paid for the development of the solution is considered to be over the market rate.

— Innovation: (positive) the project contributed to the development of a monitoring system supporting the Service Level Agreement; (negative) the project introduced a new proprietary database tool, which was quite complex to use and not as flexible as the ones already in use.

— Organisation: (positive) the project has contributed to the establishment of policies on market data usage.

— Customer: (positive) the project enabled the integration of Bloomberg data; (negative) the usability of the solution has been considered to be below expectations.

Lessons learned report

55. In the POCP it is provided that a lessons learned report should be produced as an annex to the PCR. The aim is to ensure that experiences in the implementation of a specific project are made available to the whole organisation with the aim of improving the management of future projects.

56. Although in all four PCRs a lessons learned report was provided, the standard of the content varied. In the case of EER, issues raised as lessons learned gave the impression that they were included in order to show that they had been successfully managed and not how things should be better handled in the future. In the case of MAU too many details were provided blurring the message of the lessons learnt for future projects.

57. In the case of both the MDP and TCERTO projects, issues were identified which are indeed of future relevance to the ECB’s project management procedures. Extracts from the issues mentioned in the MDP report are presented in Box 2:

Box 2 — Lessons learnt in the MDP’s Project Closure Report (extracts)

— Emphasise the importance of the preparation phase, in particular on the definition of user requirements. For the future it is suggested to empower further the end-user in the decision for the selection of the solution.

— Emphasise the importance of user involvement and accountability: without clear responsibility the user may not be fully aware of the importance of his involvement in the design and testing of the solution.

— Emphasise the importance of testing the deliverables of each phase.

— Plan resources according to the prioritisation of projects: the project suffered from a lack of resources during each test phase, due to a clash with another deliverable for the same Business Area.

— Consider a project portal as an effective knowledge sharing tool: a central and user friendly point of access to all project information helped a lot.

58. Finally, although the lessons learned are available to other project managers by accessing the PCR, issues which are considered to be of an organisation-wide interest and might enhance the sharing of experience amongst project managers were not identified and were not actively disseminated.

CONCLUSIONS AND RECOMMENDATIONS

Did the ECB have an appropriate governance framework for the management of its IT projects in place?

59. The ECB has established a governance framework for the management of its IT projects; nevertheless, there are some opportunities for improvement.

60. The ECB has not put in place a multiannual IT strategy which formally sets out its strategic goals and medium term objectives. In 2008, the ECB initiated a strategic review of its IT activities. This is expected to result in the formulation of an IT strategy.

61. Unlike the ECB’s IT projects for which financial resources were estimated, the Directorate General Information Systems’ annual planning documents did not provide any details concerning financial resources needed to achieve its objectives and implement the selected actions.

62. The ECB did improve its project selection process in 2008 by providing sufficient information for decisions to be made.

63. The ECB’s procedures for managing IT projects are largely in line with best practice. Weaknesses were found in the areas of stakeholder analysis and post-assessment of a project’s impact.

Recommendations (first audit question)

1. The ECB should formally put in place a multiannual IT strategy which should be used as an effective management tool for its IT activities;

2. the ECB should further enhance its annual IT planning by establishing a comprehensive document which sets objectives and defines performance indicators to measure their achievement. The objectives should be broken down into specific actions, indicating the financial resources needed for their attainment; and

3. the ECB should include the areas of stakeholder analysis and post-assessment of a project’s impact in its project management procedures.

Was the governance framework established for the management of the IT projects applied as intended?

64. Overall, the ECB did apply as intended the established governance framework for the management of IT projects. All audited projects were appropriately authorised at the planning stage by the approval of the Project Submission Document. However, weaknesses were found in the area of project risk assessment concerning a lack of details in the assessment and the absence of a common evaluation approach. In addition, budgets set in the initial plans were not set as precisely as they could be.

65. The Court found that during implementation three projects faced a lack of specialised resources which led to delays.

66. Overall, the ECB established appropriate tools and management information systems for the monitoring of its IT projects. However, the human resources consumed for IT projects are only partly monitored.

67. A formal assessment is carried out at completion stage in the Project Closure Report which contains all main issues to be addressed at this stage. However, only one of the six projects closed within the timeframe planned in the Project Submission Document.

68. The Court recommends the following: Recommendations (second audit question) 4. Planning of resources should be improved so as to ensure that specialised resources which are needed during implementation of the selected activities / projects are available on time and that budgets are established with more rigour; 5. Coordination between DG-IS and the Business Areas should be further improved aiming to reach an agreement on the SLA on a more timely manner; and 6. The lessons learned report should aim to identify improvement opportunities for future projects and these should be actively disseminated to all project managers.

This report was adopted by the Court of Auditors in Luxembourg at its meeting of 10 December 2009. For the Court of Auditors Víctor Manuel da SILVA CALDEIRA President

(1) Article 105(1) of the Treaty establishing the European Community, now Article 127(1) of the Treaty on the functioning of the European Union.

(2) The Statute of the ESCB and of the ECB is a protocol attached to the Treaty.

(3) Article 27(2) stipulates: ‘The provisions of Article 248 of the Treaty shall only apply to an examination of the operational efficiency of the management of the ECB’. The institutional provisions relating to the European Central Bank are included in Articles 112-115 of the EC Treaty, now Articles 283, 294, 134 and 135 of the Treaty on the Functioning of the European Union.

(4) The ECB is divided into 17 Business Areas reflecting the breadth of the functions of the ECB. Each Business Area, with the exception of the Counsel to the Executive Board and the ECB representation in Washington, is headed by a senior manager (Director General or Director) who reports to a member of the Executive Board.

(5) These are ECB projects involving IT resources and for which the project management is performed by both the Business Area concerned and by the Directorate General Information Systems.

(6) The POCP was last updated in 2006.

(7) The PMBOK sets out standards and guidelines which are widely recognised as best practice and which the ECB also uses as a standard for its project management procedures.

(8) For instance, better alignment between the core Business and IT and a move from a project to programme domain approach.

(9) For instance, adopt best practices for project delivery and management process and deliver IT projects in line with agreed costs, time and quality, including user-friendliness.

(10) Pillar one: standardised questions (22 parameters), pillar two: aggregated analysis in clusters, and pillar three: aggregated prioritisation criteria at ECB level for final decision-making.

(11) The IT Project Directorate is organised into five domains. Each domain is in charge of projects initiated by different Business Areas.

(12) Excluded from the POCP are small tasks, projects which are either conducted within one Business Area or not requiring any IT solutions, or IT infrastructure tasks with low volume of testing, low degree of innovation, low organisational impact which do not add any new service. The projects selected for detailed audit by the Court were all within the remit of the POCP.

(13) According to section 2.2 of the PMBOK, this is necessary in order to ‘ensure a successful project’. The PMBOK further stipulates that ‘failure to identify a key stakeholder can have a negative influence on the project’. In the project communications planning section 10.1 of the PMBOK it stated that ‘identifying the needs of the stakeholders and determining a suitable means of meeting those needs is an important factor for project success’.

(14) Project initiation, preparation and implementation phase.

(15) TCERTO, Target 2 SSP and EER.

(16) MDP, MPIDS and MAU.

(17) MDP, MPIDS and Target 2 SSP.

(18) Project Initiation Document, Project Preparation Document and Project Submission Document.

(19) TCERTO, MAU and EER.

(20) Phase 3 was selected for audit by the Court.

(21) MDP and TCERTO.

ANNEX Overview of the projects examined by the European Court of Auditors Project Project duration Project costs (in euro) Implementation start date Planned delivery date Planned project end date Actual delivery date Actual project end date Total budgeted resources Total actual resources Variation 1. Main computer rooms area upgrade at the Eurotower building (MAU) 28.6.2007 3.3.2008 18.4.2008 4.9.2008 2.12.2008 1 406 644 1 363 336 –43 308 –3,1 % 2. ECBLAN Eurotower Refresh (EER) 1.7.2006 13.4.2007 25.5.2007 15.2.2007 30.3.2007 1 158 692 1 014 359 – 144 333 –12,5 % 3. Teleconference, CoreNet, ESCB-Net enlargement to Bulgaria and Romania (TCERTO) 1.3.2006 16.10.2006 19.1.2007 28.3.2007 27.6.2007 2 060 927 1 594 595 – 466 332 –22,6 % 4. Monetary Policy Implementation Decision support System Phase 3 (MPIDS) 1.3.2007 20.11.2007 29.2.2008 to be provided by the ECB to be provided by the ECB 790 192 to be provided by the ECB — — 5. Market data Provision (MDP) 2.1.2007 30.9.2007 30.11.2007 31.12.2007 14.2.2008 1 859 379 1 458 105 - 401 274 -21,6 % 6. ECB Integration with the Target 2 Single Shared Platform (Target 2 SSP) 15.5.2006 20.5.2008 8.8.2008 18.5.2008 15.4.2009 508 387 540 339 +31 952 +6,3 %