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

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