17.05.2017 Views

Pan-Pacific Conference XXXIV. Designing New Business Models in Developing Economies

This publication represents the Proceedings of the 34th Annual Pan-Pacific Conference being held in Lima, Peru May 29-31, 2017. The Pan-Pacific Conference has served as an important forum for the exchange of ideas and information for promoting understanding and cooperation among the peoples of the world since 1984. Last year, we had a memorable conference in Miri, Malaysia, in cooperation with Curtin University Sarawak, under the theme of “Building a Smart Society through Innovation and Co-creation.” Professor Pauline Ho served as Chair of the Local Organizing Committee, with strong leadership support of Pro Vice-Chancellor Professor Jim Mienczakowski and Dean Jonathan Winterton.

This publication represents the Proceedings of the 34th Annual Pan-Pacific Conference being held in Lima, Peru May 29-31, 2017. The Pan-Pacific Conference has served as an important forum for the exchange of ideas and information for promoting understanding and cooperation among the peoples of the world since 1984. Last year, we had a memorable conference in Miri, Malaysia, in cooperation with Curtin University Sarawak, under the theme of “Building a Smart Society through Innovation and Co-creation.” Professor Pauline Ho served as Chair of the Local Organizing Committee, with strong leadership support of Pro Vice-Chancellor Professor Jim Mienczakowski and Dean Jonathan Winterton.

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Factors of IT project failure<br />

One of the study’s ma<strong>in</strong> research questions is to<br />

ga<strong>in</strong> <strong>in</strong>sight <strong>in</strong>to the factors for IT project failure at<br />

a South African SOE. The responses were quite<br />

diverse and related to the five of the six sources of<br />

project failure as <strong>in</strong> figure 2. The figure below<br />

summarises the key responses and how they relate<br />

to these sources of IT project failure:<br />

FIGURE 3: Factors of IT project failure<br />

Project management<br />

• Poor project plann<strong>in</strong>g<br />

• Poor requirements management<br />

• Poor documentation<br />

Organisational<br />

• Lack of skills<br />

• Project resources revert back to operational<br />

work dur<strong>in</strong>g project<br />

• IT department works <strong>in</strong> islation<br />

Process<br />

• Lack of knowledge about <strong>in</strong>ternal processes<br />

• Poor governance<br />

• Project prioritisation<br />

Top management<br />

• Lack of support<br />

• Contradict<strong>in</strong>g requirements from sponsor<br />

and bus<strong>in</strong>ess<br />

Complexity and size<br />

• Undocumented change requests<br />

Technolgy<br />

• Little knowledge of products from<br />

<strong>in</strong>ternational vendors<br />

All the <strong>in</strong>terviewees lamented the fact that poor<br />

requirements management is a central aspect.<br />

However, some of the <strong>in</strong>terviewees stated that<br />

project managers were not <strong>in</strong>volved <strong>in</strong> any<br />

mean<strong>in</strong>gful way dur<strong>in</strong>g the plann<strong>in</strong>g process. In<br />

some cases, project managers were assigned to<br />

projects that already well underway. This is<br />

extremely disconcert<strong>in</strong>g.<br />

The second greatest source of failure is<br />

organisational factors. The <strong>in</strong>terviewees were<br />

mostly concerned about human resource<br />

considerations. There was a concern about the lack<br />

of skilled resources and how they were allocated to<br />

the project. What the <strong>in</strong>terviewees found most<br />

egregious was the fact that committed resources<br />

readily reverted to their own operational duties<br />

while the project is still <strong>in</strong> execution. It would<br />

appear that these resources are not dedicated to the<br />

project by their respective management teams.<br />

A peculiar issue surround<strong>in</strong>g organisational culture<br />

and communication also emerged. Defects and<br />

project issues are not escalated timeously. There is a<br />

sense of fear of escalat<strong>in</strong>g tasks to avoid bad<br />

relationships with<strong>in</strong> the environment.<br />

Thirdly, process considerations seems to be great<br />

source of IT project failure as well. There seems to<br />

be great lack of knowledge on the part of project<br />

practitioners around <strong>in</strong>ternal processes. This may<br />

stem from the fact that these IT departments operate<br />

<strong>in</strong> isolation from the rest of the organisation. The<br />

lack of governance <strong>in</strong> many cases is also a concern.<br />

The rganizations policies and processes def<strong>in</strong>e how<br />

work is done as well as how projects are conducted.<br />

CONCLUSION<br />

All agreed that a successful project should have a<br />

technical as well as product component. A project<br />

could conceivably be successful <strong>in</strong> terms of<br />

schedule, cost and quality constra<strong>in</strong>ts and yet fail <strong>in</strong><br />

the eyes of the customer if that deliverable does not<br />

meet their needs. The opposite can be true as well.<br />

The greatest risk of failure for SOE’s <strong>in</strong> this context<br />

lies <strong>in</strong> project management, organisational and<br />

process factors. The greatest concerns lies around<br />

the commitment of resources, poor requirements<br />

management and communication.<br />

The follow<strong>in</strong>g recommendations are presented to<br />

project practitioners and managers who are<br />

accountable for successful project delivery:<br />

(i) The organization must clearly<br />

communicate their expectation to project<br />

managers <strong>in</strong> terms of what is considered a<br />

successful project: technical vs. product<br />

success.<br />

(ii) The formal adoption of project<br />

management guides or standards are<br />

strongly advised.<br />

(iii) A communication plan that facilitates<br />

open an honest communication should be<br />

implemented.<br />

(iv) Stability <strong>in</strong> fully discovered requirements<br />

are essential <strong>in</strong> ensur<strong>in</strong>g that projects do<br />

not become victims to undocumented or<br />

cont<strong>in</strong>uous change management<br />

procedures.<br />

(v) The practice of redeploy<strong>in</strong>g project<br />

managers mid-project and replac<strong>in</strong>g him<br />

or her with another project manager must<br />

halt and only be considered if absolutely<br />

necessary.<br />

(vi) Project managers who understand the<br />

technology and have the technical skills to<br />

manage a project are far more likely to<br />

successfully deliver a project. These<br />

project managers need to identify their<br />

skill gaps and approach a management<br />

team who is will<strong>in</strong>g to upskill the<br />

<strong>in</strong>dividuals who are responsible for<br />

deliver<strong>in</strong>g projects.<br />

Areas for further research <strong>in</strong>clude:<br />

(i) The role of governance <strong>in</strong> the<br />

successful delivery of IT projects <strong>in</strong><br />

the public sector;<br />

(ii) A framework for the governance of<br />

portfolios, programs and projects for<br />

public enterprises, and;<br />

(iii) A comparison of practices <strong>in</strong> public<br />

and private organisations <strong>in</strong> the<br />

delivery of IT projects.<br />

REFERENCES<br />

References available upon request.<br />

147

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!