[TimorLesteStudies] IS Project failures in Developing Countries
Jennifer Drysdale
jenster at cres10.anu.edu.au
Thu Jul 12 14:11:34 EST 2007
Please direct any queries to: Abel Pires da Silva <lybel_2000 at yahoo.com>
>Dear Jennifer,
>Below (and attached) is a paper on Information
>System project failures in developing countries.
>I think it is also relevant to Project
>Management (PM) in other sectors as well.
><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
>Comments are welcomed, especially from people
>with PM experience in <?xml:namespace prefix =
>st1 ns =
>"urn:schemas-microsoft-com:office:smarttags"
>/>East Timor or other developing countries.
>
>Regards,
>Abel
>
>==
>
>
>Information System (IS) Project failures in Developing Countries
>
>By Abel P. da Silva
>(Master of Information Technology –MIT- from
>Swinburne University of Technology, Hawthorn, Melbourne)
>
>May, 2007
>
>Abstract
>
>Project failures in Developing Countries are
>common and these failures can be categorized
>into: Project Management Failure, Project
>Failure, Project sustainability failure and Design–actuality gap.
>Project management failures can be reduced by
>applying proper Project Management tools.
>Project failures relate to managing issues
>around the project such us project ownership,
>project acceptance (user resistance), etc.
>Project sustainability failure relates to
>post-project delivery period, where after
>successful project delivery, due to lack of
>certain aspects (content update, economic
>sustainability, etc.) the project was abandoned.
>Design-actuality gap relates to the condition
>where most of the failed IT/IS project in
>Developing Countries were caused by the fact
>that those projects were designed in totally
>different environment (mostly in developed
>countries), which in fact have opposite
>conditions with host developing countries, thus,
>many assumptions made are not based on the
>reality on the ground, in the end the project was bound to fail.
>
>Keywords: Project Management, Project Failure,
>Information Technology, Information System, Developing Countries, East Timor.
>Table of Contents
>
><http://us.f904.mail.yahoo.com/ym/Compose?box=Inbox&Mid=4263_3993772_76447_3206_1541_0_87235_3089_839138535&inc=&Search=1&YY=31387&y5beta=yes&order=&sort=&pos=0&B=1#_Toc170944037>I.
>Background. 3
><http://us.f904.mail.yahoo.com/ym/Compose?box=Inbox&Mid=4263_3993772_76447_3206_1541_0_87235_3089_839138535&inc=&Search=1&YY=31387&y5beta=yes&order=&sort=&pos=0&B=1#_Toc170944038>II.
>Project Failure in Developing Countries. 5
><http://us.f904.mail.yahoo.com/ym/Compose?box=Inbox&Mid=4263_3993772_76447_3206_1541_0_87235_3089_839138535&inc=&Search=1&YY=31387&y5beta=yes&order=&sort=&pos=0&B=1#_Toc170944039>III.
>Factors Contributed to the Project Failure. 6
><http://us.f904.mail.yahoo.com/ym/Compose?box=Inbox&Mid=4263_3993772_76447_3206_1541_0_87235_3089_839138535&inc=&Search=1&YY=31387&y5beta=yes&order=&sort=&pos=0&B=1#_Toc170944040>IV.
>Propose Steps to Reduce Project Failure. 9
><http://us.f904.mail.yahoo.com/ym/Compose?box=Inbox&Mid=4263_3993772_76447_3206_1541_0_87235_3089_839138535&inc=&Search=1&YY=31387&y5beta=yes&order=&sort=&pos=0&B=1#_Toc170944041>1.
>Project Management Failure: 9
><http://us.f904.mail.yahoo.com/ym/Compose?box=Inbox&Mid=4263_3993772_76447_3206_1541_0_87235_3089_839138535&inc=&Search=1&YY=31387&y5beta=yes&order=&sort=&pos=0&B=1#_Toc170944042>2.
>Project Failure. 10
><http://us.f904.mail.yahoo.com/ym/Compose?box=Inbox&Mid=4263_3993772_76447_3206_1541_0_87235_3089_839138535&inc=&Search=1&YY=31387&y5beta=yes&order=&sort=&pos=0&B=1#_Toc170944043>3.
>Project sustainability failure. 10
><http://us.f904.mail.yahoo.com/ym/Compose?box=Inbox&Mid=4263_3993772_76447_3206_1541_0_87235_3089_839138535&inc=&Search=1&YY=31387&y5beta=yes&order=&sort=&pos=0&B=1#_Toc170944044>4.
>Design–actuality gap. 11
><http://us.f904.mail.yahoo.com/ym/Compose?box=Inbox&Mid=4263_3993772_76447_3206_1541_0_87235_3089_839138535&inc=&Search=1&YY=31387&y5beta=yes&order=&sort=&pos=0&B=1#_Toc170944045>V.
>Case Study of Failed Project 12
><http://us.f904.mail.yahoo.com/ym/Compose?box=Inbox&Mid=4263_3993772_76447_3206_1541_0_87235_3089_839138535&inc=&Search=1&YY=31387&y5beta=yes&order=&sort=&pos=0&B=1#_Toc170944046>VI.
>Conclusions. 18
><http://us.f904.mail.yahoo.com/ym/Compose?box=Inbox&Mid=4263_3993772_76447_3206_1541_0_87235_3089_839138535&inc=&Search=1&YY=31387&y5beta=yes&order=&sort=&pos=0&B=1#_Toc170944047>Bibliography.
>19
>
>
>
>I. Background
>
>
>
>
>IS project failure refers to the failure of an
>information system, most notably in its
>conception, design, construction, deployment,
>implementation and use (Yardley, 2002).
>Yardley (2002) also characterize IS project failure by the following events:
>- The degradation of an existing business capability
>- The degradation of competitive advantage
>- An increase in operating cost
>- Failure to meet critical business requirements
>- Poor levels of user satisfaction
>- Lost of control over requirements management
>- Loss of control over planning
>
>Information Technology (IT)/Information System
>(IS) project failure is a common fact in the
>industries in developed countries. The reasons
>behind these failures vary from one sector to
>another, but the most common reasons for project
>failures according to Winters (2002) are
>inadequately trained and/or inexperienced
>project managers, failure to set and manage
>expectations, poor leadership at any and all
>levels, failure to adequately identify, document
>and track requirements, poor plans and planning
>processes, poor effort estimation, cultural and
>ethical misalignment, misalignment between the
>project team and the business or other
>organization it serves, inadequate or misused
>methods, inadequate communication and including
>progress tracking and reporting.
>
>These reasons for project failures are even more
>complex in Developing Countries. It is commonly
>known that developing countries lack human
>resources that are needed to carry out these
>projects effectively and efficiently to
>guarantee the project success. The other
>contributing factor to the high failure rate is
>the fact that in developing countries external
>politics can really determine projects fate,
>especially in government funded projects. For
>instance, change in the government could lead to
>the changing of project’s team, project’s scopes
>or even change in an already allocated funding for the project.
>
>The importance of learning about project failure
>in other Developing Countries is so that the
>other countries do not repeat the same mistake
>in the future. Developing country like East
>Timor can learn from these mistakes and apply
>all the necessary tools, steps and resources to
>avoid the same mistakes made in similar
>projects, which are going to be implemented by the country.
>
>
>
>
>II. Project Failure in Developing Countries
>
>
>
>
>Although to date there is no sufficient/strong
>evidence base to support the claim that project
>failures in Developing Countries are high; but
>there are reports from individual developing
>countries that point toward high rate failure in
>Developing Countries (Heeks, 2002).
>
>Project failures in Developing Countries vary
>from country to country and from one sector to
>another. Specific areas in which IT/IS project
>failures in Developing Countries are: Software
>development projects, Information System (IS)
>projects, E-government projects and other
>on-line system or computerization delivery projects.
>
>Based on a survey conducted in South Africa by
>Smith et al. (2006), Project Managers in South
>Africa are facing many project risks such as
>lack of top management commitment to the
>project, unclear/ misunderstood scope/
>objectives, schedule Flaw, lack of client
>responsibility, ownership and buy-in of the
>project and it’s delivered systems, no planning
>or inadequate planning, project not based on
>sound business case, lack of available skilled
>personnel, not managing change properly, Lack of
>adequate user involvement and poor risk
>management. In Colombia (Latin America),
>according to Iconnect online report on the
>Connecting Colombian Schools: National Program
>of Bilinguals and Informatics project, the
>reasons behind this particular project failure
>were lack of skilled personnel, lack of
>planning, lack of coordination of project’s
>stakeholders and changing of the government
>(Murillo, 1999). In Thailand, major IS project
>in taxation department was only partly
>successfully delivered. The reasons were vary
>from unclear project scopes and requirements and
>changing software scopes, which required
>changing in hardware specifications (the problem
>was the hardware already delivered based on the
>initial software requirements) (Schware & Bhatnagar, 2001).
>
>
>III. Factors Contributed to the Project Failure
>
>
>
>
>Yardley (2002) defines that project failure
>factors for IS are not limited to project
>management, but also include those project
>activities that lies outside the scope of
>project management. These factors some
>originated from within the business, such as
>strategy, organization, roles, and
>responsibilities; others, such as competitors,
>politics, and regulations will be external to the business.
>
>In Developing Countries, IS project failure
>factors are both from the project management and
>also in many instance, from the factors outside the project management.
>
>Yardley (2002) describes factors that
>contributed to project failure that are relevant
>both to project failure in Developed Countries
>as well as to the project failures in the Developing Countries.
>
>Project Management Failure factors (Yardley, 2002):
> * Inexperienced Project Manager
> * Poor project planning
> * Poor requirements management
> * Not capturing sufficient requirements
> * Capturing a shopping list of requirements
> * Changing requirements
> * Dependency on project management tools
> * No clear project schedule
> * Weak leadership
> * Inadequate testing
>
>Key contributors to project failure:
> * Weak ownership
> * Immature or unproven technology
> * Lack of user involvement
> * Weak business case
> * Poor communication
> * Failure to examine existing business
> process and goals before deploying technology
>
>Apart from the above factors, Heeks (2002)
>argues that many project failures in Developing
>Countries are caused by the poor project
>planning (system design phase). Heeks (2002)
>explains that in Developing Countries, many
>projects were not designed according to the
>reality on the ground where the system is to be
>used; it is the Design–Actuality Gaps (Heeks,
>2002). An example can be drawn from the
>Philippines where an aid-funded project aimed to
>introduce a field health information system was
>designed according to an American model that
>assumed the presence of skilled programmers,
>skilled project managers, a sound technological
>infrastructure, and a need for information
>outputs like those used in an American
>health-care organization. In reality, none of
>these was present in the Philippine context. The
>result was a large design–actuality gap along
>dimensions including information, technology,
>and staffing/skills. The outcome was that the
>information system failed (Heeks, 2002).
>
>The same mistakes were repeated in East Timor
>when the International Labor Organization (ILO)
>was executing a project in Employment Service
>sector that aimed to strengthening East Timor’s
>national employment services (ILO, 2001). The
>project plan was developed by consultants
>working outside East Timor, based merely on the
>similar projects being implemented in other
>Developing Countries, for instance in Mozambique
>where East Timor share common Portuguese
>inheritances (mainly Portuguese language).
>
>The outcome was disastrous to the project since
>many project assumptions were simply inaccurate;
>including the assumption that the project
>specialist positions could be filled by East
>Timorese. The 4 (four) specialists required by
>the project were the Employment Service
>specialist, the Labor Market Analyst, the
>Vocational Training Specialist and the
>Management Information System Specialist. Since
>these positions were assumed to be filled by
>locals, the allocated fund for these positions
>in the project plan was very small compare to
>budget allocated for those positions categorized as international posts.
>
>In the end, when the project could not obtain
>specialists with desired level of
>qualifications, the project schedule and budget
>had to be revised to include considerable time
>to train those staff. The project condition were
>even deteriorated since the training failed to
>produce an acceptable outcome hence the project
>staff were forced to start to work and learning
>at the same time (learning by doing approach).
>
>Heeks (2002) also argues that in Developing
>Countries there is another type of project
>failure called the “sustainability failure”.
>This is an initiative that at first succeeds but
>is then abandoned after a year or so. An example
>is the creation of a set of touch-screen kiosks
>for remote rural communities in South Africa’s
>North-West Province. These were initially well
>received by the communities. However, the
>kiosks’ lack of updated or local content and
>lack of interactivity led to disuse, and they
>were removed less than a year later (Heeks, 2002).
>
>Heeks (1999) also describe that many software
>projects in Developing Countries also facing
>lack of infrastructure in particular a sizeable
>installed computer base, reliable and pervasive
>telecommunications links both domestically and
>internationally, and reliable electricity
>supply. These factors may also be key causes of
>project “sustainability failure” because most
>Developing Countries like East Timor lack
>reliable electricity supply and telecommunication links.
>
>
>
>
>
>IV. Propose Steps to Reduce Project Failure
>
>
>
>
>1. Project Management Failure:
>The Project Management failure in Developing
>Countries can be reduced by applying Project
>Management knowledge areas in Scope management,
>Time management, Cost management, Quality
>management, Human resource management,
>Communication management, Risk management and
>Procurement management and Integration management (Schwalbe, 2006):
>
>· Scope Management involves defining and
>managing all the work required to complete the project successfully
>· Time management includes estimating how
>long it will take to complete the work,
>developing and acceptable project schedule, and
>ensuring timely completion of the project
>· Cost management consists of preparing
>and managing the budget for the project
>· Quality management ensures that the
>project will satisfy the stated or implied needs for which it was undertaken
>· Human resource management is concerned
>with making effective use of the people involved with the project
>· Communication management involves
>generating, collecting, disseminating, and storing project information
>· Risk management includes identifying,
>analyzing, and responding to risks related to the project
>· Procurement management involves
>acquiring or procuring goods and services for a
>project from outside the performing organization.
>· Integration management is an
>overarching function that affects and is affected by all of the other areas.
>
>The application of project management software
>like Microsoft Project will also help to reduce
>project management failure, since it provides
>dynamic project status to the project managers
>(through Gantt chart, for example).
>
>2. Project Failure
>There are steps to reduce the likelihood of the Project failure:
>· Justification of the Project. The top
>executives (of corporate or governments) must
>demonstrate that there are real needs to have
>the project by implemented, thus they will be
>able to provide all the required resources for
>the project to be successful. Lack of commitment
>by the project owners (especially from the top
>executive) will in the end cause lack of
>allocated project resources that are required
>for the project to be successful.
>· User involvement should also be taken
>into account seriously to guarantee the project
>successfulness. Users that do not participate
>enough in the project development process tend
>to demonstrate the lack of enthusiasm to the
>product result and persistent resistance in using the product.
>
>3. Project sustainability failure
>Project sustainability failure happens to
>projects that were initially successfully
>implemented, but the projects were abandoned
>after the implementation phase. Lack of update
>content and lack of infrastructure are the main
>cause for this type of project failure.
>To minimize this failure, projects owners (both
>governments and corporations) should allocate
>adequate efforts for project post-delivery to
>guarantee the project sustainability through a
>proper viability study (technology, economic,
>human resources and infrastructure, etc. sectors).
>Adequate training and support (both technical
>and financial) should be allocated to make sure
>that the project will be self sustained after it was delivered.
>
>4. Design–actuality gap
>Heeks (2002) outlines that Design-actuality gap
>can be reduced or even closed by:
>· Actuality improvisation: changing local
>actuality to make it closer to IS design.
>For example: during the introduction of MIS into
>private-sector enterprises in Sri Lanka
>(Goonatilake et al., 2000). Here the rational
>design of the MIS often mismatched the rather
>chaotic nature of most enterprise procedures.
>Actuality was altered by, prior to
>computerization, ensuring the introduction of
>basic manual production planning, control and
>accounting procedures. Computerization could
>subsequently proceed with a greater chance of success (Heeks, 2002).
>· Design improvisation: changing the
>(often “imported”) IS design to make it closer
>to Developing Countries (DC) user actuality.
>For example: an original design option for a new
>hospital IS in Guatemala was to reengineer
>administrative processes to make them more
>efficient (Silva et al., 2000). But, in reality,
>hospital directors supported current procedures
>and wanted controls to remain in place to ensure
>corruption was held in check. The design was
>therefore amended to ensure that these current
>work processes were supported by the new system (Heeks, 2002).
>
>
>
>
>V. Case Study of Failed Project
>
>
>
>
>Thailand’s Project Failure Case: Thailand’s Tax
>Computerization Project funded by the World Bank:
>
>In January 1992, the government introduced a
>major tax-restructuring program meant to
>increase efficiency of the tax system, make the
>tax structure more competitive with regional
>neighbors, and prepare for a potential shift to
>indirect taxes as a larger share of revenues.
>Based on recommendations made by the IMF and
>World Bank teams in the late eighties, the
>business tax (a tax levied on receipts) was
>replaced by a Value Added Tax (VAT) and the
>effective rates on corporate and income taxes were lowered.
>
>Simultaneously, the government embarked on a
>program to modernize the Revenue Department
>sought World Bank financing to overhaul its
>existing computer system. The objective of the
>project is "to support tax administration
>through the provision of hardware, software, and
>systems for tax processing and analysis”. The
>goal of the project was to assist the RD in
>establishing a comprehensive, integrated data
>management and processing system for all taxes
>it administers. These include the personal
>income tax, the corporate income tax, the
>business tax, VAT, petroleum income tax, foreign
>travel tax and the withholding tax. A national
>computer system was expected to: decentralize
>tax administration, introduce a single Tax
>Identification Number (TIN) to integrate all
>taxes and returns form entity; and provide
>computerized billing and collection of all
>taxes. In turn, these changes were expected to
>produce: faster and more efficient processing
>and collection of revenues and improved tax
>records, with better access and ability to
>conduct audits at each administration (Schware & Bhatnagar, 2001).
>
>The Tax Computerization Project (TCP) was
>financed by a loan from the World Bank. The TCP
>is a turnkey project in which a consortium of
>four companies (RDC). The TCP has to provide
>operational software for twenty-five systems
>applications, various databases, management
>information systems and financial systems
>including online networking for most of revenue
>offices throughout the country and specific
>networking with government agencies. The basic
>transaction systems included the followings: TIN
>(Tax Identification Number), VAT (Value Added
>Tax), SBT (Specific Business Tax), PIT
>(Personnel Income Tax), WT (Withholding Tax) and
>PT (Petroleum Tax). Other system functions
>included: refund and audit, delinquent taxpayers
>management, appeal and litigation, canvassing
>taxpayers, minimum value added tax assessment and intelligence.
>
>The network consisted of departmental network:
>connecting the Revenue Office in Bangkok,
>Regional Offices, Are Offices and all the
>divisions in the Revenue Department, Regional
>Network: connecting all computer centers of nine
>Regional Offices and each regional computer
>center linking to the provinces under each
>region, Provincial network: networking all
>District Offices in each province by centralized
>processing at the Provincial Computer Center,
>District level: connecting all 826 district
>offices, Networking with other government
>agencies such as Bureau of Registration
>Administration, Department of Local
>Administration, Custom Departments, Excise
>Department, the Comptroller-General Department
>and the Ministry of Commerce. The hardware
>configurations included: two large of mainframe
>(IBM ES/9000 model 260), 9 medium mainframes
>(IBM RISC/1600 model 7015, for Regional
>Offices), 48 small mainframes (IBM RISC/1600
>model 7013, for Provincial Offices), 9 data
>entry systems for Regional Offices, 15 remote
>line printers for Provincial Offices, 114 data
>entry devices, and Intelligent Terminal or stand
>alone PCs up to 1,319 terminals (Kitiyadisai, 2000).
>
>There were no problems in hardware delivery
>part, but problems were mainly from the
>development of the systems’ software. By the end
>of the project, the RDC could only deliver a
>limited version for VAT and Specific Business Tax (SBT).
>
>There were many problems in the implementation
>phase of Thailand’s Tax Computerization Project (TCP):
> * Project Cultural Difference: The TCP was
> meant to deliver a new automatic system into
> the current civil servants’ environment. There
> was no preparation in the user’s side, so
> transformation from the existing system to the
> new system was a serious matter. Moreover, the
> working style of foreign consultants, project
> leaders and system analyst/programmers was
> unfamiliar to the slow pace and cautious civil
> servants and that the difficulty of
> communicating in foreign language can not be
> underestimated (Kitiyadisai, 2000).
>
> * Project Planning: The most important
> factor in causing the failure of the TCP was
> the implementation of the VAT (Value Added
> Tax). The RDC (contractor) was requested to
> sign the contract in August 1991. After the
> signing of the contract, the new VAT system was
> introduced. This caused major changes in the
> system requirements compare to the one that was
> signed in August 1991. The singing should
> instead take place in the beginning of 1992 in
> order to take into account the requirements of
> the new tax system (Kitiyadisai, 2000).
>
> * Project Accountability: The contract was
> loosely drafted with vague systems’
> requirements, there were no concrete details on
> the specific functions of the application
> programs, their capabilities or expected
> outputs. This led to disagreement over the
> scope of the project and the responsibility of
> the contractor (Kitiyadisai, 2000).
> Consequently, the contractor failed to develop
> project specifications and was therefore unable
> to develop the application software. When the
> specifications finally specified and designed
> suitable applications software, it became clear
> that the hardware system software, database
> software, telecommunications software and the
> hardware that already been delivered would have
> to be replaced (Schware & Bhatnagar, 2001).
>
> * Project Evaluation: Although there were
> steering committee, a Thai consultant and a
> specially commissioned foreign consultant to
> follow up and monitor to the project, the
> process was not disciplined and filled with
> many cancellations and postponements
> (Kitiyadisai, 2000). Moreover, Due to the lack
> of centralized milestone reporting, there was
> no single point from which management could
> obtain a clear picture of project progress.
> Without a precise measurement of work to be
> were thousands of tasks and sub-tasks requiring
> many thousands of work hours and the
> co-operation hardware, systems software, and
> network installation and support activities),
> task times, and estimates, underlying schedules
> tended to be inaccurate and of little
> operational value (Schware & Bhatnagar, 2001).
> Although the Revenue Department assigned
> several senior managers to the project, as well
> as a dozen support staff, most management
> responsibilities were not clearly defined
> (clear written terms of reference) and so roles
> such as the Implementation Manager had remained
> unfilled. The Implementation Agency was also
> lacked skills in systems integration
> engineering, facilities management,
> applications development software engineering.
> Furthermore, proper project monitoring tools
> were not used; and the complexity of software
> development process was neither understood nor
> assessed. (Schware & Bhatnagar, 2001).
>
> * Project Development Methods: The lack of
> an appropriate and well-specified project
> objective was the beginning of all troubles.
> The project's proponents were overly eager to
> purchase and install hardware and deliver
> inadequate attention and patience to project
> preparation (Schware & Bhatnagar, 2001). The
> scope of the systems’ requirements was loosely
> stated in the contract which made the
> contractor rather surprised by the unexpected
> range of systems software and capabilities
> demanded by the Revenue Department. In
> addition, the contractor did not conduct
> thorough system analysis of all the tax systems
> and there was no known systems analysis
> document. The subcontractor on software
> provision had to analyze users’ requirements
> and the complicated VAT and other tax systems
> and learn the relevant laws from Thai personnel
> whose mother tongue was not English. The
> coordination among the different contractors
> and subcontractors was not adequate as
> activities and plans did not coincide according
> to plan. Frequent changes in users’
> requirements and the high turnover of
> programmers due to a change in subcontractors
> made it difficult to progress as new analyst
> had to start the learning process of Thai taxation (Kitiyadisai, 2000).
>
> * Project Under resource: Although the
> development team was under-resourced, it was
> thought that pressure on the team compensate
> for under resourced. In fact, a lack of human
> resources and experience contributed by poorly
> prepared bidding document. The IFB included
> requirements that were met by only one system
> specifications produced by the Revenue
> Department were either too specific (e.g.,
> specifying main frame, network protocol, etc.)
> or too generic (e.g., software requirements
> were not specific enough) (Schware & Bhatnagar, 2001).
>
> * Project Power and Politics: The
> termination of the project was inevitable as
> problems and difficulties escalated at the cost
> of the RDC and the revenue
> Department. According to the regulations and
> contract, the contractor would have to pay
> penalty for being unable to deliver all the
> specified systems. But this would have meant to
> a long drawn out legal process and a halt to
> the system already in operation. The RDC, whose
> main partner was IBM, a multinational with
> substantial leverage, and the government agreed
> to compromised and terminate the project in
> August 1998 (Schware & Bhatnagar, 2001).
>
> * Project User Resistance: The new system
> required new skills to operate. Therefore, the
> users’ of the system which did not have the
> skills needed to be trained in order to reduce the users’ resistance.
>
> * Project Irrationality: The contractor
> (RDC) changed its software subcontractor and
> later requested for over a year extension of
> its deadline due to the changes in the new tax
> system that was also changed user’s
> requirements. At the same time, the government
> of Thailand was well under the economic crisis
> and was pushing to finish the system as early
> as possible so they can use the system for more taxes (Kitiyadisai, 2000).
>
>
>
>
>
> VI. Conclusions
>
>
>
>
>There are several types of project failures in
>Developing Countries: Project Management
>Failure, Project Failure, Project sustainability
>failure and Design–actuality gap.
>Project failures rate in Developing Countries
>(DC) can be reduced significantly through the
>application of standard project management tools
>and more specifically, better project planning
>that take into account the conditions of the
>country where the project is going to be implemented.
>
>The most common practice is by having the
>project planned in totally different environment
>(i.e. developed countries) and by people with
>little or no specific knowledge about the host
>country which most likely to adopt inaccurate
>assumptions which in turn contribute to the failure of the project.
>Implementing agencies need to have expertise in
>contractor management, including knowledge of
>legal aspects of contract administration, to
>help determine such issues as change-of-scope and compliance with contract.
>
>In summary, the tasks of requirement
>specification, analysis, and design must be
>carried out diligence and skilled resources done
>at the initiation stage. Should gaps remain, the
>implementation authority should be able to spot
>the weaknesses in a timely manner through the
>use of appropriate project management tools (Schware & Bhatnagar, 2001).
>
>
>
>
>
>Bibliography
>
>
>
>
> * East Timor Overview 2001, ILO Regional
> Office for Asia and the Pacific, viewed 15 May
> 2007,
> <http://www.ilo.org/public/english/region/asro/bangkok/arm/tmp.htm>http://www.ilo.org/public/english/region/asro/bangkok/arm/tmp.htm
>
> * Murillo, M. 1999, Connecting Colombian
> schools: the Bilinguals and Informatics
> national program, Iconnect-online, viewed 20
> April 2007,
> <http://www.iconnect-online.org/Stories/Story.import4074/view?searchterm=Connecting%20Colombian%20schools:%20the%20Bilinguist%20and%20Informatic%20national%20program>http://www.iconnect-online.org/Stories/Story.import4074/view?searchterm=Connecting%20Colombian%20schools:%20the%20Bilinguist%20and%20Informatic%20national%20program
>
> * Goonatilake, L., Maizza-Neto, O., and
> Jayawardene, P. 2000, ‘Enhancing enterprise
> competitiveness in developing countries through
> the promotion of management information and
> benchmarking tools’, Proceedings of the IFIP
> WG9.4 Conference 2000, Cape Town: IFIP.
> * Heeks, Richard B 1999, ‘Software
> Strategies in Developing Countries’,
> Communications of the ACM; June, Vol. 42 Issue
> 6, p15-20, 6p, Business Source Premier, EBSCOhost, viewed 18 April 2007.
> * Heeks, Richard B 2002, ‘Information
> Systems and Developing Countries: Failure,
> Success, and Local Improvisations’, Information
> Society; March, Vol. 18 Issue 2, p101-112, 12p,
> Business Source Premier, EBSCOhost, viewed 18 April 2007.
> * Kitiyadisai, K. (2000) 'The implementation
> of IT in reengineering the Thai Revenue
> Department', Proceedings of the IFIP WG9.4 Conference 2000, Cape Town: IFIP.
> * Schwalbe, K 2006, Information Technology
> Project Management, Fourth Edition, Thomson Course Technology, Boston.
> * Schware, R & Bhatnagar, S 2001,
> e-Government - Thailand's Troubled Tax
> Computerization Project, The World Bank, Viewed
> 20 April 2007,
> <http://web.worldbank.org/WBSITE/EXTERNAL/TOPICS/EXTINFORMATIONANDCOMMUNICATION>http://web.worldbank.org/WBSITE/EXTERNAL/TOPICS/EXTINFORMATIONANDCOMMUNICATION
>
> * Silva, L. O., Castro, J. C., and
> Rodriguez, E. O. 2000, ‘Outsourcing as an
> improvisation’, Proceedings of the IFIP WG9.4
> Conference 2000, Cape Town: IFIP.
> * Smith, D., Eastcroft, M., Mahmood, N. and
> Rode, H. 2006, ‘Risk factors affecting software
> projects in South Africa’, South African
> Journal of Business Management; Jun, Vol. 37
> Issue 2, p55-65, 11p, Business Source Premier,
> EBSCOhost, viewed 20 April 2007.
> * Winters, F., 2002, The Top 10 Reasons
> Project Fail, gantthead.com whitepaper, viewed
> 15 May 2007,
> <http://www.gantthead.com/article.cfm?ID=147229>http://www.gantthead.com/article.cfm?ID=147229
>
> * Yardley, D 2002, Successful IT Project
> Delivery: Learning the lessons of Project
> Failure, Pearson Education Ltd., London
More information about the Easttimorstudies
mailing list