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

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

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.

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.

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

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

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

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.

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

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

.

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:

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;

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

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

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.

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

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:

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.

Case Study Page 19

Notes

1Greece, 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/.

2Theodoros Karounos, “LGAF: Local Government Application framework”, May 2009,

http://www.infostrag.gr/wp-content/uploads/2009/06/karounos_kedke_peta_22_5_2009.pdf.

3SingularLogic,”Customers – Projects: LGAF”, accessed June 16,2013,

http://portal.singularlogic.eu/en/case-study/2257/local-government-access-framework-lgaf.

4Tony 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.

7Jolein 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, 4

th ed.,

(Pennsylvania: PMI, 2008), 255.

12 European Union, “OSEPA Report on Critical Success Factors, December 2012“.

13 Ibid.,10

14Greece 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.

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.

21Yannis 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.

25CIA, “World Fact book” (June 2013), https://www.cia.gov/library/publications/the-world-

factbook/geos/gr.html.

26 Ibid.

27 Ibid.

28Elena 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.

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.