Project IV RESEARCH FINAL

0

STUDY TITLE

An investigation into information technology project failure in Tshwane Metropolitan

Municipality.

By

Student Name

Remember Mathebula

Student Number

211056673

Submitted in partial fulfilment of the degree of BACCALAUREUS TECHNOLOGIAE: Information

Management

In the Department of Informatics,

Faculty of Information and Communication Technology,

Tshwane University of Technology

Supervisor:

Makgopela MM

Co-Supervisor:

Giresse KM

1

Table of Contents

Dedication..........................................................................................................................................2 Acknowledgement............................................................................................................................2Abstract............................................................................................................................................3

CHAPTER 1....................................................................................................................................4 1.1 Introduction: ..................................................................................................................6 1.2 Aim of the study: ...........................................................................................................4 1.3 Research objectives: .......................................................................................................4 1.4 Research questions: ........................................................................................................4 1.5 Participants: ...................................................................................................................5 1.6 Limitations and delimitations of the study..........................................................................51.7 Research methodology: ..............................................................................................….51.8 Conclusion: .................................................................................................. …………..5

CHAPTER 2.....................................................................................................................................62.0 Analysis of research results………………………………………………………………….....62.1 Introduction: ..................................................................................................................6

CHAPTER 3....................................................................................................................................6 3.0 Presentation and interpretation of results: …………………………………………………….6 3.1 Introduction: ..................................................................................................................7-18

CHAPTER 4...................................................................................................................................18 4.0 Recommendations and conclusions: ………………………………………………………….18 4.1 Introduction: .................................................................................................................18 4.2 Why projects fails: ……………………………………………………………………………18-204.3 Defining success and failure: ..........................................................................................20-21 4.4 Roles and responsibilities of the project manager: ............................................................21-22 4.5 Areas for future research: ..............................................................................................224.6 References: ..................................................................................................................23 4.7 Appendix: ....................................................................................................................24-26

2

Dedication

I dedicate this research to the almighty God who gave me the strength and brains to write this research. God is great!

Acknowledgement

First and foremost I wish to express my gratitude to Mr. Makgopela MM and his assistant Mr. Giresse KM for their valuable guidance and support and the time they sacrificed to make these research a success. I am eternally grateful for their comment and suggestion which improved my work to best one among the best. Without their assistance the success of this work was going to be very difficult.

Secondly, I would like to extend my appreciation to my loving family and friends for their love, prayers and support. I am grateful for their encouragement and faith in me.

3

ABSTRACT

Project Management is the wave of the future. This discipline and its evolution continues to be one of the principal means by which operational and strategic changes are managed in the enterprise. The importance of Project Management for organizational success will expand, rather than wane, in years to come.

Projects, particularly large scale complex ones with multiple stakeholders, are failing at alarming rates despite a wide spectrum of efforts to solve the problem. The lack of meaningful results and outcomes is due, in part, to the fact that organizations tend to operate on a set of unproven assumptions concerning project objectives, business requirements, user expectations, motivations, agendas, schedules, costs and time frames.

The objective of this dissertation was firstly to establish the factors that influence information technology project failure in Tshwane Metropolitan Municipality; and secondly, to determine the possibilities available to improve information technology projects success, that could be applied within the City.

The method of research was to issue questionnaires to the entire population of Group ICT at Tshwane Municipality. The questionnaires were designed around the simplified five-point Likert scale using closed questions. Questionnaires were used to gauge the perceptions on the current project environment within the City.

4

1.0 CHAPTER 1 – INTRODUCTION AND OVERVIEW OF THE STUDY

1.1 INTRODUCTION

To stay competitive, companies are increasingly implementing initiatives to improve their project delivery by continually reducing cycle times, minimizing costs and controlling quality. These initiatives require skilled people, standardized processes and superior technology unified and driven by effective project management.

Whether delivering products or services, all organizations need to meet project deadlines, budgets and stakeholder expectations. To maintain customer satisfaction and meet customer expectations, no room exists for project errors or delays.

This chapter describes the motivation and context of the study and introduces the reader to the project environment. This chapter further briefly outlines the objectives of the research.

1.2 Aim of the study

the aim of the study is to establish the factors that influence information technology project failure in Tshwane Metropolitan Municipality.

1.3 Objectives

The objectives of this study are:

To identify the factors that influence information technology project failure. To provide client and the project team with guidelines of the role they must play in

information technology projects. To determine the possibilities available to improve information technology projects success. To encourage an understanding of the project requirements and outcomes at the initiation

phase of the project, with clearly defined deliverables

1.4 Research Questions

What are the factors that influence information technology project failure? What are the guidelines that must be followed by client and the project team during the

development of information technology project? What are the possibilities available to improve information technology project success?

5

1.5 Participants

The research will be done in Tshwane Metropolitan municipality and questions will be distributed to managers, senior managers, developers, analyst and testers with ICT department.

1.6 LIMITATIONS AND DELIMITATIONS OF THE STUDY

Some limitations that may influence the outcome of this study are:

Respondents may find it difficult to give honest feedback. Respondents may feel that negative responses reflect on their abilities in managing projects

and not on factors beyond their control.

Delimitations that will confine the boundary of the research will be:

The research will only be conducted within City of Tshwane Municipality Group ICT.

1.7 RESEARCH METHODOLOGY

This research will be conducted by issuing questionnaires as is known as a list of printed questions that need to be completed, respondents may be requested to complete the questionnaire with the researcher not present. The questionnaires will be designed around the simplified five-point Likert scale using closed questions (Cooper & Schindler, 2001). The type of research to be undertaken can be classified as quantitative in nature.

The questionnaire was then divided into various sections that would focus on fundamentals for project success. Questionnaires were designed to target knowledgeable, experienced and suitably qualified individuals who were engaged in managing projects within Transnet at the time.

Questionnaires were used to gauge the typical understanding of project owners with respect to:

Alignment between the business vision and the operational requirements The requirements for project success. The common reasons for project failure.

Responses were analyzed by the researcher and included the use of descriptive statistics. Responses were compared to ascertain whether the results obtained were significant and did not happen by chance.

1.8 CONCLUSION

The objective of this dissertation was firstly to identify the factors that influence information technology project failure within the City; and secondly, to recommend strategies to improve the rate of project success, that could be applied within the City.

6

2.0 CHAPTER 2 – ANALYSIS OF RESEARCH RESULTS

2.1. Introduction

Twenty nine research questionnaires were collected in total. The responses were collated on an excel spreadsheet. Responses were coded to assist in the analysis process. Strongly disagree responses were coded as 1, disagree were coded 2, neither agree nor disagree were coded 3, agree as 4 and strongly agree responses were coded as a 5. The spreadsheet was then tested for validity. Basic inferential statistics were applied to the results.

3.0 CHAPTER 3 – PRESENTATION AND INTERPRETATION OF RESULTS

3.1 Introduction

This chapter presents the results obtained from data collected through questionnaires during the study. Information will be presented through the use of tables and graphs. I distributed forty (40) Questionnaires to the City of Tshwane Group ICT employees, Only 29 participants decided to take part in this research. The total number of questionnaires issued to respondents were Twenty nine (29).

Data collection was quantitative therefore quantitative data will be presented. Tables are used for the presentation of quantitative data.

The various questions on the questionnaire were categorized with respect to applicability to the objectives. The frequency distribution was computed for each question. An analysis of the respective questions is discussed below. This analysis will lend itself to either verifying or disputing the objectives supporting the research question. The coding on the frequency distributions is related to the questionnaire analysis as follows:

Response rated 1 = strongly disagreeResponse rated 2 = disagreeResponse rated 3 = neither agree nor disagreeResponse rated 4 = agreeResponse rated 5 = strongly agree

Section 1 - Strategic Alignment (SA1-6)

1. Projects are selected in line with business goals.

Table 3.1 Project are in line with business goals

Strongly disagree Neither agree Agree Strongly agree Total number of

7

disagree nor disagree participantsSA1 7% 7% 14% 48% 24% 29

Table 3.1 above indicates that the majority of respondents (72%) agreed that Projects are selected in line with business goals, whilst 14% disagree.

2. Project outcomes are generally aligned with business goals.

Table 3.2 Project outcome

Strongly disagree

disagree Neither agree nor disagree

Agree Strongly agree Total number of participants

SA2 3% 3% 17% 55% 21% 29

Table 3.2 above indicates that the majority of respondents (76%) agreed that project outcomes are generally aligned with business goals, whilst 6% disagree.

3. Requirements are clearly defined from the beginning.

Table 3.3 Project requirements

Strongly disagree



SA3 21% 10% 14% 21% 34% 29

Table 3.3 above indicates that the majority of respondents (55%) agreed that project requirements are clearly defined from the beginning, whilst 31% disagree.

4. Use of Work breakdown Structure (WBS) and Network activity when planning a project.

Table 3.4 Project planning tools

Strongly disagree



SA4 0% 10% 34% 34% 21% 29

Table 3.4 above indicates that the majority of respondents (55%) agreed that the project team use Work breakdown Structure (WBS) and Network activity when planning a project, , whilst 10% disagree.

5. Project outcomes are clearly defined by the client.

Table 3.5 Project definition

Strongly disagree



SA5 3% 10% 24% 41% 21% 29

8

Table 3.5 above indicates that the majority of respondents (62%) agreed that the project outcomes are clearly defined by the client, whilst 13% disagree.

6. The client determines project success by measuring project outcomes.

Table 3.6 Project success

Strongly disagree



SA6 3% 3% 21% 38% 34% 29

Table 3.6 above indicates that the majority of respondents (72%) agreed that the client determines project success by measuring project outcomes, whilst 6% disagree.

Section 1 - Strategic Alignment Graph

The above data from SA1 – SA6 is now presented in a form of graph.

Table 3.7

SA1 SA2 SA3 SA4 SA5 SA60

10

20

30

40

50

60

70

80

90

100

Strategic alignment Q1 - Q6

Strongly disagree disagree Neither agree nor disagreeAgree Strongly agree \

Section 2 – Project Selection (PS1-5)

1. Project managers are appointed at the concept stage of the project.

Table 3.8 Appointment of project managers


9

disagree nor disagree participantsPS1 30% 26% 14% 22% 8% 29

Table 5.8 above indicates that the majority of respondents (56%) disagree that the project managers are appointed at the concept stage of the project, whilst 30% agreed.

Results discussion

2. The project manager is involved in the project selection process.

Table 3.9 Involvement of project managers in the selection process

Strongly disagree



PS2 41% 14% 24% 21% 0% 29

Table 3.9 above indicates that the majority of respondents (55%) disagree that the project managers are involved in the project selection process, whilst 21% agreed.

3. Project results have a strategic fit in the design and execution of future products and services.

Table 3.10 Project results

Strongly disagree



PS3 0 7% 31% 48% 14% 29

Table 5.10 above indicates that the majority of respondents (62%) agreed that the Project results have a strategic fit in the design and execution of future products and services, whilst 7% disagree.

4. Projects are selected in line with business growth and expansion strategies.

Table 3.11 Project selection

Strongly disagree



PS4 0% 7% 17% 45% 31% 29

Table 3.11 above indicates that the majority of respondents (76%) agreed that the Projects are selected in line with business growth and expansion strategies, whilst 7% disagree.

5. The principles of project management are applied uniformly irrespective of the size of the project.

Table 3.12 Principles of project management

Strongly disagree



10

PS5 10% 21% 34% 17% 17% 29

Table 5.12 above indicates that the majority of respondents (34%) agreed that the principles of project management are applied uniformly irrespective of the size of the project, whilst 31% disagree and 34% neither agree nor disagree.

Section 2 - Project Selection (PS1-5) Graph

The above data from PS1 – PS5 is now presented in a form of graph.

Table 3.13

1 2 3 4 50

10

20

30

40

50

60

70

80

90

100

Project Selection Q1 - Q5

Strongly disagree disagreeNeither agree nor disagree Agree Strongly agree

Section 3 – Project outcomes (PO1-6)

1. The project usually satisfies the business operational requirements.

Table 3.14 Business requirements

Strongly disagree



PO1 3% 14% 21% 55% 7% 29

Table 3.15 above indicates that the majority of respondents (62%) agreed that the project usually satisfies the business operational requirements, whilst 17% disagree.

11

2. Project deliverables are generally produced on time and within budget.

Table 3.16 Project deliverables

Strongly disagree



PO2 45% 7% 10% 34% 3% 29

Table 3.16 above indicates that the majority of respondents (52%) disagree that the Project deliverables are generally produced on time and within budget, whilst 37% agreed.

3. The business owners usually believe that the project was successful.

Table 3.17 Business owners

Strongly disagree



PO3 7% 21% 21% 38% 14% 29

Table 3.17 above indicates that the majority of respondents (52%) agreed that the business owners usually believe that the project was successful, whilst 28% disagree.

4. Projects always deliver the business value it promises.

Table 3.18 Business value

Strongly disagree



PO4 7% 34% 10% 41% 7% 29

Table 3.18 above indicates that the majority of respondents (47%) agreed that the projects always deliver the business value it promises, whilst 41% disagree.

5. The time, cost, quality and scope constraints are usually managed as planned.

Table 3.19 Project constraints

Strongly disagree



PO5 14% 34% 24% 24% 10% 29

Table 3.19 above indicates that the majority of respondents (48%) disagree that the time, cost, quality and scope constraints are usually managed as planned, whilst 34% agreed.

6. Project ultimately provide satisfactory return on investment to the customer.

Table 3.20 Return on investment

12

Strongly disagree



PO6 3% 10% 38% 38% 10% 29

Table 3.20 above indicates that the majority of respondents (48%) agreed that the project ultimately provide satisfactory return on investment to the customer, whilst 13% disagree.

Section 3 – Project Outcomes (PO1-6) Graph

The above data from PO1 – PO6 is now presented in a form of graph.

Table 3.21

PO1 PO2 PO3 PO4 PO5 PO60

10

20

30

40

50

60

70

80

90

100

Project Outcomes Q1 - Q6

Strongly disagree disagree Neither agree nor disagreeAgree Strongly agree

Section 4 – Project Analysis (PA1-10)

1. Clients clearly defined the business case.

Table 3.22 Business case

Strongly disagree



PA1 21% 17% 31% 28% 3% 29

Table 5.22 above indicates that the majority of respondents (38%) disagree that the clients clearly defined the business case, whilst 31% agreed.

13

2. The stakeholders have knowledge about the project.

Table 3.23 Stakeholders knowledge

Strongly disagree



PA2 0% 21% 7% 41% 31% 29

Table 3.23 above indicates that the majority of respondents (72%) agreed that the stakeholders have knowledge about the project, whilst 21% disagree.

3. The stakeholders have a good communication skills.

Table 5.24 Communication skills

Strongly disagree



PA3 0% 7% 41% 31% 21% 29

Table 3.24 above indicates that the majority of respondents (52%) agreed that the stakeholders have a good communication skills, whilst 7% disagree.

4. All the functional requirements of the system gathered at the beginning.

Table 3.25 Functional requirements

Strongly disagree



PA4 10% 17% 31% 28% 14% 29

Table 3.25 above indicates that the majority of respondents (42%) agreed that all the functional requirements of the system gathered at the beginning, whilst 27% disagree.

5. The client have a better understanding about what he/she needs.

Table 3.26 Client understanding what he/she needs

Strongly disagree



PA5 10% 21% 28% 35% 7% 29

Table 3.26 above indicates that the majority of respondents (52%) agreed that the client have a better understanding about what he/she needs, whilst 32% disagree.

6. Are there software tools used in planning and management of requirements?

Table 3.27 Software tools

Strongly disagree



PA6 0% 7% 14% 69% 10% 29

14

Table 3.27 above indicates that the majority of respondents (79%) agreed that are there software tools used in planning and management of requirements, whilst 7% disagree.

7. The goals and objectives are always within the project scope.

Table 3.28 Project scope

Strongly disagree



PA7 0% 31% 28% 28% 14% 29

Table 3.28 above indicates that the majority of respondents (42%) agreed that the goals and objectives are always within the project scope, whilst 31% disagree.

8. Will the employee accept the change?

Table 3.29 Accepting change

Strongly disagree



PA8 7% 21% 34% 34% 3% 29

Table 3.29 above indicates that the majority of respondents (37%) agreed that the employees will accept change, whilst 28% disagree.

9. The project solution always meet the business needs.

Table 3.30 Project solution

Strongly disagree



PA9 0% 7% 38% 38% 17% 29

Table 3.30 above indicates that the majority of respondents (55%) agreed that the project solution always meet the business needs, whilst 7% disagree.

10. There is a proper plan which will identify any change in requirements.

Table 3.31 Proper plan

Strongly disagree



PA10 0% 24% 38% 31% 7% 29

Table 3.31 above indicates that the majority of respondents (38%) agreed that there is a proper plan which will identify any change in requirements, whilst 24% disagree.

Section 5 – Project Outcomes (PA1-10) Graph

15

The above data from PA1 – PA10 is now presented in a form of graph.

Table 3.32

PA1 PA2 PA3 PA4 PA5 PA6 PA7 PA8 PA9 PA100

20

40

60

80

100

Project Analysis Q1 - Q10


Section 5 – Reasons for failure (RFF1-12)

1. Lack of user involvement.

Table 3.33 User involvement

Strongly disagree



RFF1 3% 7% 17% 38% 34% 29

Table 3.33 above indicates that the majority of respondents (72%) agreed that lack of user involvement is one of the reason why ICT project fails, whilst 10% disagree.

2. Long or unrealistic timescales.

Table 3.34 Timescales

Strongly disagree



RFF2 3% 7% 31% 31% 28% 29

Table 3.34 above indicates that the majority of respondents (59%) agreed that ICT project fails because of long or unrealistic timescales, whilst 10% disagree.

3. Failure to adequately identify, document and track requirements.

Table 3.35 Requirement tracking

Strongly disagree



RFF3 3% 17% 14% 31% 34% 29

16

Table 3.35 above indicates that the majority of respondents (65%) agreed that failure to adequately identify, document and track requirements results in project failure, whilst 20% disagree.

4. Scope creep.

Table 3.36 Scope creep

Strongly disagree



RFF4 0% 3% 38% 48% 10% 29

Table 3.36 above indicates that the majority of respondents (58%) agreed that the change in project scope results in project failure, whilst 3% disagree.

5. No formal change control system.

Table 3.37 Formal change

Strongly disagree



RFF5 3% 7% 24% 59% 7% 29

Table 3.37 above indicates that the majority of respondents (66%) agreed that the lack of formal change control system results in project failure, whilst 10% disagree.

6. Inadequately trained or inexperienced project managers.

Table 3.38 Project managers

Strongly disagree



RFF6 0% 14% 10% 41% 38% 29

Table 3.38 above indicates that the majority of respondents (79%) agreed that inadequately trained or inexperienced project managers results in project failure, whilst 14% disagree.

7. Poor leadership at any and all levels.

Table 3.39 Poor leadership

Strongly disagree



RFF7 3% 3% 10% 52% 31% 29

Table 3.39 above indicates that the majority of respondents (83%) agreed that Poor leadership results in project failure, whilst 6% disagree.

17

8. Politics.

Table 3.40 Politics

Strongly disagree



RFF8 0% 10% 10% 34% 45% 29

Table 3.340 above indicates that the majority of respondents (78%) agreed that politics results in project failure, whilst 24% disagree.

9. Poor plans and planning processes.

Table 3.41 Poor planning

Strongly disagree



RFF9 0% 14% 17% 52% 17% 29

Table 3.41 above indicates that the majority of respondents (69%) agreed that poor plans and planning processes results in project failure, whilst 14% disagree.

10. Misalignment between the project team and the business it serves.

Table 3.42 Misalignment

Strongly disagree



RFF10

0% 21% 24% 45% 10% 29

Table 3.42 above indicates that the majority of respondents (55%) agreed that misalignment between the project team and the business it serves, whilst 21% disagree.

11. Inadequate or misused methods, processes and procedures.

Table 3.43 Misused of methods, processes and procedures

Strongly disagree



RFF11

3% 14% 38% 31% 14% 29

Table 3.43 above indicates that the majority of respondents (45%) agreed that inadequate or misused methods, processes and procedures results in project failure, whilst 17% disagree.

12. Inadequate communication in process tracking and reporting.

Table 3.44 Communication


18

disagree nor disagree participantsRFF12

0% 3% 0% 52% 45% 29

Table 3.44 above indicates that the majority of respondents (97%) agreed that there is a proper plan which will identify any change in requirements, whilst 3% disagree.

Section 5 – Reasons for Failure (RFF1-12) Graph

The above data from RFF1 – RFF12 is now presented in a form of graph.

Table 3.45

RFF1 RFF2 RFF3 RFF4 RFF5 RFF6 RFF7 RFF8 RFF9 RFF10 RFF11 RFF120

10

20

30

40

50

60

70

80

90

100

Reasons for failure Q1 - Q12


4.0 Chapter 4: RECOMMENDATIONS AND CONCLUSION

4.1 INTRODUCTION

Following from the analysis of the results of this dissertation, the following recommendations are put forward with the view to address the gaps in the project management.

This chapter will summarize research findings and will propose recommendations to bridge the gap in Tshwane’s information technology project management approach.

4.2 WHY PROJECTS FAIL

Typically, projects fail when they do not deliver on the schedule, budget, scope and quality constraints. A key factor to consider is that there is no one overriding factor to determine project failure or success. Some of the most important reasons for failure are listed below:

19

Lack of User Involvement

Without user involvement, nobody in the business feels committed to a system, and can even be opposed to it. If a project is to be a success, senior management and users need to be involved from the start and continually throughout the development of the project. Senior management must continuously support the project to make it clear to the staff that the project is priority.

Long or Unrealistic Time Scales

Long timescales for a project generally lead to a system being delivered for products and services no longer in use by an organization. The key recommendation is that project timescales should be short. Short time scales could be created by phasing or separating larger projects so that they become more manageable.

Many managers are aware of the need for fast delivery, leading the problem of unrealistic timescales. These time scales are set without considering the volume of work that needs to be completed to ensure delivery. As a result, these systems are either delivered late or only have a fraction of the facilities that were required. The recommendation here is to review all project plans to see if they are realistic.

Scope Creep

Scope is the overall view of what the system will deliver. Scope creep is the growth in the scale of a system during the life of the project. Since all the functionality of the revised system has to be delivered at one time, project timescales are negatively impacted. Scope creep is a management issue closely related to change control. Management must be realistic about project deliverables and time scales. Changes to the project must be closely controlled and monitored.

Lack of a Meaningful Change Control System

Change is continuous in business. It is not practical to expect no change in requirements while a system is being built. However, uncontrolled changes play havoc with a system under development and have caused many project failures in the past. This result emphasizes the advantages of shorter timescales and a phased approach to project management.

Poorly Defined Project Outcomes

Many projects have high level, vague and generally poorly defined requirements. Poorly defined outcomes leads to developers, having little or no input from the users, building what they believe is required, without having any real knowledge of the business.

Inevitably, when the system is delivered, business users are dissatisfied with the project results. Users must know what they require and must be able to match project deliverables with business requirements. In order to match deliverables with requirements successfully, users need skills and training.

Project managers are appointed at the concept stage of the project.The most frequent response to this question was “disagree‟. 56% respondents noted from their past experience that project managers are not appointed at the concept stage of the project.

This delay in appointing a project manager poses a problem at the very onset of the project as the

20

project manager is not fully conversant with the history or requirements of the project, he/ she may not have bought into the project dynamics and his/her overall influence on the outcomes of the project is thus limited. The PMI advocates that the project manager be appointed at the conceptual stage of a project. He/she is the strategist that formulates the management approach. The project charter is developed during the concept stage, and the project manager becomes the custodian of this charter for the life of the project. Hence, his/her acceptance and buy in from the onset of the project is crucial to project success.

The appointment of the project manager at the concept stage of the project is the responsibility of the client (project owner). A failure to timeously make this appointment could inhibit project success.

The project manager is involved in the project selection process.

The most frequent response to this question was “disagree‟. 55% respondents noted from their past experience that project managers are not involved in the project selection process.

According to Cleland and Ireland (2002: page 212), ideally, an organization will select projects that align with the strategic goals and that build on current capability. Each project that is selected and implemented should be a building block that promotes the organization’s purpose and that positions the organization for an improved future capability. Any project not aligned with the strategic goals may detract from the organizations purpose and delay its growth.

As suggested by Burke (2004: page 56), the selection of the right project for future investment is a crucial decision for the long-term survival of a company. The selection of the wrong project may well precipitate project failure leading to company liquidation.

The execution of a project will tie up company resources and, as an opportunity cost, the selection of one project may preclude a company from pursuing another (more profitable) project. Therefore, a process is required to select and rank projects on the basis of beneficial change to a company. Typically, the methods to be employed are:

1. Constrained Optimization (mathematical models)2. Benefits Measurement (these include calculations of the net present value, internal rate of

return and cost benefit analysis)

PMI recommends involvement of the project manager during the project selection process. His/her buy-in and commitment is invaluable in establishing the business case for the project, developing the project charter, clearly defining tangible project objectives and deliverables and, hence, initiating the project. Project success will be defined by delivering on these tangible objectives that are clearly defined at project initiation.

4.3 DEFINING SUCCESS AND FAILURE

In the realm of project management, a project that satisfies all the criteria of success may still carry the stigma of failure because of people’s perceptions. Project failure is measured across a spectrum. On one hand, there are clear failures such as:

No value for money delivered; The wrong thing was delivered; The delivery was so late as to render the product useless;

21

The product quality was so poor as to make the product useless; The project cost much more than was planned making the product financially not viable.

Each of these clear failures can be seen along a spectrum moving from complete failure to complete success. To avoid the perception of failure, it’s not enough to succeed – but it’s a start. Defining the boundaries of the project well, could alleviate the perception of failure, through the following:

When the project starts and ends; Prescribing the budget; Clearly defining goals and deliverables; Identifying stakeholders and what benefits they expect; Defining what level of quality is required and how quality will be measured; The change control process must be well defined and executed;

Finally, there should be ongoing communication to stakeholders and other interested parties to build an appropriate level of expectation on a project with well-defined boundaries. The project must deliver within boundaries and meet or exceed expectations that were set.

4.4 ROLES AND RESPONSIBILITIES OF THE PROJECT MANAGER

As suggested by PMBOK Guide (2004), the role of the project manager encompasses many activities including:

Planning and Defining Scope; Activity Planning and Sequencing; Resource Planning; Developing Schedules; Time Estimating; Cost Estimating; Developing a Budget; Controlling Quality; Managing Risks and Issues; Creating Charts and Schedules; Risk Analysis; Benefits Realization; Documentation; Team Leadership; Strategic Influencing; and Customer Liaison.

Running a successful project requires a high degree of stakeholder management. A stakeholder is anyone who has an interest in the project or will be affected by its deliverables or output. It is important to understand the values and issues that stakeholders have in order to address them and keep everyone on board for the duration of the project. This is effected through:

Setting Goals and Objectives

Involve stakeholders in creating a set of realistic goals and objectives. Stakeholders are not always keen to participate but engaging them at this early stage of the project will help ensure success. Stakeholders are most likely to be actively engaged by a set of goals and objectives aimed at improving business performance and thereby take an interest in the project.

22

Agreeing Deliverables

All projects need a clear set of deliverables aimed at achieving the project goals and objectives. These deliverables should be communicated clearly to the stakeholders and efforts made to ensure that there is a clear understanding regarding the quality and composition of each deliverable. In order to achieve success, prototypes and samples can be prepared to avoid misunderstandings or disappointment later.

Communicating Information

Once the project is running there are two groups of people who need to be kept informed of progress, the project team and the stakeholders. The most effective way of communicating progress is via regular progress reports. The reports form a useful record of the project and can be e-mailed to all relevant parties and/or placed in a central repository to which everyone has access.

According to Cleland and Ireland (2002), a project manager must have the following skills to succeed:

Leadership - inspiring others to create a vision and strive to achieve the goals; Good communication - ability to provide valuable information related to the project status in

a timely and effective manner; Negotiation skills - maintaining relationships with people who are involved in the project; Conflict resolution skills - assisting in resolution of any project conflicts so that the project

team members all feel part of the process and want to remain involved in the project; Relationship management - capable of working with all levels within the organization by

building relationships with them. Listening skills - using good listening skills to truly hear and try to understand what others on

the project are trying to say;

Morris and Hough (2003) assist in identifying other skills project managers need to be effective. These include:

To manage, motivate and organize people; Vision - understanding what needs to be done and how to get it done; Flexibility - capable of changing to fit the situation for the good of the project; Ability to influence without having authority;

"The project manager is the catalyst, the initiator who lifts the entire project and puts it into motion" according to Heldman (2002: page 30). He also stated "energy and attitude gives the project manager power." Leadership is crucial for a project manager who must motivate people who are on the project teams and in functional departments.

4.5 AREAS FOR FURTHER RESEARCH

The research conducted proved to be both valid and reliable. Responses received were consistent and reputable. The research achieved the objectives that it set out to achieve. Further research can be undertaken to investigate the reasons for failure of community-based Information technology projects on a regional and national basis. This study forms a good baseline for future research.

23

4.6 REFERENCES

Bailey, E.P. 1987. Writing research papers: a practical guide. New York: Holt

Creswel, J.W. 2012. Educational Research: Planning, Conducting and Evaluating Qualitative and

Quantitative Research.4th edition. Boston: Pearson Education, Inc.

Cooper, D. & Schindler, P. 2001, Research Methodology. 7th ed. New York: McGrawHill

Cookerman, J. Jan/Feb 2005. Identifying Business Needs for Success. ProquestInformation and Learning, Pgs 40-44

Project Management Institute. 2004, A Guide to the Project Management Body ofKnowledge. 3rd edition. New York: Project Management Institute Inc

Chin, P. 2003. Why IT projects Fail [Online]. Available:http://itmanagement.earthweb.com/print.php/2201981 [31 May 2011].

Creating Value in Project Management Using PRINCE2. 2010. [Online]. Available:http://www.prince2.com/downloads/CreatingValueInProjectManagementUsingPrince2.pdf [15 March 2011].

Dalcher, D. 2009. Software Project Success: Moving Beyond Failure. The EuropeanJournal for the Informatics Professional, x(5): 43-50.

Holt, M. 2003. Butler Group Review Journal Article. Why do so many IT projects fail?[Online]. Available: http://www.brett-tech.com/Downloads/itprojectfailures.pdf [31 May2011].

IT Governance Institute (ITGI). 2008. Enterprise Value: Governance of IT investments,Getting Started with Value Management [Online]. Available:http://www.isaca.org/Knowledge-Center/Val-IT-IT-Value-Delivery-/Documents/Val-ITGetting-Started-Jul-2008.pdf [21 March 2011].

24

4.7 APPENDIX

Appendix 1: Research Questionnaire

SUBJECT INFORMATION LETTER FOR PARTICIPANTS

Dear Participant

I am currently studying towards a BACCALAUREUS TECHNOLOGIAE degree in Business Information

Systems. For the purposes of my study, I intend to carry out research into the factors contributing to

project failure within City of Tshwane Municipality. The investigation requires the completion of a

questionnaire by interested employees. Kindly note that by responding to the questionnaire, you

would not only be making a valuable contribution to this research, but also provide invaluable

insight into the deterrents to project success within the city.

It would therefore be appreciated if you would complete the attached questionnaires. Your

individual responses are of importance to this research so therefore please do not consult with

colleagues. The completion this questionnaire should not take more than 15 minutes.

You are assured of the confidentiality of your responses. Responses may be anonymous and your

name is not required on the questionnaire. Your participation is voluntary and you may withdraw at

any time without giving any reasons. Kindly send back the completed questionnaire into my email

address ([email protected]) by no later than 15th October 2015.

Thank you for your co-operation and the time that you have set aside for this research.

Yours faithfully

Remember Mathebula

Research Supervisor: Mr. Makgopela MM

Head of subject: Department of

Informatics: TUT

084 029 6604 / 079 329 7387

mailto:[email protected]

25

I the undersigned agree to participate in this research

____________________

Respondent signatureInstructions: Please use the five-point scale (shown below) to respond to the questions. Fill in a cross in the box with the number that corresponds with your view.

Example using the 5 Point Likert Scale

Strongly DisagreeNeither Agree Agree Strongly

Disagree Nor Disagree Agree

1 2 3 4 5

Eg 1Project outcomes generally meet the client's business

xrequirements

Eg 2Project success is entirely within City of Tshwane’s control x

Section 1 - Strategic Alignment

1Projects are selected in line with business goals

2Project outcomes are generally aligned with businessgoals

3Requirements are clearly defined from the beginning

4Use of Work breakdown structure(WBS), Network activity when planning a project

5Project outcomes are clearly defined by the client

6The client determines project success by measuringproject outcomes

Strongly DisagreeNeither Agree Agree Strongly

Disagree Nor Disagree Agree

1 2 3 4 5Section 2 - Project Selection

1Project managers are appointed at the concept stage ofthe project

26

2The project manager is involved in the project selectionprocess

3Project results have a strategic fit in the design andexecution of future products and services

4Projects are selected in line with business growth andexpansion strategies

5The principles of project management are applieduniformly irrespective of the size of the project

Section 3 - Project Outcomes

1The project usually satisfies the business operationalrequirements

2Project deliverables are generally produced on time andwithin budget

3The business owners usually believe that the project wassuccessful

4Projects always deliver the business value it promises

5The time, cost, quality and scope constraints are usuallymanaged as planned

6Projects ultimately provide satisfactory return oninvestment to the customer

Section 4 – Project Analysis

1 Clients clearly defined the business case

2The stakeholders have knowledge about the project

3The stakeholders have a good communication skills

4All the functional requirements of the system gathered at the beginning

5The client have a better understand about what he/she needs

6

Are there software tools used in planning and management of requirements

7The goals and objectives are always within the project scope

8 Will the employees accept the change

9The project solution always meet the business needs

10 There is a proper plan which will identify any

27

change in requirements

Section 5 - Reasons for failure

1 Lack of user involvement2 Long or unrealistic timescales

3Failure to adequately identify, document and trackrequirements

4 Scope creep5 No formal change control system

6Inadequately trained or inexperienced project managers

7 Poor leadership at any and all levels8 Politics9 Poor plans and planning processes

10Misalignment between the project team and the businessit serves

11Inadequate or misused methods, processes andprocedures

12Inadequate communication in process tracking andreporting

Thanks for your time and contribution in the study. Wish you the best in your work.