natgillin/translations-raw huggingface dataset:
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. 
2008. aasta strateegia/tegevuskava sisaldas kokku­ võtlikult infosüsteemide peadirektoraadi peamisi ülesandeid 2008. aastal ning 2008. aasta eesmärkide ja peamiste tulemusnäitajate ülevaadet.
Some of these objectives related to the management of IT projects (1). 
Neist mõni eesmärk oli seotud IT projektide juhtimisega (1).
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. 
Nimetatud eesmärkide saavutamist plaaniti mõõta konkreetsete kvantifitseeritavate peamiste tulemusnäitajate abil 2008. aasta teises ja neljandas kvartalis.
This represents an improvement on the situation in 2007 and is a positive development which enhances the quality of the planning process. 
See näitab olukorra paranemist 2007. aastal ja on positiivne areng, millega parandatakse kavandamise kvaliteeti.
It was noted, though, that the 2008 work programme contained significantly more objectives than the 2008 strategic/operational outline document above. 
Siiski märgiti, et 2008. aasta töökavas oli oluliselt rohkem eesmärke kui eespool nimetatud 2008. aasta strateegias/tegevuskavas.
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. 
Töökava ei olnud koostatud selleks, et välja töötada ja esitada üksikasjad, kuidas saavutada strateegias/tegevuskavas püstitatud eesmärke, ega selleks, et lisada uusi eesmärke.
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. 
Lisaks ei näidata neis rahalisi vahendeid, mis on vajalikud iga eesmärgi saavutamiseks ja iga valitud meetme võtmiseks.
Was the process of selecting IT projects for implementation based on sound criteria? 
Kas EKP kasutas IT projektide valikul usaldusväärseid kriteeriume?
A process is therefore required to make a selection of the highest priority projects and thereby make best use of the resources available. 
Kõikidevõimalikeprojektiderahastamisekseioleigalaastalpiisavaidvahendeid.Seetõttuonvaja valida kõige prioriteetsemad projektid ja seeläbi olemasolevaid ressursse võimalikult hästi kasutada.
The2007projectprioritisationandselectionprocesswasbasedonathree-yearmedium-termproject 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. 
EKP üldeesmärke silmas pidades hindab EKP igal aastal uuesti kõiki projeke (käimas-olevad projektid, projektisüsteemis registreeritud, kuid veel alustamata projektid ja äsja registreeritud projektid).
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. 
Nimetatud keskpikka kava ajakohastatakse kaks korda aastas, et võtta arvesse äsja registreeritud projektid ja muud arengud. Projektide hindamisel võetakse aluseks nendega seotud tegevuskavade visandid ja nende rakendamiseks vajalikud vahendid.
This made project selection less objective, thus increasing the risk that the best use might not be made of the available resources. 
See vähendas projektide valiku objektiivsust, suurendades seega ohtu, et olemasolevaid ressursse ei kasutata mitte kõige paremal viisil.
In2008animprovedprojectprioritisationmethodologywasintroduced.Thiswasbasedona‘three pillar concept’ (2). 
2008.aastalvõetikasutuseletäiendatudprojektideprioriteetsuseseadmistkäsitlevmetoodika.See põhines kolme samba kontseptsioonil (2).
The methodology consisted of domain (3) specific assessments, followed by a consoli­ dation of these assessments at ECB level. 
Metoodika koosnes valdkonnale (3) antud konkreetsetest hinnan­ gutest, mis konsolideeriti EKP tasandil.
The IT project management system established in 2008 provided sufficient information for decisions to be made. 
2008. aastal loodud IT projektijuhtimissüsteem andis otsuste tege­ miseks piisavalt teavet.
Procedures for IT project management 22. 
IT projektijuhtimise menetlused 22.
The POCP includes a detailed definition of what constitutes a project and clearly sets out its field of application. 
Nimetatud dokumendis esitatakse projekti üksikasjalik määratlus ja sätestatakse selgelt selle kohaldamisala.
It also determines the organisational structure to be set up for projects, including the roles and responsibilities of the relevant participating entities. 
Samuti määratakse selles kindlaks projektide tarbeks loodava organisatsiooni struktuur, sh osalevate üksuste rollid ja vastutus.
(1) 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. 
(1) Näiteks võtta vastu parimad tavad projektide elluviimiseks ja juhtimiseks ning rakendada IT projekte kooskõlas kokkulepitud maksumuse, ajakava ja kvaliteediga, sh kasutajasõbralikkus.
(2) 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. 
(2) Esimene sammas: standardsed küsimused (22 parameetrit), teine sammas: agregeeritud analüüs klastrites ja kolmas sammas: agregeeritud esmatähtsustamise kriteeriumid lõplike otsuste vastuvõtmiseks EKP tasandil.
(3) The IT Project Directorate is organised into five domains. 
(3) IT projektide direktoraat hõlmab viit valdkonda.
Each domain is in charge of projects initiated by different Business Areas. (4) 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. 
(4) Projekti organisatsiooni-ja kontrollimenetluste alla ei kuulu väikesemahulised ülesanded, projektid, mis viiakse läbi ühe tegevusharu piires või mille puhul ei vajata IT lahendust, või IT infrastruktuuriga seonduvad ülesanded, mille testimise maht, uuenduslikkuse määr või organisatsiooniline mõju on vähene või mis ei loo uut teenistust.
The projects selected for detailed audit by the Court were all within the remit of the POCP. 
Kõik kontrollikoja poolt üksikasjalikuks auditeerimiseks valitud projektid kuulusid projekti organisatsiooni-ja kontrollimenetluste raken­ dusalasse.
EN C 32/6 Official Journal of the European Union 9.2.2010 23. 
C 32/6 Euroopa Liidu Teataja 9.2.2010 ET 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). 
Projektiorganisatsiooni-jakontrollimenetlusikäsitlevadokumendikohaseltmääratakseprojektide mõjusa kontrolli struktuur, jagades projekti tsükli loogilisteks etappideks ja määrates täpsed otsuste tegemist vajavad punktid (vt joonis 1).
A comparison of the POCP with the PMBOK showed that the POCP was to a large extent in line with this best practice. 
Eespool nimetatud dokumendi võrdlemine projektijuhtimise teabega näitas, et dokument on üldiselt kooskõlas parima tavaga.
Two areas in which the POCP could be improved include: stakeholder analysis and post-assessment of the project’s impact. 
Projekti organisatsiooni-ja kontrollimenetlusi võiks paran­ dada kahes valdkonnas, mis on sidusrühma analüüs ja projekti mõju järelhindamine.
The current weaknesses and their impact are detailed in the following paragraphs. 
Praeguseid puudusi ja nende mõju on üksikasjalikult kirjeldatud järgmistes punktides.
Diagram 1 — Project lifecycle phases Source: European Central Bank. 
Joonis 1 – Projektitsükli etapid Allikas: Euroopa Keskpank.
ThePOCPdoesnotrequiretheformalpreparationanddocumentationofastakeholderanalysis.This means that the project team does not have to formally identify the stakeholders and determine their specific project requirements (1). 
See tähendab, et projektimeeskond ei pea kindlaks määrama sidusrühmi ega määratlema nende konkreetseid projektiga seonduvaid nõudeid (1).
The absence of the formal identification of all stakeholders and their needs could have a negative impact on the success of a project. 
Kõikide sidusrühmade ja nende vajaduste kindlaksmääramata jätmine võib avaldada negatiivset mõju projekti edukusele.
It should be noted that in the case of the specific projects examined, user needs were considered (see paragraphs 33 and 36). 
Tuleks märkida, et kontrollitud konkreetsete projektide puhul olid kasutajate vajadused arvesse võetud (vt punktid 33 ja 36).
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). 
Järelhindamine annaks siiski muu hulgas ametliku hinnangu selle kohta, kas projekti heakskiitmise doku­ mentides esitatud soovitav kasu on kvalitatiivses ja kvantitatiivses mõttes saavutatud ja aitaks seeläbi kavan­ dada tulevasi projekte (vt punkt 53).
A recent positive devel­ opment 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. 
Hiljutiseks positiivseks tulemuseks nimetatud valdkonnas oli uus tagasiside vorm, millega nõutakse kliendi tagasisidet IT projektide kohta igal aastal. Selle eesmärgiks on anda ülevaade lõppkasutaja rahulolu kohta pakutud teenuse kvaliteediga.
Allocation of responsibilities and decision-making structure 26. 
Kohustuste jaotus ja otsuste tegemise struktuur 26.
Toensurethatprojectsareimplementedefficientlyandeffectivelyitisnecessarytoestablisha framework for managing them setting out clear reporting lines and responsibilities of the bodies and functions involved in the process. 
Projektidetõhusajamõjusaelluviimisetagamiseksonvajaluuanendejuhtimisraamistik,määrates selged alluvussuhted ja protsessi kaasatud organite vastutus ja funktsioonid.
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). 
Projektiorganisatsiooni-jakontrollimenetlusihõlmavasdokumendisesitatiEKPprojektijuhtimiseks ettenähtud organisatsiooniline struktuur, sh osalevate üksuste rollid ja vastutus ning koosseis (vt joonis 2).
(1) According to section 2.2 of the PMBOK, this is necessary in order to ‘ensure a successful project’. 
(1) Vastavalt projektijuhtimise teabe teise osa punktile 2 on see projekti edukuse tagamiseks vajalik.
The PMBOK further stipulates that ‘failure to identify a key stakeholder can have a negative influence on the project’. 
Lisaks sätestatakse projektijuhtimise teabes, et põhilise sidusrühma määramata jätmine võib avaldada projektile negatiivset mõju.
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’. 
Projek­ tijuhtimise teabe 10. osa punktis 1 „Projekti teavitamise kavandamine” väidetakse, et sidusrühmade vajaduste ja nende rahuldamiseks sobivate vahendite kindlaksmääramine on projekti edukuse seisukohalt tähtis tegur.
EN 9.2.2010 OfficialJournaloftheEuropeanUnion C32/7 Diagram 2 — Overview of ECB’s project management framework Source: European Central Bank. 
ET 9.2.2010 EuroopaLiiduTeataja C32/7 Joonis 2 – Ülevaade EKP projektijuhtimise raamistikust Allikas: Euroopa Keskpank.
Clear reporting lines are set in the POCP between the bodies and functions engaged in the project management process. 
Projektiorganisatsiooni-jakontrollimenetlusihõlmavasdokumendisonmääratudselgedprojekti­ juhtimise protsessi kaasatud organite ja funktsioonide vahelised aruandlusahelad.
The Project Steering Committee is the main ECB internal decision-making body for project prioritisation, planning, approval, and monitoring. 
Projekti juhtkomitee on peamine EKP-sisene organ, kes teeb otsuseid projekti prioriteetide seadmise, kavandamise, heakskiitmise ja kontrollimise kohta.
The structure created by the POCP encompasses all the necessary functions and provides clear decision-making procedures with pre-defined roles and responsibilities. 
Eespool nimetatud dokumendiga loodud struktuuriga hõlmatakse kõik vajalikud funkt­ sioonid ja esitatakse selge otsuste tegemise menetlus koos eelnevalt määratud osatähtsuse ja vastutusega.
Was the governance framework established for the management of the IT projects applied as intended? 
Kas IT projektide juhtimiseks kehtestatud haldusraamistikku kohaldati ettenähtud viisil?
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. 
IT projektide haldusraamistiku kohaldamise auditeerimisel kontrollis kontrollikoda, kas EKP: — kavandas üksikprojekte nõuetekohaselt, hinnates projekti eesmärke ja kavandatud lahendust ning võttes arvesse vajalikke vahendeid; — rakendas üksikprojekte nõuetekohaselt, tagades vahendite kättesaadavuse õigel ajal ja kontrollides piisa­ valt iga projekti väljundit; — kontrollis projekti elluviimist, luues süsteemid, millega esitada projekti kõiki asjakohaseid andmeid kokkuvõtvad aruanded, mis on otsuste tegemiseks vajalikud; — hindas ametlikult projekti väljundeid ja projekti lõpuleviimiseks kasutatud vahendeid.
The Project Submission Document (PSD) 30. 
Projekti esitamise dokument 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. 
Projektikavandamineonasjakohane,kuisellegakäsitletaksejärgmist:i)projektiüldeesmärgidja ulatus, ii) kavandatud lahendus, iii) projekti vahe-eesmärgid ja väljundid, iv) finants-ja inimressursid ja v) projektimeeskond.
EN C 32/8 Official Journal of the European Union 9.2.2010 31. 
C 32/8 Euroopa Liidu Teataja 9.2.2010 ET 31.
The main planning document is the Project Submission Document (PSD) (see Diagram 1). 
Peamine kavandamisega seonduv dokument on projekti esitamise dokument (vt joonis 1).
This document serves as the basis for a decision as to whether the selected project solution should be imple­ mented. 
Nimetatud dokumendi alusel otsustatakse, kas valitud projekti lahendust tuleks rakendada.
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. 
Kõigi kuue kontrollitud projekti puhul oli kõnealuse dokumendi sisu põhjalik ja selles käsitleti kõiki peamisi küsimusi, mida tuleks projekti heakskiitmise ajal arvesse võtta.
Project authorisation and selection 32. 
Projekti heakskiitmine ja valik 32.
AllprojectswereauthorisedinaccordancewiththeproceduresforeseeninthePOCP.Beforeeachof the three project phases (1), a formal decision to go ahead was taken by the Project Steering Committee. 
Kolme projekti puhul võttis projekti juhtkomitee enne iga projekti etappi (1) vastu ametliku otsuse järgmise etapi kohta.
Three projects (2) were considered as ‘must-do’ projects to comply with ESCB or other required standards. 
Kolme projekti (2) peeti EKPSi või muude nõutud standardite järgimise seisukohalt vältimatuteks projektideks.
The others (3) were selected on the basis of the project prioritisation methodology. 
Teised projektid (3) valiti välja projekti priori­ teetide seadmise metoodika alusel.
All projects were consistent with either the DG-IS ‘strategic/operational outline’ or the general strategies of the Business Areas concerned. 
Kõik projektid vastasid kas infosüsteemide peadirektoraadi strateegiale/ tegevuskavale või asjaomaste organisatsiooniüksuste üldisele strateegiale.
User demands and project specifications 33. 
Kasutaja vajadused ja projektide tehniline kirjeldus 33.
In the case of three of the projects (4) examined, the user requirements were assessed and docu­ mented at the planning phase. 
Kolme kontrollitud projekti puhul(4) hinnati ja dokumenteeriti kasutaja vajadused kavandamise etapis.
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. 
Kolm ülejäänud projekti olid seotud TCERTOga või olemasoleva infrastruktuuri (EKP Eurotoweri kohtvõrgu värskendus ja peamiste arvutiruumide ala uuendamine Eurotoweris) ajakohastamisega, kasutajaid kavandamise etapis ei kaasatud.
This approach was not applied in the best possible way. 
Kõnealust lähenemisviisi ei kohaldatud mitte kõige paremal viisil.
This resulted in delays and the test versions were not as sufficiently developed as expected. 
Selle tulemuseks olid viivitused ja testversioonid olid oodatust halve­ mini välja arendatud.
Risk assessment 34. 
Riskihindamine 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. 
Projektieesmärkidemittesaavutamisegaseotudriskidtuleksmääratakindlakspiisavaltüksikasjalikult. Lisaks tuleks need struktureerida ja kavandamise etapis põhjalikult hinnata, milline on riskide tõenäosus ja võimalik mõju projekti eesmärkide saavutamisele.
There is a specific section on risk analysis in the templates for each of the three planning documents (5). This section was completed for all project PSDs. 
Igakolmekavandamisegaseotuddokumendivormisonriskianalüüsiksettenähtuderiosa(5). Selline osa oli täidetud kõikides projekti esitamise dokumentides.
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. 
Projekti riskide kindlaksmääramisel ja nende võimalikkuse ning mõju hindamisel puudus siiski ühine lähenemisviis. Hindamise aluseks oli iga projektijuhi isiklik kogemus.
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. 
Projekti elluviimise käigus ilmnesid ka sisemised materiaalset laadi riskid, nagu vahendite piiratus.
As these issues were not recognised as risks, no corrective action was foreseen at the planning stage. 
Kuna selliseid probleeme ei peetud riskideks, siis kavandamise etapis parandusmeetmeid ette ei nähtud.
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. 
Rahapoliitiliste otsuste rakendamise tugisüsteemi puhul oleks võinud ette näha ka teisi riske, kuid neid projekti esitamise dokumendis ei mainitud, nagu näiteks nende organisatsiooniüksuste keerukus, mille jaoks projekt oli kavandatud.
Resource management and user participation 36. 
Vahendite haldus ja kasutajate osalus 36.
For three of the projects (6) examined, the resources and skills allocated to implement the project were sufficient. 
Kolme kontrollitud projekti puhul (6) ei olnud projekti elluviimiseks eraldatud vahendid ja oskused piisavad.
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. 
Turuinfo esituse puhul ei olnud selle kasutajad alati kättesaadavad, kuna samal ajal lõpetati ühte teist sarnast projekti.
The procurement of an external developer caused a three-month delay. 
Välisarendaja kasutamine põhjustas kolmekuulise viivituse.
After being contracted, the developer changed frequently, causing problems in the project implementation. 
Pärast lepingu sõlmimist välisarendaja tihti vahetus, mis tekitas projekti elluviimisel probleeme.
Due to its complexity the project was implemented in different phases (7). 
Oma keerukuse tõttu teostati projekti mitmes etapis (7).
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. 
Teadmiste üleandmine teisest etapist kolmandasse ei toimunud ettekavatsetud viisil, kuna enamus projektimeeskonnast, sh projektijuht oma tööd kolmandas etapis ei jätkanud.
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. 
Enamiku projektide puhul olid kasutajad esindatud projekti juhtrühmas ja/või projektimeeskonna koosole­ kutel ning samuti teavitati neid igakuistest projekti eduaruannetest.
(1) Project initiation, preparation and implementation phase. 
(1) Projekti algatamise, ettevalmistamise ja rakendamise etapp.
(2) TCERTO, Target 2 SSP and EER. (3) MDP, MPIDS and MAU. 
(2) TCERTO, Target 2 süsteemi ühisplatvorm ja EKP Eurotoweri kohtvõrgu värskendus.
(5) Project Initiation Document, Project Preparation Document and Project Submission Document. 
(5) Projekti algatamise dokument, projekti ettevalmistamise dokument ja projekti esitamise dokument.
(7) Phase 3 was selected for audit by the Court. 
(7) Kontrollikoda valis auditeerimiseks kolmanda etapi.
EN 9.2.2010 OfficialJournaloftheEuropeanUnion C32/9 External contractors 38. 
ET 9.2.2010 EuroopaLiiduTeataja C32/9 Välislepinguosalised 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. 
TuruinfoesitusthõlmavaprojektipuhultehtierandseosesEKPhankeidkäsitlevateeeskirjadegasel põhjusel, et hanget ei oleks saanud eraldada eelneva tarnija valikust.
However, software development and support were not the core business of this supplier. 
Tuli ilmsiks, et tarnija ei olnud suuteline ega võimeline pakkuma soovitavat lahendust, kuna tarnija põhitööks ei olnud tarkvara arendamine ja tugiteenused.
This made the development part of the maintenance release more expensive than foreseen. 
Probleemide tõttu osutus hooldusredaktsiooni arendamine ettenähtust kallimaks.
Testing and acceptance of the project deliverables during implementation 39. 
Projekti väljundite kontrollimine ja heakskiitmine projekti elluviimise ajal 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. 
EKP menetluse üks osa on uue või muudetud IT väljundi kontrollimine, mida tuleb teostada enne iga väljundi kasutuselevõtmist.
All six projects were tested before release. 
Kõiki kuut projekti enne nende kasutuselevõttu kontrolliti.
Tests were designed by the project team. 
Kontrollide kavanda­ jaks oli projektimeeskond.
However, end-users were not always involved in the development of the tests with the consequence that improvements needed were not identified in time. 
Lõppkasutajaid kontrollide kavandamisse siiski alati ei kaasatud, mistõttu vaja­ likke parandusi ei määratud õigel ajal.