LGAF Project Management Lessons learned


Published on

Local Government Application Framework (LGAF) , Project Management Lesson Learned Mohamed Farrag Soliman Alokaily

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

LGAF Project Management Lessons learned

  1. 1. Local Government Application Framework (LGAF) Team (Alphabetically): Liliana Simion Marian Simion Mohamed F. Soliman, PMP Taranpreet Singh CASE STUDY- PROJECT MANAGEMENT – CEE9510 Mr. Kevin McGuire, M. Eng., P. Eng., PMP MEng 2013 Summer Term
  2. 2. Case Study Page 2 INTRODUCTION TO LGAF------------------------------------------------------------------------------------ 3 LESSONS LEARNED -------------------------------------------------------------------------------------------- 5 Lesson Learned #1: Tender should have favoured companies with a history of managing open source projects---------- 5 Lesson Learned #2: Business model must be adapted to the open source needs ---------------------------------------------------- 6 Lesson Learned #3: Lack of matter experts, like ecosystem Software experts can hurt the project. ------------------------ 7 Lesson Learned #4: Start up with a clear business process---------------------------------------------------------------------------------- 8 Lesson Learned #5: Importance of technical and business awareness among the stakeholders -------------------------------- 9 Lesson Learned # 6: Stakeholders must have clear and detailed information about the project scope ----------------------10 Lesson Learned # 7: New IT projects need legislative support to be implemented-------------------------------------------------11 Lesson Learned # 8: Open source projects are suitable to a mature open source market----------------------------------------12 Lesson learned # 9: Planned budget must follow the schedule---------------------------------------------------------------------------14 Lesson learned # 10: Subcontractors are most affected by financial delays ----------------------------------------------------------16 Lesson Learned # 11: External funding might not be available in economic crisis situations ------------------------------------16 NOTES ---------------------------------------------------------------------------------------------------------- 19 BIBLIOGRAPHY ---------------------------------------------------------------------------------------------- 21
  3. 3. Case Study Page 3 Introduction to LGAF LGAF or the Local Government Application Framework involves the development of an open source platform that would allow citizens and the subject matter experts to access useful information online as well as pay taxes and fines, modify their public administration records and purchase permits and licenses.1 The ambition also encompasses upgrading the service of both citizens and enterprises in 16 Greek municipalities following the rule “Develop once, use many”, to improve the quality of the services offered by automating the communication between the participating municipalities and the citizens.2 The Vision LGAF aims at offering a single source, end-to-end, service-oriented architecture (SOA) solution for e-government implementation at the local administration level (OTA): I. Development of an online platform for payment of taxes and fines, modify public administration records, and purchase permits and licenses II. Innovation through the combined use of Business Process Management (BPM) & service-oriented architectures (SOA) III. Easy access to electronic services through different web interfaces like web services, RESTful APIs and GWT IV. Functionality of Legacy applications using SOA V. Less dependent municipalities on specific software companies because of open architecture The Tender Process The tender for the LGAF was drafted by the Central Union of Municipalities of Greece (Kede) and was an open international process. The contract, worth 1,577,463.72 euros was signed on 30th July 2007 with SingularLogic, a company that had extensive IT experience in the field of local government, but did not have a tradition of running open source projects. The Participating municipalities Between 2007 and 2009 16 Greek organizations and municipalities participated in LGAF.
  4. 4. Case Study Page 4 The Funding The project has been funded by the National Strategic Reference Framework (NSRF) since 2007, which is a structural fund of the European Union. However, NSRF subsidy ends after 2013. The Challenges3  Offering uniform e-services to both citizens and businesses alike  Standardising procedures across the participating municipalities  Automation of manual work  Consolidation of existing applications and ensuring interoperability with legacy systems The Outsourcing Since SingularLogic had no experience in the open source domain, it outsourced the project to five subcontractors:  BetaCONCEPT, a specialist in semantic and data technologies; it undertook the implementation of the enterprise content management system  ERP specialist Hilton Informatics  the Atlantis Group at the Computer Technology Institute (CTI), a specialist in business process management (BPM)  International Software Techniques (IST), the business services specialist  Institute of Communication and Computer Systems (ICCS) at NTUA (National Technical University of Athens): Development of identity management system Present State of the Project The project should finish in 2013, when LGAF would have been made available to all Greek municipalities at no cost. After 2009, nine of the sixteen municipalities stopped participating owing to a number of reasons. Also, in late July 2012, six of the seven remaining municipalities also stopped participating in the project. At present the LGAF was partly implemented in the municipality of Larissa, and the transition to complete implementation continues until the end of 2013.
  5. 5. Case Study Page 5 Lessons Learned Lesson Learned #1: Tender should have favoured companies with a history of managing open source projects LGAF was awarded to Singular Logic, a privately owned company that specializes in the development of proprietary software and providing system integration solutions. It also has extensive experience in management of projects based on technologies sourced from big IT vendors like Microsoft, Google, Oracle etc. Even though the project was eventually awarded to Singular Logic, the company had never ventured into the field of open-source projects, thus had no experience in this domain. Consequently, it outsourced the project to several others sub-contractors who had experience in this field. Extensive analysis of the case revealed that there were two principal reasons for collaborating with external vendors or sub-contractors:  The lack of experience in the open source domain  To encourage innovation by venturing into a new but unknown territory The project manager, Elias Giannitsios assumed that the management of this project would follow the general concepts of project management, and that it wouldn’t be affected by the sheer scope of the project. But since there were about five subcontractors, special heed should have been paid to the management of time, cost, quality management as well as co-ordinating with the vendors. The principal reasons4 for the failure of an open source project are:  Underestimating people, time, and required funds  Selecting the wrong vendors, if involved  Failure to build community around the open source project  No previous experience in managing a project in the same domain In addition, some of the key management issues in the management of an open source project are:  Taking care of development milestones  In case of multi-vendor reliance, keeping track of who is doing what  Deciding on the development and release schedule
  6. 6. Case Study Page 6  Who is responsible for co-ordination between the multiple vendors Therefore, the main reason for the failure of LGAF was not at all technical. However, it did commit some cardinal sins in managing an open source project. First, they overestimated the funding. Second, Singular Logic focussed on integrating the work of different vendors, since this was what the company specialized in. In conclusion, they failed to realise that the management of an open source project needed to be more agile as compared to some of the previous projects they had managed. Recommendations: The public tenders should have favoured a company that has had previous experience in the open source domain and whose business models are based on service delivery and maintenance of open source software. The tender should have gauged the chosen IT supplier on the knowledge of open source ecosystems, licensing models, version management, and the formation of an open source community. Lesson Learned #2: Business model must be adapted to the open source needs. The tender for LGAF involved bidding from some foreign multinationals too but ultimately the contract was signed with Singular Logic (owing to its experience with the local government on July 30, 2007). The project was scheduled to be completed by early 2013. However, the project is still considered to be in the development phase. In addition, most of the funding for the LGAF came from National Strategic Reference Framework (NSRF). Also, the NSRF subsidy ended after May 2013 with only the pilot phase being completed this year. But since the project was gravely behind schedule, a new business plan needed to be formulated for 2013. This is something which Singular Logic is currently lacking. Consequently, most of the companies lost business interest in LGAF, and the project is bound to be in an even graver situation for the next years. Singular Logic needed to adapt its traditional business model which was primarily based on providing system integration solutions. The LGAF was quite different from the projects that Singular Logic had previously undertaken. Therefore, it needed to adapt its usual approach to a
  7. 7. Case Study Page 7 project in order to suit projects in the open source domain, since such projects require special emphasis on service delivery and maintenance. Recommendations: Even after 2009, when nine municipalities stopped participating in LGAF, Singular Logic didn’t adapt its business plan. Consequently, six other municipalities also stopped participating, owing to consistent delays in the project. In conclusion, a company without related experience to perform an open source business is required a great deal of adaptation to the new job conditions. This meant changing their business view entirely: from a rigid, closed view of managing proprietary software, to an open view of implementing an open source platform at almost the country level, which never happened. Lesson Learned #3: Lack of matter experts, like ecosystem software experts, can hurt the project. One of the main goals of LGAF5 is interacting with municipality software and comprising all activities of the municipalities. LGAF lacked an ecosystem6 of municipality software into which it could blend seamlessly. Such an ecosystem was necessary to maintain the current platform efficiently. There are about five Greek companies that create municipality software. Only one of them is slightly open to open source software. Whenever an e-government services platform like LGAF gets new features, they should be debugged within the existing software environment7 . This requires the cooperation of the suppliers of the software. Practically it requires a shared working team between all vendors to come up with an integration plan to unify the communication between the systems. In addition, vendors need to be aware of test methodologies, agree about the testing strategy, and identify when to consider that the integration test is acceptable, then approve it. Recommendations: It’s recommended to ask the IT supplier to enrich their teams with ecosystems software experts matter and municipalities’ experts matter as well. The chosen IT suppliers should also have
  8. 8. Case Study Page 8 Three main pillars extensive knowledge of open source ecosystems, licensing models, version management, and the formation and fostering of communities. Lesson Learned #4: Start up with a clear business process Greek communities were not ready for LGAF. They have a very low degree of automation, so a lot of procedures are still totally dependent on paperwork. Therefore, the officials had to alter their daily routines and workflow radically for the project. That hindered the acceptance of LGAF significantly. For inclusion of this kind of a project, the preparation of a good plan comprises three main points: 1. People – what are the key issues: who owns the process, who is involved in the system, what are their roles, etc. 2. Process - a process can be defined as starting with a trigger event that creates a chain of actions that result in something being prepared for the customer. Starting at high level and identifying the key big steps is important in order to see the process from end to end, then moving into more detail to capture the various layers involved and various exceptions. 3. Technology – now that people are aligned, and the process developed and clarified, technology can be applied to ensure consistency in application of the process and to provide the thin guiding rails to keep the process on track. LGAF is built with the latest open source Java technologies such as Spring Framework, EJB3, Jboss Cache, JSF, Rich Faces, and Seam. Neglecting one of these pillars reflects directly in another three critical phases which are testing phase, implementation phase, and user acceptance phase. Moving from manual work or paperwork environment to automated environment is a project by itself, which needs a lot of efforts and plans. These efforts include understanding the current work process and document it as a kind of input for the next step. This next step is improving the business process and put plans to minimize the user resistance for the new process. Then, and only then, we can start implementing new systems.
  9. 9. Case Study Page 9 Recommendations: It is recommended to decrease the project timeframe and expand the project scope to include business process improvement. It is a prerequisite for the new systems to build a kind of bridge between the current business process and the target system. Lesson Learned #5: Project stakeholders need to have a common understanding of the project through technical and business awareness sessions Another problem is that Greek public officials in general lack sufficient business as well as technical knowledge to develop a smart IT strategy for the long term. At the start of the project the client, Kede, used some external advisors who had a brilliant vision. That is why LGAF had a visionary design. But they did not take the necessary steps to guarantee that this innovative open architecture received the support of all the parties involved. The implementation of an open architecture like LGAF requires a paradigm shift in the thinking of the suppliers of the existing software ecosystem. It needed their cooperation to deploy the system. Kede, however, did not communicate the general principles behind LGAF to municipalities and suppliers of legacy software. It did not explain properly that the goal of LGAF was to create an open infrastructure to which all municipality software suppliers could combine services using a set of standardised components and APIs. This lack of communication was not due to unwillingness. It was mainly caused by a lack of a strategy for adoption, as well as lack of technical awareness within Kede and the participating municipalities. Making a comparison with business opportunities in Ireland (for small but technically advanced open source companies like Beta Concept), it is easily noticed a large difference between attitudes related to open source technology between Ireland and Greece: In Ireland the technical awareness of public officials is incredibly high. IT companies can communicate with them about technical concepts, even if they do not have a technical background or high function. Therefore, there is no way to establish a communication with any party unless they both have an acceptable level of common understanding. For example, if there is no basic level of knowledge about processing or
  10. 10. Case Study Page 10 creating IT products, how can stakeholders expectations be set or managed, especially in projects like LGAF? Recommendations: It’s recommended to have a communication plan in place for all stakeholders’ levels including public and private, at the management and project staff, to increase the business and technical awareness of the project. No doubt, communication needs relate to the parties’ needs and responsibilities in the project, in order to build a common understanding across the project. Lesson Learned # 6: Stakeholders must have clear and detailed information about the project scope LGAF was a “visionary project” of an open software infrastructure among all municipalities of Greece8 . However, subcontractor Gregory Chomatas of Beta Concept said that the municipalities who were initially willing to embrace the project changed their minds because of the lack of detail about what the project was about, how it could be accomplished, and what the results should have been. This demonstrates primarily a misunderstanding about the scope of the project: municipalities’ administration considered the open source project as another e-portal among municipalities (and e-portals failed previously), instead of a software open platform to create and rewrite the common base data among municipalities. The OSEPA9 project, called Open Source Software Usage by European Public Administrations (Dec. 2012), reported three critical factors necessary to the success of FOSS (Free and Open Source Software) in public administrations: political, organizational, and technical implementation factors. That would mean that understanding the scope of the project is relevant not only to the technical staff and IT managers of the project, but project scope is most importantly relevant to the top managers who are making decisions and can steer the project towards finding IT solutions and software procurement for the success of the project. It is a strategy played at the top level and involving political choices, more than it is a technical matter10 .
  11. 11. Case Study Page 11 Recommendations: One thing that LGAF project lacked was clear communication11 with the stakeholders, which made LGAF lose the support of the top leaders of the fifteen municipalities; the failure of this project demonstrated that “sharing knowledge, communicating success stories and transferring good practices between public administrations that face similar challenges ... is the key to effective implementation and sustainable results.”12 Lesson Learned # 7. New IT projects need legislative support to be implemented “The legal system in Greece was not ready for the project”, said subcontractor Kranidiotis of Hilton Informatics.13 In 2010 there wasn’t any legal framework for the development of eGovernment practices and any freedom of information legislation in Greece14 . Therefore, documents had to be signed in person to be valid. Under law # 2690/1999 on the Ratification of the Administrative Procedure Code of Greece, eGovernment in Greece states that “interested persons have the right to access administrative documents created by government agencies. The request must be in writing.”15 This means that all government documents that involved a change in content of any kind had to be printed, so that it could be signed. This meant a lot of extra work, and the fifteen municipalities of Greece who withdrew from the project preferred to turn their backs on this, too. The bureaucracy in Greece was supported by the legislation, and the introduction of an open source platform needed a proper legislation package to permit electronic signatures, instead of paper signatures. In fact, Greece was moving towards a “digital convergence” with the other countries in Europe16 , as progress started to be made by the step by step implementation of the “Digital Strategy 2006-2013” and the “Operational Programme for the Information Society”. The areas to be implemented were from diverse sections of the Greece government: police, military, urban and rural development and real estate, customs, etc. A few of them are presented below:
  12. 12. Case Study Page 12  The Helenic Police Network that would create some electronic services for citizens and would connect 1100 police departments;  The Online Monitoring and Automatic Information & Data Management System of the Urban Planning Agencies, which would permit the managing of complains related to urban development;  Online tax and customs services;  The Information System for Greek Agricultural Security Association, which would give information about financial support and compensation. Also, this long term IT strategy comprised developments at the local municipality level as well. LGAF open source project was part of this broadband electronic digitalization of Greece administration. However, LGAF was better to start after all political, legislative, and administrative paths were cleared. OSEPA mentions the benefits of political support: “it is much more likely to overcome policy related issues that may arise. Having political support enables policy modifications/improvements”17 , like the law that demands written signature. Recommendations: For future implementation of open source projects, proper legislature needs to be in place to define the principles of open source technology and also to educate public administrations and IT suppliers to see the full potential of these software platforms. Lesson Learned # 8: Open source projects are suitable to a mature open source market In December 2009 a study called “Governance in the Age of Web 2.0” was conducted in Greece, and showed that Greeks look positively at using e-services18 :  83.6% acknowledged the operating hours of e-services: anytime;  70.9% appreciated the decrease of transactions face-to-face;
  13. 13. Case Study Page 13  61.2% praised the fast response of e-services compared to human services;  55.6% realized the decrease in paper use;  45.9% liked the increased transparency of government services. However, the electronic private services in Greece were limited and not fully integrated in every day life of Greeks:  51% of the population uses computers;  44% of the population has internet access (used or not);  Only 34% of the population uses internet regularly;  Only 6% of the population performed electronic transactions. The same study remarks that these limitations of e-services in public sectors are caused by a multitude of factors related to the piecewise mainframe organization of municipalities: lack of interoperability among data systems, as each municipality website or portal created its own data program with little chances to be expanded and linked to a general mainframe. Also, political and administrative barriers are described, as in Greece, companies request clear property rights on projects and refuse to enter a project if these are not clearly defined at the on-set of the project. The culture and tradition of Greek private and public organizations limited the implementation of open source business models, where delivery and maintenance ensure profit - not selling software licenses. Subcontractor Kavassalis adds that “this culture does not exist in Greece yet.”19 In the study made by OSEPA it is raised the importance of another critical factor for the adoption and implementation of e-services: the organizational frame related to employee and management training. As a known fact, any change produces some resistance, but personnel training raises awareness about why changes are beneficial. Also, training of relevant people would ensure that staff is prepared for active end-user involvement and knows what to expect from the software20 . In addition, OSEPA recommends personnel training within the already established open source frameworks from other communities or countries, so the relevant people have some hands on
  14. 14. Case Study Page 14 training and peer support and encouragement with working open source projects, not only using the theoretical lessons. At the Euro Spring Conference 2012, LGAF was referred to as a pilot study which has not been operational yet because of some organizational requirements related to the unification of software platforms of all municipalities into a centralized one. After studying the LGAF case, the major obstacle that delayed and brought partial failure of the project was the “low level of public demand for innovative services and specifically the demand articulated by local government bodies.”21 It is specified that no local municipality can be considered an “intelligent customer”, as they lack the human resources to monitor the design and implementation and be actively involved in this kind of project.22 Recommendations: Open source projects are better received and implemented when the related cultural and traditional climate is mature. It is also recommended that related personnel receive not only theoretical but also practical training in communities that operate in the open source model; in this way the scope is clearer and can be communicated around, and there is more preparation for the realities of the project integration. Lesson learned # 9: Planned budget must follow the schedule There are many reasons for which projects fail, and one of these reasons is funding. When starting a project it is very important to known the funds available for the project and to envision if the funds can grant sustainment for the whole project or only for a part of it. Even projects that have very strong driven marketable objective fail due to the lack of funding, or even worst, due to wrong estimates of the required funds to sustain the whole project. One of the major problems of the Greek project LGAF was the funding. The countries that are members of the European community are aware that the money coming from EU funds are very
  15. 15. Case Study Page 15 hard to be obtained, there are always delays, and the financing of the projects is based on the project performance, measured usually by the grade of the project implementation. The bureaucratic apparatus in such a huge organization as EU is slowing processes down, as well. There are steps, procedures, and assessments that make the funding process very tedious and time consuming. It is well known that the funds are not coming in lump sums; usually organizations like this lend in tranches, so the project is funded as it goes. Each tranche requires a lot a paper work, reports and documents to justify each euro cent spent. Usually successful projects are funded with a mixture of national capital and euro funds infusion. Starting an IT project at the national level in a country in which the population doesn’t have a great IT exposure and technical knowledge is a very ambitious project. In this situation is obvious that the success of the program will require a lot of funding as a first step to create the required infrastructure, and after this, to implement the project at the national level. Statistics shows than IT projects have a greater rate of failure compared to projects in non IT fields. It seems that from start the project received a little amount of money from NSRF (National Strategic Reference Framework), a structural European fund; the money was not enough to deliver all the project features after its first funding phase. All the features in the first funding phase were considered requirements for future funding. Because the requirements were not met completely, the NSRF inspection committee did not approve any retrospect project financing for LGAF. Also the inspection committee argued that they financed similar projects that failed23 . It took months of discussions and negotiation between Greek government agency and NRSF to clarify that LGAF project is unique and can’t be compared with any previous IT project financed with EU structural funds. In the end the project team received only a part of the agreed funding and the supplementary financing was internally sourced, so the project was ready for implementation phase in only one municipality from the total of 16 organizations. To ensure the success of the project the Greek government should have provided a secure and stable funding for the project development.
  16. 16. Case Study Page 16 “The resulting funding inconsistencies made these investments very risky” stated subcontractor Petros Kavassalis24 , from Computer Technology Institute (CTI). Recommendations: Such a futuristic project as LGAF is supposed to be designed in at least two stages: a pilot phase involving the infrastructure and the implementation for a small area, and next, all of this to lead to a success that will further warrant funding sustainment from National Strategic Reference Framework (NSRF) for the project’s implementation phase at the national level. Lesson learned # 10: Subcontractors are most affected by financial delays The government contractor Singular Logic did not have the experience required for an open source project like LGAF and chose to outsource the project to a network of small companies that were involved more or less in previous open source projects. The small companies being the end links of the financial chain were the most affected by the financial delays. The subcontractors received no payments or only parts of payments after long delays. One of the small companies involved in the project, Beta Concept, had to close its doors in 2012 due to the financial problems connected with delays and part payments. Unfortunately Beta Concept was one of the few companies that had experience with open concept projects in Greece. Beta Concept moved to Ireland and managed to be successful in a very short period of time. This shows one more time that Greece didn’t have the IT maturity or the premises for such a visionary project as LGAF. Recommendations: The tender procedure should favour companies with expertise in open source technologies, maintenance and service delivery based on open source software, so they will have further interest in developing the project. In this way the companies will be the direct beneficiary of the funds and the intermediate person would be eliminated. Lesson Learned # 11: External funding might not be available in economic crisis situations
  17. 17. Case Study Page 17 Greece is one of the top countries that used intensive EU aids. Up to 3.3% of annual GDP (Gross Domestic Product) in Greece is covered by European funds. The Greek economy had grown over the years by 4% and this happened mostly due to the infrastructural expenditures related to 2004 Olympic Games in Athens, and partly due to an increased availability of credit, which has sustained record levels of consumer spending. The economical prosperity ended in 2009 when the country was hit by the world economical crisis. Tightening credit conditions and government failure to address a growing budget deficit pushed Greece over the edge of 3% of GDP budget criterion established by Growth and Stability Pact for the EU members25 . Greece struggled to meet this criterion during 2001-2006, finally met it in 2007-2008, and in 2009 the deficit stroked to 15% of GDP. “In May 2010, the International Monetary Fund and Euro-Zone governments provided Greece emergency short- and medium-term loans worth $147 billion so that the country could make debt repayments to creditors.”26 This credit was followed by another bailout package of $169 billion with a call to the Greece creditors to write down a good portion of their holdings in Greek Government Bonds. In order to receive the first tranche of financial aid, the Greek government promised in exchange $40 billion combining spending, increased taxation, and cuts over three years. The second tranche in 2011 added an extra $7.8 billion on top of the promised $40 billion27 . “Years of profligate state spending and poor fiscal management have left Greece dependent on international rescue loans from other European countries and the International Monetary Fund since May 2010.”28 In return to bailouts the government started to cut pensions, salaries, and increase taxation, turning the economic crisis in a perpetual depression. More than 26% of work force is currently out of jobs, the youth unemployment rate hits 60% in an economy that shrinks every day29 . The salaries were significantly reduced and often paid with delays. In a continuous degrading economy it was very difficult for officials to focus on projects like LGAF, when they were facing a lot of problems connected to the income required to support their own families. Recommendations:
  18. 18. Case Study Page 18 When a country deals for long periods of time with economic deficits and difficulties in paying the external debits, it is not recommended to start a visionary project like LGAF at the national level, based only on external financial resources. The Greek officials were supposed to lunch projects to help improving the actual economical situation and after that to think about great IT projects.
  19. 19. Case Study Page 19 Notes 1 Greece, Ministry of Interior General Secretariat of Public Administration and e-Government, “Greek e- Government Interoperability Framework”,(June 2013), http://www.e- gif.gov.gr/portal/page/portal/egif/. 2 Theodoros Karounos, “LGAF: Local Government Application framework”, May 2009, http://www.infostrag.gr/wp-content/uploads/2009/06/karounos_kedke_peta_22_5_2009.pdf. 3 SingularLogic,”Customers – Projects: LGAF”, accessed June 16,2013, http://portal.singularlogic.eu/en/case-study/2257/local-government-access-framework-lgaf. 4 Tony Wasseman & Carnegie M. West ,“How to start an Open source Project”, January 2007, http://www.slideshare.net/gnunify/how-to-start-an-open-source-project. 5 Greece, Ministry of Interior General Secretariat, “Greek e-Government Interoperability Framework.” 6 Wikipedia, the Free Encyclopaedia, “Software Ecosystem”, accessed June 2013, http://en.wikipedia.org/wiki/Software_ecosystem. 7 Jolein De Rooij, “Lessons Learned from a Greek Open Source Project”, (JoinUp European Commission), May 07, 2013, http://joinup.ec.europa.eu/elibrary/case/lessons-learned-greek-open- source-project. 8 Ibid. 9 European Union, “OSEPA Report on Critical Success Factors, December 2012“, (June, 2013), http://osepa.eu/site_pages/News/147/OSEPA_CP3_Report_on_Critical_Success_Factors_10122012.pd f. 10 Ibid., 28. 11 Project Management Institute, A Guide to the Project Management Body of Knowledge, 4th ed., (Pennsylvania: PMI, 2008), 255. 12 European Union, “OSEPA Report on Critical Success Factors, December 2012“. 13 Ibid.,10 14 Greece Government, “eGovernment in Greece.” (April 2010), http://www.observatory.gr/files/meletes/eGovernment_in_GR_April_2010_en.pdf., p.16. 15 Ibid. 16 Ibid.,11. 17 European Union, “OSEPA Report on Critical Success Factors“(June, 2013), p. 22.
  20. 20. Case Study Page 20 18 Greece, “eGovernment in Greece”, 14. 19 “Lessons Learned from a Greek Open Source Project,” 10. 20 European Union, “OSEPA Report on Critical Success Factors“,p. 23. 21 Yannis Caloghirou, “Public Procurement for e-Government Services”, 51-53, http://eu-spri-conference- 2012.org/conf-org-wAssets/docs/Book-of-Abstracts.pdf. 22 Ibid. 23 Jolein De Rooij, “Lessons Learned”. 24 Ibid. 25 CIA, “World Fact book” (June 2013), https://www.cia.gov/library/publications/the-world- factbook/geos/gr.html. 26 Ibid. 27 Ibid. 28 Elena Becatoros, “Hundreds of Greeks Seamen Unpaid for Months,” March 27, 2013, http://www.ekathimerini.com/4dcgi/_w_articles_wsite1_1_27/03/2013_490133. 29 Ibid.
  21. 21. Case Study Page 21 Bibliography Caloghirou,Yannis, Aimilia Protogerou, and Panagiotis Panaghiotopoulos. “Public Procurement for e-Government Services: Challenges and Problems Related to the Implementation of a New Innovative Scheme in Greek Local Authorities.” in Towards Transformative Governance? Responses to Mission-Oriented Innovation Policy Paradigms. Book of Abstracts (Eu-SPRI Conference 2012). ed. Fraunhoffer Institute for Systems and Innovation Research, (2012): 51-53. http://eu-spri-conference-2012.org/conf-org-wAssets/docs/Book-of-Abstracts.pdf. CIA. “World Fact book.” June, 2013. https://www.cia.gov/library/publications/the-world- factbook/geos /gr.html. European Union. “OSEPA Report on Critical Success Factors, December 2012.“ (University of Sheffield, UK, 10 December, 2012). June, 2013. http://osepa.eu/site_pages/News/147/OSEPA_ CP3_Report_ on_Critical_Success_Factors_10122012.pdf. Greece. Ministry of Interior General Secretariat of Public Administration and e-Government. “Greek e-Government Interoperability Framework”. (June 2013). http://www.e- gif.gov.gr/portal/page/portal/egif/. Greece Government. “eGovernment in Greece, April 2010.” June, 2013. http://www.observatory.gr/files/meletes/eGovernment_in_GR_April_2010_en.pdf. Project Management Institute. A Guide to the Project Management Body of Knowledge. 4th ed. Pennsylvania: PMI, 2008.