a conceptual framework for information technology project

A CONCEPTUAL FRAMEWORK FOR INFORMATION

TECHNOLOGY PROJECT MANAGEMENT AUDITING

By:

Jean-Paul M. MUKA

DISSERTATION

Submitted in fulfilment of the requirements for the degree of

MASTER OF TECHNOLOGY

In the

DEPARTMENT OF BUSINESS INFORMATION TECHNOLOGY

At the

UNIVERSITY OF JOHANNESBURG

SUPERVISED BY Dr. Carl Marnewick

CO-SUPERVISED BY Prof. Les Labuschagne

(SEPTEMBER 2011)

i

ACKNOWLEDGEMENTS

To Shila, Andy and Flory.

First of all, I wish to thank the Almighty God for the gift of life and good health, without which I

would never have been able to complete this project.

I also wish to extend my gratitude to all those who, directly or indirectly, helped me in completing

this work. This includes family and friends who supported me in various ways. These people are

too numerous to mention by name, but I wish to single out my parents who first taught me the

value of hard work and sacrifice.

Dr. C. Marnewick, my supervisor, has helped me immensely in completing this dissertation. His

rigorous critiques proved to be exactly what was needed. Many thanks to him and to all the

University of Johannesburg (UJ) staff who contributed. I am also absolutely grateful to Prof. L.

Labuschagne, my co-supervisor, whose insights were invaluable in the conception of this

research.

Last but not least, I wish to thank my dear wife [Shila] and our two boys [Andy and Flory] for their

unfailing love and support. They were certainly robbed of precious family time during the long

hours required to complete this project. This work is dedicated to them!

To God be the glory.

ii

ABSTRACT

In this age of ever-increasing competition, organisations are facing unprecedented pressure to

meet the combined obligations of showing returns to shareholders, and staying ahead of the

competition. To meet these obligations, organisations have become increasingly dependent on

technology, as an enabler. This dependency suggests that technology projects have become

strategically more important than ever for organisations; yet the success of technology projects

remains questionable. Furthermore, organisations do not have simple mechanisms to allow them

to quickly and accurately trace the causes of IT project management failures. One of the causes

of project management failures is the inability and/or unwillingness of project managers to adhere

to project management best practices adopted by their organisations.

This research proposes a simple and repeatable model to help organisations determine whether

they are indeed following the project management best practices which they purport to follow.

The research methods consisted firstly of a wide review of relevant literature on auditing, project

management, and IT governance. Secondly, empirical data was collected and analysed. Thirdly,

modelling was used to develop a conceptual model for auditing IT project management.

The empirical study is based on a semi-structured interview, involving ten project managers in

charge of IT projects. The findings from this research confirm that project managers do not

adhere to project management best practices which they purport to follow. Consequently, this

dissertation concludes that IT project managers must adhere to best practices adopted by their

organisations, regardless of how impractical or inconvenient that may seem; the proposed model

for auditing IT project management helps them achieve just that.

Keywords: project management, auditing, model, Information Technology, IT governance.

iii

TABLE OF CONTENTS

ABSTRACT.................................................................................................................................. i ACKNOWLEDGEMENTS............................................................................................................ ii LIST OF TABLES...................................................................................................................... vii LIST OF FIGURES.................................................................................................................... vii 1 CHAPTER 1 – DISSERTATION INTRODUCTION ..............................................................1

1.1 Introduction.................................................................................................................1 1.1.1 Background........................................................................................................1 1.1.2 Research Goals .................................................................................................2 1.1.3 Research Objectives ..........................................................................................2 1.1.4 Layout ................................................................................................................3

1.2 Problem statement......................................................................................................3 1.3 Research process.......................................................................................................4

1.3.1 Explore...............................................................................................................4 1.3.2 Propose .............................................................................................................4 1.3.3 Prepare ..............................................................................................................4 1.3.4 Execute..............................................................................................................5 1.3.5 Analyse ..............................................................................................................5 1.3.6 Publish...............................................................................................................5

1.4 Research deliverables ................................................................................................5 1.4.1 Literature review.................................................................................................5 1.4.2 Audit guidelines..................................................................................................7 1.4.3 Project management components ......................................................................7 1.4.4 Guideline for auditing IT projects ........................................................................8 1.4.5 Current state of project management..................................................................8 1.4.6 Conceptual model ..............................................................................................8

1.5 Dissertation Layout .....................................................................................................9 2 CHAPTER 2 – RESEARCH METHODOLOGY AND DESIGN ...........................................11

2.1 Introduction...............................................................................................................11 2.1.1 Background......................................................................................................11 2.1.2 Goal .................................................................................................................11 2.1.3 Objectives ........................................................................................................11 2.1.4 Chapter Layout.................................................................................................12 2.1.5 Research design ..............................................................................................12 2.1.6 Research methodology.....................................................................................13

2.1.6.1 Research philosophy................................................................................14 2.1.6.2 Research approaches ..............................................................................16 2.1.6.3 Research types ........................................................................................20 2.1.6.4 Research methods...................................................................................22 2.1.6.5 Research time horizons............................................................................25 2.1.6.6 Data collection and analysis techniques ...................................................26

2.2 Conclusion................................................................................................................37 3 CHAPTER 3 – LITERATURE REVIEW ON AUDITING......................................................40

3.1 Introduction...............................................................................................................40 3.1.1 Background......................................................................................................40 3.1.2 Goal .................................................................................................................40 3.1.3 Objectives ........................................................................................................40 3.1.4 Layout ..............................................................................................................40

3.2 Brief historical overview on auditing ..........................................................................41 3.3 Defining auditing.......................................................................................................43

3.3.1 Types of audit...................................................................................................44 3.3.2 Types of auditors..............................................................................................47

iv

3.4 Auditing Standards ...................................................................................................48 3.4.1 Generally Accepted Auditing Standards (GAAS)...............................................49

3.5 Project management auditing....................................................................................51 3.5.1 Defining project management auditing..............................................................52 3.5.2 Types of project management audit ..................................................................53 3.5.3 Types of project management auditors .............................................................54 3.5.4 The project management audit process ............................................................54

3.6 Conclusion................................................................................................................56 4 CHAPTER 4 – LITERATURE REVIEW ON PROJECT MANAGEMENT ............................58


4.2 Brief historical overview on project management.......................................................59 4.3 Defining project management ...................................................................................61

4.3.1 Defining a project .............................................................................................61 4.3.2 Defining project management ...........................................................................64

4.3.2.1 Knowledge...............................................................................................65 4.3.2.2 Skills........................................................................................................65 4.3.2.3 Tools and techniques...............................................................................66

4.4 Project management best practices ..........................................................................67 4.4.1 A Guide to the Project Management Body of Knowledge (PMBOK® Guide)......68

4.5 Conclusion................................................................................................................71 5 CHAPTER 5 – LITERATURE REVIEW ON INFORMATION TECHNOLOGY GOVERNANCE.........................................................................................................................73


5.2 Overview of IT governance .......................................................................................74 5.2.1 Defining IT governance ....................................................................................74 5.2.2 The importance of IT governance .....................................................................76 5.2.3 IT governance components ..............................................................................78

5.2.3.1 IT governance principles and decision-making hierarchy ..........................78 5.2.3.2 Information strategy .................................................................................79 5.2.3.3 IT strategy................................................................................................79 5.2.3.4 IT risk management .................................................................................79 5.2.3.5 IT architecture..........................................................................................80 5.2.3.6 IT investment and project governance......................................................80 5.2.3.7 Regulatory compliance and information security.......................................81

5.3 IT governance sources .............................................................................................82 5.4 COBIT as an IT governance framework ....................................................................83

5.4.1 Brief historical overview and current perspectives.............................................83 5.4.2 What is the COBIT framework? ........................................................................84 5.4.3 COBIT structure ...............................................................................................84

5.4.3.1 IT processes ............................................................................................84 5.4.3.2 IT resources.............................................................................................85 5.4.3.3 Quality criteria..........................................................................................86

5.4.4 COBIT approach ..............................................................................................87 5.4.4.1 COBIT control mechanism .......................................................................88 5.4.4.2 Project management audit steps ..............................................................91

5.5 Conclusion................................................................................................................92 6 CHAPTER 6 – DATA COLLECTION AND ANALYSIS.......................................................94

6.1 Introduction...............................................................................................................94

v

6.1.1 Background......................................................................................................94 6.1.2 Goal .................................................................................................................94 6.1.3 Objectives ........................................................................................................95 6.1.4 Layout ..............................................................................................................95

6.2 Overview of the data collection .................................................................................95 6.2.1 Data collection steps ........................................................................................95 6.2.2 Interview questions...........................................................................................97 6.2.3 Data collection techniques................................................................................99 6.2.4 Data analysis techniques................................................................................100 6.2.5 Target population ...........................................................................................100 6.2.6 Sampling........................................................................................................100 6.2.7 Recruitment of interview respondents .............................................................101 6.2.8 Ethical considerations.....................................................................................101

6.3 Presentation of data................................................................................................102 6.4 Data analysis and recommendations.......................................................................109 6.5 Conclusion..............................................................................................................120

7 CHAPTER 7 – A CONCEPTUAL AUDIT MODEL............................................................122 7.1 Introduction.............................................................................................................122

7.1.1 Background....................................................................................................122 7.1.2 Goal ...............................................................................................................122 7.1.3 Objectives ......................................................................................................122 7.1.4 Layout ............................................................................................................122

7.2 Existing knowledge .................................................................................................123 7.3 The role of project components in the model ...........................................................125

7.3.1 The role of generic auditing steps ...................................................................125 7.3.2 The role of project components.......................................................................126 7.3.3 The role of the IT project auditing guideline in the model.................................126

7.4 The conceptual model.............................................................................................126 7.4.1 Phase 1: Merge generic audit steps and project components..........................126

7.4.1.1 Before the audit......................................................................................127 7.4.1.2 During the audit......................................................................................127 7.4.1.3 After the audit ........................................................................................127

7.4.2 Phase 2: Merge the output of phase 1 and the guidelines for auditing IT projects 128

7.4.2.1 Before the audit......................................................................................128 7.4.2.2 During the audit......................................................................................128 7.4.2.3 After the audit ........................................................................................128

7.4.3 Integrated model for IT project management auditing......................................128 7.4.3.1 Before the audit......................................................................................129 7.4.3.2 During the audit: planning ......................................................................129 7.4.3.3 During the audit: fieldwork......................................................................129 7.4.3.4 After the audit ........................................................................................129

7.4.4 Application of the conceptual audit model on the Develop project charter process 130

7.4.4.1 Before the audit......................................................................................131 7.4.4.2 During the audit: planning ......................................................................131 7.4.4.3 During the audit: fieldwork......................................................................132 7.4.4.4 After the audit ........................................................................................134

7.5 Conclusion..............................................................................................................134 8 CHAPTER 8 – DISSERTATION CONCLUSION..............................................................135

8.1 Introduction.............................................................................................................135 8.2 Revisiting the problem ............................................................................................136

8.2.1 Research Goal ...............................................................................................136 8.2.2 Research Objectives and Findings..................................................................137

8.2.2.1 Objective 1 – Guideline for the auditing process .....................................137 8.2.2.2 Objective 2 – Project components ..........................................................137

vi

8.2.2.3 Objective 3 – Guideline for auditing IT projects.......................................138 8.2.2.4 Objective 4 – Collect and analyse data through an empirical study .........138 8.2.2.5 Objective 5 – A conceptual model ..........................................................139

8.3 From findings to conclusions...................................................................................139 8.3.1.1 Conclusion 1..........................................................................................139 8.3.1.2 Conclusion 2..........................................................................................139 8.3.1.3 Conclusion 3..........................................................................................139 8.3.1.4 Conclusion 4..........................................................................................140 8.3.1.5 Conclusion 5..........................................................................................140

8.4 Research limitations ...............................................................................................140 8.4.1 Limited sampling ............................................................................................140 8.4.2 Cross-sectional time horizon for data collection ..............................................140 8.4.3 Conceptual model limited to IT project management.......................................141

8.5 Research value.......................................................................................................141 8.6 Recommendations for further research ...................................................................142

8.6.1 Larger sample for empirical study ...................................................................142 8.6.2 Conduct a longitudinal study...........................................................................142 8.6.3 Develop a conceptual model applicable to both IT and non-IT project management auditing......................................................................................................142

8.7 Self reflections........................................................................................................142 LIST OF REFERENCES..........................................................................................................144 APPENDIX A: Interview invitation letter ...................................................................................168 APPENDIX B: Interview Transcripts.........................................................................................169

vii

LIST OF TABLES

Table 1.1: Summary of research deliverables, main chapter and value ........................................8 Table 1.2: Research philosophies..............................................................................................16 Table 2.1: Deductive vs inductive research approaches.............................................................20 Table 2.3: Summary of research types.......................................................................................22 Table 2.4: Research methods....................................................................................................24 Table 2.5: Research time horizons.............................................................................................26 Table 2.6: Data collection techniques ........................................................................................31 Table 2.7: Data analysis techniques ..........................................................................................36 Table 3.1: Evolution of auditing..................................................................................................42 Table 3.2: Types of audit identified vs types of audit used for the purpose of this research.........46 Table 4.1: Evolution of project management ..............................................................................61 Table 5.1: IT governance components.......................................................................................81 Table 5.2: The four COBIT domains and their respective IT processes ......................................85 Table 5.3: The four COBIT IT resources and their respective focus............................................86 Table 5.4: The seven COBIT information criteria and their respective focus ...............................87 Table 6.1: Interview questions and answers.............................................................................103 Table 6.2: Interview data categories ........................................................................................104

LIST OF FIGURES

Figure 1.1: The Literature Review Process ..................................................................................7 Figure 1.2: Dissertation layout ...................................................................................................10 Figure 2.1: Hourglass research design.......................................................................................13 Figure 2.2: Research onion .......................................................................................................37 Figure 3.1: Three-step process of auditing.................................................................................43 Figure 3.2: Simplified triple dimension of auditing.......................................................................48 Figure 3.3: Expanded triple dimension of auditing......................................................................51 Figure 3.4: Three-step process for auditing project management ...............................................53 Figure 3.5: Four-step process for auditing project management .................................................55 Figure 3.6: Expanded process for auditing project management ................................................55 Figure 4.1: Project components .................................................................................................64 Figure 4.2: Project management components............................................................................67 Figure 4.3: Process components ...............................................................................................69 Figure 4.4: Flow of data in the “Develop project charter” process ...............................................70 Figure 5.1: Governance pyramid................................................................................................76 Figure 5.2: The COBIT control mechanism ................................................................................90 Figure 5.3: Guideline for auditing IT projects..............................................................................92 Figure 7.1: Four-step audit process .........................................................................................123 Figure 7.2: Nine project components .......................................................................................124 Figure 7.3: Guideline for auditing IT projects............................................................................125 Figure 7.4: Generic audit process merged with project components.........................................127 Figure 7.5: Integrated conceptual model for auditing project management ...............................130 Figure 8.1: Mapping between Bloom’s taxonomy of cognitive learning and this dissertation .....136

_____________________________________________________________________ Chapter 1 – Dissertation Introduction 1

CHAPTER 1 – DISSERTATION INTRODUCTION

1.1 Introduction

1.1.1 Background

In today’s business environment marked by intense competition, organisations face ever-

increasing pressures to meet shareholders’ expectations (Murray, 2002:165; McMullin, 2007;

Wyman, 2007). Achieving profitability objectives – increasing revenue and/or decreasing cost – is

an integral part of the said shareholders’ expectations (Grant & Abate, 2001:45; Australian

Shareholders’ Association, 2005:1). Successful Information Technology (IT) project management

is also recognised as a catalyst in achieving an organisation’s profitability objectives, and

ultimately in creating shareholder value (Floyd, 1997: 229-233; Cooke-Davies, 2002; Hartman &

Ashrafi, 2002). Thus, there is a link between the need to create shareholder value in business

organisations and the need to manage projects successfully.

Although people have worked on projects for centuries, several authors agree that project

management - which is defined as the application of knowledge, skills, tools and techniques to

project activities to meet project requirements (Lewis, 2007; Project Management Institute, 2008;

Schwalbe, 2009) - became recognised as a modern discipline in the mid-twentieth century. As

such, project management is nowadays applied in virtually every industry, thereby greatly

influencing the way organisations do business (Nicholas, 2004; Cleland & Ireland, 2006; Haugan,

2006; Nicholas & Steyn, 2008; Kloppenborg, 2009:5; Schwalbe, 2009).

While similarities exist between Project Management principles across disciplines (Hartman &

Ashrafi, 2002; Haugan, 2011:275), IT project management differs substantially from project

management in other disciplines (Otto, Dhillon & Watkins, 1993; Roetzheim, 1993; Raybould,

1996; Samuels, 1996; Stepanek, 2005). Notwithstanding these differences, there is a need to

understand what makes the difference between failure and success in managing projects.

Baccarini (1999:25) describes project success as consisting of project management success on

the one side, and project product success on the other. While the former focuses on how well the

project management processes are followed, the latter focuses on the project’s end-result.

Considering this description of project success, it can be said that an effort to identify whether a

project is a success or a failure should follow either or both of the following approaches: either

verifying how well project management processes were followed, or verifying the presence or

absence of the project’s end result. The goals and objectives of this research are best addressed

through the former approach. The next section sets the goals and objectives for this research.


1.1.2 Research Goals

The goal of this research is to develop a model to guide organisations, through practical steps, in

determining whether they are following project management processes which they purport to

follow.

The following objectives need to be achieved, in order to meet these goals.

1.1.3 Research Objectives

� Objective 1 – To propose a guideline for the auditing process, in alignment with the

research problem, based on existing audit principles and guidelines. This objective is

achieved in Chapter 3, through the following sub-objectives:

o Sub-objective 1: Explore the evolution of auditing over time, and define auditing.

o Sub-objective 2: Identify and critically evaluate existing auditing standards.

o Sub-objective 3: Explore project management auditing, to understand the

relevance of auditing in project management.

� Objective 2 – To identify project components, based on existing project management

best practices. This objective is achieved in Chapter 4, through the following sub-

objectives:

o Sub-objective 1: Explore the evolution of project management over time, to its

current state.

o Sub-objective 2: Review project management and identify the various aspects to

take into account when auditing project management.

o Sub-objective 3: Identify recognised project management good practices

documentations, and review the project management approach on one of these

documentations.

� Objective 3 – Propose an adequate guideline for auditing IT projects, which aligns with

recognised IT governance frameworks. This objective is achieved in Chapter 5, through

the following sub-objectives: Review and evaluate different perspectives on IT

governance.

o Sub-objective 1: Review and evaluate different perspectives on IT governance.

o Sub-objective 2: Identify and review IT governance sources and frameworks.

o Sub-objective 3: Explore project governance and the relevance of governance in

project management.


� Objective 4 – Find out the extent to which recognised project management practices are

applied in practice within project management entities. This objective is achieved in

Chapter 6, through the following sub-objectives:

o Sub-objective 1: Collect data on how project managers manage project

management processes.

o Sub-objective 2: Analyse the collected data and identify emerging trends and

issues.

o Sub-objective 3: Present the findings of the data analysis and make

recommendations.

� Objective 5 – propose a conceptual model for auditing IT project management. This

model should integrate the essential principles and knowledge gathered through the

above four objectives. This objective is addressed in Chapter 7.

1.1.4 Layout

The remainder of this chapter is laid out as follows:

Firstly, the research problem is introduced, and then the research process followed throughout

this dissertation is outlined. Having outlined the research process, the specific research

deliverables are listed and summarily discussed. This chapter ends by presenting the layout of

this dissertation.

1.2 Problem statement

The success rate of IT projects remains questionable (Gibbs, 1994; Standish Group, 1995;

Bailey, 1996; Grenny, Maxfield & Simberg, 2007; Labuschagne, Marnewick & Jakovljevic, 2008).

To ensure greater success rates of IT projects, it is necessary to have processes in place to

guide the project execution in a consistent manner. Consistently following these processes

should ensure that the project succeeds both in terms of delivering the expected end-product

(project product success), and in terms of delivering optimal efficiency of project execution by

following the right project management processes (project management success).

Many organisations have such processes in place, namely in the form of project offices (Bridges

& Crawford, 2000; Kent Crawford, 2002; Project Management Institute, 2008). Yet in reality,

these processes do not seem to be followed consistently. As a result, not only the success of the

project is made unpredictable, but also in case of project failure it becomes difficult to identify

what went wrong.


This creates the opportunity for a mechanism to verify whether processes which were supposed

to be followed in managing a project were indeed followed. In pursuing this opportunity, this

research seeks to propose a model for auditing IT project management. Thus, the research

problem is formulated as follows:

Many organisations claim to manage projects according to some form of established best

practices. However, in reality these best practices do not seem to be followed

consistently; hence the need for a guideline to verify whether project management entities

really follow the project management best practices which they claim to follow.

In addressing this problem, this dissertation follows the following research process:

1.3 Research process

In line with recommendations by Olivier (2009), the following research process was followed:

1.3.1 Explore

This phase lays the basic foundation and determines the appropriateness of the research

problem. During this phase, literature review is conducted, including but not limited to reviewing

books, articles, journals and web sites. In this phase, generic knowledge is gathered on central

themes of this research, namely auditing (Chapter 3), project management (Chapter 4), and IT

governance (Chapter 5). As part of the exploration phase, and in direct relation to Chapter 4, an

enquiry is conducted (Chapter 6) to identify the extent to which recognised project management

practices are applied in practice within project management entities.

1.3.2 Propose

This phase seeks to establish that investigating the problem is worthwhile and realistic. Indeed,

considering low success rates in IT projects, and the resulting need to verify whether projects

managers follow the processes which they are supposed to (or claim to) follow, this research

proposes a conceptual model for auditing IT project management (Chapter 7). At this stage, the

research achieves its goal.

1.3.3 Prepare

Preparation is done to determine the main guidelines on how this research should be conducted.

This includes the research methodology and design presented in Chapter 2.


1.3.4 Execute

This phase entails collecting data, to determine a relevance of the claim according to which

project managers do not seem to consistently follow project management processes which they

purport to follow.

1.3.5 Analyse

During this phase, the collected data is presented and analysed qualitatively, and

recommendations are made. This is done in Chapter 6.

1.3.6 Publish

This is the final phase of the research, which consists of publishing the final dissertation, and

preparing an article for submission at a project management conference.

1.4 Research deliverables

The sum total of each chapter’s deliverable constitutes the research deliverable. The researcher

also intends to propose, later in the research, a whole is indeed greater than the sum of its parts;

that is, to propose a model for auditing IT project management, by integrating individual research

deliverables created throughout the research. This deliverable constitutes the overall research

value of this dissertation. For now, here is a list of individual research deliverables:

� Literature review;

� Generic audit steps;

� Project components considered in a project management audit;

� Guideline for auditing IT projects;

� A conceptual audit model for IT project management;

Each of these deliverables is discussed in the next section.

1.4.1 Literature review

Neither the author’s interest, nor the relative popularity of the project management discipline

should constitute sound justification for yet another research project in the said discipline. What is

required is to narrow the issue to a relevant problem currently faced in the industry, and find a

methodical and realistic solution to the problem. The first deliverable of this research is therefore

a literature review, which aims to establish the researchability of this topic upfront, and to create

in the author a rigorous research attitude towards the topic at hand, and towards the


determination of the appropriate research design and methodology in the time available (Hart,

1998:13).

The following steps are followed while conducting this literature review (Machi & McEvoy,

2009:5):

1. Select a topic: The research topic has emerged as a result of the author’s interest in a

practical problem. This interest is expressed through ideas that form a researchable topic. This

topic is stated as the research problem, which specifies and frames the next step.

2. Search the literature: By narrowing the vast amount of available information to only the data

that provides the strongest evidence to support the theses, this step determines what information

will be featured in the literature review. This explores and catalogs the next step.

3. Develop the argument: To argue the dissertation successfully, the case is formed and then

presented. To form the case, the claims need to be arranged logically. To present the case,

relevant data is organised into a body of evidence that explains what is known about the topic.

This organises and forms the next step.

4. Survey the literature: This step assembles, synthesises and analyses the data to form the

argument about the current knowledge on the topic. A logical set of defensible conclusions or

claims is created, which in turn provides a basis for addressing the research question. This

documents and discovers the next step.

5. Critique the literature: The current understanding of the topic is interpreted by analysing how

previous knowledge answers the research question. This step advocates and defines the next

step.

6. Write the review: This step intends to accurately convey the research, so as to be understood

by the intended audience. This step addresses step 1 above, thereby closing the loop of the

literature review cycle.

The literature review is delivered throughout this dissertation, particularly in Chapters 2 through 5.

Figure 1.1 illustrate the above-mentioned literature review cycle:


Figure 1.1: The Literature Review Process. Source: Machi & McEvoy (2009:5)

1.4.2 Audit guidelines

This research aims to propose a new model for auditing. This implies that auditing is a central

theme in the research. To ensure the relevance and correctness of the audit model, it is

necessary to align it with existing audit principles and guidelines. Audit guidelines are presented

in the form of audit steps that serve to guide the auditor in conducting the audit (Moeller,

2009:248). This research therefore intends to tap into existing knowledge in the audit discipline, in

order to review relevant approaches or guidelines to auditing, and retain auditing steps as a

guideline. This is delivered in Chapter 3.

1.4.3 Project management components

The multi-faceted aspect of project management implies that this discipline consists of several

components (Pitagorsky, 2007:30). For a new model for auditing IT project management to be

effective, these components need to be identified upfront. They constitute the various aspects to

take into account when performing the audit. Addressing each of the identified components

should ensure the effectiveness and repeatability of the audit. Consistently doing so should make

the audit process repeatable. The identified project management components are delivered in

Chapter 4.


1.4.4 Guideline for auditing IT projects

Having identified generic audit guidelines, it becomes possible to adapt these guidelines to the IT

industry. This adaptation should be informed by recognised IT governance best practices, as

done in Chapter 5.

1.4.5 Current state of project management

The research problem states that many project managers do not always put into practice the

project management theory which they purport to adhere to. This deliverable therefore focuses on

determining the extent to which this statement is valid. This is achieved in Chapter 6, by

collecting, analysing and interpreting data, and making recommendations.

1.4.6 Conceptual model

Having delivered (a) an auditing guideline, (b) project management components, and (c) IT

project management audit guidelines, it then becomes necessary to propose a conceptual model

integrating the above, and guiding the application of the above in an audit situation. This

conceptual model is proposed in Chapter 7.

Table 1.1 summarises the above-mentioned research deliverables and indicates where these

deliverables feature in the dissertation.

Table 1.1: Summary of research deliverables, main chapter and value

Deliverables

Main

Chapter(s)

Value of the deliverable(s)

Deliverable 1: Literature review. 3, 4, 5 Provides an understanding of existing knowledge

in the field being studied.

Deliverable 2: Generic audit guidelines. 3 Highlights the relevant audit guideline for this

research, after exploring existing guidelines.

Deliverable 3: Project management components. 4 Identifies specific “facets” of project management

which can be audited.

Deliverable 4: IT project management audit guidelines 5 Provides audit guidelines which are aligned to

both established audit guidelines and IT

governance principles.

Deliverable 5: Current state of the application of project

management theory.

6 Determines the extent to which project managers

put their project management theory into practice.

Deliverable 6: Conceptual model 7 Ensures consistency and repeatability of the

model by elaborating it in a pre-defined pattern.

The next section presents the layout of this dissertation.


1.5 Dissertation Layout

This dissertation consists of eight chapters, grouped into five sections. Terms and concepts are

defined when they are first introduced. This implies that the best way to read this dissertation is to

read the chapters by following the order indicated in the figure 1.2.

The first section consists of the problem definition. In this section, the rationale for this research is

presented, and the research problem outlined. This section contains one chapter - Chapter 1. The

second section consists of the research design and structure. In this section, the author

investigates existing knowledge related to research design and highlights the design used for this

specific research. This section contains one chapter – Chapter 2. The third section consists of

literature review. In this section the author investigates existing knowledge in the fields being

researched, as a basis for proposing a solution. This section contains three chapters – Chapters

3, 4, and 5.

The fourth section consists of data collection and analysis. This section focuses on conducting a

basic inquiry in order to understand the extent to which project managers currently follow the

project management theory which they claim to follow. This section contains one chapter –

Chapter 6. The fifth section addresses the research solution. This section contains two chapters,

namely Chapter 7, which proposes a conceptual model and Chapter 8, which presents the

dissertation conclusions and recommendations.

A brief description of each chapter is provided below.

Chapter 1 – Provides the background information and motivation for this research. This chapter

presents the research problem, elaborates on the research process followed in addressing the

problem, and lists the research deliverables.

Chapter 2 – Provides background information and literature review on scientific research. The

knowledge gathered in this exercise allows the author to make informed choices on the design of

this research.

Chapter 3 – Investigates the field of auditing, includes its evolution to its current state. This

chapter also explores generic audit guidelines and derives the relevant audit guideline for the

purpose of this research.

Chapter 4 – Investigates the project management discipline and highlights key project

management components. These components direct the audit focus onto specific facets of

project management.


Chapter 5 – Investigates IT governance frameworks, as an authoritative sources from which the

identified generic audit guidelines can be adapted into detailed guidelines for auditing IT projects.

Chapter 6 – Is directly related to Chapter 4, and should be read as such. After providing the

overview on project management (Chapter 4), it became necessary to devote a chapter to a

formal enquiry aimed at determining the extent to which project managers follow best practices

which they purport to follow.

Chapter 7 – Proposes a conceptual model. This chapter integrates the knowledge gathered as

part of the previous chapters, into a conceptual model.

Chapter 8 – Concludes this research. This chapter summarises the research deliverables

presented throughout the dissertation and presents the unique value of this research. The

chapter also discusses some closing points, including key learning points, areas for further

research, research limitations, and final thoughts from the author.

Figure 1.2 illustrates the flow of the above-mentioned sections and chapters.

Figure 1.2: Dissertation Layout

The next chapter discusses the research methodology and design.

_____________________________________________________________________ Chapter 2 – Research Methodology and Design 11

2 CHAPTER 2 – RESEARCH METHODOLOGY AND DESIGN

2.1 Introduction

2.1.1 Background

The previous chapter presented an overview of this research, including the research problem,

process and deliverables. It has been highlighted that there is a need to systematically verify

whether an organisation consistently applies the project management theory which it claims to

adhere to. This chapter focuses on how the research is designed, to arrive at the said model.

Research is a gathering of data, information and facts for the advancement of knowledge

(Shuttleworth, 2008). This definition aligns with Saunders, Lewis and Thornhill (2009), who define

research as “…something that people undertake in order to find out things in a systematic way,

thereby increasing their knowledge…” The latter definition highlights two important phrases,

namely “systematic way” and “to find out things”.

“Systematic” suggests that research is based on logical relationships and not just beliefs (Ghauri

& Grønhaug, 2005); “to find out things” suggests that there are various possible purposes for

which to conduct research. These may include describing, explaining, understanding, criticising

and analysing (Ghauri & Grønhaug, 2005).

The next section sets the goals and objectives for this chapter.

2.1.2 Goal

The goal of this chapter is to articulate the research methodology used throughout this research.

The following objectives need to be achieved, in order to meet this goal.

2.1.3 Objectives

� Objective 1: Review the literature on research philosophies and highlight the one(s)

adopted for the purpose of this research.

� Objective 2: Review the literature on research approaches and highlight the one(s)

adopted for the purpose of this research.

� Objective 3: Review the literature on research methods and highlight the one(s) adopted

for the purpose of this research.

� Objective 4: Review the literature on alternative research time horizons and highlight the

one(s) adopted for the purpose of this research.


� Objective 5: Review the literature on data collection and data analysis methods and

highlight the one(s) adopted for the purpose of this research.

2.1.4 Chapter Layout

The remainder of this chapter is laid out as follows:

The first section discusses the flow of this research project, from a research design perspective.

The second section reviews research philosophies and highlights the philosophy used for the

purpose of this research. The third section reviews research approaches and highlights the

approach used for the purpose of this research.

The fourth section reviews research methods and highlights the method(s) used for the purpose

of this research. The fifth section reviews research time horizons and highlights the time horizon

of this specific research. The last section reviews data collection and analysis techniques and

highlights the ones used for this research.

2.1.5 Research design

Research design is the process through which a research question is transformed into a research

project (Robson, 2002). The “hourglass design” is one of many ways to conceptualise the

research design (Trochim, 2006). This entails picturing a research project in the shape of an

hourglass - wide at the top, narrow in the middle and wide again at the bottom.

Below is a brief elaboration of the “hourglass design”:

The research process starts at the top of the hour glass with the research problem that the

researcher intends to study. However, this initial problem is often too wide to effectively cover in a

single study, hence the need to narrow the problem down to a question that can reasonably be

addressed in a single study. This might imply formulating a hypothesis or a focus question. In the

current research, the wider area of interest relates to project management. This area is narrowed,

through literature review, to specific topic which can reasonably be explored in a single research,

namely the proposal of a new model for auditing IT project management.

The next step in the hourglass process corresponds to the narrowest point of the hour glass (the

middle). At this point, the actual measurement or observation of the question at hand is

performed. In the current research, this step corresponds to determining the extent to which the

research hypothesis is valid.


The scope of the hour glass then widens, as the researcher starts to analyse and apply the

research results in a variety of ways. At this stage, some initial conclusions are formulated,

subsequently to the outcome of the data analysis. In the current research, this step corresponds

to presenting data analysis findings and making recommendations.

The final stage refers to the bottom of the hour glass. At this point, the researcher attempts to

address the original goal of the study at hand, by generalising the research results to other

related situations (Trochim, 2006). In the current research, this step corresponds proposing a

conceptual model.

Figure 2.1 illustrates the above-mentioned hourglass design, and highlights its relevance to this

particular research.

Figure 2.1: Hourglass research design (Adapted from Trochim, 2006)

While the above-mentioned design provides a picture of how this research project is organised, it

does not precisely inform the reader on how the researcher went about conducting this research.

This clarity is provided in the research methodology, discussed in the next section.

2.1.6 Research methodology


Research methodology is the theory of how research should be undertaken, including the

theoretical and philosophical assumptions upon which research is based and the implications of

these for the method(s) adopted (Saunders et al., 2009). Since a research question has been

defined for this research, the researcher might consider beginning thinking of this research

project in terms of how to collect and analyse data to answer the research question. However,

some authors argue that it is important to first of all define the philosophy and paradigm

underpinning the research (Guba & Lincoln, 1994:105; Johnson & Clark, 2006; Saunders et. al,

2009). This refers to the important assumptions from which the author embarks in this research,

and serves to inform the researcher about the appropriate methods to be used, in line with the

research goals.

2.1.6.1 Research philosophy

Research philosophy relates to the development of knowledge and the nature of that knowledge

(Saunders et. al, 2009). The philosophy adopted in this research is influenced, on the one hand

by practical considerations, and on the other hand, by the researcher’s view of the relationship

between the knowledge being sought and the process by which this knowledge is developed.

Ultimately, the important issue should be for the researcher to be able to reflect upon the

philosophical choices used and defend them in relation to the alternatives which could have been

used.

The aim is not to argue on which philosophy is better than the other, but rather to highlight which

philosophy best allows the researcher to answer the research question within the practical

limitations of this research project. Some possible overlaps may exist between the alternatives

chosen, but for the purpose of this research, the researcher attempts as much as possible to

present the various choices as distinct and separate alternatives. The philosophical choices

discussed in this section include pragmatism, interpretivism, realism, and positivism. This list in

by no means exhaustive, but these are some of the most common philosophies used in

management research (Saunders et al. 2009).

a) Pragmatism

Pragmatism argues that the research question is the most important determinant of the ontology,

epistemology and axiology adopted by the researcher (Tashakkori & Teddlie, 1998:26; Saunders

et al., 2009). The pragmatism philosophy considers that the researcher should study the topic of

interest in the different ways deemed appropriate, and use the results in ways which can

generate positive consequences within the researcher’s value system (Tashakkori & Teddlie,

1998:30).


b) Interpretivism

Interpretivism focuses primarily on the understanding of that which is being studied (Olivier,

2009). This philosophy advocates that the researcher should understand the differences between

conducting research among human beings, rather than objects. This implies interpreting the

meaning and actions of actors according to their own subjective frame of reference, with as little

generalisation as possible, even though avoiding generalisation is nearly impossible in any kind

of research (William, 2000:2).

c) Realism

Realism advocates that objects exist independently of our knowledge of their existence. The

essence of realism is that there is a reality quite independent of the mind. This philosophy

assumes a scientific approach to the development of knowledge. This assumption underpins the

collection and understanding of data (Saunders et al., 2009).

d) Positivism

Positivism advocates working with an observable social reality. This philosophy emphasises on

highly structured methodologies to facilitate replication. It argues that the purpose of science is

simply to stick to what can be observed and measured. Any knowledge beyond this is impossible,

according to the positivist philosophy (Trochim, 1996). The end product of positivism is therefore

generalisations, similar to those produced by the physical and natural scientists.

Table 2.1 summarises the philosophical alternatives considered in this research and highlights

the one used.


Table 2.1. Research philosophies

Positivism Realism Interpretivism Pragmatism

Ontology: The

researcher’s view

of the nature of

reality or being

External, objective

and independent of

social actors

Objective. Exists

independently of

human thoughts and

beliefs or knowledge

of their existence

Subjective. Socially

constructed

External, multiple view

chosen to best enable

answering of the

research question

Epistemology:

The researcher’s

view of what

constitutes

acceptable

knowledge

Focus on causality

and generalisations.

Only observable

phenomena can

provide credible data

Observable

phenomena provide

credible data, facts.

Subjective meanings

and social phenomena.

Focus upon the details

of a situation, the

reality behind these

details, and subjective

meanings motivating

actions

Either or both

observable phenomena

and subjective

meanings can provide

acceptable knowledge

depending on the

research question.

Axiology: The

researcher’s view

of the role of

values in research

Research undertaken

in a value-free way.

Researcher is

objective and

independent from data

Researcher is

biased by world

views, cultural

experiences and

upbringing.

Research is value

bound. Researcher is

part of is being

researched.

Values play a large role

in interpreting results.

Researcher’s view both

objective and

subjective

From an ontological point of view, the researcher’s view is mainly subjective. This view is

exemplified by the focus, during data analysis, on perceptions of respondents. From an

epistemological point of view, this research focuses mainly on the details of situations and

understanding the realities behind those details. This view is exemplified by the drive, during data

collection and analysis, to not only understand the state of the phenomena being studied, but also

gather as much insight as possible on why the human beings behind these phenomena act in the

way they do. From an axiology point of view, the researcher is actively involved in the research,

as opposed to being detached from it.

In line with the aim the drive, in this research, to interpret the meaning of data according to the

respondents own subjective perceptions, and the need to avoid generalisations as much as

possible, the interpretivist philosophy seems to be most appropriate. Table 2.1 contrasts the

above-mentioned research philosophies and highlights the one used for in this research.

2.1.6.2 Research approaches

Most research involves the use of theory (Saunders et al. 2009) and this research project is no

exception. This section discusses the options available for the research to relate to the theory.

The researcher has two alternatives. The first option is to develop a theory and related hypothesis


(or hypotheses), and design an appropriate research method to test the theory and hypothesis;

the second option is to build the theory as a result of data collection and analysis. The first option

refers to the deductive approach, and the second one refers to the inductive approach (Saunders

et al. 2009). Both of these approaches are discussed, in an effort to identify the most appropriate


a) Deductive approach

Robson (2002) suggests that deductive approach follows five sequential steps, namely:

(i) Deducing the hypothesis from the theory; that is, developing the theory into a testable

proposition about the relationship between two or more concepts or variables.

(ii) Expressing the hypothesis in operational terms by indicating exactly how the

variables will be measured.

(iii) Testing the operational hypothesis through the appropriate research method(s)

(iv) Examine the specific results of the testing and determine whether they tend to

confirm or negate the theory.

(v) Depending on the findings in step IV, the theory may be modified if necessary.

These steps reflect several characteristics. First, there appears to be a focus on causal

relationships between variables. Secondly, these relationships are tested through the collection of

data which is most likely to be quantitative, even though Saunders et al. (2009) caution that this

data could also be qualitative; a third characteristic is that hypotheses needs to be tested within a

controlled environment to minimise the changes in how the different variables being tested relate

to each other. Additionally, Gill and Johnson (2002) advocate the use of a highly structured

methodology to facilitate replication and ensure reliability.

At this stage it can be said that scientific rigor behind the deductive approach requires the

researcher to be independent from what is being researched. The final characteristic transpiring

from this approach is the need to generalise the findings of the research. This need would be best

addressed if the sample selected is of sufficient numerical size.

In this specific research, a hypothesis would need to be made regarding whether project

managers adhered or not to the project management theory which they purport to follow. The

hypothesis would then be quantified in terms of what exactly is meant by “adhering to the theory”.

An example would be to clearly define whether “adherence” here refers to following the theory all

the time, or most of the time. The “project management theory” itself would also potentially be

broken down in just exactly what the term entails for the purpose of this research. This inquiry


would need to be performed through an appropriate research method. Research methods are

further discussed later in this chapter.

b) Inductive approach

The inductive approach is concerned with developing the theory as a result of the observation of

empirical data (Saunders et al. 2009). While the deductive approach, discussed above, focuses

on the cause-effect link between particular variables, the inductive approach is wary of

developing such a cause-effect relationship without understanding the way in which human

beings interpret their social world (Saunders et al. 2009).

In this research project, it can be argued that treating project managers as human beings whose

adherence (or lack of) to the project management best practices professed within their

organisation is a more realistic approach. This approach opposes the deductive approach which

seems to insinuate that project managers are expected to respond in a mechanic way to certain

circumstances (in this case, adhering to professed project management best practices).

The methodology followed in inductive research is less rigid than the one typically used in the

deductive approach. This flexibility allows the researcher to find alternative explanations of what

is going on (Saunders et al., 2009). Research following inductive approach is likely to focus on

the context within which events happen. For this reason, it can be argued that when following the

inductive approach, samples tend to be small, as opposed to the typically large samples

recommended for the deductive approach (Easterby-Smith, Thorpe & Lowe, 2008).

It is necessary for the researcher to be clear on which research approach to follow in a particular

research project. This, according to Easterby-Smith et al (2008), is the case for three reasons:

Firstly, it enables the researcher to make an informed decision regarding the appropriate

research method and data collection and analysis technique to use in the research project.

Secondly, it helps the researcher to focus on the most appropriate research methods for the

purpose of the particular research project, thereby discarding the less appropriate methods.

Thirdly, understanding the alternative research approaches allow the researcher to adapt the

research design and methodologies to constraints faced by a particular research project. Such

constraints could include, but should not be limited to time, budget, and access to data.

While Easterby-Smith et al (2008) have proposed some benefits for making a clear choice on the

research approach, Cresswell (2003) suggests a number of practical criteria for making such

choice. The most important of these are that firstly, the nature of the research topic should be

taken into consideration when deciding which research approach to adopt; an established topic

on which abundant information is available might be more suitable for deductive than inductive


approach. Secondly, the researcher should consider the time available to carry out the research

project. Deductive research can be quicker to complete and would typically require a single

iteration of data collection and analysis; the inductive approach, on the other hand, could be quite

protracted as the ideas, based on longer periods of data collection and analysis, tend to emerge

gradually. Thirdly, the researcher should determine the extent to which he or she wishes to

indulge in risk. A deductive approach potentially carries less risk, even though there are still some

non negligible risks, such as research subjects failing to return questionnaires. Inductive

approach, on the other hand, constantly carries the risk, despite multiple iterations, it may happen

that no useful data pattern or theory emerges.

It should be noted that the literature reflects some overlaps in the terminology. Cresswell

(2003:18) reflects such overlap when describing the main research approaches are (i) qualitative,

(ii) quantitative, and (iii) mixed approach. However, for the purpose of this research, deductive

and inductive are the research approaches used. Qualitative and quantitative are alternatives

which only play a role at the data collection and analysis stage (Saunders et al. 2009:11). Data

collection and analysis techniques are discussed later in this chapter.

The above discussion may convey the idea that a researcher needs to choose either of the

research approaches. However, Saunders et al (2009) disagree by arguing that a combined

approach in a single research project is both possible and advantageous in some cases. This

view is acknowledged, but for the purpose of this research, the combined approach is not used.

The alternative research approaches have been considered, including the selection criteria and

risks for either approach. The mixed approach has also been identified as possible and potentially

advantageous. For the purpose of this research the inductive approach will be followed.

Table 2.2 summarises the major differences between inductive and deductive approaches to

research, and highlights the approach followed in this research project.


Table 2.2. Deductive vs. Inductive research approaches

Deduction emphasises Induction emphasises

1 Scientific principles Gaining an understanding of the meanings humans

attach to events.

2 Moving from theory to data Building the theory from empirical data

3 The need to explain causal relationships between variables A close understanding of the research context

4 The collection of mainly quantitative data The collection of mainly qualitative data

5 The application of controls to ensure the validity of data A more flexible structure to allow changes of research

emphasis as the research progresses

6 Researcher independence of what is being researched A realisation that the researcher is part of the research

process

7 The necessity to select large samples in order to generalise

conclusions

Small sample selections as there is less concern for the

need to generalise

The next section discusses research types.

2.1.6.3 Research types

Research types refer to how the research purpose is classified. For the purpose of this research,

“research type” and “research classification” are synonymous. Saunders et al (2009:139) identify

three main research types, depending on how the researcher intends to answer the research

question: exploratory, descriptive and explanatory. These authors argue that the research type is

tightly linked to the overall research purpose, and that a single research project can have multiple

purposes. This argument is echoed by Robson (2002), who points out that the purpose of a

research project may change over time.

Various research types are identified in the literature, including basic, applied and practical

research (Henrichsen, Smith & Baker, 1997a; Verma & Mallick, 1999:11; Miller & Salkind,

2002:3). Other research types identified in the literature include descriptive as opposed to

analytical, applied as opposed to basic (or fundamental) and conceptual as opposed to empirical

(Kothari, 2008).

Due to its specific link to the research purpose, this research focuses on the research types

proposed by Saunders et al (2009):

a) Exploratory research

This is a means of finding out what is happening, to seek out new insights, to ask questions and

to assess phenomena in new lights (Robson 2002:59). According to Saunders et al (2009), there


are three main ways of conducting exploratory research, namely: searching the literature,

interviewing experts on the subject, and conducting focus group interviews. Exploratory research

is a research type which is flexible, yet does not lose direction. This means that this research type

typically starts with a broad focus, which tends to become progressively narrower as the research

progresses (Blankenship, Breen & Dutka, 1998:21; Saunders et al, 2009). While exploratory

research is a great way to seek new insights and establish greater understanding of the problem

at hand, it has an inherent risk of not delivering a definitive or conclusive answer to the research

problem (McGivern, 2006:88).

b) Descriptive research

This research type aims to portray an accurate profile of persons, events or situations (Robson,

2002:59). Descriptive research runs the risk of being perceived as not adding particular value,

unless the researcher goes further to evaluate and synthesise, and draw conclusions from the

data being described.

c) Explanatory research

This research type focuses on researching a situation or problem, in order to explain the

relationships between variables (Saunders et al, 2009). This focus on causal explanations is

echoed by De Vaus (2002).

Having defined the different research types and pointed out the possibility to apply more than one

type in a single research, exploratory research will be the main type for the purpose of this

research, mainly due the flexibility that it provides (Blaikie, 2000:74). The search and review of

existing literature (literature review), which has been identified as one of the major ways to

uncover information in exploratory research, is a regular feature in this research.

Table 2.3 summarises research types and highlights the one applicable for the purpose of this

research.


Table 2.3: Summary of research types

Research types Brief description

1 Explanatory research Research that focuses on studying a situation or problem in order to

explain the relationship between variables.

2 Exploratory research Research that aims to seek new insight into phenomena, to ask

questions, and to assess phenomena in a new light.

3 Descriptive research Research aiming to produce an accurate representation of persons,

events or situations.

4 Basic research Research undertaken purely to understand processes and their

outcomes.

5 Applied research Research of direct and immediate relevance to practitioners that

addresses issues they see as important. Research results are

presented in a way practitioners can understand and act upon.

6 Practical research Research aiming at applying the research findings in a practical

situation. The focus on applying the research transcends that of

developing the theory.

7 Analytical research Research making use of available facts and information with a

specific focus on analysing and making critical evaluation.

8 Conceptual research Research related to abstract ideas or theories, generally used by

philosophers and thinkers to develop new concepts and reinterpret

new ones.

9 Empirical research Research that relies on experience and observation alone, often

without much consideration for pre-defined systems and theories.

The next section discusses research methods.

2.1.6.4 Research methods

In conducting research, researchers can make use of a variety of research methods. These are

formal ways how the research seeks to address the research problem (Hoepfl, 1997; Arts and

Humanities Research Council, 1999; Olivier, 2009).

Olivier (2009) identifies nine commonly used research methods in Information Technology

including: (i) literature review; (ii) modelling; (iii) languages; (iv) prototypes; (v) mathematical

proofs; (vi) experiments; (vii) surveys; (viii) case studies and (ix) arguments. Saunders et al

(2009) focus on management research and list the following as the most used research methods:

(i) experiments; (ii) surveys; (iii) case study; (iv) action research; (v) grounded theory; (vi)

ethnography and (vii) archival research.


For each applicable section of this research, as highlighted in the dissertation layout in Chapter 1,

a corresponding research method has been identified. The identified research method

corresponds to the best way to achieve the purpose of the relevant section. ‘Section 1’ (research

problem definition) and ‘Section 2’ (research design) do not require a formal research method.

The research methods applicable to ‘Section 4’ (data collection and analysis) are specifically

discussed later in this chapter under sub-heading 2.1.3.5 (data collection and analysis

techniques). For the purpose of this research, research methods are therefore only applicable to

Section 3 (literature review) and Section 5 (research solution).

The research method used in Section 3 is literature review. Section 5 uses modelling for the

purpose of developing a conceptual model in chapter 7. The above research methods (literature

review and modelling) therefore constitute the focus of the next discussion.

a) Literature review

A literature review is a written argument that promotes the position of a thesis by building a case

from credible evidence based on previous research (Machi & McEvoy, 2009:4). Literature review

has been discussed in Chapter 1 as a research deliverable, due to its importance, and the extent

to which it features in this study. However, this section emphasises the use of literature review as

a specific research method. In the latter capacity, literature review furthers two goals: firstly, it

helps to refine the research ideas and to critically review available literature; secondly, it allows

the researcher to demonstrate understanding of the current state of knowledge in the fields being

researched, and how the research fit in the wider context (Hart, 1998; Gill & Johnson, 2002;

Jankowicz, 2005:16).

b) Modelling

Modelling is used to represent systems in the real world through simplification, to perform an

experiment which cannot be done in the real world (Egger & Carpi, 2008). Modelling generally

refers to studying a small segment of a bigger phenomenon in a controlled environment. The

results obtained can then be extrapolated so as to enable a better understanding of the

phenomenon and its expected behaviour under certain circumstances.

When using modelling as a research method, three main steps are usually followed: firstly, the

researcher needs to define what needs to be modelled; secondly, the model needs to be

developed; thirdly, the model needs to be tested (Egger & Carpi, 2008; Olivier, 2009; Jordaan &

Lategan, 2010). In this research, modelling is used to propose a conceptual model (Chapter 7).

One of the possible uses of modelling is to guide the construction of a prototype (Olivier, 2009).

The goal of this research is achieved through proposing a conceptual model; therefore the


prototype falls outside the scope of this research and constitutes a worthwhile area for further

research. Table 2.4 summarises the research methods and highlights the ones applicable for the


Table 2.4: Research Methods

Research method Brief description

1 Literature review Analysis and commentary of the literature within the chosen area,

which demonstrates familiarity with what is already known about the

research topic.

2 Modelling Simplification of a complex system into a simpler system which

captures the essential aspects of the complex system. Results derived

from the understanding of the simpler system can be extrapolated to

the complex system.

3 Languages Expression of the automation of processes in computing. Can be a

programming language, a language specifying managerial aspects of

IT organisations, or a language for specifying highly abstract

properties of systems.

4 Prototypes Proof of concept to demonstrate that a conceptual model can be

implemented.

5 Argument Detailed reasoning used when two or more alternative solutions to a

problem are compared, to justify why one alternative is better than the

other(s).

6 Mathematical proof The ultimate argument, which is a way to demonstrate the absolute

truth of a statement. It assumes that if the proof is correct, it cannot be

disputed.

7 Experiments Method involving the definition of a theoretical hypothesis, the

selection of a sample population, the allocation of samples to different

experimental conditions, the introduction of planned changes to one or

more of the variables, and the measurement on a small number of

variables and control of other variables.

8 Surveys Structured collection of data from a sizeable population

9 Case studies Empirical investigation of a particular contemporary phenomenon

within its real-life context, using multiple sources of evidence.

10 Action research Method concerned with the management of a change and involving

close collaboration between practitioners and researchers.

11 Grounded theory Method in which theory is developed from data generated by a series

of observations or interviews.

12 Ethnography Description and interpretation of the social world through first-hand

field study.

13 Archival research Analysis of administrative records and documents as principal source

of data because they are products of day-to-day activities.

The next section discusses research time horizons.


2.1.6.5 Research time horizons

This section discusses the way research is approached from a time perspective. Research tends

to be either a “snapshot” taken at a particular time or a diary or series of snapshots of events

taken over a given period. The “snapshot” time horizon is called cross-sectional research, while

the series of snapshots is called longitudinal research (Saunders et al. 2009).

a) Cross-sectional research

This is the study of a particular phenomenon at a particular time (Olsen & St. George, 2004).

Research is often approached in this way when time is an important constraint (Saunders et al.

2009).

b) Longitudinal research

This is the study of a particular phenomenon over an extended period of time. Longitudinal

research studies allow the researcher to specifically find out whether there has been change and

development over a certain period of time (Ruspini, 2002; Saunders et al. 2009). While it is often

used when there is ample time available for the research, longitudinal research is also possible

when the research is undertaken under time constraints.

For the purpose of this research, the decision on whether to use cross-sectional or longitudinal

research is informed primarily by the suitability of the adopted time horizon to the research goal.

This research aims to propose a model allowing organisations to verify whether they follow the

project management best practices which they purport to follow. It does not appear necessary to

observe the current state of this matter over an extended period of time, in order to successfully

address this goal. A snapshot of what the reality is at a specific point of time should provide a

suitable enough indication of whether project management best practices are followed or not.

The researcher acknowledges that there could be added value in doing this observation over an

extended period of time, as this could potentially reveal that at different points in time, the

behaviour observed changes (for better or worse). However, gathering such insight does not form

part of the scope of this research.

The above does not constitute a comprehensive discussion of the distinction between alternative

research time horizons, but it provides a good enough basis for cross-sectional time horizon to be

applied in this particular research. Having said this, longitudinal time horizon is a potentially useful

area for further research.


Table 2.5 summarises the alternative time horizons discussed, and highlights the one used for

the purpose of this research.

Table 2.5: Research time horizons

Cross-sectional research Longitudinal research

1 Studies a particular phenomenon at a particular time. Studies the changes and developments over time.

2 Applies mainly when research is undertaken within

considerable time constraints.

Mainly applicable when there is ample time for the

research, but also possible when time is a constraint.

The next section discusses data collection and analysis techniques.

2.1.6.6 Data collection and analysis techniques

Data collection techniques allow the researcher to systematically collect information about the

object of the study and about the setting in which they occur (IDRC, 2004). It is particularly true

that the quality of data collected determines the quality of the data analysis (Varkevisser,

Pathmanathan & Templeton, 2003).The research design and the data collection methods are

interlinked and often mutual dictators (Lehner, 1998:183).

Data collection and analysis techniques are broadly categorised as either qualitative or

quantitative. A common way of distinguishing between the two is to identify whether the focus is

on numeric data (numbers) or non-numeric data (words). On the one hand, the use of numeric

data, abstracting particular instances to seek general description or to test causal hypotheses,

usually aligns with quantitative data collection and analysis techniques (Olivier, 2009; Saunders

et al, 2009; Mattie & Camozzi, 2005:31; Muijs, 2004:1; Murray Thomas, 2003:2). On the other

hand, the use of non-numeric data, with emphasis on human perception and understanding,

usually aligns with quantitative data collection and analysis techniques (Stake, 2010:11;

Saunders et al. 2009; Olivier, 2009; Henrichsen et al., 1997b; Holloway, 1997:1).

Literature on qualitative and quantitative research approaches gives ample indication to both their

perceived complementary (Auerbach & Silverstein, 2003:22; Bamberger, 2000:77; Flick, 2009:26)

and differences (Bless & Higson-Smith, 2000:37; Bryman & Bell, 2007:28; Thomas, Nelson &

Silverman 2005:346). However, neither approach should be seen as better than the other at face

value. Murray Thomas (2003:7) advises that the researcher’s decision to use qualitative or

quantitative data collection and analysis should rather be informed by the suitability to address

the research problem and objectives. It is also possible to combine qualitative and quantitative

data collection and analysis techniques in a single study (Saunders et al, 2009; Murray Thomas,

2003:2; Tashakkori, 2003).


Based on the above discussion, this research uses qualitative data collection and analysis and

will therefore not discuss quantitative data collection and analysis techniques. Literature shows

that specific data collection and analysis techniques apply to the qualitative realm. These are

successively discussed for the purpose of this particular research, starting with data collection

techniques.

(i) Data collection techniques

The qualitative data collection techniques proposed by Landy & Conte (2009:61) include

qualitative interview, case study, and observation. Saunders et al (2009) identify observation,

interviews and questionnaires. Landy & Conte (2009:61) discuss qualitative interview, case study

and observation. These data collection techniques are summarily discussed below.

a) Observation

The value of observation, as a data collection technique, is often somewhat underestimated in

research, yet it can considerably add to the richness of research data (Saunders et al, 2009). This

added value is particularly true when the researcher watches carefully in a manner which is

scientific, objective, systematic, unbiased, reliable, valid, and quantifiable if possible (Powell,

1997:117). Ary, Jacobs, Razavieh and Sorensen (2009:431) insist that the rigorous structure

demanded by this data collection technique makes it “more than just watching”.

Collecting data through observation implies that the researcher stays with a group of people for

an extended period of time, in order to record any observed behaviour of individuals and groups,

as well as written impressions experienced by the observer, as they occur (Tenenbaum &

Driscoll, 2005:102). Depending on the role taken by the researcher, observation can be

categorised as either participant, or structured observation (Saunders et al, 2009; Smith,

2002:162; Cohen, Manion & Morrison, 2007:398; Tassoni, 2007:101).

Observation is said to be participant observation when the observer participates in the daily life of

the subjects being observed with the objective of sharing in people’s lives while attempting to

learn their symbolic world (Carpenter and Dyck, 2000:5; Carson, 2001; Gill & Johnson, 2002:

144; Saunders et al., 2009). Structured observation, on the other hand, adopts a more detached

stance, whereby the researcher focuses on watching and recording behaviour in a way which

does not involve any kind of interaction with the subjects being observed (Saunders et al, 2009;

Bless, Higson-Smith and Kagee, 2006:114; Dyer, 1995:170).

The next data collection technique discussed is interview.


b) Interview

As a purposeful discussion between two or more people (Kahn & Cannell, 1957), interview is a

general term for several types of data collection techniques (Saunders et al, 2009). Interviews

may be highly formalised and structured, using standardised questions for each research

participant, or they may be informal and unstructured conversations; furthermore, there is a third

way to describe interviews, which fits in-between the above two. These three positions are

respectively referred to as structured, unstructured (or in-depth), and semi-structured interviews

(Saunders et al, 2009; Bryman & Bell, 2007:213). Other typologies differentiate between

standardised and non-standardised interviews (Kretschmer, 2008:119); yet other authors

distinguish these types as respondent (participant) and informant interviews (Robson, 2002;

Powney & Watts, 1987:162). For the purpose of this research, the typology adopted is the one

distinguishing between structured, unstructured and semi-structured interviews.

Structured interviews use questionnaires based on a predetermined and standardised or identical

set of questions ((Kretschmer, 2008; Saunders et al, 2009). Unstructured interviews are informal

and allow the person being interviewed to tell their story at length, in their own words, with little

direction or intervention from the researcher (Saunders et al, 2009; Macnee & McCabe,

2008:167; Bowling & Ebrahim 2005:218; Kvale, 1996:5 ; Bailey 1994:194; Burgess, 1986:165). In

semi-structured interview, the questions are formulated in advance, but the answers are open-

ended and can be further expanded at the discretion of the interviewee and the interviewer,

namely by further probing from the latter (Schensul, Schensul & LeCompte, 1999:149).

Identifying these types, and using the correct one in a particular research project, is all the more

important because the interview type used should be consistent with research problem,

objectives and research methods adopted. This research aims to develop a model for auditing IT

project management, which could be used in organisations as a tool to determine whether the

organisation follows in practice the project management theory which it claims to follow. It has

been established that the data will be collected and analysed in a qualitative manner which,

among other things, involves working with non-numerical data emphasising on human perception

and understanding.

c) Questionnaires

There are various accepted definitions for questionnaires as a data collection technique

(Oppenheim, 2000). These definitions range from techniques where the person answering the

question actually records their own answers, to interviews administered face to face, to telephonic

interviews. For the purpose of this research, the term questionnaire includes all data collection


techniques in which each person is asked to the same set of questions in a pre-determined order

(Saunders et al, 2009; De Vaus, 2002). This definition includes questionnaires where the

researcher is physically present in from or the respondent, those conducted by telephone, and

those where the researcher is not physically present (such as online questionnaires).

Like other data collection techniques, the researcher’s decision to use questionnaires should be

informed by its relevance to the research problem and objectives. Questionnaires, as a technique

for collecting data, also tends to be best suited for descriptive and explanatory research, where

standardised questions are often used, and the researcher can be reasonably confident that all

questions will be interpreted the same way by all respondents. This characteristic implies a

limitation when using questionnaires in research requiring a large number of open-ended

questions, such as exploratory research (Saunders et al, 2009; Robson, 2002). It is possible to

use questionnaires as the only data collection method in a research, but it is often more desirable

to combine questionnaire with other data collection techniques, such as unstructured or semi-

structured interviews, in order to offset the above-mentioned limitation (Saunders et al, 2009;

Jancowitz, 2005).

d) Case study

A case study is an empirical enquiry that investigates a contemporary phenomenon within its real-

life context, when the boundaries between phenomenon and context are not evident (Robson,

2002:178; Munhall, 2007:350). A case study is most suitable when the phenomenon being

studied is not easily distinguishable from its context. Furthermore, a case study should not aim to

understand other cases, but rather to understand the very specific case being researched, by

maximising what can be learned (Yin, 2003:4; Esteves, 2010:80). This dedicated focus on a

single case provides excellent opportunities for respondents and researchers to check their

understanding and keep asking questions until they obtain sufficient answers and interpretations

(Marschan-Piekkari & Welch, 2004:111).

Case studies are distinguished in two distinct typologies, namely single as opposed to multiple

case, and holistic as opposed to embedded case. The first typology (single as opposed to

multiple) argues on the, one hand, that a single case is often used for a critical or alternatively an

extremely unique case, thereby providing the researcher the opportunity to observe and analyse

a phenomenon that few or no researchers has analysed before. On the other hand, case studies

with multiple cases are often used in research in order to establish whether the findings in the first

case occur in, and can therefore be generalised to, the other cases. The second typology (holistic

as opposed to embedded) refers to the unit of analysis. When a researcher conducts a case

study on an entity, say on a company, the case study is said to be holistic when the researcher


only needs to treat the entire company as a whole. Conversely, if the researcher also needs to

examine a number of logical sub-units, such as departments or business units, then the case will

inevitably involve more than one unit of analysis. This is called embedded case study (Yin, 2003).

These characteristics of case study may raise scepticism, as adopting this data collection method

may feel less scientific. However, Saunders et al (2009) argue that a well constructed case study

can constitute a very useful way of exploring and/or challenging existing theory and provide a

source of new research questions.

For the purpose of this research, and based on the above discussion of data collection

techniques, questionnaire and semi-structured interview are the main data collection techniques

used.

Table 2.6 summarises the data collection techniques discussed, and highlights the ones used for

the purpose of this research.


Table 2.6: Data collection techniques

Data collection techniques Typology Brief description

Participant observation The observer (researcher) participates in the daily life of the

people being observed with the objective of sharing in these

people’s lives while attempting to learn their symbolic world.

1 Observation

Structured observation Adopts a more detached stance whereby the researcher focuses

on watching and recording behaviour in a way which does not

involve any kind of interaction with the subjects being observed.

Structured interviews Interviews using questionnaires based on a predetermined and

standardised or identical set of questions.

Semi-structured Intermediate between structured and unstructured interviews.

Questions are formulated in advance, but the answers are open-

ended and can be further expanded at the discretion of the

interviewee and the interviewer.

2 Interviews

Unstructured Informal interviews allowing the person being interviewed to tell

their story at length, in their own words, with little direction or

intervention from the researcher.

Face to face Data collection technique, involving direct face to face interaction

between the interviewer (researcher) and the person being

interviewed, in which each person is asked to the same set of

questions in a pre-determined order

Telephone Data collection technique, involving direct telephonic interaction

between the interviewer (researcher) and the person being

interviewed, in which each person is asked to the same set of

questions in a pre-determined order

3 Questionnaires

Online Data collection technique, involving no direct interaction between

the interviewer (researcher) and the person being interviewed, in

which each person is asked to the same set of questions in a pre-

determined order (e.g. through a web site).

Single vs. multiple Single case is conducted on a critical or extremely unique case,

whereby the researcher can observe and analyse a phenomenon

that few or no researchers has analysed before; Multiple cases

serve to establish whether the findings in the first case occur in,

and can therefore be generalised to, the other cases.

4 Case study

Holistic vs. embedded Holistic case applies when a researcher conducts a case study

on an entity and only needs to treat the entire entity as a whole;

Embedded case applies if the researcher also needs to examine

a number of logical sub-units within the entity being researched.

The data collection stage (and consequently the data collection technique used) is crucial in

research, because the quality of data collected determines the quality of the data analysis

(Varkevisser, Pathmanathan & Templeton, 2003).


The next discussion discusses the specific data analysis techniques applicable to the above-

mentioned data collection techniques. In view of the link between data collection and data

analysis, the next discussion only emphasises on the data analysis techniques which are suitable

for the already identified data collection techniques.

(ii) Data analysis techniques

The qualitative data collected in this research will inevitably constitute non-numeric data that have

not been quantified. This implies that qualitative data is based on meanings expressed through

words, collected in non-standardised formats requiring classification into categories, and

analysed through the use of conceptualisation (Dey, 1993; Miles & Hubarman, 1994).

According to Saunders et al (2009), there is no standardised procedure for analysing such

diverse data, but it is still possible to group it into three main types of processes: The first one is

summarising (or condensation of meaning); the second one is categorisation (or grouping) of

meanings, and the third one is structuring (or ordering) of meanings using narrative. The above-

mentioned literature elaborates on these processes, but no further elaboration is necessary for

the purpose of this chapter. However, it is important to note that these processes use specific

qualitative data analysis techniques, allowing the researcher to develop theory from the collected

data.

There are qualitative data analysis techniques for both deductive and inductive approaches

(Saunders et al, 2009). The deductive approach to data analysis involves using existing theory to

shape the approach that the researcher adopts to the qualitative research process and to aspects

of data analysis. Conversely, the inductive approach to data analysis seeks to build a theory that

is adequately grounded in the data collected (Yin, 2003).

a) Deductive approach to data analysis

Yin (2003) suggests that, where the researcher makes use of existing theory to formulate the

research question and objectives, the researcher may also use the theoretical propositions that

helped him/her to do this as a means to devise a framework for organising and directing data

analysis. However, there is a debate as to the appropriateness of deductive approach, as applied

to data analysis. Bryman (1988:81) argues that prior specification of a theory has the risk of

introducing a premature conclusion on the issues to be investigated, as well as the risk that the

theoretical assumptions may differ from the view of the people being researched. Should such

risk materialise during a research project, the researcher ought to adapt their approach.


Devising theoretical assumptions prior to collecting data emphasises certain data analysis

techniques, namely pattern matching and explanation building (Yin, 2003). Pattern matching

involves predicting a pattern of outcomes, based on theoretical assumptions to explain what the

researcher expects to find. The researcher needs to develop a conceptual or analytical

framework, utilising existing theory, and subsequently test the adequacy of the framework as a

means to explain the findings. The more the pattern of the data matches what was predicted, the

more valid the conclusions are considered.

Explanation building is the other qualitative data analysis technique used as part of deductive

approach. Explanation building involves an attempt to build an explanation, while collecting and

analysing data, rather than testing a predicted explanation (Yin, 2003).

Alternative, data can be analysed inductively.

b) Inductive approach to data analysis

This approach advocates starting data collection, and then exploring the data to see which

themes or issues to follow up and concentrate on (Hatch, 2002; Yin, 2003; Strauss & Corbin,

2008). Saunders et al (2009) associate this approach mainly with exploratory research. However,

Yin (2003) warns that such approach may prove daunting to an inexperienced researcher. This is

likely to be the case where the researcher simply collects data without examining them to assess

which themes are emerging as the research progresses. It is therefore more advisable to analyse

the data as they are collected, and to develop a conceptual framework to guide subsequent data

analysis. This is also referred to as grounded approach.

Saunders et al (2009) identify a number of inductively based data analysis techniques to analyse

qualitative data. These include: data display and analysis, template analysis, analytical induction,

grounded theory, discourse analysis, narrative analysis. In practice, some of these techniques

may apply to both inductive and deductive approaches to analyse qualitative data, but for the

purpose of this research, they are solely discussed as inductively based techniques. Bryman

(1988) suggests two good reasons to justify this view: firstly, this exploratory research project

may generate a direction for further research; secondly, the scope of this research may be

constrained by adopting restrictive theoretical propositions that do not reflect the participants’

views and experience. The above-mentioned techniques are briefly discussed.

Data display and analysis advocates that the process of analysing data consists of three

concurrent sub-processes, namely data reduction, data display, and drawing and verifying

conclusions (Miles & Huberman, 1994). These processes imply firstly summarising and

simplifying the data collected in order to transform and condense them. Secondly, the data is


organised and assembled into summary diagrammatic or visual displays. Thirdly, using the data

displays to recognise relationships and patterns in the data, as well as draw and verify

conclusions.

Template analysis involves developing categories from the data collected, and attaching these

categories to units of data (Donnellan, 2006:78). Firstly, data are coded and analysed to identify

themes, patterns and relationships. Secondly, these codes are shown hierarchically to help the

analysis process. As data collection proceeds, the template is revised as part of the data analysis

process.

Analytic induction is an inductive version of the explanation-building technique described

above, as part of deductive approach to data analysis. This is an extensive examination of a

strategically selected number of cases, in order to empirically establish the causes of a specific

phenomenon (Cassell & Symon, 2004:165). As an inductively-based approach, analytic induction

starts with a less defined exploration of the phenomenon to be explored, which is not derived

from existing theory. This explanation is then tested through a specially selected case study to

allow the phenomenon to be explored.

Saunders et al (2009) advise that, given the loosely defined nature of the explanation, it is likely

either that the explanation will need to be redefined, or that the scope of the phenomenon to be

explained will be narrowed. Adopting one of these courses of action leads to redefining the

phenomenon or its explanation, and creates the need to explore a second case study that will

also be specially selected. Where the explanation appears to be confirmed, the researcher may

either stop data collection on the basis that a valid explanation has been found, or test the

explanation in other specially selected cases, to see whether it is still valid.

Grounded theory has already been briefly mentioned as a research method earlier in this

chapter, under heading 2.1.3.4. However for the purpose of this research, it is also viewed as a

qualitative data analysis technique, and is therefore briefly discussed as such in this section. In

grounded theory, data collection also starts without the formation of an initial theoretical

framework (Saunders, 2009). Theory is therefore developed from data generated by a series of

observations. These data lead to generating predictions, which are then tested by further

observations that may confirm or invalidate the predictions (Saunders et al, 2009, Collis &

Hussey, 2003; Goulding, 2002).

Discourse analysis is a general term that covers a wide variety of techniques used for the

analysis of language, and is concerned with how and why individuals’ language is used by

individuals in specific social contexts (Wood & Kroger, 2000; Saunders et al, 2009). This data


analysis technique particularly explores how language (discourse) in the form of talk and text both

constructs and simultaneously reproduces and/or changes the social world, rather than using it as

a means to reveal the social world as a phenomenon (Phillips & Hardy, 2002). The focus is

therefore on identifying how this reproduction or change occurs.

Narrative analysis is a data analysis technique used as a means to explore linkages,

relationships, and socially constructed explanations that naturally occur within narrative accounts,

where it would not be necessary to fragment these accounts into categories and themes. Data

collected as narratives (stories) through, for example, semi-structured or unstructured interviews

may not always present facts, but they provide meaning to the facts (Herman & Vervaeck, 2005).

It is also likely that the inductive approach to data analysis will combine some elements of

deductive approach, as the researcher first seeks to develop a theoretical position, then tests its

applicability through subsequent data collection and analysis (Saunders et al, 2009).

Consequently, while the data analysis may commence with either an inductive or deductive

approach, in practice a research is likely to combine elements of both. It should also be

mentioned that the use of computer aided qualitative data analysis software (CAQDAS) greatly

enhances the use of number of these data collection techniques (Saunders et al, 2009). A

detailed discussion of CAQDAS packages is beyond the scope of this research.

For the purpose of this research, and based on the above discussion of data analysis techniques,

the main analysis technique adopted is data display and analysis.

Table 2.7 summarises the data analysis techniques and highlights the one adopted for the



Table 2.7: Data analysis techniques

Qualitative Data Analysis Technique

Deductively based Inductively based

1. Data display and analysis: Data analysis technique that involves

three concurrent sub-processes of data reduction, data display, and

drawing and verifying conclusions.

2. Template analysis: Analysis of qualitative data that involves

creating and developing a hierarchical template of data codes or

categories representing themes revealed in the data collected and

the relationship between these.

1. Pattern matching: Data analysis technique that

involves the prediction of a pattern of outcomes, based

on theoretical propositions to seek to explain a set of

findings.

3. Analytic induction: Analysis of qualitative data that involves the

iterative examination of a number of strategically selected cases to

identify the cause of a particular phenomenon.

4. Grounded theory: Analysis technique in which theory is

developed from data generated by a series of observations or

interviews.

5. Discourse analysis: Variety of data analysis techniques that

explores how language constructs and simultaneously reproduces

and/or changes the social world rather than using it as a means to

reveal the social world as a phenomenon.

2. Explanation building: Data analysis technique that

involves the iterative examination of a number of

strategically selected cases to test a theoretical

proposition.

6. Narrative analysis: The collection and analysis of qualitative data

that preserves the integrity and narrative value of data collected,

thereby avoiding their fragmentation.

This research design and methodology can be conceptualised into a multi-layer structure, similar

to an onion which is peeled one layer at a time, beginning with the outer layer (Saunders et al,

2009). This ‘research onion’ depicts the various research philosophies, approaches, methods,

time horizons, and data collection and analysis techniques discussed in this chapter.

Figure 2 .2 illustrates the ‘research onion’ and highlights the design adopted for the purpose of

this research.


Qualitative

Quantitative

Cross-sectional

Longitudinal

Action research

Archival research

Ethnography

Grounded theory

Modelling

Case study

Literature review

Survey

Experiment

Inductive

Deductive

positivism

Realism

Interpretivism

Pragmatism

Philosophies

Approaches

Methods

Time horizons

Data collection

And

Analysis

Figure 2.2: The ‘research onion’ (Adapted from Saunders et al., 2009)

The next section concludes this chapter.

2.2 Conclusion

The goal of this chapter was to present the way this research is designed. It has been shown that

there are more than one ways to design a research project, but for the purpose of this research, it

is appropriate to consider the research process as layers which can be “peeled” progressively,

from the outside layer to the inside layer.

Each layer of the research design represented an objective of the chapter. The first one was to

determine the research philosophy followed in this research. This equates to exploring important

assumptions about the way in which the researcher addresses this research. These assumptions

can be grouped in three major categories, namely epistemology, ontology and axiology. These

categories refer successively to the researcher’s view of the nature of reality, the researcher’s

view of what constitutes acceptable knowledge, and the researcher’s view of the role of values in

research. It appears that this particular research is socially constructed, focused on subjective

meanings, and that the researcher is part of the research process. These characteristics align

with the interpretivism philosophy.


The second objective was to go one layer deeper into the ‘research onion’, and identify the

research approach. This refers to whether the research end result delivers data, based on a

theory, or the research builds a theory based on empirical data. The former option refers to

deductive approach, while the latter refers to inductive approach. It is possible to combine these

approaches in a single research project. However, this research mainly adopted the inductive

approach.

Having determined the philosophy and approach for this research, it became necessary to

determine how the research would formally go about resolving the research problem (third

objective). This effort amounted to reviewing the relevant research methods, and determining the

most appropriate one(s) for the purpose of this research. It was established that this research

uses literature review and modelling as research methods.

The fourth objective referred to how this research was approached from a time perspective. One

of the options identified was to approach the research as a once-off exercise, representing a

snapshot research results at a particular point in time. The alternative way was to approach this

research as a repetitive endeavour, over time, so as to observe the changes in the results, on

each iteration. The merits of each option were explored, and it was established that, for the

purpose of this research, it was more appropriate to do a once-off (cross-sectional) research.

The final objective was to determine how data would be collected and analysed in this research.

The first decision at this stage was to determine whether this research would be quantitative or

qualitative. After exploring each of these options, it appeared that the purpose of this research

was best served by qualitative research. This decision, in turn, influenced how the data was going

to be collected and analysed. It was established that data was going to be collected through

semi-structured interview and telephone questionnaires. It was also established that data was

going to be analysed inductively, using the data display and analysis technique. This technique

involves simplifying the data collected, organising it into summary diagrammatic or visual

displays, and drawing conclusions.

From a design and methodology perspective, this research can therefore be describes as:

A qualitative, interpretive, inductive and cross-sectional study of auditing, project management

and IT governance, which collects data through literature review, semi-structured interviews and

telephonic questionnaires, analyses the collected data inductively through data display and

analysis, and uses modelling to propose a conceptual model.

The research design and methodology alternatives identified in this chapter are neither

exhaustive, nor an attempt to affirm the superiority of some over others. Instead, these


alternatives represent distinct and often complementary positions, which can be adopted in

designing a research project, depending on the research problem and objectives.

The value of this chapter lies in the fact that it has been demonstrated that the researcher did not

merely make instinctive guesses on the design of this research. Instead, several alternatives

were carefully weighed, based on their relevance to the research goals. Only the options which

best served the goals of the research were eventually selected, but the process of exploring

alternatives contributed to knowledge and awareness of the various research design possibilities.

The next chapter explores auditing.

_____________________________________________________________________ Chapter 3 – Literature Review on Auditing 40

3 CHAPTER 3 – LITERATURE REVIEW ON AUDITING

3.1 Introduction

3.1.1 Background

The overall goal of this research is to develop a model to guide organisations in determining

whether they are following the project management best practices which they purport to follow.

To reach this goal, the research needs to meet certain objectives, as outlined in Chapter 1, under

heading 1.1.3 “Research Objectives”. This chapter focuses on the first research objective:

Explore auditing through literature review. This review is intended to demonstrate critical

understanding of auditing, which is a key part of this research. At the end of this literature review,

the researcher hopes to attain a clear understanding of auditing, and how it applies to project

management. The next section sets the goals and objectives for this chapter.

3.1.2 Goal

The goal of this chapter is to review and evaluate critically standards related to auditing in

general, and project management auditing in particular. In order to meet this chapter goal, the

following objectives need to be achieved.

3.1.3 Objectives

� Objective 1: Explore the evolution of auditing over time and define auditing.

� Objective 2: Identify and critically evaluate recognised audit standards.

� Objective 3: Explore project management auditing, to understand the relevance of

auditing in project management.

3.1.4 Layout

The remainder of this chapter is laid out as follows: the first section reviews the evolution of

auditing over time, to its current state. The fundamental traits and other trends observed over

time should highlight some major auditing principles. The second section identifies and evaluates

critically a recognised audit standard. The third section explores the issue of auditing with

particular relevance to the project management field. The last section concludes the chapter and

summarises key emerging issues.


3.2 Brief historical overview on auditing

Auditing has been in existence in one form or another for as long as there has been a need for

men to account for their transactions. There is no universal consensus as to when auditing

concepts became what they are nowadays known as: some evoke the nineteenth century

(Boynton & Kell, 1996:8; Gupta, 2005:3; Basu, 2009:1), yet others find the roots of modern

auditing as far back as the seventeenth century (Woolf, 1997:2). Notwithstanding these apparent

differences, it clearly appears that auditing is an established profession which has been exercised

for centuries and has gradually evolved over time into the form in which it is currently known.

As times evolved and commercial appetite grew, it became evident that some control was needed

to safeguard the environment in which these commercial activities took place. A couple of

examples illustrate this: Firstly, during the industrial revolution (1750-1850), as manufacturing

organisations became bigger in size, owners increasingly passed the management of their

business ventures to professional managers, which created the need for the former to verify the

work performed by the latter (Ramamoorty, 2003:2; Basu, 2009:1-2). The second example relates

to the international trade explosion in the sixteenth and seventeenth centuries, which saw a rise

of business opportunities between Europe and other regions such as the East or Americas. The

adventurers who pursued these business opportunities rarely had the required financial capacity.

They therefore relied on outside funding from wealthy merchants, bankers, or even royalty. The

promoters of these business opportunities sometimes painted a picture much brighter than reality.

Some massive frauds also occurred from time to time. These incidents contributed to creating the

need for some form of control (Woolf, 1997:2; Arter, 2003a:1), which was provided by appointing

auditors who started producing periodic reports on the work they had performed, for the attention

of the persons who appointed them.

Shortly thereafter - in the second half of the nineteenth century - it became evident that the work

of auditors was far too important to be left to individuals who possessed limited experience or

training. The emergence of professional bodies logically ensued.

In the first half of the twenty first century, the focus of audit activities gradually shifted away from

fraud detection towards reporting the actual financial condition of an organisation. Basu (2009:3)

asserts that the primary focus of auditing became to provide an opinion on financial statements,

and that fraud detection only became secondary. While it is valid, this assertion does not capture

all the major changes that happened during this period in the field of auditing. Boynton & Kell

(1996:9) add two more major changes that characterised this evolution: firstly, there was a shift

from detailed verification of accounts to sampling or testing as a basis for rendering an opinion on

the fairness of financial statements. Secondly, it became common to establish a link between the


testing to be done and the auditor’s evaluation of a company’s internal control. These three

changes have been major characteristics of the evolution of auditing during the first half of the

twenty first century, but there is still considerable controversy about the shift away from fraud

detection. This is because the public still expects the auditor to detect fraud (Vinten, 2005).

The period from 1960 to 1980 was characterised by some important factors. Firstly, wage costs

constantly increased in the auditing profession. Secondly, business complexity vastly increased

and computerised information systems proliferated. These two factors, as Basu (2009:3)

recognises, mainly contributed to the increased demand for more efficient and effective ways to

audit. The answer was the emergence of information systems based auditing, known as

Electronic Data Process (EDP) auditing (Senft & Gallegos, 2008:3). It is in this same period

(1969) that a small group of individuals, concerned with auditing controls in the computer

systems, created the EDP Auditors Association, which later gave birth to ISACA - an educational

foundation for large-scale research efforts to expand the knowledge and value of IT governance

and control (ISACA, 2007).

In the couple of decades leading to 2010, the focus in auditing has largely drifted towards

establishing a coordinated profession and using harmonised standards and frameworks

worldwide (Gupta, 2005:4). Some of these frameworks are reviewed later in this chapter. The

above-mentioned milestones are summarised in table 3.1.

Table 3.1: The evolution of auditing

Evolution of auditing

Approximate Period Description

Before the 16th Century Auditing already exists in one form or another

The auditors role is gradually formalised

Creation of first professional bodies

16th to 19

th Century

Audit focuses mainly on fraud detection

Auditing focus shifts to providing an opinion on

financial statements

Focus shifts from detailed verification to sampling

and testing

1900 – 1950

Necessity to link testing and auditor’s evaluation of

internal controls

1960 – 1980 Emergence of Information Systems based auditing

1980 – 2010 Focus towards standard audit frameworks worldwide

From the above historical review of auditing, it appears that, despite some changes over time, the

overall purpose of audits have remained fairly constant. Having explored the changing part of


auditing, it is now fitting to also cast some light on the constant part. The next section therefore

explores what an audit is.

3.3 Defining auditing

Simply put, auditing is a formal examination or verification of records (Badiru, 1995:150). While

this definition has the merit of brevity, it seems over-simplistic. O’Reilly et al. (1999:4) propose a

more elaborate and explicit definition, as they claim that auditing is:

“… a systematic process of objectively obtaining and evaluating evidence regarding specific

assertions – including actions and events, to ascertain the degree of correspondence between

those assertions and established criteria, and communicating the results back to interested

parties…”

The latter definition appears to provide more insight into what auditing is, and seems to be more

widely adopted, as confirmed by Raffa (2003).

The first element in this definition refers to the fact that auditing needs to be a systematic

process. This indicates the importance of structuring and planning a dynamic audit strategy, as

part of the audit process (Shamoo, 1989:17; O’Reilly et. al, 1999:7; Watne & Turney, 2002:108).

O’Reilly et al (1999:4) and Raffa (2003) further highlight the fact that audits focus on the process

of obtaining and evaluating evidence, as corroborated by Abou-Seada & Abdel-Kader (2003:1)

and Shamoo (1989:17). It also appears from the definition that an opinion is formed as part of the

audit process, after aggregating the collected evidence and comparing it to the established

criteria (Abou-Seada & Abdel-Kader, 2003:1). Lastly, the definition refers back to the interested

parties with specific audit feedback, thereby closing the auditing loop. This audit feedback should

attest the degree of correspondence, or discrepancy, between the evidence collected and the

established requirements.

Auditing can therefore be said to be a systematic process for collecting evidence, comparing it to

previously set criteria, and communicating feedback on the matches and mismatches between

the evidence gathered and the criteria initially set. This process is summarized in Figure 3.1.

Figure 3.1: Three-step process of Auditing


The auditing profession comprises several types of audits. Getting more insight into these audit

types would advance the purpose of this research. This is addressed in the next section.

3.3.1 Types of audit

The types of audits seem to be as multiple and varied as the terminology commonly used to

describe them. Some of the most recurrent terminology found in the literature includes “audit

category” and “audit sub-category”. For the purpose of this research, no specific distinction is

made between these terms. All of these classifications are therefore discussed as “types of

audits”.

Some authors suggest that the main types of audit include financial, compliance, and operational

audits (Whittington & Pany, 1998; The Office of Audit Compliance and Privacy (OACP), 2006;

Leicestershire City Council, 2008). Besides, other sources identify information systems audit, and

follow-up audit (University of Alberta, 2007; Yukon Executive Council, 2008). Russell (2005:19)

as well as Surak and Wilson (2007:103) broadly categorise audits as first-, second-, and third-

party audits. Badiru (1995) and Bandyopandhyay (1996) have yet another way of categorising

audits, namely as systems, process, and product audit.

This apparent deluge of terminology to describe different types of audits is potentially confusing.

This feeling is compounded by the impression that further literature review would have probably

yielded yet other types of audit. Notwithstanding this evident lack of consensus in the literature

regarding the types of audit, there is a consensus that, on the one hand, an audit is called internal

or first-party audit when it is performed by the organisation on or for itself; on the other hand, an

audit is called external audit when it is performed by an outside organisation (Boynton & Kell,

1996: 839; Woolf, 1997:62; Hall, 2000:4; Hall & Singleton, 2005:4; Gray & Manson, 2005: 564).

Based on this consensus, internal and external audits are therefore considered as overall audit

types for the purpose of this research.

A brief description is offered here, for other types of audit identified in this review of the audit

literature:

� Financial audit: Is concerned with the accuracy, reliability and fairness of an

organisation’s financial data (University of Alberta, 2007). The aim of financial audits is to

form an independent opinion on the integrity of the financial information being presented,

and to establish reliability on the means by which it is reported (University of Melbourne,

2005). This type of audit is normally performed by firms of certified public accountants

(Whittington & Pany, 1998).


� Compliance audit: Checks that the supplier of products or services has met the

requirements of the relevant specifications, contract or regulation (Russell, 2005:5). This

audit type looks at whether or not an organisation is adhering to specific laws, regulations

and the control operations according to policy, directives, standards or contracts (Yukon

Executive Council (YEC), 2008).

� Operational audit: provides an objective evaluation of an area, department or functional

operation (University of Alberta, 2007). Operational audit provides senior management

with an understanding of the degree to which management has achieved its

responsibilities and mitigated the risks associated with the operations within the

organisation (McGill, 2006).

� Information Systems audit: focuses on the controls that govern all stages of application

systems development in a particular environment, including development, operation,

maintenance, and security (University of Melbourne, 2005; University of Alberta, 2007).

� Follow-up audit: Is conducted after an internal or external audit report has been issued.

Follow-up audits are designed to evaluate corrective action that has been taken on the

audit issues reported in the original report (Western Washington University, 2006;

University of Alberta, 2007).

� First-party audit: Is performed within an organisation to measure its strengths and

weaknesses against its own procedures or methods and/or against external standards

adopted (voluntary) or imposed on (mandatory) the organisation. A first party audit is

otherwise referred to as an internal audit (Badiru, 1995; Bandyopandhyay, 1996;

International Register of Certified Auditors (IRCA), 2000; Spencer-Pickett, 2004; IIA,

2008).

� Second-party audit: Is performed within an organisation by a customer or by a

contracted organisation. This is typically an audit of contractors/suppliers undertaken by,

or on behalf of a purchasing organisation. Second-party audits are often regulated by a

contract and tend to be more formal because audit results could influence a customer’s

purchasing decisions. Second-party audits are also known as external audits

(Bandyopandhyay, 1996; Spencer Pickett, 2004; IRCA, 2008).

� Third-party audit: Is an audit of an organisation undertaken by an independent

certification body or registrar or similar third party organisation. Third-party audit is

performed by an audit organisation independent of the customer-supplier relationship and

is free of any conflict of interest. A key characteristic of third-party audits is the

independence of the audit organisation, and the fact that this type of audit may result in

certification, registration recognition, license approval, a citation, a fine, or a penalty

issued by the third-party organisation or an interested party (IRCA, 2008).


� Systems audits: Is an assessment of the entire system or all of the processes or

functions of an organisation. A system audit scrutinizes the interactive quality structure of

an organisation as a whole, and the effect of the system on the product or service. The

purpose of a system audit is to verify whether or not quality management systems are

indeed carried out as specified in the documentation (Badiru, 1995; Bandyopandhyay,

1996; Christensen, Coombes-Betz & Stein, 2007:22).

� Product audit: Is an assessment of the final product produced by an organisation and its

fitness for use, evaluated against its intended purpose (Badiru, 1995; Bandyopandhyay,

1996; Christensen, Coombes-Betz & Stein, 2007:22).

Table 3.2 summarises the audit types found in this literature review, and highlights those

identified as main audit types for the purpose of this research.

Table 3.2: Types of audit identified vs. Types of audit used for the purpose of this research

Audit types identified in the literature

Main audit types Description

1 Internal audit Performed by an organisation on or for itself

2 External audit Performed by an outside organisation

Other audit types identified Description

3 Financial audit Concerned with the reliability, accuracy and fairness

of financial data

4 Compliance audit Checks that the supplier of products or services has

met the relevant specifications

5 Operational audit Provides an objective evaluation of an area,

department or functional operation

6 Information systems audit Focuses on systems development governance and

controls

7 Follow-up audit Evaluates corrective action taken as a result of the

original audit

8 First-party audit Performed within an organisation to measure its

strength against external standards

9 Second-party audit Performed within an organisation by a contracted

organisation

9 Third-party audit Undertaken by an independent body

10 Systems audit Assessment of all processes or functions of the

organisation

11 Product audit Assessment of the final product and its fitness for use


On the basis of the above literature review, two main observations emerge: Firstly, the above list

of audit types is not exhaustive. It only captures the audit types encountered in this particular

literature review; this list is nevertheless sufficient for the purpose of this research. Secondly, the

audit types identified and listed above are not necessarily different from the two main types

highlighted above. In fact, some of them are synonymous. This is exemplified by first-party and

second-party audits which, according to their descriptions above, are respectively synonymous to

internal and external audits.

The importance and historical longevity of auditing explored in the previous section directs

inevitable attention towards the person responsible for conducting the audit, namely the auditor.

3.3.2 Types of auditors

An auditor is the person who plans and performs the audit (Russell, 2005:26). In fact, more than

merely conducting the audit, the auditor is required to be competent to conduct the audit. Gray

(2008) agrees as he underlines that the competence of the auditor is a key ingredient in

generating confidence in the audit process. If the competence of the auditor is so crucial to

auditing, then it can be argued that it is essential to assign the right type of auditor to the right

type of audit. Having identified internal and external audits as main audit types, it then seems

logical that the main types of auditors should be internal and external auditors. This view is

echoed in the literature (Boynton & Kell, 1996:5; Hall, 2000:4; Label, 2010:162).

A brief description of these main types of auditors follows:

� Internal auditors: Are professionals employed by organisations to investigate and

appraise the effectiveness with which the various organisational units of the company are

carrying out their assigned functions (Whittington & Pany, 1998). Spencer Pickett

(2004:3) extends this definition to include concepts such as the independence, objectivity

and added value that organisations expect from their internal auditors. Essentially,

internal auditors should provide directors and executives with an assessment of the

adequacy of internal controls (The Institute of Internal Auditing (IIA), 2008).

� External auditors: Are audit professionals from outside the audited organisation, who

primarily perform audits on financial statements in compliance with professional

standards (Golden, Skalak, and Clayton, 2006:264). This, according to Puttick, Van Esch

and Kana (2008:366), mainly involves identifying and addressing material misstatements.

The above descriptions should not portray the impression that the two types of auditors exist in

totally separate worlds. Indeed, there are areas of collaboration between them. This is illustrated


by Folkerts-Landau & Lindgren (1998) and Singh (2007), as they affirm that much of the external

auditor’s work consists of checking and verifying the internal auditor’s work.

The definitions of auditing point to the fact that auditing focuses on verifying what has been done,

how it was done, and who did it. The what question refers to the essence of auditing, namely the

historical evolution and the audit types. The how refers to accepted auditing standards, and the

who refers to the types of auditors. For the purpose of this research, these are collectively

referred to as the triple dimension of auditing, and are highlighted in Figure 3.2.

Figure 3.2: Simplified triple dimension of auditing

While the previous section focused on the what and who, the next section discusses on the how.

To explore this question, and in line with the second objective of this chapter, a set of auditing

standards is critically reviewed.

3.4 Auditing Standards

The end product of an audit exercise is a formal written report that expresses the auditor’s

opinion about the reliability of audited information (Hall, 2000:3; Hall & Singleton, 2005:7). This

implies that the auditor’s opinion itself needs to be reliable. For this reason among others, many

organisations have set auditing standards to provide guidelines to individual practitioners who

aspire to provide quality audit work (Boynton & Kell, 1996:19). Among these, the American

Institute of Certified Public Accountants (AICPA) has developed generally accepted auditing

standards (GAAS), which are the most recognised auditing standards in the public accounting

profession (Boynton & Kell, 1996:40); the Institute of Internal Auditing (IIA) has established

practice standards for internal auditors (Boynton & Kell, 1996:840); and the General Accounting

Office (GAO) has established the generally accepted government auditing standards (GAGAS)

(Boynton & Kell, 1996: 853).


This research therefore recognises that several auditing standards exist. However, based on their

wide recognition and global adoption (Boynton & Kell, 1996:840; Siegel & Shim, 2006:482), the

generally accepted auditing standards are discussed for the purpose of this research.

3.4.1 Generally Accepted Auditing Standards (GAAS)

GAAS comprise of ten auditing standards developed by the American Institute of Certified Public

Accountants (AICPA). These ten standards are categorised into three classes: general

qualification standards, field work standards, and reporting standards. A brief discussion of each

of these classes follows:

a) General standards

The general standards of the GAAS relate to qualifications of the auditor and to the quality of the

auditor’s work. The three general standards relate to: (i) the need for technical training and

proficiency; (ii) independence of mental attitude, and (iii) due professional care in the

performance of the audit and preparation of the report (Boynton & Kell, 1996; Hall & Singleton,

2005:7).

Firstly, these standards highlight the need for auditors to be formally trained, to be experienced in

the practice of their profession, and to continually educate themselves during their professional

career. Secondly, it appears that competency alone is not sufficient; while it is important to have a

technically competent auditor, it is equally important that the auditor be free from client influence

while performing the audit. Thirdly, the auditor is expected to be diligent and careful in performing

an audit and issuing a report on the findings.

The above confirms that the auditor plays a key role in the audit process. In order to live up to this

expectation, the auditor, as an individual, needs to have sufficient formal training and practical

experience. An inexperienced or technically incompetent auditor should therefore not be

entrusted with an audit exercise. The auditor should also ensure that nothing exposes him or her

to being influenced by the client who is being audited. The key role played by the auditor also

implies that auditors should take their duty to conduct audits and to report on findings very

seriously, and need to avoid negligence or complacency in so doing.

b) Standards of field work

This set of standards relates primarily to conducting the audit on the client’s premises (the field)

and focuses on (i) the importance of adequately planning and supervising the audit, (ii)

understanding the client’s internal control structure, and (iii) obtaining sufficient competent


evidential matter (Boynton & Kell, 1996; American Institute of Certified Public Accountants, 2001;

Hall & Singleton, 2005:7).

These standards firstly suggest that it is essential to develop adequate strategies, to design audit

programs, and to supervise the various activities undertaken as part of the audit, particularly

when these activities are performed by assistants who are less experienced than the auditor.

Secondly, internal control structure ensures that the audit is conducted in an effective and

efficient manner, and that the audit results are reliable. Thirdly, it is important that auditors have a

reasonable basis, both in terms of the quantity and quality of the evidence, for expressing an

opinion on the audit. This review of the standards of field work illustrate that activities before,

during, and after the audit should not be taken lightly by auditors.

Auditors should therefore remain aware that the audit is a process which should begin with

adequate preparation. They then need to demonstrate an understanding of how the client’s

internal controls work, in order to ensure that audit results are reliable. Lastly, auditors cannot

reach a conclusion on any basis other than having gathered sufficient and competent evidence to

support their opinion.

c) Standards of reporting

This set of standards relate to criteria which must be met when the auditor reports audit results.

The focus of these standards is placed on (i) alignment between the financial statement

assertions being audited and generally accepted accounting principles (GAAP); (ii) consistency in

the application of GAAP; (iii) adequacy of informative disclosures; and (iv) expression of opinion

(Boynton & Kell, 1996; American Institute of Certified Public Accountants, 2001; Hall & Singleton,

2005:7).

These standards imply firstly that the GAAP constitute the main established criteria to evaluate

assertions presented in the financial statement. Secondly, these standards highlight that auditors

should explicitly refer in their reports to instances where the GAAP have not been consistently

followed. Thirdly, when auditors determine that the information disclosed in the financial

statements are not reasonably adequate, they must state so in the audit report. Lastly, in the

audit report, the auditor must either express an opinion as a result of the audit, or state that an

opinion cannot reasonably be expressed. In the latter scenario, the auditor should provide

reasons for not expressing an opinion.

The standards of reporting highlight the importance of having a set of criteria, or best practices

against which to perform an audit. If the audit finds instances where these best practices have not


been followed, auditors should specifically highlight these instances in the audit report.

Furthermore, if it happens that the auditing party finds the information provided by the audited

party to be inadequate for the purpose of the audit, the former party is required to notify the latter

party of such finding. Lastly, auditors are required to take their responsibility and make a

pronouncement after conducting the audit.

From the above discussion, it can be suggested that the auditor’s report should be accurate,

reliable and compliant with best practices. Adhering to the general standards ensures accuracy;

reliability is ensured by adhering to field work standards, and compliance is achieved by adhering

to reporting standards.

This review of GAAS contributes to the previously established understanding of auditing, as

illustrated in figure 3.3.

Figure 3.3: Expanded triple dimension of auditing

The above discussion has defined auditing and explored types of audits (what), types of auditors

(who) and auditing standards (how). The next section explores project management auditing in

similar structure.

3.5 Project management auditing

Generic auditing has been summarised as the process of collecting evidence, comparing it to

requirements set in advance, and measuring the matches and mismatches. One can therefore

surmise that applying these processes to project management would constitute project

management auditing. This claim appears somewhat superficial. The review in the next section

therefore intends to review and evaluate literature, as a means to deepen the understanding of

the relevance of auditing in project management.


3.5.1 Defining project management auditing

The Project Management Body of Knowledge (PMBOK® Guide) acknowledges the role of

auditing in project management, as it states that “…audits in project management ensure that the

composition of a project configuration item is correct and that the corresponding changes are

registered, assessed, approved, tracked, and correctly implemented…” (Project Management

Institute, 2008; Scheid, 2010). This definition conveys a notion of controlling how projects are

being implemented or have been implemented. Stanleigh (2009) reinforces this idea when he

stresses that auditing provides an opportunity to uncover issues, concerns and challenges

encountered during the project lifecycle.

While the above definitions point to the supposed importance of auditing in project management,

they do not offer the combined benefit of accuracy and depth found in the Certified International

Project Auditor (CIPA) study guide (International Association of Project and Program

Management (IAPPM), 2008:26); the latter source depicts project management auditing as “…an

independent assessment or analysis of a project, product or project management office to verify

compliance to company and industry standards for project and project management…”. This

implies firstly that the auditor is expected to perform the audit work from an independent position,

free from pressures and other possible impediments that may arise from the person or entity

being audited. The emphasis on auditor independence confirms an important ingredient of a

successful audit, which has already been identified earlier in this research, when auditing

standards we discussed.

Secondly, the IAPPM’s definition of auditing clearly applies to both stand-alone projects and

project management offices, as opposed to the previously mentioned definitions, which are rather

unclear on this matter. It assumes an abstraction between project auditing and project

management auditing. This research will therefore do the same and may refer to project auditing

and project management auditing interchangeably. Lastly, the IAPPM definition explicitly takes

account of the necessity to verify compliance to previously set standards within the company or

the industry. This aspect is directly relevant to the current research problem.

In line with the above, project management auditing can therefore be said to be a process of

independently collecting evidence on a project or project office, verifying that collected evidence

complies with previously set company or industry standards, and communicating the results to

the individual or entity audited. This process is summarised in figure 3.4.


Figure 3.4: Three-step process for auditing project management

The next section explores the types of project management audits.

3.5.2 Types of project management audit

The IAPPM (2008:43) lists eight classifications, or types, of project management audits, as

follows:

� Assessing companies: Project-driven or outsourcing-related evaluation of a company.

� Internal control reviews: Specialised reviews to assist managers with various aspects of

their control responsibilities.

� Pre-implementation reviews: Aimed at identifying possible weaknesses in new system

prior to implementation.

� Preliminary assessments: initial internal control performed without issuing the audit

conclusion. Aimed at introducing the audited party to the auditing process, and opening

communication links between the auditor and the audited party.

� Contracted third-party substantive work: Auditing work performed primarily by an external

auditing firm.

� Training: Presentations and workshops on internal controls, finance or other specialty

area.

� Contract reviews: Audit of contract compliance, including construction audits, acquisition

and divestiture reviews, advertising and other third-party, contract reviews.

� Other reviews, including staff pre-scope reviews, follow-up reviews and other assistance.

Each of the above types of project management audit is either performed within an organisation

by internal resources, or by resources from an external provider. This means that each of the

above-mentioned falls either under internal or external project management audit. This review of

the CIPA study guide on project management auditing concurs with the review of auditing

performed in section 3.3.1. “Types of audit”.

It can therefore be said that the two main types of project management audits are: internal and

external project management audits. Types of project management auditors are now

investigated.


3.5.3 Types of project management auditors

The IAPPM (2008:59) provides a useful guideline regarding skills that a project management

auditor should possess. These include a good understanding of project management, in addition

to skills in the following areas: infrastructure, engineering, Information Technology, contract and

sub-contract, networking, information assurance, finances, planning and scheduling, portfolio

management, training and human resources, and compliance training. A detailed discussion of

these skills is beyond the scope of this research. However, each of these skills can equally apply

to an internal or external project.

Besides these suggested auditor skills, the AIPPM literature does not give any indication that

there exists a type of auditor different from the types of auditor previously discussed in section

3.3.2 “Types of auditors”. Therefore, for the purpose of this research, the two main types of

project management auditors are: Internal and external project management auditors.

For the purpose of this research, the CIPA study guide is the main authoritative reference on

project management auditing, based on its clarity and depth (as illustrated through the above

definition of project management auditing), and its global recognition (AllPM, 2003; IAAPM,

2008:7). The types of project management audit (what) and the types of project management

auditors (who) referred to in the in the CIPA study guide have now been explored. The next

section explores the project management audit process (how).

3.5.4 The project management audit process

The project management audit process is divided in four main steps, namely: Audit risk

assessment, planning, field work, and audit report (IAPPM, 2008:45).

The risk assessment step serves to identify audit risks, in view of meeting the audit needs in the

most efficient manner. The auditor subsequently engages in preliminary discussion with

representatives of the audited party, to survey company information and formalise the audit

scope. Undertaking the audit field work is the next step, which entails evaluating and

documenting existing systems of internal controls, based on the auditor’s observations, enquiries

and testing. Towards the end of the audit field work, a draft audit report is reviewed with

representatives of the audited entity, before a final audit report is issued to the audited party,

effectively signalling the end of the audit.

This four-step process to project management auditing not only complements the three-step

process previously discussed in section 3.5.1 “defining project management auditing”, but it also

enhance it considerably. These enhancements mainly reside in the fact that the four-step project


management audit process introduces audit risk assessment and planning as new steps, which

do not feature in the three-step process. The first two of the three-step project management audit

process (namely collect evidence and verify compliance) are summarised in the “field work” step

of the four-step process. Finally, the audit report in the four-step process corresponds to the

“communicate results” step of the three-step process.

The four-step audit process is illustrated in Figure 3.5.

Figure 3.5: Four-step process for auditing project management

The four-step process for project management auditing has contributed to enhancing the

previously identified three-step process (see Figure 3.4). Figure 3.6 below juxtaposes the two

processes and reflects not only the overlaps between them, but also the value added by the four-

step process. On the one hand (three-step process) the process of project management auditing

begins with independent collection of project management evidence, followed by verification of

the compliance between collected evidence and set standards, and ends with communication of

the audit findings. On the other hand (four-step process), the audit process begins with audit risk

assessment, which results in a Risk assessment report; the second step entails the planning of

the project management audit, resulting in and audit plan; the third step is fieldwork, resulting in

audit questions, audit answers and best practices; the last step is about communicating audit

findings, in the form of an audit report.

Audit risk

assessment

Plan project

management audit

Field work

Communicate audit

findings

Risk assessment

reportAudit plan

Audit questions

Andit answers

Best practicesAudit report

Independently

collect PM evidence

Verify compliance of the evidence

with set company or industry

standards

Figure 3.6: Expanded process for auditing project management

This literature review has provided the understanding of auditing and its relevance to project

management. The acquired understanding has strengthened the researcher’s contention that

investigating project management auditing is a relevant endeavour. The research findings should

therefore add value to the existing project management body of knowledge. This is especially

true, considering that the CIPA study guide reviewed above makes strong references to areas


which this research intends to focus on in the next chapters, namely project management

(IAPPM, 2008:30) and IT governance (IAPPM, 2008:27).

The next section concludes this chapter and introduces the next chapter.

3.6 Conclusion

This chapter has reviewed and evaluated critically the relevant literature on auditing. Firstly, the

chapter explored the evolution of auditing. Secondly, the chapter identified some auditing

standards, and a widely adopted auditing standard was evaluated critically, in relation with the

objective of this chapter. Lastly, the chapter explored project management auditing.

The study of relevant auditing literature revealed that auditing is an established profession which

has been in existence for centuries. However, it is in recent centuries that the auditing profession

gradually took the shape in which it is currently known. The major developments observed during

this time included firstly that the auditor’s role was gradually formalised. The second development

observed was the creation of professional bodies, in response to the realisation that the work of

auditors was far too important to be left to individuals with limited experience or training. The third

phenomenon observed through this literature review was that auditing, during this period, focused

solely on fraud detection (Wolf, 1997:2; Arter, 2003a:1).

Auditing evolved in the first half of the twentieth century, and so did the above tendencies. For

example, the focus of auditing gradually shifted from fraud detection to providing an opinion on

the financial statement of an organisation (Basu, 2009:3). Another notable change during this

period, as Boynton & Kell (1996:9) note, was that the auditing profession started doing away with

the detailed verification of accounts, in favour of sampling as a basis for the auditor to render his

opinion on the fairness of financial statements. However, this latter tendency has not been

without controversy in the auditing profession, as the auditor is still largely expected to focus on

detecting fraud (ibid.)

The review of auditing literature has also revealed that while it is correct to consider auditing

merely as a formal verification of records (Badiru, 1995:150), auditing is in actual fact a more

elaborate process. This process entails the collection of evidence, some comparison between the

collected evidence and certain criteria set in advance, and the communicating results found

(O’Reilly et al., 1999:4; Raffa, 2003).

Several types of auditing have been identified in the literature, including financial, compliance,

operational, information systems, follow-up, first-party, second-party, third-party, systems, and

product audit. This variety in terminology does not necessarily mean that all these types of audit


are radically different. In fact, some of these are practically synonymous; but most importantly, it

emerged that all these audit types can be grouped into two main audit types, namely internal and

external audits (Boynton & Kell, 1996:839; Woolf, 1997:62; Hall, 2000:4; Hall & Singleton, 2005:4;

Gray & Manson, 2005:564). Consequently, it was also established that the main types of auditors

included internal and external auditors.

The above-mentioned literature review on auditing and auditors explored the fundamental

questions of what and who. It become evident that the how was yet to be explored. This led to

identifying auditing standards, which constitute guidelines to auditors as they perform audits. The

auditing standards found in the literature include the generally accepted auditing standards

(GAAS), the practice standards for internal auditors, and the generally accepted government

auditing standards (GAGAS). While this literature review acknowledged the existence of other

standards, it focused mainly on the generally accepted auditing standards (GAAS). This decision

was informed by the global recognition and adoption of GAAS in the auditing profession (Boynton

& Kell, 1996:840; Siegel & Shim, 2006:482).

As this research intends to propose an audit model in the field of project management, it was

necessary to also direct this literature review towards project management auditing. Similarly to

the literature on generic auditing, the literature on project management auditing revealed that

although several types of project management audit exist (e.g. assessing companies, internal

control reviews, pre-implementation reviews, preliminary assessments, contracted third-party

substantive work, training, contract reviews and other reviews), each of these types can be

classified as internal or external project management audit. Consequently, project management

auditors were also classified as either internal or external project management auditors.

As with generic auditing, after identifying what and who, it became necessary to explore the how,

which entailed reviewing the applicable literature on the project management auditing process.

This review identified a four-step process, including audit risk assessment, planning, field work,

and the audit report. This four-step process adds value to this research by enhancing the already

identified three-step process for generic auditing. The four-step audit process is illustrated in

figure 3.5 in comparison to the three-step process.

This chapter has therefore successfully achieved its goal of reviewing and critically evaluating the

literature on auditing. The next chapter is a literature review on project management.

_____________________________________________________________________ Chapter 4 – Literature Review on project Management 58

4 CHAPTER 4 – LITERATURE REVIEW ON PROJECT MANAGEMENT

4.1 Introduction

4.1.1 Background

This literature review examines project management, to identify distinct constituents of projects.

These constituents or components should therefore a checklist of aspects against which a project

management audit should be conducted. This literature review addresses the second objective of

this research, as highlighted under heading 1.1.3 “Research Objectives”, namely to explore

project management through literature review.

A significant contribution should be made to this research, through exploring existing project

management best practices. The ultimate value of this literature review lies in providing a

structured discussion and understanding of project management, from the perspective of project

components to take into account, in a project management audit situation. The next section sets

the goals and objectives of this chapter.

4.1.2 Goal

The goal of this chapter is to identify project components and review recognised project

management good practices. In order to meet this goal, the following objectives need to be

achieved.

4.1.3 Objectives

� Objective 1: Explore the evolution of project management over time, to its current state.

� Objective 2: Review project management and identify the particular components of a

project, which should be taken into account when auditing project management.

� Objective 3: Identify recognised project management best practices, and further review at

least one of them.

4.1.4 Layout

The remainder of this chapter is laid out as follows: the first section reviews the evolution of

project management over time, to its current state. This review intends to highlight some of the

major milestones contributing to the development of project management into the shape in which

it is currently known. The second section identifies a set of project components to take into

account when conducting a project management audit. The third section reviews literature on


recognised project management best practices. The last section concludes the chapter and

summarises key emerging issues.

4.2 Brief historical overview on project management

As one observes the organisation leading to the building of great monuments from ancient

civilisations, such as the ancient cities of Mesopotamia, or the pyramids of Egypt, there is reason

to believe that some form of project management was involved. This, in turn, would lead to

believe that project management already existed in some or other way, that far back in history.

Literature concurs with this view that project management is not a new practice (Lock, 2007:1;

Stober & Hansman, 2009:15; Morris, Pinto and Soderlund, 2011:16).

These ancient milestones, for the purpose of this discussion, are situated in the period before the

twentieth century. Projects were then managed by the architects and creative engineers

themselves; workers were then nothing more than cheap and expandable resources, and the job

was done through sheer hard work (Lock, 2007:2). Thus, project management was not

recognised as a formal practice or profession during that time.

The years from 1900 to 1949 were marked by rapid industrialisation and the demand for

ammunitions for World War II, which saw the emergence of management scientists and industrial

engineers, who studied people and productivity in factories (Lock, 2007:2). Frederick Winston

Taylor’s study of people and productivity in factories is one such example (Lock, 2007:3). It

becomes apparent here that management had evolved from the perspective of merely throwing

cheap resources at the task, in order to get the job done anyway, to the more intelligent approach

of getting the job done more efficiently. During this period, significant management landmarks

were reached, such as Henry Ford’s production line manufacture (idem).

This trend to bring a scientific approach to management became evident in project management

as well. Some of the main project management milestones in this period include Adamiecki’s

harmonogram (vertical chart) in 1903 (Morris et al, 2011:16); Gantt’s bar chart in 1917 (Schwalbe,

2009:27); the emergence of the formal project coordinator role in the in US Army Corps in the

1920’s; project engineers and project officers in engineering companies in the 1930’s; and the

introduction of the matrix organisations by Gullick in 1936 (Morris et al, 2011:16).

The above milestones have hugely contributed to recognition of project management, as a formal

discipline, around the 1950s (Lock, 2007:3; Cleland & Gareis, 2006:1-4). One distinctive feature

of this period was the development of techniques for planning and controlling schedules and

costs (Kloppenborg, 2009:5). This is exemplified by the US Navy’s adoption of modern project

management methodologies, namely for their Polaris project (Carayannis, Kwak & Anbari,


2005:1). It can therefore be inferred that, like management, the emergence of formal project

management has been progressive.

Experts still debate on whether project management is, or should be recognised as a separate

profession (Morris et al, 2011:15), but for the purpose of this research, it suffices to note that

project management became a formally recognised practice in the 1950s.

The late 1960s and the 1970s were marked by the emergence of project management

associations, and the proliferation of project management software (Lock, 2007:3). The Project

Management institute (PMI) was founded during this period (1969), in an attempt to foster the

profession of project management through education, certification, creation and promulgation of

standard, and sponsorship of professional meetings (Mooz, Forsberg & Cotterman, 2003:61).

The emergence of high-powered computers followed, bringing capabilities to run powerful project

management software and more intuitive colour graphical user interfaces, in the 1980s. This era

marked the emergence of sophisticated project management practices (Lock, 2007:4). It

therefore appears that Information Technology (IT) started to have its influence on project

management between the 1960s and the 1980s. One can therefore surmise that IT project

management was born during this period.

This progressive evolution continued into the 1990s and 2000s, as project management became

firmly established as a respected discipline. Some of the phenomena observed during this era

included flourishing project management associations, computer-based applications, and a

growing interest in project risk (Lock, 2007:2).

The above evolution shows undeniably that project management has matured over time. Modern

project managers therefore have innumerable lessons to learn from this progressive evolution,

and certainly a role to play in further maturing project management. It is in this light that this

research attempts to contribute specifically to the auditing dimension of project management.

The above-mentioned evolution is summarised in table 4.1.


Table 4.1: The evolution of project management

Evolution of project management

Approximate Period Description

Projects managed mainly by architects and creative

engineers

Project management is not a formally recognised

discipline

Before the 20th Century

Project success depends mainly on hard work

performed by as many cheap resources as possible

More scientific approach to project management 1900 – 1949

e.g. Creation of Gantt chart

1950 – 1960 Project management recognised as a formal

discipline

1960 – 1980 Emergence of project management associations

Growing influence of Information Technology on

project management

1990 – 2010 Project management becomes a firmly established

and respected discipline

Having explored the evolution of project management, the next section defines a project and

project management.

4.3 Defining project management

It seems necessary to understand what a project is, before further exploring project management.

It has been observed, during the review of relevant literature that authors tend to discuss the

notion of a project, as an introduction for further discussing project management (Kerzner,

2001:2; Nicholas, 2004: 4; Phillips, 2007:14; Project Management Institute, 2008; Schwalbe,

2009:4). This trend underlines the importance of understanding what a project is, and

consequently dictates that this review focuses first on literature relating to projects.

4.3.1 Defining a project

The guide to the Project Management Body of Knowledge (PMBOK® Guide) defines a project as

a temporary endeavour to create a unique product, service or result (Project Management

Institute, 2008). This is echoed by other project management authors (Schwalbe, 2009:4; Phillips

2007:14). The words “temporary” and “create” are central to this definition. The temporary nature

of a project alludes to the fact that a project has a definite start and finish. This notion refers to

time, and therefore highlights time as a first component of a project.


The definition of a project also suggests a creative endeavour, which focuses on delivering

specific result. The PMBOK® Guide refers to these results as deliverables, defined as a unique

and verifiable product, result or capability to perform a service (Project Management Institute,

2008). It can therefore be accepted that deliverables are a second components of a project.

It also appears that projects need to create deliverables within certain boundaries or constraints.

These constraints, according to Dobson (2004:7) and Schwalbe (2009:8), include scope, time

and cost. These authors contend that scope refers to all the work that needs to be done, in order

to produce the required deliverable; time, on the other hand, refers to how long it should take to

complete the project; lastly, cost refers to the monetary worth of the resources required to carry

out the project.

The review of the literature also identifies Quality, which is defined as the degree to which a

project fulfils requirements, as a fourth project constraint (Rose 2005:6; Dinsmore & Cabanis-

Brewin, 2006:2) also advocate that creating quality deliverables is an important requirement in a

project. This shows a relationship between quality and project requirements, in the sense that

conformance to requirements is a key aspect of project quality. It can therefore be said that a

project should not simply be concerned with creating deliverables, but doing so in conformance to

project requirements. Requirements should then be considered as another key component of a

project.

The PMBOK® Guide defines project requirement as “…a condition which must be met or

possessed by a product, service or result, in order to satisfy imposed specifications, and

expectations from project stakeholders…” (Project Management Institute, 2008). According to this

literature review, “result” in this latter quote can also mean “deliverable”. However, this latter

definition highlights the following as additional components of a project: specifications and

stakeholders.

Specifications are defined (Project Management Institute, 2008) as “…a document describing in a

complete, precise and verifiable manner, the requirements of a deliverable and often the

procedures to determine whether these requirements have been met…”. It is interesting to note,

from this definition, that specifications are linked to requirements.

Stakeholders are defined as the individuals and organizations who are involved in the project, or

whose interests are directly or indirectly affected by the project (Project Management Institute,

2008; Saladis & Kerzner, 2009:172). One can appreciate the clarity offered by Nicholas (2004:90)

on stakeholders, as he states that these are “…anyone who is affected by the project, and can

potentially alter its outcome…”. In this category can be found the project sponsor, project


manager, project team and project customers; and there can be many more stakeholders. As was

the case for other project components of a project, there also appears to be a distinct link

between stakeholders. For example, the project sponsor works with the project management

team to typically assist with issues such as project funding, clarifying scope questions, and

influencing other stakeholders for the benefit of the project (Project Management Institute, 2008).

The project manager (named above as a stakeholder) is the individual assigned the responsibility

to ensure that the project deliverables meet the requirements. In fact, it would be an

understatement to simply say that the project manager is responsible for the project meeting its

requirements. Accountability and absolute dedication are also expected from the project

manager, as advocated by Nicholas (2004:11). Thankfully, for all the responsibility, accountability,

and absolute dedication expected of them, project managers are usually not expected to single-

handedly make the project successful. To this end, project managers generally have a group

performing the actual project work. This group is referred to as the project team (Project

Management Institute, 2008).

The project customer (another stakeholder mentioned above) is the person or organisation that

will use the project’s deliverable (Project Management Institute, 2008). The above descriptions of

various stakeholders provide ample illustration of the various links between components of a

project. For example, the project sponsor definition highlights a link between stakeholders and

cost; the project sponsor definition highlights a link between stakeholder and scope; and so on.

Considering the Project Management Institute’s (2008) assertion, which confirms Squire & Van

der Tak (1975:15) initial suggestion that projects often have limited resources, such as skilled

personnel, equipment, supply and funds, at their disposal, it appears that resources are definitely

a project component too. These would include human resources (the people working on a

project) and non-human resources (other resources such as equipment, supply and funds). This

description also shows that project resources do not exist in isolation from other identified project

components. For example, a link can be seen between project resources and stakeholders

(skilled personnel are both a stakeholder and a resource to the project), or budget (project funds

are a resource).

Howell (2009:17) further illustrates these relationships when he describes a project as having

“dedicated resources, a single point of responsibilities, clear boundaries within which resources

and deliverables move, and limited duration”. A link appears from this description, between

resources and other identified project components, namely the project manager (single point of

responsibilities), scope (boundaries), deliverables, and time (limited duration).


From the above, it can be said that the following are key components of a project: deliverables,

time, scope, cost, quality, requirements, specifications, stakeholders, and resources.

An important observation from the above is that these components do not only form the key

constituents of a project, but they are also inter-related, as illustrated above on numerous

occasions. It must also be stated that this literature review did not encounter evidence suggesting

that the above list of project components is exhaustive. In fact, the researcher believes that

further literature review would yield more components. However, for the purpose of this research,

these components shall suffice.

These nine project components are illustrated in Figure 4.1.

Cost

Specifica

tions

Resources

Figure 4.1: Project components

Having reached an understanding of what constitutes a project, the next section focuses on

project management.

4.3.2 Defining project management

Several attempts to define project management were reencountered in the literature. Most of the

literature reviewed (Kerzner, 2001:3; Frigenti & Comninos, 2002:38; Lewis, 2006:8; Lewis,

2007:4; Schwalbe, 2009:10 ) explicitly refers to, and consequently align with, the Project

Management Institute’s definition (2008), which states that project management is “…the

application of knowledge, skills, tools and techniques to achieve project requirements…”. Based

on this wide consensus in the literature, the PMI’s definition is considered as the authoritative

one, for the purpose of this research. For this reason too, much of the review on project


management is focused on the PMI literature, particularly the PMBOK® Guide, fourth edition,

which is the most recent at the time of this writing.

The said definition highlights knowledge, skills, tools and techniques. These will therefore be

considered, for the purpose of this research, as main components of project management. The

next section delves into each of these components.

4.3.2.1 Knowledge

The PMBOK® Guide describes “knowledge” as understanding something with the familiarity

gained through experience, education, observation or investigation (Project Management

Institute, 2008). This idea of knowledge in connection with project management inevitably brings

to mind the concept of knowledge areas. A knowledge area is an identified area of project

management defined by its knowledge requirements and described in terms of its processes

(Project Management Institute, 2008). The PMBOK® Guide predicates forty two project

management processes, across nine knowledge areas. Grouping project management processes

in terms of the knowledge required (knowledge areas) is one way of understanding the said

processes.

However, as the project progresses from its inception to its effective end, there appears to be

some similarities among certain processes. Thus, the PMBOK® Guide has grouped similar

processes in a logical way, for ease of consistent application (Dinsmore & Cabanis-Brewin,

2010:27). This second way of understanding project management processes complements the

above-mentioned knowledge areas. Thus, the forty two project management processes are

grouped in five categories, referred to as process groups (Project Management Institute, 2008;

Schwalbe, 2009:78).

For the purpose of this research, process groups and knowledge areas therefore encompass the

main knowledge required for project management. The next section discusses skills.

4.3.2.2 Skills

The Project Management Institute (2008) advances that skills as the ability to use knowledge.

Additional attributes used in lieu of skills include proficiency, ability or dexterity (Cleland & Ireland,

2010:12). As a component of project management, skills therefore refer to the ability of the

project manager to be proficient and demonstrate dexterity across the nine knowledge areas,

throughout the five process groups.

The necessary skills required of a project manager are identified in the Project Management

Competency Development framework (PMCD). Project manager skills are often associated with


knowledge, attitudes and behaviours - collectively referred to as competence (Project

Management Institute, 2007). Project management competence can be viewed in three separate

dimensions:

� Project management knowledge: What the project manager knows about project

management.

� Project management performance: What the project manager is able to accomplish while

applying project management knowledge.

� Personal competency: The behaviour, attitudes and personality traits of the project

manager while performing the project.

In order to be considered as competent, a project manager would need to possess the right

combination of knowledge, performance and personal competence (Project Management

Institute, 2007).

The next section discussed Tools and techniques, as the final component of project

management.

4.3.2.3 Tools and techniques

A project management tool is something tangible, such as a template or a software program,

used to create a project deliverable; a technique, on the other hand, is a defined systematic

procedure employed by people in a project towards creating a project deliverable (Project

Management Institute, 2008). Project management tools and techniques consist of the methods

available to assist the project manager and the project team in carrying out a project (Schwalbe,

2009:12). Each project management knowledge area has corresponding project management

processes consisting of one or more tools and techniques to transform inputs into outputs. The

PMBOK® Guide therefore recommends several tools and techniques for project management.

As was the case during the review of project components, there appears to also be links between

the three identified project management components. For example, knowledge is linked to skills,

as skills in a project manager represent his/her ability to use knowledge. Knowledge is also linked

to tools and techniques, as there are tools and techniques (methods, templates, software

programs) applicable to each process group across the nine knowledge areas. Tools and

techniques are also linked to skills, in the sense that effective use of tools (methods, templates

and software programs) in project management across the nine knowledge areas has a lot to do

with the project manager’s and project team’s proficiency in using these tools in the first place.

These three project management components are illustrated in figure 4.2 below:


Figure 4.2: Project management components

The above discussion has shed some light on project and project management components, as

well as skills expected of the person conducting the project management function – the project

manager. The next section explores how project management should be conducted. To this end,

different perspectives are reviewed, through the review of recognised repositories of project

management best practice.

4.4 Project management best practices

In recent decades, several project management organisations have been formed across the

world. Some of these organisations have developed repositories of project management best

practices. Cagle (2005) identifies the following as notable examples: In Australia, the Australian

Institute for Project Management (AIPM) developed the national Competency Standard for

Project management (NCSPM); in Great Britain, the Association for Project Management (APM)

developed the PRINCE methodology, later updated as PRINCE 2; the International Project

Management Association (IPMA) was created by the APM and sets standards for participating

organisations all over the world; the Project Management Institute developed the guide to the

Project management Body of Knowledge (PMBOK® Guide) for the United States and many

countries throughout the world; in South Africa, the Project Management South Africa (PMSA) is

one of the main project management organisations representing project managers across

industries, in line with the PMI (PMSA, 2010).

These organisations have generally developed on a geographical basis, mainly due to the fact

that each country might have its own qualification and certification requirements. However, in

recent years there has been a tendency among these organisations to extend their respective

spheres of influence beyond their countries of origin. Consequently, a highly competitive

environment has been created between these organisations, namely for membership and

certification (Cagle, 2005).


APM certifications are designed to meet the needs of a project manager throughout their career.

APM certifications are also aligned with IPMA’s 4-level certification programme. The AIPM

certification is aligned with the Australian Qualification Framework (AQF) and based on individual

assessment against National Competency Standards for Project Management (NCSPM) (PM

Forum, 2010). However, the PMI certifications are not based on any specific methodology

(Project Management Institute, 2010). For this reason, the PMI certifications should be flexible

and adaptable between industries, market segments and geographic locations. It is evident that,

while there appears to be complementarities between the various project management

certifications, each organisation strives to propose a unique value to attract membership.

It is striking to note that while many organisations seem to have had declining memberships, the

PMI has grown steadily over the recent decade or so (Schwalbe, 2009:1; Moustafaev, 2010:23).

The PMI is considered to be the first organisation to recognise the need for formal project

management, through the first publication of the PMBOK® Guide (Cagle, 2005; Ohara, 2010). As

a recognised standard for the project management profession and an industry-accepted,

authoritative source of project management information (Ibbs & Kwak, 2000:32), the PMBOK®

Guide can be said to represent the sum of knowledge within the project management profession

(Project Management Institute, 2008). For the above reasons, this review of project management

best practices focuses on the PMBOK® Guide.

4.4.1 A Guide to the Project Management Body of Knowledge (PMBOK® Guide)

Having identified the PMBOK® Guide as an authoritative literature on project management, this

section surveys relevant literature. An attempt is then made to present the understanding

emerging from this review, as a basic framework on how projects should be managed. This basic

framework should, in turn, inform an auditor on how to proceed in auditing project management.

This section fully acknowledges a word of caution from Stackpole (2010:1), who advocates that

the PMBOK® Guide, as a standard, merely identifies what is considered to be good practices in

managing projects, as opposed to prescribing how these practices should be implemented. In

fact, this principle raises a debate on the use of the phrase good practices as opposed to best

practices; the former phrase, according to Stackpole (2010:1), refers to generic situations, while

the latter tends to refer to a specific industry or organisation. For the purpose of this research

however, these two phrases will be used interchangeably.

The PMBOK® Guide’s content is centred on the forty-two project management processes,

mapped across the nine knowledge areas and five process groups (Saladis & Kerzner, 2009:1).

This suggests that project management processes constitute an essential part of the PMBOK®


Guide content. For this reason, and for the purpose of this research, processes will not be

discussed individually. The focus will rather be directed towards understanding how the PMBOK®

Guide views what constitutes a project management process.

A process is a set of inter-related actions and activities, involving inputs, tools and techniques that

can be applied, and resulting outputs (Project Management Institute, 2008). Inputs are those

ingredients needed to complete a process and bring about outputs (Saladis & Kerzner, 2009:15).

A tool is something tangible, such as a template or software program, used to manipulate the

input towards producing the outputs (Stackpole, 2010:2); an output is the product, result, or

service generated by a process (idem). While the above-mentioned appear to constitute discrete

components of a process, there is a distinct flow of data from input to output. This flow continues

beyond individual processes, in the sense that outputs from one process often become inputs into

the next process (Stackpole, 2010:17). This basic relationship between process components is

pictured in figure 4.3.

Figure 4.3: Process components

The relationship between process components, illustrated in Figure 4.3, applies to each of the

forty-two project management processes. If one considers, for example, the Develop Project

Charter process, the following can be observed:

The project initiator or sponsor brings input into the process, namely the contract, the project

statement of work, and the business case; the organisation or the enterprise brings organisational

process assets and enterprise environmental factors into the process as inputs. The project

statement of work describes the end-product to be produced by the project, and can be part of

the contract, if the work is done by an external organisation (Stackpole, 2010:18). The business

case provides the justification for whether the project is worth investing in (Project Management

Institute, 2008).

The organisation or enterprise contributes with organisational process assets and enterprise

environmental factors as inputs into the process. Organisational process assets constitute the

formal and informal means that help people understand, follow, and improve business processes

in a specific organisations (Schwalbe, 2009:146); enterprise environmental factors are critical


factors to be considered when deciding which projects should be approved (Saladis & Kerzner,

2009:15), including factors such as the organisation’s structure, culture, infrastructure, human

resources, personnel policies, marketplace conditions, stakeholder risk tolerances, industry risk

information, and project management information systems (Schwalbe, 2009:146).

When developing a project charter, the project manager needs to make use certain tools and

techniques, such as consulting people with expert judgement on technical, business, or project

management areas (Stackpole, 2010:18). The project charter, which provides an initial

understanding of the need that the product, service or result will fulfil, is the output derived from

these inputs and tools and techniques. The project charter feeds into (in other words, constitutes

an input for) the next project management process, namely Develop Project Management Plan.

The project charter can also constitute an indirect input into other subsequent processes, such as

collect requirements, define scope, and identify stakeholders.

The above flow of data is summarised in the Figure 4.3 below:

Input

Direct Output

Indirect Output

Indirect Output

Indirect Ou

tput

Figure 4.4: Flow of data in the “Develop Project Charter” process (Source: PMBOK® -

Fourth Edition, p. 74)



4.5 Conclusion

This chapter has reviewed the relevant literature on project management. Firstly, project

management was explored in terms of the evolution from ancient history, to the twenty first

century. Secondly, the review focused on project management components, and identified

individual components against which project management audits should be conducted. Thirdly,

the review identified recognised project management best practices in the project management

literature. Lastly, a single best practice document was reviewed, in terms of its approach to

project management.

The project management literature reviewed in this chapter confirmed that project management is

not a novel practice (Lock, 2007:1; Stober & Hansman, 2009:15; Morris et al, 2011:16). Great

architectural achievements, such as the pyramids of Egypt, attest that some form of project

management was already applied that far back in history.

Before the twentieth century, projects were mainly managed by architects and creative engineers,

who got the work done by assigning as many cheap resources as possible on it (Lock, 2007:2).

The first half of the twentieth century saw a more scientific approach applied to project

management, in line with the general trend in management.

Project management then became formally recognised in the 1950’s (Lock, 2007:3; Cleland &

Gareis, 2006:1-4). The couple of decades following this recognition were marked by a growing

influence of IT over project management (Lock, 2007:3). This can be seen as the birth of IT

project management. Several project management associations emerged during this period. In

the past two decades leading to 2010, project management became firmly established and

recognised as a formal discipline.

In an effort to identify and understand project management components, the literature review has

first uncovered nine inter-related project component, namely: deliverables, time, scope, cost,

quality, requirements, specifications, stakeholders, and resources. Having understood project

components, the following three project management components were then identified and

reviewed: knowledge, skills, tools and techniques. These components constitute the various

aspects of a project to be considered in a project management audit situation.

Having identified the project management components, the literature then focused on project

management best practices, including the National Competency Standard for Project

Management, PRINCE 2, and the PMBOK® Guide.


The PMBOK® Guide was reviewed with particular emphasis, by virtue of its global recognition.

This review revealed that the PMBOK views project management as a succession of logically

arranged processes, mapped around process groups and knowledge areas. Each of these

processes receives some input from the previous process (except where there is no previous

process), uses the relevant tools and techniques, and delivers an output. This output is an input

for the next process.

This literature review has identified nine project components, three skill sets (or competencies)

required of the project manager, and a three-phase cycle through which project management

processes need to go through. The inter-relationship between these components has been

illustrated.

This list of components attests that the chapter has achieved its goal. The next chapter explores

IT governance.

_____________________________________________________________________ Chapter 5 – Literature Review on IT Governance 73

5 CHAPTER 5 – LITERATURE REVIEW ON INFORMATION TECHNOLOGY GOVERNANCE

5.1 Introduction

5.1.1 Background

The role of Information Technology (IT) departments is to support and enable the rest of the

organisation to meet the organisation’s objectives. For this reason, IT often consumes sizeable

portions of company budgets and other resources; yet IT has long struggled with providing the

level of service demanded by the business side of the organisation, resulting in a misalignment

between the organisation’s core business and the areas where most resources are invested (IT)

(Doughty & Grieco, 2005; ISACA, 2007; Wallace & Webber, 2008:4). To bridge this gap, sound

controls are needed within organisations, in order to manage how resources are allocated, how

changes are managed, and how services are delivered. Such controls constitute the essence of

Information Technology governance (Hoogervorst, 2009:11).

This literature review explores IT governance, in line with the third objective of this research, as

highlighted under heading 1.1.3 “Research Objectives”. This literature review intends to

contribute to this research by providing insight into the concept of IT Governance, its value, and

relevance to project management.

The next section sets the goals and objectives for this chapter.

5.1.2 Goal

The goal of this chapter is to gain an understanding of the main underlying principles of IT

governance. In order to meet this goal, the following objectives need to be achieved:

5.1.3 Objectives

� Objective 1: Review and evaluate different perspectives on IT governance.

� Objective 2: Identify and review IT governance sources and frameworks.

� Objective 3: Explore project governance and the relevance of governance in project

management.

5.1.4 Layout

The remainder of this chapter is laid out as follows: the first section reviews and evaluates

different IT governance perspectives found in relevant literature. This review intends to expand


the understanding of IT governance for the purpose of this research, by highlighting

complementarities and contrasts between various authors’ views on IT governance.

The second section surveys the literature, in order to identify recognised IT governance

frameworks. The discussion then focuses on one of these frameworks. The third section explores

the issue of governance, with particular relevance to project management. The last section

concludes the chapter and summarises key emerging issues.

5.2 Overview of IT governance

5.2.1 Defining IT governance

IT governance is an important subset of corporate governance and of governance as a whole

(Calder, 2008:148; Hunter & Tan, 2006:153). It is therefore necessary to briefly introduce the

concepts of governance and corporate governance, in order to better understand IT governance.

Chant & McIlwaine (2009:292), Davies (1999:3) and the Institute on Governance (IOG) (2009),

collectively agree that governance is a wide and complex subject, which can be difficult to capture

in a single, universally applicable definition. Of the many definitions of governance found in the

literature, some of the most poignant ones include that governance is:

� “…the process of decision-making and the process by which decisions are implemented,

or not implemented…” (UNESCAP, 2009).

� “…the process of reconciling between individual ambition and collective interest…”

(Davies, 2009:3).

� “…the act, manner, or function of governing, sway control…” (Oxford English Dictionary).

� “…how an institution or a state is run…” (IOG, 2009).

It appears from the above that governance is a process, rather than an event. Governance, unlike

management, is not about what decisions get made, but about who makes the decisions, and

how these decisions are made (Brisebois, Boyd & Shadid, n.d.). It also emerges from the above

definitions that decision-making and collective interest are central to the concept of governance.

Finally, it can also be inferred that good governance is, to a great extent, about ensuring

accountability within institutions or organisations.

When applied to companies, governance is known as corporate governance (Davies, 1999:2-7;

Du Plessis, McConvill & Bagaric, 2005:2). The emergence of scandals in the corporate sector

(such as Enron, WorldCom, Global Crossing, Arthur Andersen or Adelphia), coupled with a

growing culture of greed fuelled by capitalism, are some of the key factors that have contributed

to the growing interest in corporate governance (ISACA, 2007; Davies, 1999:2-7). Similarly to


governance, it is difficult to find a single, universally accepted definition of corporate governance

(Du Plessis et. al, 2005:2). Corporate governance refers to the system by which companies are

directed and controlled (King III, 2009; UK Cadbury Report, 1992).

While this definition is useful in beginning to understand corporate governance, it is still

somewhat vague. The Institute of Directors in South Africa provides more clarity when considers

corporate governance as a company’s strategic response to the need to assume prudent risks,

appropriately mitigated, in exchange for measurable rewards (King III, 2009). Corporate

governance, therefore, also refers to the legal organisation frameworks within which, and the

principles and processes by which, corporations are governed, controlled and held to account.

Every organisation has to determine, as part of its overall approach to corporate governance, how

it intends to govern the information, information assets, and information technology on which its

business model relies; this need has led to the emergence of IT governance (Calder & Watkins,

2008:2).

Calder and Watkins (2008:3) define IT governance as “…the framework for the leadership,

organisational structures and business processes, standards and compliance to these standards,

which ensures that the organisation’s information systems support and enable the achievement of

its strategies and objectives…”. This rather long definition implies that the IT governance

oversees the formulation and subsequent implementation of rules to ensure that IT enables the

business to achieve its goals. The Japanese Ministry of Economy, Trade and Industry (METI,

1999) supports this view, when it presents IT governance as the organisational capacity to control

the formulation and implementation of IT strategy and guide to proper direction for the purpose of

achieving competitive advantages for the corporation.

The above discussion shows firstly that governance focuses on generic controls. Secondly, it is

seen that as this control focuses on companies, it becomes corporate governance. Lastly, when

this control is narrowed down to IT within organisations, it is referred to as IT governance. Figure

6.1 illustrates this.


Figure 5.1: The Governance pyramid

The next section focuses on the importance of IT governance.

5.2.2 The importance of IT governance

IT governance can, and should, increase a company’s competitive advantage, as pointed out by

the METI (1999). Competitive advantage, according to Armstrong (2006:121), entails the

distinctive competence that keeps an organisation ahead of its competitors. Businesses with a

genuine need to stay ahead of their competitors can therefore not afford to overlook the

importance of IT governance. It is perhaps no coincidence that the interest in IT governance has

grown so much in recent times, as the competitiveness of the business environment has reached

unprecedented heights.

Most interestingly, IT governance has often been given less attention than most other corporate

governance issues, such as scrutinising business strategy, or strategic risks. This, Guldentops

(2004:271) notes, is due to reasons ranging from the unfortunate tradition of treating IT as

separate from the business, to the lack of technical insight to understand how IT affects the

business, to the sheer complexity of IT. However understandable these reasons may be, they

should be no excuse for top management to overlook IT governance, for the very important

reason that IT governance is key to competitive advantage. Top management, who have the

mandate to steer the company towards achieving competitive advantage, must therefore

overcome these impediments, and fully embrace IT governance as a priority.

When organisations fail to adhere to corporate governance, of which IT governance is a subset,

disasters are bound to happen. Enron and Worldcom are some of the most notable examples of

financial scandals, which happened due to bad corporate governance (ISACA, 2007; Davies,

1999:2-7). Consequently, by virtue of the link previously established between IT governance and

corporate governance, it is conceivable that these scandals must have resulted, at least partially,


from bad IT governance. Such failures resulted in unprecedented developments in the field of

governance, the most significant of which came in the form of the Sarbanes-Oxley (SOX) Act.

The SOX Act was specifically directed at corporate governance, not IT governance. However, as

Calder (2008:2) notes, the SOX Act has had considerable implications on IT.

Hunter and Tan (2006:151) also agree on the importance of IT governance, but they recognise

that it is not always been applied in the same way across organisations. They indicate that the

last two decades have seen the emergence of three major structures, namely the centralised,

decentralised, and hybrid IT governance structures.

In the centralised structure, the IT decisions are vested with the Board of directors and senior

management. This structure allows the organisation to benefit from the economies of scale and

scope by leveraging the planning process, acquisition, and deployment of IT resources. The

centralised structure also ensures a degree of uniformity in control procedures across the

organisation; however, centralised IT governance results in a certain lack of local control and

ownership at business unit level, which can create an impression of rigidity and irrelevance and

ultimately lack of genuine buy-in by the business units.

In the decentralised structure, IT decisions are made by the relevant business units. This

structure allow for decisions on IT systems to be made by the actual users of those systems,

which potentially increases the relevance and acceptance of the IT decisions made; however, the

decentralised IT governance structure may prove too costly since it does not leverage from the

economies of scale offered by the centralised structure. The decentralised structure also has the

risk of creating IT decisions which are not harmonised and integrated between separate business

units of the same organisation.

The hybrid IT governance structure attempts to combine the best of both centralised and

decentralised IT governance, by allowing for the Board and senior management to make overall

decisions on the IT infrastructure, while the business units make decisions regarding the actual

application of those decisions (Hunter & Tan, 2006:151).

Regardless of the structure employed in an organisation, the main value of IT governance should

be found in its ability to derive value from IT, in alignment with the business (Van Grembergen,

2004:57).

It can therefore be said that IT governance is absolutely vital for organisations, and organisations

with an IT governance strategy in place are set to perform better than those that do not have one

(Calder, 2008:1). The next section further dissects IT governance into its components.


5.2.3 IT governance components

Having previously introduced the concept and importance of IT governance, this section

discusses the components of IT governance. The literature offers ample frameworks shedding

light on IT governance components (Brand & Boonen, 2007:5; ISACA, 2007; OGC, 2007; Van

Bon, 2007; Wallace & Webber, 2008:4; Hightower, 2008; Calder and Moir, 2009:71). These

frameworks hold many similarities, but each of them has a unique way of presenting IT

governance components.

Calder and Moir (2009:71), for example, state that IT governance should be viewed as “a set of

principles, a decision-making hierarchy and an appropriate suite of reporting and monitoring

processes”. They further argue that IT governance should encompass seven components,

namely:

� IT governance principles and decision-making hierarchy;

� Information strategy;

� IT strategy;

� IT risk management;

� IT architecture;

� IT investment and project governance;

� Regulatory compliance and information security.

Each of these components is briefly discussed below:

5.2.3.1 IT governance principles and decision-making hierarchy

Calder and Moir (2009:78) propose six principles intended to guide decision making. These

include responsibility, strategy, acquisition, performance, conformance, and human behaviour.

Responsibility recognises that those responsible for IT within the organisation must have the

authority to perform the actions for which they are responsible. IT managers therefore need to be

given authority to take responsibility, but also to be held accountable for all IT decisions within the

organisation.

Strategy advocates the necessity for the IT strategy to align with business requirements. ISACA

(2007:24) echoes this view, by recognising strategic alignment of goals as a primary enabler for

IT governance.

Acquisition is a principle which argues that IT investment decision-making should be clear and

transparent. This principle further advocates an appropriate balance between cost and


opportunity, clear understanding of risk, and a view of both the short and long term. When

considering that IT project success rates are questionable (Labuschagne, Marnewick &

Jakovljevic, 2008), it appears absolutely vital that any IT investment should adhere to this

principle.

Performance refers to ensuring that the IT investment is fit for purpose (Calder & Moir, 2009:79).

This principle links back to the necessity, for IT projects, to meet specified requirements as

previously identified in Chapter 4, under heading 4.3.1 “Defining a project”.

Human behaviour emphasises that people are central to the success of any IT implementation. IT

policies, practices, and decisions, should be designed and implemented with particular attention

paid to the human beings who need to uphold and enforce them (Calder & Moir, 2009:79).

Humans (including the project manager, project sponsor, customer, project team) were already

identified as key stakeholders in IT projects, in Chapter 4, under heading 4.3.1 “Defining a

project”.

5.2.3.2 Information strategy

Information strategy of an organisation must be derived from the business strategy. It should deal

with “what information is required, where it comes from, and what will be done with it” (Calder &

Moir, 2009:72). These authors recognise the importance of IT governance, as an enabler for

competitive advantage, but organisations should be wary of thinking good IT governance and IT

systems are sufficient to ensure competitive advantage; an organisation should also have better

business processes than its competitor, in order to achieve competitive advantage (Cleveland,

2006).

5.2.3.3 IT strategy

The IT strategy component of project governance also emphasises the previously discussed

alignment between business and IT strategy (ISACA, 2007:6), as it argues that business strategy

should drive information strategy. The information required by the organisation should determine

the information systems needed; the information systems strategy should in turn determine the

technology strategy. Finally, the chosen technology should be suitable to the information

requirements of the organisation (Calder & Moir, 2009:21).

5.2.3.4 IT risk management

In order to survive in today’s competitive business environment, organisations need to continually

strive to stay ahead of the competition (Armstrong, 2006:121). However, organisations should do

so while minimising risks, as advised by Calder & Moir (2009:37), who recognise two major IT


risks, namely interruptions of business processes and customer service (caused by project failure

or unplanned disruption), and IT overspending. These two risks appear to be pertinent for the

purpose of this research, as they point to project components previously identified in Chapter 4.

The former risk relates to the quality component of a project, while the latter relates to the time

component. IT risks are certainly closely related to the IT strategy, but it should be noted that IT

risks can sometimes extend beyond the IT realm. Areas such as strategic risk can also be related

to IT risks, as noted by ISACA (2009), especially when IT is a key enabler of a new business

initiative.

5.2.3.5 IT architecture

As a component of IT governance, IT architecture considers two major questions. Firstly, how IT

hardware, software, applications and communication protocols are specified, developed,

authorised, acquired and managed; secondly, the architecture component of IT governance

considers what parts of IT should be outsourced, why, how, and to whom (Calder & Moir,

2009:73). As previously mentioned in the above discussion on information strategy, the IT

architecture also requires to be aligned with the business strategy (Monash University, 2010).

5.2.3.6 IT investment and project governance

IT investment needs to be done in line with the IT strategy, with particular considerations for

aspects such as the implementation, prioritisation, project management, change management on

the initiatives requiring the said investment (Calder & Moir, 2009:73).

Renz (2007:19) defines project governance as a “process-oriented system by which projects are

strategically directed, integratively managed, and holistically controlled, in an entrepreneurial and

ethically reflective, appropriate to the singular, time-wise limited, interdisciplinary, and complex

context of projects”. This complex definition is supported by a simpler, yet equally valid one, from

Garland (2009:11), who advocates that project governance, is the framework within which project

decisions are made. This concept of guiding decision-making aligns with the tenets of

governance and IT governance. The definition of project governance is therefore consistent with

the definitions of governance and IT governance previously established in this chapter.

Project governance stems from the realisation that the business environment today is so dynamic

that “original assumptions on which a project’s rationale were based can become fatally

undermined before the project has been completed” (Calder and Moir, 2009:61). This has meant

that projects, even though they may begin as IT projects, can quickly grow in scope and

ramifications to the point of influencing the entire business strategy of an organisation.


Consequently, organisations should manage projects with a governance approach, as opposed to

a stand-alone approach.

Muller (2007:5) presents project governance as a three-step process happening at three different

levels. At the first level, he considers what can be done (education); the second level deals with

what should be done (management demands), and the third level looks at what is actually done.

5.2.3.7 Regulatory compliance and information security

This component of IT governance considers the criteria for securing information, how legal or

regulatory compliance should be demonstrated or measured, how intellectual property is

protected, and what audits are required (Calder & Moir, 2009:38).

The above discussion has established that IT governance is a complex subject comprising of

multiple components. This list should not be exhaustive as it only represents one of the points of

views encountered in the literature. It should not be prescriptive either, as each organisation has

its unique business unique business strategy, to which the IT governance should align. The

identified components therefore provide a good understanding of things to consider when

implementing an IT governance framework. The table 6.1 summarises these components:

Table 5.1: IT Governance components

IT GOVERNANCE COMPONENTS

Co

mp

on

en

ts

Principles and

decision

making

Information

strategy

IT strategy

IT risk

management

IT architecture

IT investment

and project

governance

Regulatory

compliance

and

information

Fo

cu

s a

rea

s

1. Responsibility

2. Strategy

3. Acquisition

4. Performance

5. Conformance

6. Human

behaviour

1. Business

strategy

2. Business

processes

1. Business

strategy

2. Info

strategy

3. Info

systems

4. Technology

strategy

5. Information

requirements

1. Service

interruptions

2. Process

interruptions

3. IT

overspending

4. Strategic

risk

1. Hardware

2. Software

3. Applications

4. Communications

protocols

5. Service

outsourcing

6. Business

strategy

1. IT strategy

2. What can be

done

3. What should

be done

4. What is done

1. Intellectual

property

2. Audits

The next section reviews existing IT governance frameworks.


5.3 IT governance sources

There are several IT governance sources. The following are among the most recognised ones:

� Control Objectives for Information and related Technologies (COBIT) (ISACA, 2007;

Tarantino, 2008; Wallace & Webber, 2008:5).

� Committee of Sponsoring Organisations (COSO) of the Treadway Commission

(Tarantino, 2008; Wallace & Webber, 2008:5).

� Information Technology Infrastructure Library (ITIL) (OGC, 2007; Tarantino, 2008;

Wallace & Webber, 2008:5).

Each of these IT frameworks is briefly discussed below:

COBIT is a set of best practices for IT Management and control framework developed by the

Information Systems Audit and Control Association (ISACA), in order to support professionals

whose job was auditing controls in the computer systems (Brand & Boonen, 2007; ISACA, 2007).

COBIT is internationally accepted as a control framework, enabling organisations to implement an

IT governance structure throughout the enterprise (Gudentops, 2004:270; ISACA, 2007). Many

corporations and government organisations have adopted COBIT throughout the world, since its

first release (McLane, 2003:7).

The Committee of Sponsoring Organisations of the Treadway Commission (COSO) is a

framework originally developed to sponsor a private sector initiative in studying the causes of

fraudulent financial reporting by public companies. It is the basis for COBIT’s professional

standards for internal controls (Wallace & Webber, 2008:4). These include processes, affected by

an entity’s Board of Directors, management or other personnel, designed to provide reasonable

assurance about the achievement of objectives in effectiveness and efficiencies of operations, as

well as in reliability of financial reporting (Ratcliffe & Landes, 2009). The COSO framework

recognises that a company must first have an appropriate set of financial reporting objectives in

place. At a high level, the objective of financial reporting is to prepare reliable financial

statements, which involves attaining reasonable assurance that the financial statement is free

from material misstatements. An integral part of internal controls is the auditor’s ability to

establish whether the set control objectives were achieved (Ratcliffe & Landes, 2009).

The Information Technology Infrastructure Library (ITIL) is an integrated collection of best

practices used by successful companies as a guideline for efficient IT operations (Tarantino,

2008:164; Van Bon & Pieper, 2008:14). As a strict and practical approach to the identification,

planning, delivery and support of IT services to the business, ITIL is the most adopted IT service

management framework in the world (OGC, 2007; Arraj, 2010). ITIL was developed in recognition


of the fact that organisations are increasingly dependent on IT to meet their corporate objectives.

ITIL aims to provide customers with services that are fit for purpose and reliable (OGC, 2007).

None of these frameworks is perfect. ITIL for example, is often criticised for the its lack of holistic

and visible links between theory and practice; this criticism is specifically levelled at the fact that

ITIL has an extensive focus on what should be done and not sufficient focus on how things

should be done (Bider, 2010:110). To some extent, the COBIT framework has also been subject

to the same criticism (iSeries, 2004; Skyview Partners, 2004). The main shortcoming of COSO is

that it does little to prevent fraud and risk failures, as most these fraud cases happen at executive

and board level – situated above the internal controls which COSO is designed to address

(Tarantino & Cernauskas, 2009:312).

Other sources for IT governance include ISO 17799:2005, ISO 27001:2005, Prince 2, OPM3,

Balanced Scorecard, Six Sigma, ISO 20000 and the CMMI / /SPICE (ISO/IEC 15504) (Brand &

Boonen, 2007:5; ISACA, 2007; Calder, 2008; Tarantino, 2008). While some of these sources are

referred in the literature as frameworks, most of them rather constitute input into IT governance

frameworks. Nothing in the literature suggests that this list is exhaustive. Nonetheless, it suffices


Among the above-mentioned frameworks, COBIT is the most widely accepted (Gudentops,

2004:270; ISACA, 2007). For this reason, it is necessary to devote a section to COBIT.

5.4 COBIT as an IT governance framework

5.4.1 Brief historical overview and current perspectives

In 1967, the Information Systems Audit and Control Association (ISACA) was founded to support

professionals whose job was auditing controls in the computer systems, in an attempt to create a

centralized source of information and guidance in the field. It was not until 1969 that this group

formalized, incorporating as the EDP Auditors Association (ISACA, 2009). ISACA maintains a

research organisation called IT Governance Institute (ITGI), to continually research contemporary

issues on IT Governance. Among the documents published by the ITGI, is the Control Objectives

for Information and related Technologies framework – COBIT (ISACA, 2007, Jenkins, 2008).

COBIT was developed to provide a reference framework for management, users, auditors and

security practitioners (ISACA, 2007; Tipton & Krause 2007; Maizlish & Handler 2005).

When originally released in 1992, COBIT was meant to serve as an IT process and control

framework, linking Information Technology (IT) to business requirements. In 1998, management

guidelines were added to the COBIT framework and, as a result, it became increasingly used as

a management framework, providing management tools such as metrics and maturity models to


complement the control framework. In 2005, the fourth version of COBIT was published, which is

more closely aligned to, and harmonized with other standards (such as ITIL, ISO 17799, PMBOK

and Prince 2). ISACA (2007) claims that this forth version has a stronger business orientation

(ISACA, 2007), which reinforces a prior affirmation, by Ridley, Young and Carroll (2004) that

COBIT is “…arguably the most appropriate control framework to help an organisation ensure

alignment between use of information technology (IT) and its business goals...”.

The next section discusses the structure of COBIT is more detail.

5.4.2 What is the COBIT framework?

This section explores how COBIT, as an IT governance framework, is organised. As a result of

this exploration, the underlying control mechanism in COBIT will be highlighted. This discussion

involves firstly the basic structure of COBIT, secondly the COBIT approach, and lastly the COBIT

control mechanism.

5.4.3 COBIT structure

The basic structure of COBIT entails three interrelated view points, namely: IT processes, IT

resources, and quality criteria (Brand & Boonen, 2007:25; ISACA, 2007). Each of these view

points is described in the following paragraphs, starting with IT processes.

5.4.3.1 IT processes

The “IT processes” side of COBIT entails domains, processes, and activities. COBIT processes

are organised in four domains, namely:

� The Plan and Organise (PO) domain, which is concerned with identifying how IT can best

contribute to the achievement of business objectives;

� The Acquire and Implement (AI) domain, which is concerned with identifying, developing

or acquiring, implementing, integrating, and maintaining existing systems to ensure that

the solutions continue to meet business objectives;

� The Deliver and Support (DS) domain, which is concerned with the actual delivery of

required services. This includes service delivery, management of security and continuity,

service support for users, and management of data and operational facilities; and

� The Monitor and Evaluate (ME) domain, which is concerned with the regular assessment

of all IT processes over time for their quality and compliance with control requirements,

including performance management, monitoring of internal control, regulatory

compliance, and governance.


Each domain contains a number of processes, as listed in table 5.2. More detailed discussion of

these processes can be obtained from ISACA (2007:29) or Brand & Boonen (2007:25).

Table 5.2: The four COBIT domains and their IT processes

Plan and Organise (PO) Deliver and Support (DS)

PO 1: Define a strategic IT plan

PO 2: Define the information architecture

PO 3: Determine the technological direction

PO4: Define the IT processes, organisation and relationships

PO 5: manage IT investment

PO 6: Communicate management aims and direction

PO 7: Manage IT human resources

PO 8: Manage quality

PO 9: Assess and manage IT risks

PO 10: Manage projects

DS 1: Define and manage service levels

DS 2: Manage third-party services

DS 3: Manage performance and capacity

DS 4: Ensure continuous service

DS 5: Ensure systems security

DS 6 : Identify and allocate costs

DS 7: Educate and train users

DS 8: Manage service desk and incidents

DS 9: Manage the configuration

DS 10: Manage problems

DS 11: Manage data

DS 12: Manage the physical environment

DS 13: Manage operations

Acquire and Implement (AI) Monitor and Evaluate (ME)

AI 1: Identify automated solutions

AI 2: Acquire and maintain application software

AI 3: Acquire and maintain technology infrastructure

AI 4: Enable operation and use

AI 5: Procure IT resources

AI 6: manage changes

AI 7: Install and accredit solutions and changes

ME 1: Monitor and evaluate IT performance

ME 2: Monitor and evaluate internal control

ME 3: Ensure regulatory compliance

ME 4: Provide IT governance

The second point of view relating to COBIT is IT resources.

5.4.3.2 IT resources

COBIT identifies four classes of IT resources (ISACA, 2007; Brand & Boonen, 2007:34;

Enterprise Architecture, 2009):

� People: addresses the human resources needed to plan, organise, acquire, deliver,

support, monitor and evaluate information systems and services.

� Applications: addresses the automated systems and manual procedures that process the

information.

� Information: includes data as input and output of information systems, in any form used

by the business.

� Infrastructure: Comprises of the technology and facilities that enable the processing of

applications.


Table 5.3: The four COBIT IT resources and their respective focus

COBIT IT Resources In

clu

des

People

Applications

Information

Infrastructure

Ad

dre

ss

es

Human resources needed to plan,

organise, acquire, deliver, support,

monitor and evaluate information systems

and services.

Automated systems

and manual

procedures that

process the

information.

Data as input and

output of information

systems, in any form

used by the

business.

Comprises of the

technology and

facilities that enable

the processing of

applications.

The third point of view is quality criteria.

5.4.3.3 Quality criteria

This aspect of COBIT advocates that control of IT is approached by looking at the information that

is needed to support the business requirements (ISACA, 2007; Brand & Boonen, 2007:34).

COBIT considers the information criteria as follows:

� Effectiveness: The extent to which the information serves the defined objectives

� Efficiency: The extent to which activities relating to the provision of information are carried

out at an acceptable cost and effort.

� Confidentiality: The extent to which data is only accessible to a well-defined group of

authorised persons.

� Integrity: The extent to which data correspond with the actual situation represented by

that data.

� Availability: The extent to which a resource is available to the intended users at the

intended times.

� Compliance: The extent to which processes act in accordance with those laws,

regulations and contractual arrangements to which the process is subject.

� Reliability of information: The extent to which appropriate information is provided for

management to operate the entity and to exercise it’s financial and compliance reporting

responsibilities.

These criteria are depicted in table 5.4.


Table 5.4: The seven COBIT Information Criteria and their respective focus

COBIT Quality Criteria In

clu

des

Effectiveness

Efficiency

Confidentiality

Integrity

Availability

Compliance

Reliability

Ad

dre

ss

es

Does info serve the

defined objectives?

Are activities

carried out at

acceptable

cost and

effort?

Is data only

accessible to

authorised

persons?

Do data

correspond

to the

situation

represented?

Are the

resources

available to

the right

person at the

right time?

Are processes

in accordance

with the laws

and

regulations to

which they are

subject?

Is the

appropriate

information

provided?

The next section discusses the COBIT approach.

5.4.4 COBIT approach

The COBIT approach can be summarised as business-focused, process-oriented, controls-based

and measurement-driven (ISACA, 2007). The following characteristics are briefly explained

below:

� Business-focused: COBIT is designed not only to be employed by IT service providers,

users and auditors, but also to provide comprehensive guidance for management to

business process owners.

� Process-oriented: COBIT defines IT activities in four domains, as discussed in the

previous section.

� Controls-based: COBIT defines control objectives for each of its thirty four (34)

processes, as well as overarching process and application controls. It defines controls as

the policies, procedures, practices and organisational structures designed to provide

reasonable assurance that business objectives will be achieved, and undesirable events

will be prevented or detected and corrected.

� Measurement-driven: COBIT addresses the need for every enterprise to understand the

status of its own IT systems and to decide what level of management and control are

needed. This is done by providing: a) Maturity models to enable bench-marking and

identification of necessary capability improvements; b) Performance goals and metrics for

the IT processes; and c) Activity goals for enabling effective process performance.

The next section discusses the COBIT control mechanism.


5.4.4.1 COBIT control mechanism

This section highlights how the COBIT framework ensures control. This control mechanism will be

used as a guideline in applying controls to project management processes, towards developing a

project management audit model. The COBIT framework is built around processes, control

objectives, business requirements, process goals, activity goals, key metrics measures and

maturity models (ISACA, 2007). Each of them is discussed below:

a) Processes

COBIT comprises of thirty four (34) processes, which are collections of procedures with a clear

reason for existing, accountable owners, clear roles and responsibilities around their execution,

and the means to measure them.

b) Control objectives:

Each process has a control objective, which represents a statement of the desired result or

purpose to be achieved by implementing control procedures in that process. Control objectives

are all the high-level requirements to be considered in providing reasonable assurance that

business objectives will be achieved, and undesirable events will be prevented, detected or

corrected.

c) Business requirements:

Each control objective should be linked to a specific business requirement that it needs to satisfy.

d) Process goals:

To satisfy business requirements, control objectives need to focus on key process goals. In other

words, control objectives have to focus on the goals (or outputs) which the process should

achieve.

e) Activity goals:

Process goals should be further broken down into activity goals if necessary. Processes are

known to be a collection of inter-related activities (Dinsmore & Cabanis-Brewin 2006; Project

Management Institute, 2008). Therefore, activity goals should aggregate to form process goals.

e) Key metrics:


Metrics describe what about the process needs to be measured and how it is to be measured.

This could include the unit used, frequency, ideal target value, the procedure to carry out

measurement, and the procedure for the interpretation of the assessment, as necessary. The key

purpose of defining key metrics is to clarify how the processes will actually be measured.

f) Measures:

After metrics have been set, measures represent a standard value to evaluate and communicate

performance against the expected result. The actual assessment of the process happens, and

the actual result is compared to the expected result.

f) Maturity models:

Maturity models are a method for evaluating an organization after measuring its processes, so as

to be able to rate that organization (ISACA, 2007). Rating the maturity of an organization’s

processes involves:

� Comparing it with peers in the industry;

� Determining what is acceptable industry best practice;

� Determining how well the organization is doing compared to industry best practices and

how far the organization wants to go towards meeting these best practices, and finally;

� Determining a required growth path to fill the gap.

Maturity models in the COBIT framework range from level 0 (non-existent), 1 (initial / ad Hoc), 2

(repeatable but intuitive), 3 (defined process), 4 (managed and measurable) to 5 (optimised).

The above-mentioned COBIT control mechanism can be summarised in the following steps:

Step 1: Identify processes - This refers to what needs to be controlled. In the case of this

research, the project management processes identified by the PMBOK® Guide are what should

be controlled.

Step 2: Identify control objectives - The questions “what are we trying to achieve?” and/or

“what are we trying to avoid?” should be addressed.

Step 3: Link to business requirement - Determine if there is a business justification for this

control exercise. Control objectives should be linked to a business justification.


Step 4: Identify process goals - Each process should deliver some outputs. This step should

focus on what needs to be done to ensure that the process outputs are achieved.

Step 5: Identify activity goals - If necessary, each process goal (output) should be further

broken down into more detailed sub-objectives that need to be achieved for the process goal to

be reached.

Step 6: Determine metrics - Determine how the processes will be measured and what the

expected results are.

Step 7: Measure processes - After determining how results will be measured and what the

expected results are, the actual measurement should take place, and actual results compared to

expected results.

Step 8: Determine maturity model - The measured processes should be rated. This rating

should be a process involving the determination of where the company’s processes stand,

comparing them to industry standards, and determining steps to fill the gap. As this research

focuses primarily on an audit model for project management processes, maturity models fall

outside the scope of this research, and constitute an area for further study. The above steps are

depicted in Figure 5.2.

Figure 5.2: The COBIT Control Mechanism


On the basis of the wide recognition of COBIT as an IT governance framework, the above steps

can be adapted into new steps, which should guide the process of auditing IT project

management.

5.4.4.2 Project management audit steps

The new IT project management audit steps are outlined below:

� Step 1: Identify project management processes to be audited: For the purpose of this

research, the project management audit will focus on one process only. This process will

be selected out of the forty-two project management processes included in the PMBOK®

Guide 4th Edition.

� Step 2: State the audit objectives: Before undertaking the audit, there needs to be clarity

as to what the audit is trying to achieve or avoid.

� Step 3: State the business justification for the audit: The audit objectives in step 2 must

have a genuine business justification. Failing this, the audit objective should be revisited.

� Step 4: Determine the goal of the audited process: There needs to be clarity as to what

the audited project management process is supposed to achieve

� Step 5a: Break process goal into detailed activity goals

� Step 5b: Identify detailed activity goals (if necessary)

� Step 6: Determine how the project management process is measured and the expected

results

� Step 7: Perform the audit

� Step 8: Analyse the audit results and make recommendations

These steps are depicted in Figure 5.2 next to the COBIT control mechanism, from which they

are adapted.


Figure 5.3: Guidelines for auditing IT projects - adapted from the COBIT control

mechanism


5.5 Conclusion

The relevant literature on governance has been reviewed in this chapter, including IT governance

and project governance. Firstly, the governance literature was explored. It was then established

that corporate governance and IT governance are subsets of broader field of governance; these

subsets were reviewed accordingly, from a literature review perspective. The literature review

then narrowed down on IT governance, and COBIT was identified as the focus IT governance

framework for this research. The COBIT framework was then discussed accordingly.

The literature reviewed has confirmed that IT governance is a subset of corporate governance,

which in turn, is a subset of governance (Calder, 2008:148; Hunter & Tan, 2006:153). This review


has led to the realisation that IT governance is unquestionably important, as highlighted by

Hunter and Tan (2006:151).

Several governance frameworks were identified in the literature, including ITIL, COBIT, COSO,

ISO 17799:2005, ISO 27001:2005, Prince 2, OPM3, Balanced Scorecard, Six Sigma and ISO

20000 (ISACA, 2007; Calder, 2008; Tarantino, 2008; Tarantino, 2008; Wallace & Webber,

2008:5). However, COBIT was highlighted as the main framework to be discussed, by virtue of its

wide recognition and adoption (Gudentops, 2004:270; ISACA, 2007). The review of the COBIT

control mechanism allowed this research to derive IT governance control steps, which in turn

were adapted into new IT project management audit steps.

The value of these new audit steps lies primarily in the fact that they have been derived from a

widely recognised IT governance framework. This ensures that the audit model proposed in this

research is conducted within the limits of accepted IT governance principles.

Chapter 3 provided the basic principles of auditing; chapter 4 then went on to identify project

management components, and chapter 5 has now established a governance framework within

which IT project management audit needs to be conducted. These three deliverables constitute

the foundation on which the proposed IT project management audit model is built (chapter 7).

The next chapter investigates the extent to which project managers adhere to their project

management best practices.

_____________________________________________________________________ Chapter 6 – Data Collection and Analysis 94

6 CHAPTER 6 – DATA COLLECTION AND ANALYSIS

6.1 Introduction

6.1.1 Background

This research comes from fact that business organisations operate under enormous pressure to

remain profitable, and that doing so relies to a big extent on staying ahead of the competition.

One way to do so is to constantly innovate in areas such as new product developments. These

innovations are often achieved through projects which need to be delivered within certain time,

budget, and requirement boundaries. There exist various bodies of best practices from which

organisations adapt their way of managing projects, in order to successfully manage their projects

within the above-mentioned constraints.

However, it seems that many organisations claim to manage their projects in line with some form

of established best practices, whereas in reality it seems, only few of them actually do (Economist

Intelligence Unit, 2009:3; Byatt, Hamilton and Hodgkinson, 2011). While this claim is may tend to

be generally accepted, this research has not encountered solid evidence to substantiate it.

Hence, this chapter attempts firstly to probe into this claim, secondly to establish whether this is a

real problem, thirdly to measure the extent of the problem (project managers not adhering to best

practices) if it is found to be a valid one, and lastly to use the findings as basis for making

recommendations on how to remedy the problem.

The chapter therefore conducts an empirical investigation, consisting of gathering data from

project managers in a manner permitting to understand how they manage their project

management processes, and then comparing their responses to the recommendations found in

the best practice which they claim to adhere to.

In line with the overall exploratory nature of this research, this empirical investigation seeks to

gain greater understanding on what project managers do (or fail to do), that serves as a basis to

infer that they do (or fail to) adhere to the best practices which they purport to follow.

The next section discusses the goal and objectives of the chapter.

6.1.2 Goal

The goal of this chapter is to establish whether project managers adhere to project management

best practices, and measure the extent to which they do so. In order to reach this goal, the

following objectives need to be achieved:


6.1.3 Objectives

� Objective 1: Collect data on how project managers manage project management

processes.

� Objective 2: Analyse the collected data in comparison to project management best

practices.

� Objective 3: Present the findings of the data analysis and make recommendations.

6.1.4 Layout

The remainder of this chapter is laid out as follows: the first section focuses on the steps followed

to collect the data. This section includes the data collection methodology and techniques used.

The second section analyses the collected data. In this section, the data is summarised,

presented diagrammatically, and compared to best practices. Based on the pattern emerging,

conclusions then drawn. The third section presents the findings of the data analysis as well as the

impact of these findings on auditing, and makes recommendations. The last section concludes

the chapter and introduces the next chapter.

6.2 Overview of the data collection

The data was collected from ten different project managers employed in this capacity, anywhere

in Africa. These project managers were interviewed on how each of them managed their project

management processes. Each of these project managers are responsible for managing IT

projects, even though their respective employers may or may not have IT as its core business.

The data collection followed the following steps:

6.2.1 Data collection steps

Step 1 - Identify project management processes to be audited:

For the purpose of this research, the PMBOK® Guide is as the best practice against which

responses to the interview questions will be compared. Having made this decision, it then

became necessary to specify which project management process to audit. Even though the

PMBOK® guide, fourth edition, addresses forty-two processes, this data collection targets only a

few project management processes. This is for two main reasons: firstly, a detailed interview

covering all forty-two project management processes far exceeds the scope and time boundaries

applicable to this research; secondly, given that this research ultimately seeks to propose a

repeatable model for auditing project management, it would be of limited, if any, added value to


cover more than a few processes in this data collection. The mechanism that this research seeks

to propose is intended to be replicable onto any other project management process.

The project charter is the main theme selected for this data collection. This is for no other reason

than the fact that the project charter is one of the first themes, if not the very first theme, to

emerge from the discussion on project management processes in the PMBOK® Guide, 4th edition

(Project Management Institute, 2008).

It also appears from the PMBOK® Guide that five processes (the first five) involve the project

charter, either as input or output. These processes include:

� Develop project charter

� Identify stakeholders

� Develop project management plan

� Collect requirements

� Define scope

The interview was therefore designed to only address these five processes.

Step 2 - State the audit objective:

Respondents were briefed on what this data collection is aiming to achieve. They understood and

valued that by the conclusion of this research, a greater understanding would have been reached,

not only on how well they personally adhered to best practices, but also how well other project

managers tended to do in this respect.

Step 3 – State the business justification for the audit:

Among the benefits of following a structured project management method, one finds that it

enables companies to predict and mitigate risks, better manage costs, and deliver quality results

that satisfy clients (Economist Intelligence Unit, 2009:3). Each respondent identified with the need

to achieve these benefits, and agreed that these benefits were crucial in influencing the business

success and competitive advantage of their organisation.

Step 4 – Determine the goal of the audited processes:

The project management processes covered in this data collection have the following goals

(Project Management Institute, 2008; Heldman & Mangano, 2009; Schwalbe, 2009):


� Develop project charter: Involves working with stakeholders to create the project charter,

which is the document that formally authorizes a project.

� Identify stakeholders: Involves identifying all people or organizations impacted by the

project, and documenting relevant information regarding their interests, involvement,

impact on project success, and potential negative influences on the project.

� Develop project management plan: Involves coordinating all planning efforts to create a

consistent and coherent document – the project management plan -, which becomes the

primary source of information for how the project will be planned, executed, monitored

and controlled, and closed.

� Collect requirements: Involves defining and documenting the project and product features

and functions needed to meet stakeholder’s needs and expectations.

� Define scope: Involves developing a detailed description of the project and product. This

process elaborates further on existing information obtained earlier in the project, such as

the project charter.

For the purpose of this research, it was not necessary to break these process goals into more

detailed activity goals. The next steps therefore focused on measuring the processes.

Step 5 – Determine how the project management processes are measured:

These project management processes are measured by a set of questions aimed at determining

whether the respondent adheres to the process, in line with the PMBOK® Guide, or not.

Therefore, the initial questions are closed questions, whereby the expected response is either

“yes” or “no”. In line with the semi-structured nature of this interview, the interviewer had the

option to ask follow-up questions where it was deemed necessary, in order to gather further

insight into the respondent’s answer. The interviewer also allowed the respondent to further

elaborate on their “yes” or “no” answer, in order to better understand the respondent’s

perspective.

The next section discusses the interview questions.

6.2.2 Interview questions

A total of seventeen questions were used to collect the data. This list is by no means exhaustive,

but for the purpose of this research, is deemed broad enough to allow meaningful data to be

collected and analysed.

Below is a list of all interview questions, grouped by project management process, and a brief

summary of their respective aims:


Project management process 1: Develop project charter

� Does a project charter exist? This question aims to verify the existence of a formal

document authorizing the project.

� Is the project charter signed by all identified key stakeholders? This question aims to

verify whether the project has been authorized by all identified key stakeholders.

� Was the project charter signed by all identified key stakeholders prior to the official

project start date? This question aims to verify whether the project was formally

authorized by the time of its official start.

� Was the signed project charter communicated to the entire project team? This question

aims to verify whether everyone taking part in the project has been informed of its formal

authorization, and the terms under which it has been authorized.

Project management process 2: Identify stakeholders

� Are all key stakeholders identified prior to the project start? This question aims to verify

whether key stakeholders on the project were identified prior to project start.

� Is the relevant information about key stakeholders documented? This question aims to

verify whether the relevant information about the identified stakeholders has been

documented in a stakeholder register or equivalent document. This information includes

the stakeholders’ interest, involvement, impact on the project success, potential negative

influence.

� Has a strategy been developed on how to manage the identified stakeholders? This

question aims to verify whether a stakeholder management strategy has been created.

This includes creating a stakeholder expectation management matrix, an issue log or

equivalent.

Project management process 3: Develop project management plan

� Is there a project management plan? This question aims to verify the existence of a

project management plan.

� Are all nine project management knowledge areas reflected in the project management

plan? This question aims to verify whether each of the nine knowledge areas is

addressed in the project management plan (e.g. what part of the plan addresses project

integration management, scope management, cost management, etc).

� Is the project management plan up to date? This question aims to verify whether the

project management plan is current and up to date.


� Is the project management plan communicated to all stakeholders? This question aims to

verify whether all team members have received and are aware of the project plan.

Project management process 4: Collect requirements

- Are stakeholder requirements defined and documented? This question aims to verify

whether there is a formal process for collecting, defining and documenting stakeholders’

expectations on the project.

- Are the stakeholder requirements tracked throughout the project? This question aims to

verify whether the stakeholders’ requirements are tracked, throughout the project, to

ensure that approved requirements are delivered at the end of the project.

- Have the documented stakeholder requirements been collected from all identified key

stakeholders? This question aims to verify whether all identified key stakeholders have

been consulted, and have had their requirements documented.

Project management process 5: Define scope

- Does the project have a project scope statement? This question aims to verify whether

there is a formal document detailing the work which forms part of the project, and the

work specifically excluded from the project.

- Is the project scope statement communicated to all stakeholders? This question aims to

verify whether all stakeholders have been notified of the work included in the project, and

the work excluded from the project.

- Are changes to the project scope statement reflected in the other project documents, and

communicated to all stakeholders, throughout the project? This question aims to verify

whether all the relevant project documents are updated to reflect a change in the project

scope statement, should such change occur. Furthermore, this question verifies whether

all changes to the project scope statement are communicated to all stakeholders.

The methodology followed in this data collection exercise is discussed in the next section.

6.2.3 Data collection techniques

The data has been collected through semi-structured interviews. This qualitative research

interview method is based on covering a set of questions, although the interview respondent has

more flexibility in how they answer the questions, and the interviewer has the option to further

explore certain emerging themes by asking follow-up questions (Del Barrio, 1999; Aira,

Kauhanen, Larivaara and Rautio, 2003; ESDS Qualidata, 2007).


6.2.4 Data analysis techniques

Data was analysed inductively, through the data display and analysis technique. This data

analysis technique implies that firstly the data is summarised and simplified; secondly, the data is

organised into diagrammatic displays and analysed, and lastly conclusions are drawn from the

patterns emerging from data analysis (Miles & Huberman, 1994).

6.2.5 Target population

The target population included project managers in charge of IT projects. Furthermore, these

project managers had to use the PMBOK® Guide as their main source of best practices – seeing

that a decision has been made earlier that this research would focus on the PMBOK.

Interview participants were selected from various industries, including the Information and

Communication Technology (ICT), telecommunications, retail, and financial industries.

6.2.6 Sampling

Non-probability sampling was used, as the subjects have not been selected randomly (Lunsford &

Lunsford, 1995; Doherty, 1994). The timing and budget constraints around this research called for

convenience sampling, whereby accessibility of the researcher to participants has been the

dominant selection criterion (Castillo, 2009). Convenience sampling was found more appropriate

for the purpose of this research, even though the researcher acknowledges the likelihood that the

sample might not be representative enough of all members of the population (i.e. all project

managers in charge of IT projects in Africa). Having said this, all reasonable efforts have been

made for the sample to be as random as possible.

It should also be noted that the unit of analysis (the source of data) is individual project

managers, not organisations. This means data is collected on how the individual project manager

interviewed handles their project management processes, and no extrapolation is made to the

way the entire organisation manages projects.

As a final note on the sampling, project managements participating to the interview were not

further classified into any categories. For example, the sampling for data collection (and

subsequent analysis) has not attempted to categorise participants (or their responses) according

to specific criteria, such as years or project management experience, or educational background.

Such categorisation falls beyond the scope of this research, even though it is acknowledged that

it has the potential to deliver useful insight; the data analysis could, for example, reflect on

whether data collected from experienced project managers – say those with more than five years


experience –, is better aligned with best practices than data collected from their less experienced

counterparts – say those with less than five years experience.

6.2.7 Recruitment of interview respondents

The recruitment of participants was done according to the following steps:

� Firstly, the researcher identified potential interview respondents among work colleagues,

customers, and business collaborators who are employed as project managers in their

various companies.

� Secondly, the researcher sent each potential respondent an invitation, via email, to

participate to the interview. The official invitation letter, including ethical considerations

from the University of Johannesburg, was attached to the email. This invitation letter is

also attached in Appendix A of this dissertation.

� Thirdly, the researcher had a follow-up telephone call or face-to-face meeting with each

potential respondent. The purpose was to further elaborate the purpose of the interview

and ethical considerations included in the invitation letter. Any other issues raised by the

potential respondents were also addressed.

� Lastly, a date and time was set for the interview, as soon as the respondent accepted the

invitation.

6.2.8 Ethical considerations

This section describes the ethical considerations, including what was expected from interview

respondents, how the interview results are used, and steps taken to ensure confidentiality.

Respondents have participated to this interview on a voluntary and anonymous basis. By

providing the information requested in the interview, the respondents agreed to participate in this

research and to the publication of the results with the understanding that anonymity is preserved.

The interview lasted a maximum of forty-five (45) minutes and covered seventeen questions.

However, in line with the qualitative approach of this research, respondents had the option to

clarify or further elaborate on their answers. Based on the respondent’s answers, the interviewer

had the option to ask some logical follow-up questions for more clarity or accuracy. There is no

attempt to uncover the respondent’s identity or the identity of the respondent’s organisation.

While the result of the research may be published, any information which may identify the

respondent is not disclosed.


6.3 Presentation of data

The ten projects involved in this interview (one per respondent) included five internal projects and

five external projects. Internal projects are those managed by an organisation’s internal

personnel, for the organisation’s own purpose, whereas external projects are those where an

organisation sub-contracts the project management function to an external third-party

organisation (Cleland & Ireland, 2006:49; Lock, 2007:465). While this was not a sampling

criterion, it is one of the first observations made, as data was compiled for presentation – see

table 6.1.


Table 6.1: Interview questions and answers

Interview Questions

C. 1 (Ext. Proj)

C. 3 (Ext. Proj)

C. 4 (Ext. Proj)

C. 5 (Ext. Proj)

C. 10 (Ext. Proj)

C. 2 (Int. Proj)

C. 6 (Int

Proj)

C. 7 (Int

Proj)

C. 8 (Int

Proj)

C. 9 (Int

Proj)

1. Does a project charter exist? Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes 2. Is the project charter signed by all identified key stakeholders? No Yes No Yes Yes Yes No Yes No No

3. Was the project charter signed by all identified key stakeholders prior to the official project start date?

Yes Yes No Yes Yes No No Yes No No

Develo

p P

roje

ct

Chart

er

4. Was the signed project charter communicated to the entire project team?

Yes Yes No Yes Yes Yes No No No No 5. Are all key stakeholders identified prior to the project start? Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes 6. Is the relevant information about key stakeholders documented?

Yes No No Yes No No No No No No

Ide

ntify

S

take

ho

lders

7. Has a strategy been developed on how to manage the identified stakeholders?

Yes No No Yes No No No No No No 8. Is there a project management plan? No Yes Yes Yes No No No No No No 9. Are all nine project management knowledge areas reflected in the project management plan?

No Yes Yes Yes No No No No No No

10. Is the project management plan up to date? No No Yes Yes No Yes No No No No

Develo

p P

M P

lan

11. Is the project management plan communicated to all stakeholders?

Yes Yes Yes Yes No Yes No Yes Yes No 12. Are stakeholder requirements defined and documented? Yes Yes No No Yes No No Yes Yes Yes 13. Are the stakeholder requirements tracked throughout the project?

No Yes Yes Yes Yes Yes Yes Yes Yes Yes

Colle

ct

req

uir

em

ents

14. Have the documented stakeholder requirements been collected from all identified key stakeholders?

Yes Yes Yes Yes Yes Yes No Yes Yes No 15. Does the project have a project scope statement? Yes Yes Yes Yes Yes Yes Yes Yes Yes No 16. Is the project scope statement communicated to all stakeholders?

Yes Yes Yes Yes Yes Yes No Yes Yes No

Define

Sco

pe

17. Are changes to the project scope statement reflected in the other project documents, and communicated to all stakeholders, throughout the project?

Yes Yes Yes Yes No Yes No No No No


The data presented in table 6.1 is further categorised below, according to percentages of positive

answers per question, as depicted in table 6.2:

Table 6.2: Interview data categories

Interview Questions

Percentage of respondents who answered “Yes”

Project Charter exists (Q1) 100% Stakeholders identified prior to start (Q5) 100% Requirements tracked throughout (Q13) 90%

Project Scope Statement exists (Q15) 90%

requirements collected from all stakeholders (Q14) 80%

Scope statement communicated to all (Q16) 80%

PM Plan communicated to all (Q11) 70%

Requirements defined and documented (Q12) 60%

Project Charter signed by all stakeholders (Q2) 50%

Project Charter signed by all before start (Q3) 50%

Signed Proj Charter communicated to all (Q4) 50%

Scope changes reflected and communicated (Q17) 50%

PM Plan exists (Q8) 30%

All 9 Knowledge Areas reflected in PM Plan (Q9) 30%

PM Plan up to date (Q10) 30%

Stakeholder info documented (Q6) 20%

Stakeholder management strategy in place (Q7) 20%

The full transcript for each interview can be found in “Appendix B”.

The next section further describes and elaborates on the patterns emerging from the data

presented in tables 6.1 and 6.2.

Q1. All projects (100%) have a document meant to formally authorize the project. The data

suggests that all projects concerned by this research have a formal authorising document. It also

appears that not all projects adopt the “project charter” terminology. Other names used for this

document include “Statement of work” for external projects, or “project approval request” for

internal projects.

Q2. Half of the project charter documents (50%) exist but are not signed by all identified

key stakeholders. While all ten projects involved in this study had a project charter drafted, only

half of these projects ensured that the said project charter is actually signed by all key

stakeholders identified as signatories. For the other half, project charters missed one or more of


the required signatures. However, while some respondents agreed that missing signatures from

some identified key stakeholders was a problem, some did not. This is the case of one external

project, where the project manager insisted that, while several stakeholders have been identified

both on the client and on the project performing company, only two signatures are required to

officially authorise the project. In this case, the required signatories are the highest executive

managers from either side (client’s side and project performing organisation’s side).

Confidentiality reasons were also cited to justify the fact that only executive managers needed to

sign the project charter. This, according to respondents, is due to sensitive information included in

the authorizing document, such as wages of the project manager and other “potentially sensitive

legal information”.

Q3. Half of the signed project charters (50%) were signed after the project had already

started. The interview results show that half of the projects started without the necessary

authorising signatures. All respondents who had their project charters signed prior to the project

start insisted that obtaining all the required authorizing signatures was a non-negotiable pre-

requisite to commencing their project. One project manager on an external project commented

that they had a strict “no signature, no start” policy. This situation has been more frequently

observed in the case of external projects, where four in five projects (80%) did not start until all

required authorizing signatures were obtained. Failing to have a binding document introduces a

“big risk of non-payment once the job is done”, as stated by one of the respondents who

managed external project. This seems to be a common reason why external projects tend to be

fully and duly authorized before they start.

On the other hand, two main reasons were noted among those respondents who did not get all

the required signatures before project start, namely:

(a) On one internal project, the interview respondent clarified that “The IT Director’s authorization

is all an internal IT project needs, in order to start”. The respondent added that “the IT Director is

mandated by the Board, therefore every project authorized by the former is ultimately binding to

all involved, for he acts on the Board’s mandate”. In this case, according to this particular

respondent, “it is only a matter of time before other stakeholders sign the authorizing document”.

(b) The other respondents indicated that most of their projects were initiated with a deadline in

mind, therefore once the stakeholders were identified, there was “an assumption that all identified

stakeholders will sign the project charter”. The actual project execution therefore started

immediately, in order to “avoid wasting time”.


Q4. Half of the signed project charters (50%) were not communicated to all stakeholders.

Once the project was considered authorised, only half of respondents ensured the authorizing

document was communicated to all stakeholders. Among those that did not communicate the

authorizing document to all stakeholders, the only notable reason was related to the

confidentiality attached to the document’s content.

Q5. All projects (100%) identified their key stakeholders prior to the start of the project.

Each one of the interview respondents indicated that all key stakeholders on their projects were

identified prior to project start. However, all respondents agree that this does not constitute a

guarantee that new stakeholders won’t emerge later on in the project life cycle.

Q6. Eight projects out of ten (80%) do not document information on key stakeholders. The

interview data shows that a mere twenty percent of respondents have a formally documented

record of important information on their key stakeholders. One reason for not doing this is the fact

that the information is generally known in the project management team, but not formally

recorded. In the words of one respondent: “We usually have this information, but it is not always

formally recorded”. Another reason is that the project is too small to worry about documenting

stakeholder information. To stress this point, one respondent said “the project is relatively small,

and any relevant information in this regard would typically be found in the project initiation

document any way”. The interview data also suggests that none of the internal projects had

formal documentation on key stakeholder information.

Q7. Eight projects out of ten (80%) do not have a strategy on how to manage key

stakeholders. Eight projects out of ten had no strategy in place for managing their key

stakeholders. It was also observed that the projects having formally documented key stakeholder

information also had a stakeholder management strategy in place. A clear link appears between

the documentation of stakeholder information and the elaboration of a stakeholder management

strategy. This link is confirmed by a respondent who pointed out that “it is impossible to manage

what we don’t know about stakeholders”. Among the projects having no formal stakeholder

management strategy, respondents seemed to indicate that such effort was not worthwhile. This

is the case of a relatively small internal project, where the respondent indicated that an ad hoc

approach is more practical, adding that a formal stakeholder management strategy “only makes

sense in large projects”.

Q8. Seven out of ten projects (70%) do not have a project management plan. When asked

whether they have a project management plan for their projects, all respondents initially gave a

positive response. However, after further clarifying the definition of a project management plan

according to the PMBOK® Guide, namely that it is “the formal, approved document which defines


how a project is executed, monitored and controlled” and that “it may include one or more

subsidiary plans”, many responses to this question became negative. The interview highlighted

the erroneous tendency in the majority of respondents, to assimilate the project schedule (Gantt

chart) to the project management plan. Only three projects out of ten (30%) had a project

management plan in line with the above definition.

Q9. Seven out of ten project management plans (70%) do not reflect all nine project

management knowledge areas. The data emphasizes the point made earlier, namely that many

project managers, while basing their project management processes on the PMBOK® Guide, still

wrongly perceive the project schedule as synonymous to the project management plan.

However, while 70% of projects did not have all nine knowledge areas reflected in their project

management plans, many reflected more than one knowledge area. This is a case of an internal

project respondent who clarified that their project management plan included “the project

schedule and some aspects of risk, communication, procurement, and cost management,

communicated in various forms at some points, mainly via email”.

The data also reflects that none of the internal projects have all nine knowledge areas reflected in

what they consider to be their project management plan. When asked why this was the case, one

respondent simply said “we are not doing it, but we should be”. This echoes the sentiment of

most others, who generally recognize that reflecting all nine knowledge areas in the project plan

is a good practice, but it is not always realistic, given the tendency to give priority on meeting the

project completion deadline.

Q10. Seven out of ten project management plans (70%) are outdated. The requirement to

keep the project management plan up to date at all times was only met by 30% of respondents.

The data reflects that only two in ten projects meet both requirements of reflecting all nine

knowledge areas in their project management plan, and keeping the said plan up to date.

The data also reflects that one project management plan, while failing to reflect all nine

knowledge areas, was up to date on those knowledge areas which it reflected. The interview data

also shows one project where all nine knowledge areas were reflected, but the overall project

management plan was outdated.

Q11. Seven out of ten project management plans (70%) were not communicated to all

stakeholders. The interview data shows that only three projects communicated what they

considered to be their project management plan to all stakeholders. Two of them communicated

the project management plan via email. The third project made use of a central web-based portal


accessible to all stakeholders. In light of the above, communication seems to be “a big problem in

projects” as one respondent puts it.

Q12. Four out of ten projects (40%) have not defined and documented stakeholder

requirements. When it comes to defining and documenting stakeholders’ requirements, the

interview data shows that six projects out of ten do not comply. The interview data shows

however that half of the non-compliant projects have at least defined stakeholder requirements,

albeit not formally documented. One of the respondents in this category said: “we have defined

the stakeholder requirements, and we know most of them… however, they are not always

formally documented”.

Q13. Nine out of ten projects (90%) tracked stakeholder requirements throughout the

project. Tracking stakeholder requirements seems to be a regular practice, as only one project

failed to meet this criterion. On this latter project, the respondent claimed that “this is a very niche

project and we do not do full-blown project management”, suggesting that the specialised nature

of the project, and the fact that they do not have a dedicated project office, were the reasons why

they did not constantly adhere to strict tracking of stakeholder requirements throughout the

project.

Q14. Eight out of ten projects (80%) have involved all identified key stakeholders in

collecting stakeholder requirements. Two out of ten interview respondents failed to involve all

identified key stakeholders in collecting stakeholder requirements. The interview data shows that

both happen to be internal projects, and both recognize they should have consulted all identified

key stakeholders. “We should have done better” said one respondent, which leads to believe that

internal projects should pay particular attention to involving all identified key stakeholders in

collecting stakeholder requirements.

Q15. Nine out of ten projects (90%) have a project scope statement. The interview data

shows that the vast majority of projects seem to comply with the requirement to have project

scope statement. The fact that nine projects out of ten complied with this requirement attests to

this. The only non-compliant respondent on this point claimed that the inclusions and exclusions

on projects were known, despite the fact that they were not documented. The respondent said:

“we know what is included and what is excluded from the project”, and added: “we just haven’t

formally documented these things”.

Q16. Eight out of ten projects (80%) have communicated the project scope statement to all

stakeholders. The interview data shows that eight respondents out of ten managed to

communicate the project scope statement to all stakeholders. The interview data further suggests


that: (a) the project with no formally documented scope statement also naturally could not

communicate any; and (b) one project managed to have a formally documented scope statement,

but just failed to communicate it to all stakeholders. On this specific project, omission was cited

as the reason for the failure to communicate.

Q17. Half of the projects (50%) did not ensure that changes to the project scope statement

were reflected in the other project documents, and communicated to all stakeholders,

throughout the project. While as many as nine projects had formally documented scope

statements (refer to Q15), only five of these projects also updated other project documents with

the applicable changes, and communicate these updates to all stakeholders throughout the

project. All projects meeting this requirement referred to the existence, in their project

environment, of a change management process beginning with a change request form. Of the

non-compliant projects (five of them), four did not provide any particular reason for their non-

compliance, other than the fact that they know they should do this, but they are not doing it.

However, one respondent claimed that complying with this criterion was not always practical in

their projects environment.

The above data is further analysed and recommendations are made in the next section.

6.4 Data analysis and recommendations

The data gathered through this qualitative interview reveals that the project management

practices recommended by the PMBOK® Guide are generally not followed by project managers.

This section analyses the interview data by category, as reflected in table 6.2. The data grouping

has yielded eight data category, ranging from the highest positive response rate of hundred

percent, to the lowest positive response rate of twenty percent. The next discussion focuses on

each of the data categories, in terms of what the data contains (data presentation), what it means

(data implication), and what can be done about it (data recommendations).

1. Data category 1 (100%)

a. Data presentation:

“Data category 1” (100%) includes interview questions where all interview subjects responded

positively. This category includes the question verifying whether a Project Charter document

exists (Q1) and whether stakeholders were identified prior to the official start of the project (Q5).

The data reflects that (a) all projects concerned have a project charter, and (b) key stakeholders

were identified prior to the official start of the project.


b. Data implication:

The data in this category implies that:

(a) All respondents seem to acknowledge the relevance of the project charter, as a

document which should formally authorise the start of a project. “Data category 6” below

explores the extent to which stakeholders actually commit to these project charters (Q2),

whether they give their commitment prior to the start of the project (Q3), and the extent to

which this commitment is communicated to the project team (Q4).

(b) By the start of each project involved in the interview, the project management teams had

done their homework in terms of identifying the individuals and/or organisations impacted

by the execution of the project. Doing this increases the chances of identifying any

potential hindrances to the smooth execution of the project, right from the start. This

could also prevent wasting project resources, including money, as is the case when a

project has to be abandoned half-way, because of failure to identify a show-stopper right

from the start.

c. Recommendations:

The following recommendations can be made on this data category:

(a) While each of the projects researched had a document meant to formally authorise it, the

naming of this document varied from one project to the other. Some of the names

mentioned included “project charter”, “project approval request”, and “statement of work”.

In line with the PMBOK® Guide, the naming of these authorising documents should be

standardised to “project charter” on all projects.

(b) Notwithstanding the positive fact that key stakeholders were identified prior to the start of

the project, stakeholder identification should be a continuous exercise throughout the

project. This is because additional key stakeholders could emerge after the start of the

project.



Data category 2 (90%) includes interview questions where 90% of interview subjects responded

positively. This category includes the question verifying whether stakeholder requirements were

tracked throughout the project (Q13) and whether the projects had a project scope statement

(Q15). The data reflects that (a) on 10% of the projects researched, stakeholder requirements


were not tracked throughout the project, and (b) 10% of the projects researched did not have a

project scope statement.



(a) Failing to track stakeholders’ requirements throughout the project, ten percent of

respondents are limited in their ability to establish a link between each requirement and

the associated business and project objectives. In this case, it is difficult to ensure that

each requirement adds business value. It is equally difficult to establish a structure for

managing changes to the project scope. “Data category 5” explores whether these

stakeholder requirements are defined and formally documented (Q12), and “data

category 3” explores whether these requirements are collected from all identified

stakeholders (Q14)

(b) Due to lack of a scope statement document, ten percent of respondents are unable to

describe in detail the project deliverables, as well as the work required in creating those

deliverables. This further indicates that the said projects are unable to build upon major

deliverables, assumptions and constraints documented during project initiation. “Data

category 3” explores the extent to which these project scope statement have been

communicated to stakeholders, and “Data category 6” explores the extent to which

changes to the scope document are reflected in other project documents, and

communicated to stakeholders throughout the project.

c. Recommendations:


(a) Each project should make use of a requirement traceability matrix, to trace requirements

throughout the projects, and ensure that the approved requirements are delivered.

(b) Each project should also develop a project scope statement, which highlights the

project’s inclusions and exclusions. The project scope statement and other documents,

such as the stakeholder register, stakeholder requirement document and the requirement

traceability matrix, should continuously be kept up-to-date. This would ensure that any

changes in the initial project scope are formally acknowledged, and can therefore be

managed accordingly.




Data category 3 (80%) includes interview questions where 80% of interview subjects responded

positively. This category includes the questions verifying whether requirements were collected

from all stakeholders (Q14) and whether the project scope statement was communicated to the

entire project team (Q16). The data reflects that (a) on 20% of the projects researched,

requirements were not collected from all stakeholders, and (b) on 20% of the projects researched,

project scope statements were not communicated to the entire project team.



(a) By failing to collect requirements from all stakeholders, twenty percent of respondents are

exposed to the risk of omitting important requirements and/or information pertaining to

the project. Such omissions may result in lack of support and/or buy-in from those

stakeholders who were not consulted. “Data category 5” explores the extent to which

these stakeholder requirements were defined and documented on the projects

researched (Q12), and “Data category 2” explores the extent to which these stakeholder

requirements were tracked throughout the project (Q13).

(b) By failing to communicate the project scope statement to the entire project team, twenty

percent of respondents are limited in their ability to create awareness – and consequently

potential support – among all stakeholders, regarding the project’s inclusions and the

project’s exclusions. Project team member to whom the project scope statement is not

communicated are unlikely to support to the project. Furthermore, failing to communicate

the project’s inclusions and exclusions to all stakeholders could mean a missed

opportunity to involve potentially influential individuals and/or organisations that could

have provided important support to the project.

“Data category 2” explores the extent to which respondents had a project scope

statement in place (Q15), and “Data category 6” explores the extent to which changes to

the project scope statement are reflected in other project documents, and communicated

to all stakeholders, throughout the project.

c. Recommendations:



(a) Project managers should constantly make sure that no identified key stakeholder is

omitted in the process of gathering requirements. To enhance the effectiveness of this

process, the project manager should refer to high-level requirements in the project

charter, as well as the list of identified stakeholders in the stakeholder register.

(b) Project managers should communicate the project scope statement and other related

documentation to all stakeholders, to create awareness, and therefore ensure proper

management of stakeholders’ expectations, with regards to the project’s inclusions and

exclusions. Besides the project scope statement, project managers should constantly

communicate other important information, such as updates to the stakeholder register,

updates to the stakeholder requirement document, and updates to the requirement

traceability matrix.



“Data category 4” (70%) includes interview the question where 70% of interview subjects

responded positively. This category includes the question verifying whether the project

management plan was communicated to all stakeholders (Q11). The data reflects that on 30% of

the projects researched, the project management plan was not communicated to all stakeholders.


The data in this category implies that 30% of respondents had kept some team members

potentially unaware of the project status and of the contribution expected from team members,

due to lack of communication. This is likely to result in a lack of involvement and/or awareness

from some stakeholders, which in turn exposes the project to problems such as delay and/or

inaccuracies. While the importance of communicating the project management plan is

emphasised here, “data category 7” explores the extent to which project management plans were

up-to-date among the projects researched through the interview (Q10).

c. Recommendations:

The following recommendation can be made on this data category:

The project management plan should be communicated to the right people, at the right time, and

in the right format. One useful tool in this process is the RACI chart, as it reflects Responsibility

(who is responsible for the task being done), Accountability (who is accountable for, or performs


the task), Consultation (who provides consultation and advice for the task), Informed (who must

be kept informed or up-to-date about the task).



Category 5 (60%) includes interview questions where 60% of respondents responded positively.

This category includes the question verifying whether stakeholder requirements are defined and

documented (Q12). The data reflects that on 40% of the projects researched, stakeholder

requirements are not defined or documented.


The data in this category implies that 40% of projects researched are at risk of failing to satisfy

stakeholder requirements, as these requirements are unlikely to be known, or referred to, at the

right time. This creates a project environment without a centralised and standardised means of

recalling what the stakeholder requirements were, at any given point in time. Given the link

between project success and meeting stakeholder requirements, it is hard to achieve project

success on the projects in this category. Besides simply documenting them, stakeholder

requirements need to be tracked throughout the project.

“Data category 2” explores the extent to which respondents track requirements (Q13). Another

important characteristic of stakeholder requirement is that they need to be collected from all

identified key stakeholders. “Data category 3” explores the extent to which respondents

demonstrated this ability (Q14).

c. Recommendations:


Project managers should put a process in place to enforce the practice of defining, documenting,

and tracking stakeholder requirements throughout the project.



“Data category 6” (50%) includes interview questions, where 50% of respondents responded

positively. This category includes the question verifying whether: (a) the project charter was


signed by all identified stakeholders (Q2), (b) the project charter was signed by all identified

stakeholders before the start of the project (Q3), (c) the signed project charter was communicated

to all stakeholders (Q4), and (d) changes to the project scope are reflected and communicated to

all stakeholders (Q17).

The interview data reflects that: (a) on 50% of projects researched, the project charter was not

signed by all identified stakeholders; (b) on 50% of projects researched, the project charter was

not signed by all identified stakeholders before the start of the project; (c) on 50% of projects

researched, the signed project charter was not communicated to all stakeholders, and (d) on 50%

of projects researched, changes to the project scope were not reflected and communicated to all

stakeholders.



(a) 50% of respondents did not ensure that all stakeholders are formally bound to the project

charter. This is demonstrated by the failure to have these stakeholders sign the project charter.

This limits the respondents’ ability to obtain support and buy-in from stakeholders who did not

sign the project charter. These stakeholders could then impede the progress of the project, by

withholding much needed support and/or buy-in. In order to provide further understanding into the

context within which these implications are made, “data category 1” explores the extent to which

projects researched had a project charter in the first place (Q1), “data category 6” explores both

the extent to which these project charters were signed prior to the start of the project (Q3), and

the extent to which the project charters wee communicated to all stakeholders (Q4).

(b) Starting the project before signing the project charter, as was the case for half of the

respondents, creates a risk of conflict, as the signed project charter could contradict the work

already underway. Such contradiction could result in unnecessary cost, such as the cost of

undoing and/or redoing work which was already done – and paid for; other consequences of such

contradictions could include project delays.

“Data category 1” complements this section by exploring the extent to which the projects

researched had a project plan in the first place (Q1); “data category 6” adds to this perspective by

exploring both the extent to which project charters were signed by all identified stakeholders

among the projects researched (Q2), and the extent to which these signed project charters were

communicated to all stakeholders.


(c) The fact that half of the respondents failed to communicate the signed project charters to all

stakeholders, implies that these respondents are unable to proactively ensure that each

stakeholder is formally made aware of the project and its commitments. Consequently, the project

is exposed to the lack of required support and/or buy-in from these stakeholders. “Data category

1” explores the extent to which the projects researched had a project charter in the first place;

“data category 6” explores both the extent to which the project charters are signed by all identified

stakeholders, and the extent to which the said signatures are done prior to official start date,

among the projects researched.

(d) Failing to reflect scope changes in other project documents, and to communicate these

changes to all stakeholders, half of the respondents were potentially unable to proactively take

the said changes into account as they executed the project. This exposes the projects to risks,

such as wasting project resources towards work which was meant to be excluded from the

project. Other risks include the lack of project support from aggrieved stakeholders, and a missed

opportunity to gain support from potentially influential stakeholders who would have supported the

project if they had otherwise been consulted.

“Data category 2” explores the extent to which respondents had a project scope statement in the

first place (Q15), and “data category 3” explores the extent to which these scope statements were

communicated to all stakeholders, among the projects researched (Q16).

c. Recommendations:


(a) Project managers should ensure that the project charter is signed by all identified key

stakeholders.

(b) The project charter should be signed by all identified key stakeholders, prior to the start of the

project, to ensure that the project is implemented in line with what key stakeholders have agreed

to, and authorized.

(c) The project charter should be communicated to all stakeholders to ensure awareness, and

consequently, increase chances of support and/or buy-in from these stakeholders.

(d) The project scope document, and other related documents, such as the stakeholder register,

stakeholder requirement documentation, and requirement traceability matrix, should continuously

be kept up-to-date. By doing this, project managers would ensure that any changes to the initial

scope are formally acknowledged, and can therefore be managed accordingly. Furthermore, the


project scope statement and related information should be communicated, to ensure proper

management of stakeholders’ expectations, regarding the project’s inclusions and exclusions.



“Data category 7” (30%) includes interview questions where 30% of interview subjects responded

positively. This category includes the questions verifying whether (a) the project has a project

management plan (Q8), (b) the project management plan reflects all nine knowledge areas (Q9),

and (c) the project management plan is up-to-date (Q10). The data reflects that (a) 70% of

projects researched do not have a project management plan; (b) 70% of projects researched do

not have a project management plan with all 9 knowledge areas reflected; and (c) on 70% of

projects researched, the project management plan is not up to date.



(a) Failing to have a project management plan in place, seventy percent of respondents were

unable to effectively guide the development of, and coordination between the subsidiary plans.

Consequently, these project managers may have difficulty in defining and guiding actions on how

a project should be executed, monitored and controlled, and closed, across all nine knowledge

areas. The absence of a project plan also implies the inability to effectively correlate between any

of the nine knowledge areas, meaning that project managers were unlikely to establish a link

between a change in one knowledge area and its impact on another knowledge area. This

category also further discusses the extent to which project plans reflect all nine knowledge areas

(Q9), and the extent to which these plans are kept up-to-date (Q10); “data category 4” discusses

the extent to which these project plans are communicated to all stakeholders (Q11).

(b) Seventy percent of respondents had project plans which did not include all nine knowledge

areas. This creates a risk of missing important information about a particular knowledge area.

This potential lack of information in turn, results in incomplete and/or misleading project

management plan. Consequently, the project manager would be unable to accurately guide and

coordinate the project integration, execution, monitoring and closing. This data category also

discusses the extent to which respondents had a project plan in the first place (Q8), and the

extent to which these plans were up-to-date; “data category 4” discusses the extent to which

these project plans are communicated to all stakeholders (Q11).


(c) Because of outdated project plans, seventy percent of respondents could potentially be misled

as they execute the project, due to lack of recent updates. This data category also explores the

extent to which the projects researched had a project plan in the first place (Q8), and the extent to

which these plans reflected all nine knowledge areas (Q9). “Data category 4” explores the extent

to which respondents communicated project plans to all stakeholders (Q11).

c. Recommendations:


(a) Each project should have a project management plan, as a reference document to guide

its execution.

(b) The project management plan should reflect all nine knowledge areas, even though some

knowledge areas might not contain important information, depending on the nature of the

project. Each of these knowledge areas should be presented as a subsidiary project plan,

and should be updated as often as necessary. These updates should result from regular

project review meetings and any other new information which may have emerged in

connection with any of the nine knowledge areas.

(c) Finally, the updated project management plan should be communicated to all

stakeholders, in at the right time and in the right format.



“Data category 8” (20%) includes interview questions where 20% of respondents responded

positively. This category includes the questions verifying whether: a) the relevant information

about stakeholders was documented (Q6); and b) there was a stakeholder management strategy

in place (Q7). The data reflects that: (a) on 80% of the respondents failed to document

stakeholder information; and (b) 80% of respondents did not have a stakeholder management

strategy in place.



(a) For eighty percent of respondents, the absence of documented information on

stakeholders limits their ability to take proactive action, based on known information on

stakeholders. Such information could include attributes and other known attitudes of a


particular stakeholder towards the project. Missing such information is a missed

opportunity to gain the support of some stakeholders, or avoid a clash with others.

Therefore, failing to record stakeholder information potentially decreases the likelihood of

an uninterrupted project execution, and consequently, the likelihood of project success.

Stakeholders need to be identified before information about them is documented. “Data

category 1” explores the extent to which respondents identified stakeholders prior to the

start of the project (Q5). This category further explores the extent to which the projects

researched had a strategy in place, on how to manage these stakeholders (Q7).

(b) Failing to have a stakeholder management strategy in place, eighty percent of

respondents have limited ability to proactively implement a mechanism which would allow

project managers to maximize on the positive influence and/or mitigate potentially

negative influence of stakeholders. “Data category 1” explores the extent to which

respondents identified stakeholders prior to the start of the project (Q5). This category

further explores the extent to which respondents documented stakeholder information

(Q6).

c. Recommendations:


Project managers should ensure that as much relevant information about stakeholders as

possible is recorded in a stakeholder register, or equivalent document. Such information may

include: information on their identification (i.e. name, position, role on the project, contact

information), assessment information (i.e. major requirements, main expectations, potential

influence on the project), the classification of stakeholders (i.e. internal, external, supporter,

resistor).

Furthermore, project managers should have a strategy in place, regarding the management of

stakeholders. One of the benefits of doing this, is that it enables the project manager to anticipate

(and therefore better prepare for) aspects of the projects that are likely to be supported by

specific stakeholders and those that are not. This ability is even more crucial for stakeholders

who have been identified as influential to the project execution.

The above set of recommendations is by no means exhaustive. However, they address the

purpose of this dissertation. Recommendations from a study to develop a comprehensive model

can complement the recommendations from this study. The next section concludes this chapter.


6.5 Conclusion

This chapter collected and analysed data from project managers, in order to determine the

validity of the claim that many organisations do not adhere to the project management best

practices which they purport to follow.

To achieve this, a semi-structured interview has been conducted, whereby a set of seventeen

questions was asked to ten project managers, aiming to understand how they handled their

project management processes. These questions were spread across the five PMBOK® Guide

processes where the project charter is directly involved. In an effort to keep the data collection,

and subsequent analysis, within the scope of this research, the interview questions were limited

to the above-mentioned processes.

Data collected was subsequently analysed according to the data display and analysis technique.

This technique entails firstly summarising the data collected, then presenting it in a graphical

manner, and lastly drawing inferences from observing the patterns which emerged from the data.

On the Develop project charter process, one of the observations, among the projects concerned

with this investigation, that half of the project charters were not yet signed by all identified key

stakeholders, at the time the project was considered to have started. This introduces risks on the

projects, as some stakeholders may, later on, claim not to be bound by the project charter.

Interestingly, out of all project charters which were duly signed before the project started, eighty

percent pertained to external projects.

On the Identify stakeholder’s process, it appeared, among other things, that eighty percent of all

projects investigated did not formally document information on key stakeholders. It also appears

that none of the internal projects had any formal documentation on stakeholder information, as

part of project documentation.

On the Develop project management plan process, the data shows that seventy percent of

projects investigated did not have a project management plan in place. Similarly to the previous

observation, none of the internal projects met this condition.

The above are only three out of the several examples that show sufficiently that external projects

tend to adhere better to these PMBOK® guide recommendations, in comparison to internal

projects. This is alarming, when considering that all respondents claim to follow the PMBOK®

Guide in the management of their projects. This also begs the question on whether the strict

application of the PMBOK® Guide, in its current version, is adapted to internal project. Perhaps it


is the project managers in charge of internal projects who should do their best to strictly adhere to

the PMBOK – which they purport to follow - regardless of whether it seems practical or not.

This debate spans beyond the scope of this research. For the purpose of this research, suffice to

say that the claim stating that most project managers do not apply the project management

theory which they purport to follow, is a valid one. This research has also discovered that this

claim is even more valid for internal projects than it is for external projects.

The next chapter proposes a conceptual model for auditing IT project management.

_____________________________________________________________________ Chapter 7 – A Conceptual Audit Model 122

7 CHAPTER 7 – A CONCEPTUAL AUDIT MODEL

7.1 Introduction

7.1.1 Background

A four-step approach to auditing has been highlighted in Chapter 3. Chapter 4 has highlighted

project components to take into account when auditing project management; and Chapter 5 has

defined a basic guideline for the auditing of IT projects. The current chapter intends to integrate

the knowledge derived from the above-mentioned chapters, into a conceptual model for IT project

management auditing. Such model can be quite broad, depending on the nature of the project

being audited. However, this chapter is primarily concerned with proposing a conceptual model. It

therefore aims to illustrate, in a simplified way, the main features of a potentially more complex

model (Murthy, 2008; Olivier, 2009).

The next section elaborates on the goal and objectives of this chapter.

7.1.2 Goal

The goal of this chapter is to propose a conceptual model for auditing IT project management. To

reach this goal, the following objectives need to be achieved.

7.1.3 Objectives

� Objective 1: Revisit the audit process identified in Chapter 3, and demonstrate how it

contributes to building the conceptual model.

� Objective 2: Revisit the project management components identified in Chapter 4, and

demonstrate how each of them contributes to building the conceptual model.

� Objective 3: Revisit the guideline for auditing IT projects defined in chapter 5, and

demonstrate how it contributes to building the conceptual audit model.

� Objective 4: Present and describe the conceptual model

7.1.4 Layout

The remainder of this chapter is laid out as follows: The first section discusses the role of the

four-steps auditing process in the model. The second section discusses the nine project

components and their roles in the model. The third section discusses the IT project audit steps

and their role in the model. The last section integrates the above into a conceptual model.


7.2 Existing knowledge In setting out to propose the conceptual model, it is important to briefly revisit the knowledge

acquired in Chapters 3 through 5, as it is the said knowledge that is integrated into the conceptual

model. Chapter 3 (auditing) has produced a 4-step audit process, consisting of audit risk

assessment, audit planning, field work, and communication of audit results. It appears that the

first step (risk assessment) is carried out before the actual audit begins. The second and third

steps (planning and field work) constitute the actual audit work, and the last step (communicate

results) happens after the audit. Below is the grouping of processes:

� Before the audit: Audit risk assessment.

� During the audit: Audit planning, field work

� After the audit: Communicate results.

Figure 7.1 illustrates these processes.

Figure 7.1: Four-step audit process

Chapter 4 (project management) has produced nine project components, which correspond to the

various aspects that need to be considered when auditing project management, namely:

1. deliverables,

2. time,

3. scope,

4. cost,

5. quality,

6. requirements,

7. specifications,

8. stakeholders, and

9. resources.

The process followed in Chapter 4 to derive these components has not highlighted any hierarchy

among these components. This research therefore does not emphasize on a particular order in


which these components should be considered, in an audit situation. They should rather be

viewed as a checklist of project components to go through, when auditing project management.

The said components are illustrated in figure 7.2.

Scope

Cost

Specifica

tions

Stakeholders

Resources

Figure 7.2: Nine project components

Chapter 5 (IT governance) has produced a guideline for auditing IT projects. Similarly to the audit

steps identified in Chapter 4, the steps in the said guideline can also be categorized in three

groups, namely those that happen before the audit, during the audit, and after the audit:

� Before the audit: Perform audit risk assessment

� During the audit: Identify process to be audited, state audit objectives, state the business

justification, determine process goal, identify activity goals, define how the process will be

measured, and perform the audit.

� After the audit: Analyse audit results and make recommendations.

These steps are illustrated in Figure 7.3:


Figure 7.3: Guideline for auditing IT projects

The above knowledge, summarised in figures 7.1 through to 7.3, constitutes the foundation of the

conceptual model proposed in this chapter. The next section explains the role of each of these

constituents in the conceptual model.

7.3 The role of project components in the model

7.3.1 The role of generic auditing steps

As a model for auditing, it is crucial that this model is based on existing auditing principles. The

literature review and subsequent interpretation of auditing yielded reasonable understanding on

what the concept of auditing entails. A key part of the knowledge gathered is the grouping of audit

steps, in relation to when they feature in the audit process. This allows the auditor to clearly

conceptualise the audit work before it begins. These generic audit steps, while not

comprehensive enough, have contributed more to the structure than to the content of the audit

model. Therefore, the unique contribution of auditing steps to this model is that the model will be


viewed as a logical succession of steps, grouped in terms of steps that happen before, during,

and after the audit.

7.3.2 The role of project components

It has been established that projects are multi-faceted entities, comprising of several interlinked

components. However, attempting to determine the multiple facets of any project while an audit is

already underway can prove detrimental to the success of the audit. It is therefore important for

the auditor, and all concerned by the audit, to know in advance the aspects against which the

project will be measured. These nine project components can therefore be considered as a

thoroughly researched checklist to be followed.

7.3.3 The role of the IT project auditing guideline in the model

The literature review of IT governance has contributed to this research by providing

understanding of recognised IT governance frameworks. Adapting the main principles behind

these frameworks into a guideline applicable to the audit of IT projects ensures that the audit

steps emanate from a rigorous control background, and therefore maximises the chances of a

repeatable audit process.

The guideline for auditing IT projects also brings a more detailed perspective on the audit steps.

Such depth enriches both the content and the structure of the superficial steps proposed, as part

of generic audit steps.

It can be seen that the conceptual model is a progressive integration of these individual

constituents. The next section illustrates this integration and presents the end product.

7.4 The conceptual model The conceptual model proposed in this research is designed to help organisations in structuring

their approach to auditing IT project management. Thus, it proposes principles meant to guide

auditors as they audit IT projects. Industry and company specific context should be applied in

addition to this model, as dictated by circumstances. However, based on the rigorous

methodology which has led to this conceptual model, any deliberate deviation on the part of the

auditor should be carefully considered. At this point, the three separate constituents of the

conceptual model have been identified, namely generic audit steps, project components, and IT

project framework. The next section progressively merges these constituents.

7.4.1 Phase 1: Merge generic audit steps and project components


The first phase in building the conceptual model consists of merging the first two constituents.

This entails merging the four generic audit steps with the nine project components. The results

are as follows:

7.4.1.1 Before the audit Risk assessment is conducted prior to the audit work commencing, in order to identify and

mitigate any risk associated to the audit.

7.4.1.2 During the audit The audit starts with audit planning. Fieldwork is then conducted, in line with the audit plan.

These two steps (audit plan and fieldwork) are interdependent. In other words, the initial audit

plan determines how the fieldwork is to be conducted; and conversely, during the fieldwork, the

auditor is likely to encounter situations prompting a change to the initial audit plan. While this loop

is repeated, the audit work should remain focused on the nine project components. When all nine

project components have been considered, the audit should end, and proceed to the next step.

7.4.1.3 After the audit The auditor communicates audit findings to the audited party. The above phases are illustrated in

Figure 7.4.

Figure 7.4: Generic audit process merged with project components


7.4.2 Phase 2: Merge the output of phase 1 and the guidelines for auditing IT projects

The second phase towards merging the constituents of the conceptual model consists of merging

the result of phase 1 (above), with the IT projects auditing guideline. This guideline does not alter

the structure of the conceptual model (i.e. before, during, after); it simply brings more granularity

to the audit steps. The results are as follows:

7.4.2.1 Before the audit Risk assessment is conducted prior to the audit work commencing.

7.4.2.2 During the audit The steps during the audit process are classified in two groups. The first group consists of the

audit planning steps, and the second group consists of the field work steps.

The audit planning steps are further broken down into more specific actions, including:

(a) identify the PMBOK processes to be audited;

(b) for each of the PMBOK processes identified, state the objectives of the audit;

(c) determine the business justification for the audit,

(d) determine the goal of the PMBOK processes being audited;

(e) determine if detailed activity goals are necessary for the processes being audited; if yes,

outline them, if not, proceed to the next step;

(f) determine how the processes will be measured.

Fieldwork steps on the other hand, are further broken down into nine fieldwork steps i.e. one for

each of the identified project components. These nine steps might not all apply to a particular

process, but they should nonetheless be used as a checklist when auditing a project

management process. Whenever they do not apply, the auditor should attest to that, and

document his or her judgement on the matter.

7.4.2.3 After the audit The auditor analyses audit results, makes recommendations, and communicates the audit

findings in an audit report.

7.4.3 Integrated model for IT project management auditing

Based on the above, the integrated conceptual model is therefore presented in the following

steps.


7.4.3.1 Before the audit � Step 1: Perform an audit risk assessment.

7.4.3.2 During the audit: planning � Step 2: Identify project management processes to be audited.

� Step 3: State the audit objectives.

� Step 4: Determine the business justification for the audit.

� Step 5: Determine the goal of the audited process.

� Step 6: Identify detailed activity goals, if necessary.

� Step 7: Determine how the identified project management process will be measured, and

state the expected results.

7.4.3.3 During the audit: fieldwork � Step 8: Verify whether the selected process has delivered the expected deliverable.

� Step 9: Verify whether and how time is addressed within the said deliverable.

� Step 10: Verify whether and how scope is addressed within the said deliverable.

� Step 11: Verify whether and how cost is addressed within the said deliverable.

� Step 12: Verify whether and how quality is addressed within the said deliverable.

� Step 13: Verify whether and how requirements are addressed within the said deliverable.

� Step 14: Verify whether and how specifications are addressed within the said deliverable.

� Step 15: Verify whether and how stakeholders are addressed within the said deliverable.

� Step 16: Verify whether and how resources are addressed within the said deliverable.

7.4.3.4 After the audit Upon completion of the above steps, the auditor should:

� Step 17: Analyse the audit results and make recommendations.

� Step 18: Communicate the audit findings and recommendations to the audited party, in

the form of an audit report.

Figure 7.5 depicts this conceptual model.


Figure 7.5: Integrated conceptual model for auditing project management.

The next section illustrates, through practical steps, how this conceptual model can guide the

audit of a project management process, in line with the PMBOK® Guide. Although any project

management process can be used, this illustration only focuses on the Develop project charter

process.

7.4.4 Application of the conceptual audit model on the Develop project charter process


7.4.4.1 Before the audit � Step 1 - Perform an audit risk assessment:

Identify and mitigate any risk threatening the successful completion of the audit exercise.

7.4.4.2 During the audit: planning � Step 2 - Identify project management processes to be audited:

For the purpose of this illustration, the Develop project charter process is used.

� Step 3 - State the audit objectives:

The objective of the audit is to verify whether the Develop project charter process is managed

in line with best practices contained in the PMBOK® Guide.

� Step 4 – Is there a business justification for the audit? If yes, state it and proceed to the

next step; if not, revisit the audit objectives:

Yes, there is a business justification. The organisation has invested time and money in

aligning its project management processes with the PMBOK® Guide, in order to ensure that

projects are managed consistently throughout the organisation. By doing this, the

organisation attempted to ensure that all projects are delivered on time, according to client

specifications, and with no cost overruns.

� Step 5 - Determine the goal of the audited process.

The Develop Project Charter process ensures that the project manager works with

stakeholders to create the project charter, which is the document that formally authorizes a

project.

� Step 6 - Identify detailed activity goals

The goal of the audit process outlined in step 5 presupposes at a minimum, the existence of a

project charter, its signature by all stakeholders, its signature prior to the project start, and its

communication to all stakeholders. Therefore, the detailed activities should consist of

verifying that these minimum conditions are met, by asking the following audit questions:

� Does a project charter exist? The project manager must be able to produce a

formal document authorizing the project.

� Is the project charter signed by all identified key stakeholders? The project

manager must be able to prove that all identified key stakeholders have signed

the project charter.


� Was the project charter signed by all identified key stakeholders prior to the

official project start date? The project manager must prove that all identified key

stakeholders signed the project charter before the project official start date.

� Was the signed project charter communicated to the entire project team? The

project manager must be able to prove that everyone taking part in the project, or

affected by its execution, has been informed of its official authorisation and

applicable terms.

� Step 7 - Determine how the “Develop project charter” process is measured, and state the

expected results.

The Develop Project Charter process is measured according to the answers to the four

questions posed above, in step 6. The answer to each question is expected to be “yes”, as a

result of two conditions being met: (a) the project manager’s ability to clearly respond by the

affirmative; and (b) the auditor’s ability to verify the existence of the physical evidence of the

project manager’s answer. Failing to meet either of these conditions, the auditor has to mark

the answer as “No”. Furthermore, the auditor must inspect the evidence produced by the

project manager, in line with Steps 8 through 16, and obtain reasonable assurance that

recommendations from the PMBOK® Guide were adhered to, on each step. Should the

findings align with the PMBOK® Guide on each of these steps (8 through 16), the auditor

must state so in his audit report. Similarly, any misalignment must be reported in the audit

report, including a summary of the said misalignment, the specific step at which it has been

noticed, and its likely implication.

7.4.4.3 During the audit: fieldwork � Step 8 – Verify whether the “Develop Project Charter” process has delivered its expected

deliverable, in line with the PMBOK® Guide.

The PMBOK® Guide recommends that the “Develop a project charter” delivers a project

charter, duly signed by all identified key stakeholders.

� Step 9 - Verify whether and how time is addressed within the project charter.

The project charter must be delivered, and duly signed, before the official start date of the

project. Furthermore, it must contain a summary schedule of the project, including start and

finish dates.

� Step 10 – Verify whether and how scope is addressed within the project charter, with

particular emphasis on verifying the presence of information which must be contained in

it.


According to the PMBOK® Guide, the project charter must at least include a project

statement of work, business case, contract, enterprise environmental factors, and

organisational process assets (Schwalbe, 2009:148).

� Step 11 – Verify whether and how cost is addressed within the project charter

According to the PMBOK® Guide, the project charter must contain a summary of the project’s

budget or a reference to budgetary documents.

� Step 12 – Verify whether and how quality is addressed within the project charter.

Having defined quality earlier in this research as the degree to which a project fulfils

requirements (Rose 2005:6; Dinsmore & Cabanis-Brewin, 2006:2), this step must then verify

that the project charter addresses project success criteria, including project approval

requirements and who signs off on the project (Schwalbe, 2009:148).

� Step 13 – Verify whether and how requirements are addressed within the project charter.

Having defined requirement, earlier in this research as a condition which must be met or

possessed by a product, service or result, in order to satisfy imposed specifications, and

expectations from project stakeholders (Project Management Institute, 2008), the project

charter must contain information on key stakeholders’ expectations from the project.

� Step 14 – verify whether and how specifications are addressed within the project charter.

Having noted, earlier in this research, the link between requirements and specifications, the

finding gathered from the previous step should apply to this step, unless otherwise specified

by the project manager, and verified by the auditor.

� Step 15 - Verify whether and how stakeholders are addressed in the project charter.

According to the PMBOK® Guide, the project charter must contain information on the

planned approach for managing the project, including stakeholder needs, important

assumptions, and constraints. Furthermore, the project charter must contain a section for

stakeholders to sign off, and register important comments concerning the project (Schwalbe,

2009:148).

� Step 16 – Verify whether and how resources are managed within the project charter.

The project charter should list the project’s critical resources, including human resources (the

project team) and non-human resources (other critical resources such as equipment, supply

and funds available).


7.4.4.4 After the audit Upon completion of the above steps, the auditor should:

� Step 17 - Analyse the audit findings and make recommendations.

At this stage, the auditor should compile the audit report. In doing so, the auditor should at a

minimum:

(a) Introduce the audit report, by briefly revisiting the main points emerging from steps 1

through 5 of the audit process;

(b) record the answers to the four questions posed at step 6 of the audit process;

(c) explain how audit results are measured and state the expected results, as per step 7 of

the audit process;

(d) record the findings of the verification exercise done in steps 8 through to 16; and

(e) list the likely implications of each of these findings.

� Step 18 - Communicate the audit findings and recommendations in the audit report.

At this stage, the auditor must communicate the audit report to the project manager, and to

any other recipient identified in step 3 of the audit process.

If followed correctly, the above steps should greatly increase the percentage of positive answers

reflected in Table 5.2.

7.5 Conclusion

This chapter has proposed a conceptual model, as a simplified representation of the full model for

auditing IT project management. The chapter has built on knowledge which was gathered in the

previous chapters, particularly the audit process, the project management components, and the

guideline for auditing IT projects.

The goal of this chapter was to propose a conceptual model for auditing IT project management.

In reaching this goal, the chapter firstly reviewed the audit process identified in chapter 3, and

then went on to show how these steps fit in the conceptual model. This has been achieved

through aligning this conceptual audit model with generic audit principles. Secondly, the project

management components identified in chapter 4 were listed, and specific steps were outlined for

each of them. Thirdly, the guideline for auditing IT project, identified in chapter 5, was integrated

into the conceptual model, to provide more detail and depth to the audit steps. Lastly, the

conceptual model was presented as simplified, coherent, step-by-step mechanism to guide the

auditing of project management processes.

The next chapter concludes this dissertation.

_____________________________________________________________________ Chapter 8 – Dissertation Conclusion 135

8 CHAPTER 8 – DISSERTATION CONCLUSION

8.1 Introduction

This is the last chapter, which concludes this research study. The chapter aims to demonstrate

that the problem which this research set out to address and the subsequent objectives it set out

to achieve, were all addressed and achieved, through a structured approach. In fact, this chapter

is the culmination of a learning journey which started by defining a perceived problem worth

studying, and went on gathering and organising information towards a solution, and applying the

gathered information to validate the said solution. In essence, this chapter is the part of the

dissertation that evaluates the research solution.

A useful way to illustrate the learning process undergone throughout this study is to match the

Bloom’s taxonomy of cognitive learning (Anderson, Krathwohl and Bloom , 2001; Biggam,

2008:70) with the progression of this dissertation. This taxonomy advocates that learning can be

represented as a pyramid made of layers, from the broadest layer (the base), moving upward to

the narrowest layer (the summit). Knowledge or remembering is the first layer, which consists of

gathering simple facts and figures. The second level is comprehension, or understanding, which

consists of summarising the gathered knowledge in one’s own words or way. The third layer is

application, which consists of practically illustrating the acquired understanding. The fourth layer

is analysis, which consists of dissecting a concept into its constituent parts. The fifth layer is

synthesis, which consists of aggregating disparate elements of one’s thinking, into a coherent

argument. The sixth layer is evaluating, which consists of voicing one’s opinion on the work

achieved, in line with the principles set in getting thus far.

Chapters 1 through 5 of this dissertation mainly addressed the Knowledge and Comprehension

layers of Bloom’s taxonomy of cognitive learning. Chapters 6 and 7 mainly addressed the

Application, Analysis, and Synthesis layers. Finally, the current chapter (Chapter 8) addresses

the Evaluation layer. The chapters of this dissertation may overlap the layers to a certain extent,

but the above is considered sufficiently accurate to illustrate how the learning in this dissertation

has evolved to this chapter. The above is illustrated in Figure 8.1.


Learning

Figure 8.1: Mapping between Bloom’s taxonomy of cognitive learning and this dissertation

Having said this, the chapter reviews the initial goal and the various research objectives outlined

in reaching the overall research goal. Then, each objective is considered, with particular attention

paid to how it was achieved, and what could be learnt about the said objective from the literature

review or the empirical study. This leads to drawing research conclusions. The research

limitations are then discussed, the research value articulated, and the last section is devoted to

self reflection, including a closing word from the researcher.

The next section revisits the initial research goal and objectives.

8.2 Revisiting the problem

8.2.1 Research Goal

The goal of this research was to provide project managers and decision makers involved in, or

affected by project management in the IT industry, with a model allowing them to determine

whether they are following the project management best practices which they purport to follow.

The importance of this model is made more relevant by the current reality, whereby IT is an

increasingly important catalyst in allowing business organisations to show returns to their

shareholders, and outsmart their competitors. The latter statement would be considered as

something of a generalised, therefore inappropriate, statement for this research, if it was not

complemented by the acknowledged necessity to manage IT endeavours (or projects) in a way

that warrants them being rightly considered as the cutting edge for organisations.

In the face of this need for IT projects to be conducted in a way that benefits the organisation’s

profitability and competitiveness, it is conceivable that many risks could contribute to IT projects

failing to meet this expectation. One such risk is when an organisation has set specific best


practices to guide the management of IT projects, but has not devised a way to verify that these

best practices are constantly adhered to. Such risk, if indeed present, constitutes a worthwhile

gap to fill. Therefore, probing the extent to which this is a worthwhile gap, and eventually filling

the said gap, is what the research set out to achieve.

In pursuing this goal, this research needed to meet the following objectives:

8.2.2 Research Objectives and Findings

8.2.2.1 Objective 1 – Guideline for the auditing process

The first objective of this research was to propose a guideline for the auditing process, based on

a structured exploration of the concept of auditing, its evolution over time, an evaluation of

existing standards in the auditing profession, and how the concept of auditing has been applied to

IT. This process revealed at least the following key findings:

Firstly, it has been shown, through literature review, that auditing is an established, multifaceted

profession that has matured through the centuries. Indeed, literature highlights some evidence of

auditing taking place as far back as before the sixteenth century. This review has also shown how

auditing became gradually formalized, up to the emergence of auditing standards and

frameworks. Secondly, the multifaceted nature of auditing has been highlighted, as the literature

review showed that auditing can be considered in terms of the types of audit conducted, the types

of auditors conducting them, and the auditing standards applied. The main types of audits were

found to be internal and external audits; auditors were accordingly found to be mainly categorized

as internal and external auditors; auditing standards included general, fieldwork, and reporting

standards.

Thirdly, it has been shown that auditing can be simply described as a systematic process of

collecting evidence, comparing the evidence to criteria set in advance, and communicating the

matches and mismatches found in such comparison. Fourthly, the literature review and analysis

has allowed to expand this audit process and apply it to project management, yielding the

understanding that the process of auditing project management amounts to: a) assessing the

audit risks; b) collecting project management evidence, c) doing the field work – including project

management evidence and comparing the evidence with set company or industry standards; and

d) communicating the audit findings.

8.2.2.2 Objective 2 – Project components

The second objective of this research was to identify components of a project, which should be

taken into consideration when a project management audit is performed. This objective was


achieved by exploring the evolution of project management over time, and by identifying and

reviewing recognised project management best practices. This process revealed at least the

following key findings:

Firstly, it has been shown that some evidence of project management can be found from as early

as the ancient civilizations of Egypt or Mesopotamia, but it is not until the 1950’s that project

management became recognised as a formal discipline. Secondly, it has been shown that there

exists a rich body of project management best practices, including but not limited to, NCSPM,

PRINCE, APM, and PMBOK. The PMBOK was found to be the most authoritative project

management best practice. It was also found that in an audit situation, a project should be

considered from nine points of view, referred to as project components in this research. These

include deliverables, time, scope, cost, quality, requirements, specifications, stakeholders, and

resources.

8.2.2.3 Objective 3 – Guideline for auditing IT projects

The third objective of this research was to understand the main underlying principles of IT

governance. This objective was achieved by reviewing and evaluating different perspectives on IT

governance, identifying and reviewing recognised IT governance sources and frameworks, and

exploring project governance. This process revealed at least the following key findings:

Firstly, IT governance is a subset of corporate governance, which itself is a subset of generic

governance; the importance of IT governance is such that organisations with an IT governance

strategy in place are set to perform better than those without one. Secondly, it was shown that

there exists a vast body of IT governance sources and frameworks, including, but not limited to

COBIT, COSO, ITIL, ISO 17799:2005, ISO 27001:2005, PRINCE 2, OPM3, Balanced Scorecard,

Six Sigma, ISO 20000 and the CMMI / /SPICE (ISO/IEC 15504). COBIT was found to be the

most authoritative IT governance framework. Thirdly, the COBIT control mechanism was

highlighted, and adapted into practical steps, referred to as guidelines for auditing IT projects.

8.2.2.4 Objective 4 – Collect and analyse data through an empirical study

The fourth objective of this research was to measure the extent to which project managers

adhered to best practices which they purported to follow. This objective was achieved through an

empirical data collection and analysis. This process revealed at least the following key findings:

Firstly, project managers do not strictly follow the project management best practices which they

purport to follow. Secondly, an unexpected finding from this empirical study was that in general,

external project managers fared better than their internal counterparts.


8.2.2.5 Objective 5 – A conceptual model

The fifth objective of this research was to propose a conceptual model for auditing IT project

management. This objective was achieved through revisiting the audit process, project

components, and guideline for auditing IT projects, and highlighting the role played by each of

these constituents in the model. These constituents were then merged, and the integrated into a

conceptual audit model. This process revealed at least the following key findings:

Firstly, the structure of a conceptual audit model for IT project management is informed by the

thoroughly researched phases of an audit process, which can be summarised in terms of

activities to be carried out before, during, and after the audit. Secondly, the content of a

conceptual audit model for IT project management is informed by the thoroughly researched

detailed steps constituting a guideline for auditing IT projects.

8.3 From findings to conclusions

This section focuses on drawing inferences on what the researcher believes to be the key

lessons learned from the above research findings, vis-à-vis the initial research objectives.

8.3.1.1 Conclusion 1

The first research conclusion is derived from the findings of the first research objective. It can be

concluded that, while the detailed approach to auditing activities may vary from one industry to

the other, auditors – and project management auditors in particular – do not need to reinvent the

wheel in such a mature discipline. The overarching principle in this discipline is to set criteria with

which the organization must comply, collect evidence to verify compliance, and communicate the

findings of such verification back to the organisation, with recommendations.


The second conclusion is derived from the findings of the second research objective. It can be

concluded that a project management audit is incomplete until, and unless, it examines the

audited projects from at least the following nine points of view: deliverables, time, scope, cost,

quality, requirements, specifications, stakeholders, and resources.


The third conclusion is derived from the findings of the third research objective. It can be

concluded that no IT governance endeavour must be undertaken without careful consideration of

their alignment with the corporate governance strategy, and the governance principles in general.



The fourth conclusion is derived from the findings of the fourth research objective. It can be

concluded that once approved by the organisation, project management best practices must be

followed at all times, on every project. This must be the case, regardless of how practical or

convenient alternative courses of action may seem, and regardless of whether the project is

internal or external.


The fifth conclusion is derived from the findings of the fifth research objective. It can be concluded

that every organisation having adopted project management best practices must have a readily

available and structured mechanism, comprising of practical steps, to verify whether the adopted

best practices are constantly followed. By doing this, the organisation avoids wasting precious

time and resources in determining the soundness of their project management processes, in

comparison to adopted best practices.

The next section discusses the limitations of this research.

8.4 Research limitations

8.4.1 Limited sampling

Although the data collected and analysed through the empirical study has proved insightful, the

researcher feels that the sample of respondents could be enlarged, in order to have a more

representative sample. A larger sample should therefore better mitigate the risk of questioning the

validity of research results. Similarly, random sampling would have been a better alternative to

the convenience sampling used in this research. This is because random sampling would have

afforded every member of the target population equal chances to be selected. Lastly, the

sampling does not further categorise respondents, which if done, has the potential to yield more

insight from the data. An area of concern from the researcher at this stage is the inability to

answer the question as to whether interviewing more experienced, or less experienced project

managers would have yielded different results.

8.4.2 Cross-sectional time horizon for data collection

The data collected and subsequently analysed in the empirical study reflects the state of project

management at one particular point in time. While conducting the empirical study in this manner

answers the initial question - of determining whether or not project managers adhere to the best

practices which they purport to follow -, it does not tell the researcher anything on whether the


trend towards adhering to best practices is improving or worsening. A longitudinal research offers

better prospects of getting this additional knowledge.

8.4.3 Conceptual model limited to IT project management

The conceptual model proposed in this research results from IT-specific governance principles.

The researcher recognises that while IT is important to the success of organisations, the need for

IT project management to adhere to best practices is only one part of the full picture. In effect, the

management of non-IT projects must also adhere to best practices. Thus, properly managing IT

projects and failing to properly manage other non-IT projects may not be sufficient to avoid a

project management disaster.

The next section highlights the unique value of this research

8.5 Research value

Notwithstanding the above-mentioned limitations, this research is a uniquely useful contribution to

the project management body of knowledge.

The first unique contribution lies in the very aim of the study. Merely verifying whether project

management adheres to the best practices adopted by the organisation is not unique or original;

what is original is the fact that this research has looked beyond the mere verification the

existence of deliverables, from a given project management process or activity. This research has

provided a mechanism to rapidly verify whether the steps followed in producing a specific project

management deliverable are consistent with the adopted project management best practices.

The second unique contribution of this research lies in the empirical finding that internal projects

are much worse at adhering to adopted best practices than external projects. While at first look,

any observer may be tempted to conclude that internal projects are simply managed in a manner

which is worse than external projects – and therefore conclude that internal project managers are

generally worse than their external counterparts -, a closer look points to realising that there may

be more to it than meets the eye; seeing that project managers can act as both internal and

external project managers (depending on whether the project is managed within the organisation,

or for an external client), the following question rises: how can the same project manager

suddenly become better, or worse, simply because they have switched to an external project, or

vice versa? This question, in turn, raises another more fundamental one: is there perhaps a need

to adapt currently recognised project management best practices (such as the PMBOK Guide)

into a format which would be more practical for internal projects? Without this research, the

pertinence of such questions would not have appeared so clearly.


8.6 Recommendations for further research

If this researcher was to make any research recommendation to another researcher interested at

picking up from where this study left of, the following would apply:

8.6.1 Larger sample for empirical study

A larger sample has the potential to be more representative, and therefore yield results

considered of higher validity. The choice to interview ten project managers in this study was only

due to the timing and resource constraints under which this research had to be carried out. There

is no reason why the study can not involve a bigger number of participants.

8.6.2 Conduct a longitudinal study

A longitudinal study has the advantage of providing the researcher with a view on the state of

affairs at different points in time. This is invaluable, as it enables the researcher to perform further

analysis, such as to track the trend over a given amount of time. Perhaps with such value added

insight (the information of the trend), the set of recommendations, and indeed the resources

needed to implement the recommendations, can be tailored to the exact need of each

organisation. For example, a company on an improving trend may require less resources than

one on a declining trend.

8.6.3 Develop a conceptual model applicable to both IT and non-IT project management auditing.

If implemented properly, this model has the potential to save the organisation precious time and

resources in identifying and rectifying the flaws in their project management processes, in

comparison to adopted best practices. However, this researcher recognises that such capability

would be of little of no value to the organisation at large, if the rest of non-IT projects are not

managed in line with best practices. Based on the knowledge gathered in this research, the

additional effort to address non-IT projects may be incremental, but in the big scheme of things,

its added value should be exponential.

8.7 Self reflections

It is extremely difficult to succinctly reflect upon an activity that has become such an integral part

of one’s life. During the life cycle of this dissertation, the researcher experienced feelings and

emotions that were both varied and contrasted. These range from the initial excitement of

undertaking such a big research project; the anxiousness about finding an appropriate research

topic; the joy of reading the work of other more experienced researchers – and how easy it often


seemed; the confusion over the abundance of research material to have to sift through; the

disillusionment in realising that there are no shortcuts to a thoroughly researched dissertation; the

frustration of having to abandon dead leads; the pain of having to remove work which, in

hindsight, added no value to the research... to the relief at finally being able to complete the

conclusion chapter. However, the feeling that overshadows all the above is the pride felt, as a

result of demonstrating the necessary courage and determination to cross the finish line.

In conclusion, project managers and other decision makers now have a tool to help them verify,

with little or no waste of time and resources, whether their IT projects are managed in a manner

consistent with adopted best practices. After all, what is the point in spending time and resources

to align internal processes with recognised best practices, if the latter are not followed? Worse

yet, why gamble with the organisation’s well-being by investing precious time and resources in

adopting best practices, without implementing readily available tools to help verify that these best

practices are followed without fail?

-- End --

_____________________________________________________________________ List of References 144

LIST OF REFERENCES

Abdomerovic, M. (2010). Brainstorming the PMBOK guide: The complete reference for relating

and chronologically sequencing process inputs and outputs, 4th Edition. PM Publications.

Abou-Seada, M. & Abdel-Kader, M. (2003). Behavioural aspects of auditors' evidence evaluation:

a belief revision perspective. England: Ashgate Publishing Limited.

Ahlenius, I.B. (2001). Code of ethics and auditing standards. Congress of INTOSAI, Seoul.

Available from http://intosai.connexcc-hosting.net/blueline/upload/1codethaudstande.pdf.

Accessed 2 July 2010.

Aira, M., Kauhanen, J., Larivaara, P. & Rautio, P. (2003). Factors influencing inquiry about

parents’ alcohol consumption by primary health care physicians: Qualitative semi-structured

interview study. Family Practice (20) 3: 270-275. Oxford University Press. Available from

http://fampra.oxfordjournals.org/cgi/content/full/20/3/270. Accessed 02 June 2010.

AllPM (2003) Announcement: IAAPM is launched [Online] Available at

http://www.allpm.com/index.php?name=News&file=article&sid=832 (Accessed on 15 March

2011).

American Institute of Certified Public Accountants (AICPA) (2001). Generally Accepted Auditing

Standards. [Online] available at

http://www.aicpa.org/Storage/Resources/Standards/DownloadableDocuments/AU-00150.PDF.

Accessed on 11 March 2011.

Anderson, L.W., Krathwohl, D.R. & Bloom, B.S. (2001). A taxonomy for learning, teaching, and

assessing: a revision of Bloom's taxonomy of educational objectives. USA: Longman.

Armstrong, M. (2006). A handbook of management techniques: a comprehensive guide to

achieving managerial excellence and improved decision making. UK: Kogan Page Publishers.

Arraj, V. (2010). “New to ITIL?” ITIL e-newsletter. [Online] Available at www.itil-officialsite.com

(Accessed on 30 October 2010).

Arter, D.R. (2003a). Quality audits for improved performance. Milwaukee: American Society for

Quality.


Arter, D.R. (2003b). How to Audit the Process-Based Qms. Milwaukee: American Society for

Quality.

Arts and Humanities Research Council (AHRC). (2009). Definition of research. [Online] available

at http://www.ahrc.ac.uk/About/PeerReview/Documents/Definition%20of%20Research2.pdf.

Accessed on 08 November 2010.

Ary, D., Jacobs, L.C., Razavieh, A. & Sorensen, C. (2009). Introduction to Research in Education,

Eighth Edition. Wadsworth, USA: Cengage Learning.

Auerbach, C.F. & Silverstein, L.B. (2003). Qualitative data: an introduction to coding and analysis.

New York: NYU Press.

Australian Shareholders’ Association. (2005). Shareholders’ expectations. Chatswood: Australian

Shareholders’ Association Ltd.

Avison, D.E. & Pries-Heje, J. (2005). Research in Information Systems: A Handbook for

Research Supervisors and their Students. Gulf Professional Publishing.

Baccarini, D. (1999). The Logical Method Framework For Defining Project Success. Project

Management Journal 30 (4): 25-32

Badiru, A.B. (1995). Industry's Guide to ISO 9000. New-York: John Wiley & Sons.

Bailey, R. (1996). Approving systems projects: Eight questions an executive should ask. PMI

Network 10 (5): 21-24.

Bailey, K.D. (1994). Methods of social research, Fourth Edition. New York: The Free Press.

Bamberger, M. (2000). Integrating quantitative and qualitative research in development projects,

Volume 1999. Washington: World Bank Publications.

Bandyopadhyay, J.K. (1996). QS-9000 Handbook: A Guide to Registration and Audit. Delray

Beach, USA: St. Lucie Press.

Basu, S.K. (2009). Fundamentals of Auditing. India: Dorling kindersly.


Bider, I. (2010). Enterprise Business Process and Information Systems Modelling.11th

International workshop BPMDS 2010 and 15th International Conference, EMMSAD 2010, held at

CAiSE 2010, Hammamet, Tunisia, June 7-8, 2010.

Biggam, J. (2008). Succeeding with your Masters dissertation. UK: McGraw Hill.

Blaikie, N. (2000). Designing social research. Cambridge, UK: Blackwell Publishing.

Blankenship, A.B., Breen, G.E. & Dutka, A.F. (1998). State of the art market research, second

edition. USA: McGraw-Hill.

Bless, C. & Higson-Smith, C. (2000). Fundamentals of Social Research Methods: African

Perspective, Third Edition. Cape Town: Juta and Company Ltd.

Bless, C., Higson-Smith, C. & Kagee, A. (2006). Fundamentals of Social Research Methods:

African Perspective, Fourth Edition. Cape Town: Juta and Company Ltd.

Botha, H. & Boon, J.A. (2003) The Information Audit: Principles and Guidelines. Department of

Information Science, University of Pretoria, South Africa.

Bowie. (2004:61f). As quoted in Campbell, T. & Houghton, K.A. (2005). Ethics and Auditing.

Canberra: ANU E Press.

Bowling, A. & Ebrahim, S. (2005). Handbook of health research methods: investigation,

measurement and analysis. Maidenhead, England: McGraw-Hill International.

Boynton, W.C. & Kell, W.G. (1996). Modern Auditing, Sixth Edition. New-York: John Wiley &

Sons.

Brand, K. & Boonen, H. (2007). IT Governance based on COBIT 4.1: A Management Guide.

Zaltbommel, The Netherlands: Van Haren Publishing.

Bridges, D. & Crawford, D. (2000). How to start up and roll-out a project office. Paper presented

at the PMI Symposium: Houston, TX.


Brisebois, R., Boyd, G. & Shadid, Z. (n.d.). What is IT Governance and why is it important for the

IS auditor. Edition 25, Canada. Available from

http://www.intosaiitaudit.org/intoit_articles/25_p30top35.pdf. Accessed 25 May 2009.

Bryman, A. (1988). Quantity and quality in social research, second edition. USA: Unwin Hyman.

Bryman, A. & Bell, E. (2007). Business research methods, Second Edition. Oxford: Oxford

University Press.

Burgess, R.G. (1986). Field research: a sourcebook and field manual. New York: Routledge.

Byatt, G., Hamilton, G. & Hodgkinson, J. (2011). Project management for the small business.

[Online] Available at http://www.theicpm.com/blog/item/4568-project-management-for-the-small-

business?tmpl=component&print=1. (Accessed on 01 May 2011).

Cagle, R.B. (2005). Your Successful Project Management Career. NY: Amacom.

Calder, A. (2008). Corporate Governance: A Practical Guide to the Legal Frameworks and

International Codes of Practice. London: Kogan Page Publishing.

Calder, A. & Moir, R. (2009). IT Governance: Implementing Frameworks and Standards for the

Corporate Governance of IT. Cambridge: IT Governance Publishing.

Calder, A. & Watkins, S. (2008). IT governance: a manager's guide to data security and ISO

27001/ISO 27002. UK: Kogan Page Publishing.

Calhoun, C.H., Oliverio, M.E. & Wolitzer, P. (1998). Ethics and the CPA: Building Trust and

Value-Added Services. New-York: John Wiley and Sons.

Campbell, T. & Houghton, K.A. (2005). Ethics and Auditing. Canberra: ANU E Press.

Carayannis, E.G., Kwak, Y.H. & Anbari, F.T. (2005). The story of managing projects: An

interdisciplinary approach. Westport, USA: Greenwood Publishing Group.

Carson, D. (2001). Qualitative marketing research. London: Sage.


Cassell, C. & Symon, G. (2004). Essential guide to qualitative methods in organizational

research. London: Sage.

Castillo, J.J. (2009). Non Probability sampling. Available from http://www.experiment-

resources.com/non-probability-sampling.html. Accessed 21 may 2010.

Chant, S. & McIlwaine, C. (2009). Geographies of Development in the 21st Century: An

Introduction to the Global South. Cheltenham, UK: Edward Elgar publishing.

Christensen, E.H., Coombes-Betz, K.M. & Stein, M.S. (2007). The Certified Quality Process

Analyst Handbook. Milwaukee: American Society for Quality.

Cleland, D.I. & Gareis, R. (2006). Global project management handbook: planning, organizing,

and controlling international projects. New-York: McGraw-Hill.

Cleland, D.I. & Ireland, L.R. (2004). Project manager's portable handbook. New-York: McGraw-

Hill.

Cleland, D.I. & Ireland, L.R. (2010). Project manager's portable handbook, 3rd

Edition. New-York:

McGraw-Hill.

Cleland, D.I. & Ireland, L.R. (2006). Project Management: Strategic Design and Implementation,

5th Edition. New-York: McGraw-Hill.

Cleveland, S. (2006). “Manage your business processes to create a competitive advantage”. BP

Trends. February 2006.

Cohen, A.R. (2002). The portable MBA in management. New-York: Wiley.

Cohen, L., Manion, L. & Morrisson, K. (2007). Research methods in education, Sixth Edition.

Abingdon: Routledge.

Collis, J. & Hussey, R. (2003). Business research: a practical guide for undergraduate and

postgraduate students. Palgrave Macmillan.

Cooke-Davies, T. (2002). The “real” success factors on projects. International Journal of Project

management, 20: 185-190.


Cresswell, J.W. (2003). Research design: Qualitative, quantitative and mixed approaches, 2nd

Edition. Thousand Oaks: Sage Publications.

Crowe, A. (2005) The PMP Exam: How to Pass On Your First Try. Kennesaw, USA: Velociteach

Press.

Davies, A. (1999). A strategic approach to corporate governance. Aldershot, England: Gower

Publishing.

Davis, B. (2009). 97 Things Every Project Manager Should Know: Collective Wisdom from the

Experts. Sebastopol, Canada: O’reilly Media.

Del Barrio, C. (1999). The use of semi-structured interviews and qualitative methods for the study

of peer bullying. Universidad Autonoma de Madrid, Spain. Available from

http://old.gold.ac.uk/tmr/reports/aim2_madrid1.html. Accessed 28 May 2010.

De Vaus, D. (2002). Surveys in social research. London: Routledge

Dey, I. (1993). Qualitative data analysis: a user-friendly guide for social scientists. New-York.

Dinsmore, P.C. & Cabanis-Brewin, J. (2006). The AMA Handbook of Project Management. New-

York: AMACOM.

Dinsmore, P.C. & Cabanis-Brewin, J. (2010). The AMA Handbook of Project Management, 3rd

Edition. New-York: AMACOM.

Donnellan, B. (2006). The transfer and diffusion of information technology for organizational

resilience: IFIP TC8 WG 8.6 International Working Conference, June 7-10, 2006. Galway, Ireland.

New-York: Springer.

Dyer, C. (1995). Beginning research in psychology: a practical guide to research methods and

statistics. Malden, USA: Blackwell Publishing.

Dobson, M.S. (2004). The Triple Constraints in Project Management. Vienna: Management

Concepts.


Dobson, M.S. (2003). Streetwise Project Management: How to manage people, processes and

time, to achieve the results you need. Avon, USA: Streetwise Publication.

Doherty, M. (1994). Probability versus non-probability sampling in sample surveys. New Zealand

Statistical Review, March 1994 issue, pp 21-28. Available from

http://www.nss.gov.au/nss/home.NSF/75427d7291fa0145ca2571340022a2ad/768dd0fbbf616c71

ca2571ab002470cd/$FILE/Probability%20versus%20Non%20Probability%20Sampling.pdf.

Accessed 20 May 2010.

Doughty & Grieco. (2005). IT Governance: Pass or Fail? Information Systems Control Journal (2).

Available from

http://www.isaca.org/Content/ContentGroups/Journal1/20058/IT_Governance_Pass_or_Fail_(JO

nline).htm. Accessed 24 May 2009.

Du Plessis, J.J., McConvill, J. & Bagaric, M. (2005). Principles of contemporary corporate

governance. New-York: Cambridge University Press.

Easterby-Smith, M., Thorpe, R. & Lowe, A. (2002). Management research: an introduction, 2nd

edition. London: Sage.

Economist Intelligence Unit (EIU) (2009). Closing the gap: The link between project management

excellence and long-term success.[Online] Available at

http://viewswire.eiu.com/report_dl.asp?mode=fi&fi=1865031771.PDF&rf=0 (Accessed on 02 April

2011).

Egger, A. & Carpi, A. (2008). “Research Methods: Modelling”, Vision Learning Vol. POS-1 (8).

[Online] available at http://www.visionlearning.com/library/module_viewer.php?mid=153

Accessed on 01 December 2010.

Enterprise Architecture (EA). (2009). COBIT: From Strategy to Execution [Online]. Available at

http://iea.wikidot.com/cobit. Accessed on 10 May 2011.

ESDS Qualidata. (2007). ESDS Qualidata Teaching Resources: Exploring diverse interview

types. Available from http://www.esds.ac.uk/qualidata/support/interviews/semi.asp. Accessed 01

June 2010.


Esteves, J. (2010). Proceedings of the 9th European Conference on Research Methods in

Business and Management: IE Business School Madrid, Spain, 25-25 June 2010. Spain: IE

Business School.

Flick, U. (2009). An introduction to qualitative research, Fourth Edition. London: Sage

Floyd, C. (1997). Managing technology for corporate success. Farnham, U.K: Gower Publishing

Ltd.

Folkerts-Landau, D.F. & Lindgren, C.J. (1998). Toward a Model for Financial Stability.

Washington: International Monetary Fund.

Frigenti, E. & Comninos, D. (2002). The practice of project management: a guide to the business-

focused approach. London: Kogan Page Publishers

Garland, R. (2009). Project governance: A practical guide to effective project decision-making.

London: Kogan Page Publishers

Ghauri, P & Grønhaug, K. (2005). Research Methods in Business Studies: A Practical Guide (3rd

Edition). Harlow: Financial Times Prentice Hall

Gibbs, W. (1994). Software chronic crisis. Scientific American, 271 (3): 86-95.

Gilb, T. & Brodie, L. (2005). Competitive engineering: a handbook for systems engineering,

requirements engineering, and software engineering using language. Oxford, UK: Butterworth-

Heinemann.

Gill, J. & Johnson, P. (2002). Research methods for managers, Third Edition. London: Sage

Publications.

Golden, T.W., Skalak, S.L. & Clayton, M.M. (2006). A guide to forensic accounting investigation.

New York: John Wiley & Sons

Goodwin, W.L. & Goodwin, L.D. (1996). Understanding qualitative and quantitative research in

early childhood and education. New York: Teachers College Press.


Gorlin, R.A. (1999). Codes of Professional Responsibility: Ethics Standards in Business, Health,

and Law. BNA Books.

Goulding, C. (2002). Grounded theory: a practical guide for management, business and market

researchers. London: sage.

Gowthorpe, C. & Blake, J. (1998). Ethical Issues in Accounting. Oxon: Routledge.

Grant, J.L. & Abate, J.A. (2001). Focus on value: A corporate and investor guide to value

creation. New Jersey: John Wiley & Sons.

Gray, J.E. (2008). Using Lean to Improve an Audit Program. The Auditor; e-edition; July 2008.

Available http://www.theauditoronline.com/e_edition/e_edition_article_1.html. Accessed 20

August 2008.

Gray, I. & Manson, S. (2005). The Audit Process: Principles, Practices and Cases, Third edition.

London: Thomson Learning.

Grenny, J., Maxfiel, D. & Simberg, A. (2007). How project leaders can overcome the crisis of

silence. MIT Sloan Management Review, Summer 2007, 48(4). Available from

http://vingus.com/course%20work%20data%20files/CIS8000/grenny.silence.pdf (Accessed 11

February 2010).

Gudentops, E. (2004). Governing through COBIT. In W. Van Gremburgen, ed. Strategies for

information technology governance. Hershey, USA: Idea Group Publishing.

Guba, E. & Lincoln, Y. (1994). ‘Competing paradigms in qualitative research’, in Denzin & Lincoln

(eds). Handbook of Qualitative Research. London: Sage, pp 105-17.

Gupta, K. (2005). Contemporary auditing, 2nd

Edition. New Delhi: Tata McGraw-Hill.

Haggar, B. (2003). The Biomedical Quality Auditor Handbook. Milwaukee: American Society for

Quality.

Hall, J.A. (2000). Information Systems Auditing and Assurance. London: Thomson.

Hall, J.A. & Singleton, T. (2005). Information Technology Auditing and Assurance, second edition.

USA: Thomson South Western.


Hammell, K.W, Carpenter, C. & Dyck, I. (2000). Using qualitative research: a practical

introduction for occupational and physical therapists. Amsterdam: Elsevier Health Sciences.

Hart, C. (1998). Doing a Literature Review. London: Sage Publishing.

Hartman, F. & Ashrafi, R.A. (2002). Project management in the Information Systems and

Information Technologies industries. Project Management Journal. Sep 2002, 33 (3):5-15.

Hatch, J.A. (2002). Doing qualitative research in education settings. New-York: Suny Press.

Haugan, G.T. (2006) Project Management fundamentals: Key concepts and methodology.

Garner, USA: Management Concepts.

Haugan, G.T. (2011) Project Management fundamentals: Key concepts and methodology.

Garner, Second Edition. USA: Management Concepts.

Haughey, D. (2009). Project Management Body of Knowledge. Available from

http://www.projectsmart.co.uk/pdf/pmbok.pdf (Accessed 30 June 2010).

Heldman, K. (2003). Project Management Jumpstart. John Wiley & Sons.

Heldman, K. (2009). PMP: Project Management Professional Exam Study Guide. New-York:

John Wiley and Sons.

Heldman, K & Mangano, V. (2009). PMP: Project Management Professional Exam Review Guide.

New-York: John Wiley and Sons.

Henrichsen, L., Smith, M.T. & Baker, D.S. (1997a). Taming the research beast. Available from

http://linguistics.byu.edu/faculty/henrichsenl/researchmethods/RM_1_04.html. Accessed 10 May

2008.

Henrichsen, L., Smith, M.T. & Baker, D.S. (1997b). Taming the research beast. Available from

http://linguistics.byu.edu/faculty/henrichsenl/researchmethods/RM_2_04.html. Accessed 10 May

2008.

Herman, L. & Vervaeck, B. (2005). Handbook of narrative analysis. USA: University of Nebraska

Press.


Hightower, R. (2008). Internal Controls Policies and Procedures. NY: John Wiley & Sons.

HIH Royal Commission. (2001). Directors’ duties and other obligations under the corporation act.

Background Paper 11:27, para 76. Available from http://www.hihroyalcom.gov.au. Accessed on

21 may 2009.

Hilb, M. 2004. New Corporate Governance: Successful Board Management Tools. Switzerland:

Springer.

Hoepfl, M.C. (1997). Choosing qualitative research: a primer for technology education

researchers. Journal of Technology Education, 9(1).

Hoogervorst, J.A. (2009). Enterprise Governance and Enterprise Engineering. The Netherlands:

Springer.

Holloway, I. (1997). Basic concepts for qualitative research. Malden, USA: Blackwell Science Ltd.

Howell, M. (2009). Project management on track. Cornwall, UK: Academy Press.

Huber, M. & Pallas, M. (2006). Customising stakeholder management strategies: concepts for

long-term business success. Warren, USA: Springer.

Hunter, M.G. & Tan, F.B. (2006). Advanced topics in global information management, Volume 5.

Hershey, USA: Idea Group Publishing.

Ibbs, C.W. & Kwak, Y.H. (2000). Assessing Project Management Maturity. Available from

http://home.gwu.edu/~kwak/pmass.pdf. Accessed 30 June 2010.

IDRC (2004). Module 10A: Overview of Data Collection Techniques. Accessed from

http://www.idrc.ca/en/ev-56606-201-1-DO_TOPIC.html. Accessed on 10 June 2008.

Institute of Internal Auditing (IIA). (2008). Available from www.theiia.org. Accessed 10 July 2008.

International Association of Project and Program Management (IAPPM). (2008). A guide to

project management auditing, assessments and recommendations [Online]. Available at

www.iappm.org. (Accessed on 10 March 2011).


International Register of Certificated Auditors (IRCA). (2000). Available from

http://www.irca.org/about/glossary.html#I. Accessed 15 August 2008.

ISACA (Information Systems Audit and Control Association). (2007). Control Objectives for

Information related Technology (COBIT) 4.1 Framework. Available from

http://www.isaca.org/cobit.htm. Accessed 25 May 2010.

ISACA (Information Systems Audit and Control Association). (2009). Risk IT Framework.

Available from http://www.isaca.org/riskIT.htm. Accessed 01 May 2011

Institute on Governance (IOG). (2009). Available from

http://www.iog.ca/boardgovernance/html/gov_whe.html. Accessed 20 May 2009.

iSeries. (2004). iSeries Extra Administrators Newsletter. Accessed on 04 November 2010.

Israel, G.D. (2009). Analyzing Survey Data. University of Florida, IFAS Extension. Available from

http://edis.ifas.ufl.edu/pd007. Accessed 02 April 2010.

Jackson, S.L. (2007). Research Methods: A modular approach. Mason, USA: Cengage Learning.

Jancowicz, A.D. (2005). Business research projects. UK: Cengage Learning.

Jenkins, G.H. (2008). IT Governance: Policies & Procedures. New-York: Aspen Publishers.

Johnson, P. & Clark, M. (2006). ‘Mapping the terrain: and overview of business and management

research methodologies’, in Johnson & Clark. (eds) Business and Management Research

Methodologies. London: Sage.

Jordan, G.D. & Lategan, L.O.K. (2010). Modelling as research methodology. South Africa: African

Sun Media.

Kahn, R.L. & Cannell, C.F. (1957). The dynamics of interviewing: theory, technique, and cases.

USA: Wiley.

Kent Crawford, J. (2002). The strategic Project Office: A guide to improving organisational

performance. Boca Raton, USA: CRC Press.


Kerzner, H. (2001). Strategic Planning for Project Management Using a Project Management

Maturity Model. Available from http://www.allbusiness.com/management/1031510-1.html.

Accessed 20 January 2008.

Kerzner, H. (2004). Advanced project management: best practices on implementation. New-York:


King Report for Corporate Governance in South Africa (King III, 2009). Available from

www.cliffedekker.com. Accessed 01 April 2010.

Kloppenborg, T.J. (2009). Contemporary Project Management. Mason, USA: Cengage Learning.

Kothari, C.R. (2008). Research Methodology: Methods and Techniques. New Age.

Kretschmer, K. (2008). Performance evaluation of foreign subsidiaries. Germany: Garber Verlag.

Kvale, S. (1996). Interviews: an introduction to qualitative research interviewing. Thousand Oaks,

USA: Sage.

Label, W. (2010) Accounting for non-accountants: The fast and easy way to learn the basics.

Illinois: Sourcebooks.

Labuschagne, L., Marnewick, C. & Jakovljevic, M. (2008). “IT Project Management Maturity: A

South African Perspective”. Proceedings of the PMSA Conference 2008: From Strategy to

Reality.

Landy, F.J. & Conte, J.M. (2009). Work in the 21st Century: An Introduction to Industrial and

Organizational Psychology. New Jersey: John Wiley & Sons.

Lechtman, E. (2005). A Holistic Framework for Successful Sponsoring IT Projects from an IT

Governance Perspective, MCom dissertation, University of Johannesburg: South Africa

Lehner, P.N. (1998). Handbook of ethological methods. Cambridge, UK: Cambridge University

Press.

Leicestershire City Council. (2008). Available from www.leics.gov.uk. Accessed 20 July 2008.


Lewis, J.P. (2005). Project Planning, Scheduling, and Control: A Hands-on Guide to Bringing

Projects in on Time and on Budget. New-York: McGraw-Hill.

Lewis, J.P. (2006). The project manager’s desk reference: Project planning, scheduling,

evaluation, control, systems. New-York: McGraw-Hill.

Lewis, J.P. (2007). Fundamentals of Project Management. New York: AMACOM.

Lock, D. 2007. Project Management, Ninth Edition. Aldershot, England: Gower Publishing.

Luckey, T. & Phillips, J. (2006). Software Project Management for dummies. New Jersey: Wiley.

Lunsford, T.R. & Lunsford, B.R. (1995). The research Sample, Part I: Sampling. JPO Online

Library (3) 7:105-112. Available from http://www.oandp.org/jpo/library/1995_03_105.asp.

Accessed 28 March 2010.

Machi, L.A. & McEvoy, B.T. (2009). The Literature Review: Six Steps to Succeed. Thousand

Oaks, USA: Corwin Press.

Macnee, C.L. & McCabe, S. (2008). Understanding nursing research: using research in evidence-

based practice, Second Edition. Philadelphia: Lippincott Williams & Wilkins.

Maizlish, B & Handler, R. (2005). Information Technology Portfolio Management Step-by-Step:

Unlocking the Business Value of Technology. New-York: John Wiley and Sons.

Malachowski, A.R. (2001). Business Ethics: Critical Perspectives on Business and Management.

London: Routledge.

Marschan-Piekkari, R. & Welch, C. (2004). Handbook of qualitative research methods for

international business. Cheltenham, UK: Edward Elgar publishing.

Martin, P.K. & Tate, K. (2001). Getting started in project management, Volume 47. New-York:


Matthews, D. (2006). A history of auditing: The changing audit process in Britain. London:

Routledge.


Mattie, A. & Camozzi, A. (2005). Qualitative research for tobacco control: a how-to introductory

manual for researchers and development practitioners. Ottawa: IDRC.

McGill University. (2006). Available from

http://www.mcgill.ca/internalaudit/objectives/primary/operational. Accessed 20 July 2008.

McGivern, Y. (2006). The practice of social and market research: An introduction, Second Edition.

Harlow: Pearson Education Limited.

McLane, G. (2003). IT governance and its impact on IT management. Masters dissertation.

Sydney: University of technology Sydney.

McMullin, J. (2007). To builder business buy-in, designers need to buy into business. Available

from http://nform.ca/publications/investing-in-design. Accessed 12 March 2010.

Merriam, S.B. (2009). Qualitative research: A guide to design and implementation. San

Francisco: John Wiley & Sons.

Miles, M.B. & Huberman, A.M. (1994). Qualitative data analysis: an expanded sourcebook. USA:

Sage.

Miller, D.C. & Salkind, N.J. (2002). Handbook of research design and social measurement, 6th

Edition. Thousand Oaks, USA: SAGE.

METI (Japanese Ministry Economy, Trade and Industry) (1999). Corporate approaches to IT

governance. [online] Available at http://www.jipdec.or.jp/chosa/MITIBE/index.htm (Accessed on

01 April 2011).

Moeller, R. R. (2004). Sarbanes-Oxley and the New Internal Auditing Rules. New-York: John

Wiley and Sons.

Moeller, R. R. (2007). COSO Enterprise Risk Management: Understanding the New Integrated

ERM Framework. NY: John Wiley and Sons.

Moeller, R. R. (2009). Brink’s Modern Internal Auditing: A Common Body of knowledge. New-

York: John Wiley and Sons.


Monash University (2010). IT Architecture. [Online] available at

http://www.its.monash.edu.au/staff/architecture/. (Accessed on 01 May 2011).

Mooz, H., Forsberg, K. & Cotterman, H. (2003). Communicating project management: the

integrated vocabulary of project management and systems engineering. New-York: John Wiley &

Sons.

Morris, P.G., Pinto, J.K. & Soderlund, J. (2011). The Oxford handbook of project management.

New-York: Oxford University Press.

Moustafaev, J. (2010). Delivering exceptional project results: A practical guide to project

selection, scoping, estimation and management. Fort Lauderdale: J Ross Publishing

Muijs, D. (2004). Doing quantitative research in education with SPSS. London: SAGE.

Muller, R. (2009). Project governance. Surrey, England: Gower Publishing.

Munhall, P. (2007). Nursing research: a qualitative perspective. Canada: Jones & Bartlett

Learning.

Murray, G. (2002). Work and employment relations in the high-performance workplace. London:

Routledge.

Murray Thomas, R. (2003). Blending qualitative & quantitative research methods in theses and

dissertations. (pp 2-7) Thousand Oaks: Crowing Press.

Murthy, B. (2008). Research Methodology: Modelling and Methods. Presented at International

Congress on Pervasive Computing and Management. Delhi School of Economics.

Neelan, M.H. (2006). Focus on Finance and Accounting Research. New-York: Nova Science

Publishers.

Nicholas, J. (2004). Project Management for business and engineering: Principles and practice,

Second Edition. Oxford, UK: Butterworth-Heinemann.

Nicholas, J & Steyn, H. (2008). Project Management for business and engineering: Principles and

practice, Third Edition. Oxford, UK: Butterworth-Heinemann


Office of Audit Compliance and Privacy (OACP). (2006). Audits. University of Pennsylvania.

Available from http://www.upenn.edu/audit/oacp/audit/audit.htm#types. Accessed 15 July 2008).

Office of Government Commerce (OGC). (2007). The Official Introduction to the ITIL Service Life

Cycle. UK: The Stationary Office.

Ohara, S. (2010). Framework of Contemporary Japanese Project Management (1): Project

Management Paradigm – Interpretation, Application and Evolution to KPM. [online] Available on

http://www.worldscibooks.com/etextbook/6657/6657_chap01.pdf. Accessed on 24 September

2010.

Olivier, M.S. (2009) “Information Technology Research: A Practical Guide for Computer Science

and Informatics, 3rd

Edition”. Pretoria: Van Schaik.

Olsen, C. & St. George, DM. (2004). Cross-sectional study design and data analysis. [Online]

Available on http://www.collegeboard.com/prod_downloads/yes/4297_MODULE_05.pdf

Accessed on 15 January 2011

Oppenheim, A.N. (2000). Questionnaire design, interview and attitude measurement. New-York:

Continuum International Publishing Group.

ORAU, (n.d.). Quantitative research methods. Available from

http://www.orau.gov/cdcynergy/demo/Content/activeinformation/tools/toolscontent/quantiativemet

hods.htm. Accessed 01 July 2010.

O’Reilly, V.M., McDonnell, P.J., Winograd, B.N., Gerson, J.S., Jaenicke, H.R. (1999).

Montgomery Auditing Continuing Professional Education. New-York: John Wiley & Sons.

Otto, R.A, Dhillon, J & Watkins, K. (1993). Implementing Project Management in large-scale

Information-Technology projects. AMA Handbook of Project Management: 352-361.

Patton, M.Q. (2002). Qualitative research and evaluation methods, Third Edition. Thousand Oaks,

USA: SAGE

Petroni, G. & Cloete, F. (2005). New technologies in public administration, Volume 28.

Amsterdam: IOS Press.


Phillips, J. (2007). CAPM/PMP Project Management All-in-One Exam Guide. New-York: McGraw-

Hill.

Phillips, N. & Hardy, C. (2002). Discourse analysis: investigating processes of social construction.

London: Sage.

Pitagorsky, G. (2007). The Zen Approach to Project Management: Working From Your Center To

Balance Expectations and Performance. New-York: IIL Publishing.

PM Forum (2010). [online] Available at

http://www.pmforum.org/standards_certifications/index.htm. (Accessed on 05 September 2010).

Powell, R. R. (1997). Basic research methods for librarians, Third Edition. Westport, USA:

Greenwood Publishing Group.

Powney, J. & Watts, M. (1987). Interviewing in education research. London: Taylor & Francis.

Project Management Institute (PMI). (2007). Project Management Competency Development

(PMCD) Framework. Newtown Square, USA: PMI.

Project Management Institute (PMI). (2008). A Guide to the Project Management Body of

Knowledge (PMBoK® Guide), 4th Edition. Newtown Square, USA: PMI

Project Management Institute (PMI). (2010). [online] Available on

http://www.pmi.org/Certification/Why-Choose-a-PMI-Certification.aspx. Accessed on 05

September 2010.

Project Management South Africa (PMSA). (2010). [online] Available at

http://www.pmisa.org.za/page.aspx?Id=15&CateId=2&Category=About%20Us&SubCateId=15&S

ubCategory=Profile (Accessed on 15 August 2010).

Punch, F.P. (2006). Developing effective research proposals, Second Edition. Thousand Oaks,

USA: SAGE.

Puttick, G., Van Esch & Kana, S. (2008). The Principles and Practice of Auditing, Ninth Edition.

Cape Town: Juta & Co. Ltd.


Raffa, P.C. (2003). Levels of Service. Available from

http://www.cof.org/files/Documents/Education_Collaborations/Audit%20Conference%20Call%20

Handouts/3_Levels_of_Attestation_Services_Defined-HANDOUT_3.pdf. Accessed 27 June 2008.

Ramamoorti, S. (2003). Internal Auditing: History, evolution, and prospects. The Institute of

internal Auditors Research Foundation. Available from

http://www.yektatadbir.com/maghalatkharegi/hesabresidakheli/7.pdf Accessed 10 July 2010.

Ratcliffe, T.A. & Landes, C.E. (2009). Understanding Internal Controls and Internal Control

Services. [Online] www.aicpa.com (Accessed on 29 05 November 2010).

Raybould, M. (1996). Is Project Management of software projects a special case? Proceedings of

the Project management Institute’s 27th Annual Symposium: 549-554. Boston, MA. Upper Darby,

PA: PMI.

Renz, P.S. (2007). Project governance: implementing corporate governance and business ethics

in non-profit organizations. New-York: Springer.

Richey, R. & Klein, J.D. 2007. Design and development research: Methods, strategies and

issues. New Jersey: Routledge.

Ridley, G., Young, J. & Carroll, P. (2004). COBIT and its Utilisation: A Framework from the

literature. Proceedings of the 37th Hawaii international conference on System Sciences (HICSS).

Hawaii: Institute of Electrical and Electronics Engineers.

Ritchie, J. & Lewis, J. (2003). Qualitative research practice: a guide for social science students

and researchers. Thousand Oaks, USA: SAGE.

Robson, C. (2002). Real World research (2nd

Edition). Oxford: Blackwell.

Roetzheim, W. (1993). Managing software projects: Unique problems and requirements. AMA

Handbook of Project Management: 341-352. New York: Amacom.

Rose, K. (2005). Project quality management: Why, What and How. Boca Raton, USA: J. Ross

Publishing.


Rosenbaum, A. (1996). Good Governance, Accountability and the Public Servant. Available from

http://unpan1.un.org/intradoc/groups/public/documents/NISPAcee/UNPAN005698.pdf. Accessed

20 May 2009.

Rumbold, G. (1999). Ethics in Nursing Practice. China: Elsevier Health Sciences.

Ruspini, E. (2002). Introduction to longitudinal research. USA: Routledge.

Russell, J.P. (2005). The ASQ Auditing Handbook: Principles, Implementation, and Use, Third

Edition. Milwaukee: American Society for Quality.

Saladis, F.P. & Kerzner, H. (2009). Bringing the PMBOK Guide to Life: A Companion for the

Practicing Project Manager. New-York: John Wiley & Sons.

Samuels, R. (1996). Managing software programs: A different kind of animal. Proceedings of the

Project Management Institute’s 27th Annual Symposium: 627-633. Boston, MA, Upper Darby, PA:

PMI.

Sarbanes, P & Oxley, M (2002). Sarbanes-Oxley Act of 2002. Available from www.findlaw.com.

Accessed 05 March 2008.

Saunders, M, Lewis, P & Thornhill, A. (2009). Research methods for business students (5th

Edition). Harlow: Financial Times Prentice Hall.

Scheid, J. (2010). Protocol for a project management audit [Online]. Available at

http://www.brighthub.com/office/project-management/articles/73959.aspx. Accessed on 01 March

2011.

Schensul, S.L., Schensul, J.J. & LeCompte, M.D. (1999). Essential ethnographic methods:

observations, interviews, and questionnaires. Walnut Creek, USA: Altamira Press.

Schwalbe, K. (2009). Information Technology Project management, 6th Edition. Stamford:

Cengage Learning.

Senft, S. & Gallegos, F. (2008). Information Technology Control and Audit. Boca Raton, USA:

CRC Press.


Shamoo, A.E. (1989). Principles of research data audit. New York: Gordon & Breach.

Shuttleworth, M. (2008). Definition of research. [online] Available on http://www.experiment-

resources.com/definition-of-research.html. Accessed on 10 Dec 2010.

Siegel, J.G. & Shim, J.K. (2006). Accounting handbook, Fourth Edition. New York: Barron’s

Educational Series.

Singh, D. (2007). Banking Regulation of UK and US Financial Markets. Aldershot, England:

Ashgate Publishing, Ltd.

Skyview Partners (2004). COBIT Security. [Online] Available at

http://skyviewpartners.com/pdf/COBIT_Security.pdf. (Accessed on 10 October 2010).

Smith, F. (2002). Research methods in pharmacy practice. Grayslake, USA: Pharmaceutical

Press.

Spencer-Pickett, K.H. (2004). The Internal Auditor at Work: A Practical Guide to Everyday

Challenges. New-York: John Wiley and Sons.

Spencer-Pickett, K.H. (2010). The Internal Auditing Handbook, Third Edition. Chichester, UK:

John Wiley & Sons.

Squire, L. & Van der Tak, H.G. (1975). Economic analysis of projects. Baltimore: World Bank

Publications.

Stake, R.E. (2010). Qualitative research: Studying how things work. New York: Guilford Press.

Stackpole, C. (2010). A user’s manual to the PMBOK Guide. New York: John Wiley & Sons.

Standish Group. (1995). Chaos. Available from: http://www.projectsmart.co.uk/docs/chaos-

report.pdf (Accessed 20 November 2008).

Stanleigh, M. (2009). Undertaking a successful project audit [Online]. Available at

http://www.projectsmart.co.uk/undertaking-a-successful-project-audit.html. Accessed on 01

March 2011.


StatSoft. (2009). Categorization in STATISTICA frequency tables. Available from

http://www.statsoft.com/LinkClick.aspx?fileticket=Uc8jnXBY8j0%3D&tabid=115. Accessed 06

April 2010.

Stepanek, G. (2005). Software Project Secrets: Why Software Projects Fail. Berkeley, CA:

Apress.

Stober, T. & Hansmann, U. (2009). Agile Software development: best practices for large software

development projects. Eidelberg, Germany: Springer

Strauss, A.L. & Corbin, J.M. (2008). Basics of qualitative research: techniques and procedures for

developing grounded theory. New-York: Sage.

Strohm, C. & SpringerLink. (2006). United States and European Union Auditor Independence

Regulation: Implications for Regulators and Auditing Practice. Publisher: DUV.

Tarantino, A. (2008). Governance, Risk and Compliance Handbook: Technology, Finance,

Environmental and International guidance and Best Practices. NY: John Wiley & Sons.

Tarantino, A. & Cernauskas, D. (2009). Risk Management and Finance: Six Sigma and Other

Next generation Techniques. NY: John Wiley & Sons.

Tashakkori, A. & Teddie, C (1998). Mixed Methodology: Combining Qualitative and Quantitative

Approaches. Thousand Oaks, CA: Sage.

Tassoni, P. (2007). CACHE Level 3 Child Care and Education, Fourth Edition. Oxford:

Heinemann.

Tenenbaum, G. & Driscoll, M.P. (2005). Methods of research in sport sciences: quantitative and

qualitative approaches. Oxford: Meyer & Meyer Sport (UK) Ltd.

Thomas, J.R., Nelson, J.K. & Silverman, S.J. (2005). Research methods in physical activity, Fifth

Edition. Champaign, USA: Human Kinetics.

Tipton, H.F. & Krause, M. (2007). Information Security Management Handbook, Sixth Edition.

USA: CRC Press.


Trochim, W.M. (2006). The research method knowledge base. Design. [Online] Available from

http://www.socialresearchmethods.net/kb/design.php. Accessed 10 May 2008.

UK Cadburry Report. (1992). The financial aspects of Corporate Governance. [Online] Available

from http://www.ecgi.org/codes/documents/cadbury.pdf. Accessed 18 June 2009.

UN Economic and Social Commission for Asia and the Pacific (UNESCAP). (2009). Available

from http://www.unescap.org/pdd/prs/ProjectActivities/Ongoing/gg/governance.asp. Accessed 20

May 2009.

University of Alberta. (2007). Available from

http://www.uofaweb.ualberta.ca/internalaudit/nav01.cfm?nav01=41677. Accessed 20 July 2008.

University of Melbourne. (2005). Available from

http://www.unimelb.edu.au/audit/services/financial.html. Accessed 15 August 2008).

US National Research Council. (2000). National research initiative: A vital competitive grant

program in food, fibre and natural resources research. Washington, USA: National Academies

Press

Van Bon, J. (2007). Release and Control for IT Service Management, Based on ITIL: A

Practitioner’s Guide. The Netherlands: Van Haren Publishing.

Van Bon, J. & Pieper, M. (2008). Service Strategy Based ON ITIL v3: A Management Guide. The

Netherlands: Van Haren Publishing.

Van Grembergen, W. (2004). Strategies for IT Governance. The Idea Group.

Varkevisser, C.M., Pathmanathan, I & Brownlee, A.T. (2003). Designing and conducting health

systems research projects: Proposal development and fieldwork, Volume 1. Ottawa: IDRC.

Verma, G.K. & Mallick, K. (1999). Researching education: Perspectives and Techniques. London:

Routledge.

Verzuh, E. (2008). The fast forward MBA in Project Management. New-York: John Wiley and

Sons.


Vinten, G. (2005). Managerial auditing journal: Financial regulation, Volume 20, Issue 3. Emerald

Group Publishing.

Wallace, M, & Webber, L. (2008). IT Governance Policies and Procedures 2009. NY: Aspen

Publishers Online.

Watne, T.A. & Turney, P.B. (2002). Auditing EDP Systems, Second Edition. South Africa:

Prentice hall International Editions.

Weiss, S. (2002). Hand-held usability. New-York: John Wiley & Sons.

Western Washington University. (2006). [Online] Available from

http://www.wwu.edu/depts/internalaudit/types.shtml. Accessed 10 July 2008.

Whittington & Pany. (1998). Principles of Auditing. McGraw-Hill.

Wild, J. & Diggines, C. (2010). Marketing research. Cape Town: Juta and Company Ltd.

William, M. (2000). Interpretivism and generalisation. [Online] Available from

http://www.slis.indiana.edu/faculty/hrosenba/www/Research/methods/williams_generalization.pdf.

Accessed on 25 January 2011.

Wood, L.A. & Kroger, R.O. (2000). Doing discourse analysis: methods for studying action in talk

and text. London: Sage.

Woolf, E. (1997). Auditing Today. UK: Prentice Hall

Wyman, O. (2007). The new finance and risk agenda: What’s your risk appetite? Available from

http://www.mmc.com/knowledgecenter/newFinance_RiskAppetite_OW.pdf. Accessed 15

December 2009.

Yin, R.K. (2003). Applications of case study research, Second Edition. Thousand Oaks, USA:

Sage.

Yukon Executive Council (YEC). (2008). Types of audit. Available from

http://www.eco.gov.yk.ca/govaudserv/audit_types.html. Accessed 20 July 2008).

_____________________________________________________________________ Appendix A: Interview Invitation Letter 168

APPENDIX A: Interview invitation letter IT PROJECT MANAGEMENT INTERVIEW 2010

Dear participant, Thank you for your willingness to participate in this research project on IT Project Management Audit. Below is more information regarding this project:

Why are we doing this? The aim of the project is to develop a model for IT Project Management auditing. This model, based on the PMBoK® Guide, 4

th Edition, is intended to serve as a guideline to IT auditors in a project management environment. The audit

focuses primarily on the project management processes followed throughout the project life cycle, and not on the project deliverables. The conceptual model in this research is built on the project management processes involving a project charter – either as a direct input or output. However, the model should be applicable to any of the forty-two project management processes outlined in the PMBoK® Guide, 4

th Edition.

Who are the researchers?

This study is being carried out by Mr. Jean-Paul Muka, M-Tech student at the University of Johannesburg. The study is supervised by Dr. Carl Marnewick, Head of Department of Business Information Technology, Faculty of management, University of Johannesburg.

What do we request from you in the study? Participation in this interview is voluntary and anonymous. By providing the information requested in the interview, you agree to participate in this research and to the publication of the results with the understanding that anonymity will be preserved. The interview will take you, at most, 45 minutes. All questions are closed (yes/no) questions. However, to accommodate the qualitative aspect of this study, you could have the opportunity to clarify or further elaborate on your answer to the interviewer. Furthermore, based on your answers to the questions, some logical follow-up questions could be asked, in an attempt to gather the most precise information.

How are we going to use the results? This is an anonymous interview. We are not attempting to uncover your identity, the identity of your organisation, or examine the response on an individual basis. The result of the project will be published, but you may be assured that any information obtained in connection with this study, which may identify you, will remain confidential and will not be disclosed.

What are we doing to ensure confidentiality? To ensure confidentiality, data is stored electronically in a database, on a secured server, and access is restricted to the researchers. Printed questionnaires or other physical evidence of the interview (e.g. recorded tape) will be stored in a locked storage room for a period of five years, after which the information will be destroyed. If at any stage you have any queries or concerns regarding your participation in the study, please feel free to contact us directly Yours truly, Dr. Carl Marnewick Head of Department Department of BIT Faculty of Management University of Johannesburg Auckland Park Bunting Road Campus Johannesburg Tel: +27 (0)11 559 1316 Fax: +27 (0)11 559 1239 Email: [email protected] http://www.uj.ac.za/bit

_____________________________________________________________________ Appendix B: Interview Transcripts 169

APPENDIX B: Interview Transcripts

Interview 1 a. Case overview

� Case description: The project is concerned with the implementation of an electronic content and document management at a financial institution. The project aims to consolidate all customer data records, in view of establishing a “single source of truth” across the enterprise.

� Industry: Financial � Type of project: External project � Respondent’s contact details: Anonymous � Respondent’s job role: Project Manager � Interview date: 25 Feb 2010. � Interview duration: 45 minutes

b. Feedback to audit questionnaire

# Question Objective Answer Additional Comments

P1 – Develop Project Charter

1 Does a project charter exist?

Verify the existence of a formal document authorizing the project.

Yes Seeing that the project is conducted by a services organization, the signed Statement of Work (SOW) is the official authorization document for the project to start.

2 Is the project charter signed by all identified key stakeholders?

Verify whether the project has been authorized by all identified key stakeholders.

No The Statement of Work (SOW) only makes provision for two signatories, namely the Business Unit Executive from the performing organization, and the sponsor from the client.

3 Was the project charter signed by all identified key stakeholders prior to the official project start date?

Verify whether the project was formally authorized by the time of its official start.

Yes The project may not commence without both above-mentioned signatures.

4 Was the signed project charter communicated to the entire project team?

Verify whether everyone taking part in the project has been informed of the project’s formal authorization, and the terms under which it has been authorized.

Yes The project sponsor has communicated the signed SOW to all identified stakeholders from the customer side. The Business Unit Executive has done the same to all identified stakeholders on the performing organization’s side. The SOW has been made available through a project management portal, for the benefit of external stakeholders (e.g. business partners and the procurement division)

P2 – Identify Stakeholders

5 Are all key stakeholders identified prior to the project start?

Verify whether key stakeholders on the project were identified prior to project start.

Yes All effort is made to identify all stakeholders, even though there is no guarantee that new stakeholders won’t emerge after the initial project authorization.

6 Is the relevant information about key stakeholders documented?

Verify whether the relevant information about the identified stakeholders has been documented in a stakeholder register or equivalent document. This information includes the stakeholders’ interest, involvement, impact on the project success, potential negative influence.

Yes

7 Has a strategy been developed on how to manage the identified stakeholders?

Verify whether a stakeholder management strategy has been created. This includes creating a stakeholder expectation management matrix, an issue log or equivalent.

Yes

P3 – Develop Project Management Plan


8 Is there a project management plan?

Verify the existence of a project management plan.

No There is no formal project management plan, including all nine knowledge areas. However, a project schedule is available (Gantt Chart)

9 Are all nine project management knowledge areas reflected in the project management plan?

Verify whether each of the nine knowledge areas is addressed in the project management plan (e.g. what part of the plan addresses project integration management, scope management, cost management, etc).

No

10 Is the project management plan up to date?

Verify whether the project management plan is current and up to date.

No

11 Is the project management plan communicated to all stakeholders?

Verify whether all team members have received and are aware of the project plan.

No However the project schedule is communicated to all stakeholders to whom it is deemed appropriate. Security and confidentiality aspects are taken into consideration in the communication.

P4 – Collect Requirements

12 Are stakeholder requirements defined and documented?

Verify whether there is a formal process for collecting, defining and documenting stakeholders’ expectations on the project.

Yes Included in SOW and elaborated in WBS

13 Are the stakeholder requirements tracked throughout the project?

Verify whether the stakeholders’ requirements are tracked, throughout the project, to ensure that approved requirements are delivered at the end of the project.

No There is still room for improvement on this aspect. This shortcoming is mainly due to the fact that formal project management is still not fully embraced in this young department.

14 Have the documented stakeholder requirements been collected from all identified key stakeholders?

Verify whether all identified key stakeholders have been consulted, and have had their requirements documented.

Yes All identified stakeholders (internal and external) have been consulted

P5 – Define Scope

15 Does the project have a project scope statement?

This question aims to verify whether there is a formal document detailing the work which forms part of the project, and the work specifically excluded from the project.

Yes Included in the Statement of Work. Includes namely: completion criteria, deliverables, inclusions, exclusions and assumptions.

16 Is the project scope statement communicated to all stakeholders?

This question aims to verify whether all stakeholders have been notified of the work included in the project, and the work excluded from the project.

Yes Included in SOW and communicated directly to stakeholders at both client and performing organization, as well as through a central portal, for external stakeholders.

17 Are changes to the project scope statement reflected in the other project documents, and communicated to all stakeholders, throughout the project?

This question aims to verify whether all the relevant project documents are updated to reflect a change in the project scope statement, should such change occur. The question also aims to verify whether all changes to the project scope statement are communicated to all stakeholders.

Yes Change request process in place. Approval process for any change is similar to the initial SOW approval. Any approved changes are immediately communicated to all stakeholders.



� Case description: The project is concerned with the implementation of a value-add service for mobile subscribers.

� Industry: Telecommunications � Type of project: Internal project � Respondent’s contact details: Anonymous � Respondent’s job role: Project Manager � Interview date: 03 Mar 2010. � Interview duration: 45 minutes






Yes Called approval request form



Yes The CIO is the project sponsor. Marketing department is the client. All other departments (e.g. Operations are stakeholders.



No Started based on the CIO’s go-ahead. All other departments signed along the way.



Yes Via email




Yes The repetitive nature of this type of internal projects makes it easier to identify all stakeholders from the beginning.



No Relatively small project. Project manager knows details about each stakeholder by heart.



No




Yes



No Some of the knowledge areas (e.g. risk, procurement) don’t exist formally. Others (e.g. scope, cost and communication) exist in separate documents or in emails



Yes Even though it exists in various documents. There is a risk of forgetting to update.



Yes Via email




Yes Defined but not fully documented


Verify whether the stakeholders’ requirements are tracked, throughout the project, to ensure that approved requirements are delivered at the end of the

Yes


project. 14 Have the documented stakeholder

requirements been collected from all identified key stakeholders?


Yes

P5 – Define Scope



Yes Included in the work request document (detailed document highlighting what is to be done)



Yes Via email



Yes



� Case description: The project is concerned with the implementation of an emergency calling line, with interactive voice response at a health care institution.

� Industry: Health Care � Type of project: External � Respondent’s contact details: Anonymous � Respondent’s job role: Project Manager � Interview date: 03 Mar 2010. � Interview duration: 45 minutes






Yes



Yes



Yes



Yes Via email, central portal




Yes



No Considered to be known by the project manager



No Ad hoc




Yes



Yes



No Project schedule systematically updated. The rest is updated haphazardly







Yes



Yes This is a condition for payment.

14 Have the documented stakeholder requirements been collected from all

Verify whether all identified key stakeholders have been consulted, and have had their

Yes


identified key stakeholders?

requirements documented.

P5 – Define Scope



Yes



Yes



No Only changes to project schedule are communicated throughout the project.



� Case description: The project is concerned with the development of an online payment platform at a financial institution.

� Industry: Financial � Project type: External � Respondent’s contact details: Anonymous � Respondent’s job role: Project Manager � Interview date: 05 Mar 2010. � Interview duration: 45 minutes






Yes Called project authorization document



No Few signatures pending. Project manager following up. Those considered as main stakeholders have signed (CIO from client side and Chief Architect from supplier side)



No



No Will be communicated once signed by all




Yes



No Not formally, even though some knowledge exists.



No Not formally. Managed ad hoc.




Yes



Yes



Yes Updated after the weekly project review







No They are known but not thoroughly documented



Yes This is a pre-requisite for payment




Yes Kick-off workshop

P5 – Define Scope



Yes






Yes All documents updated weekly after weekly project review meeting.



� Case description: The project is concerned with upgrading the subscriber provisioning platform. � Industry: Telecommunications � Type of project: External project � Respondent’s contact details: Anonymous � Respondent’s job role: Project Manager � Interview date: 05 Mar 2010. � Interview duration: 45 minutes






Yes Comprehensive document including all projects to be deployed for the year



Yes



Yes



Yes Communicated to project managers from each department, who in turn communicate it to their respective teams (e.g. IT. Core Network, etc.).




Yes



Yes Stakeholder register



Yes




Yes



Yes



Yes The client enforces this as a pre-requisite for payment, as this is a project led by an external firm







Yes



Yes This is enforced as a pre-requisite for payment.

14 Have the documented stakeholder Verify whether all identified key stakeholders Yes Through the different department


requirements been collected from all identified key stakeholders?

have been consulted, and have had their requirements documented.

project managers, who are the contact points (interfaces) with the project management performing organization

P5 – Define Scope



Yes



Yes Through the different department project managers, who are the contact points (interfaces) with the project management performing organization



Yes Communicated via email through the different department project managers, who are the contact points (interfaces) with the project management performing organization



� Case description: The project is concerned with developing a reporting tool for corporate customers. � Industry: Information and Communications Technology � Type of project: Internal project � Respondent’s contact details: Anonymous � Respondent’s job role: Project Manager � Interview date: 06 Mar 2010. � Interview duration: 45 minutes






Yes Email from Head of IT



No No signature. Only email



No



No Email was sent to development team and to project manager




Yes



No



No Not deemed necessary given the relatively straightforward nature of the project.




No



No



No Only project schedule exists and is up to date.



No Only to developers and to Head of IT




No They are known by the Project Manager.



Yes In project weekly project review meetings



No Only internally. Corporate customers were not consulted formally


P5 – Define Scope



Yes Included in the project design document



No Only internally to developers and to Head of IT



No Only reflected in the project schedule and not always communicated promptly.



� Case description: The project is concerned with the deployment of a facility access control system. � Industry: Information and Communication Technology � Type of project: Internal project � Respondent’s contact details: anonymous � Respondent’s job role: Project Manager � Interview date: 08 Mar 2010. � Interview duration: 45 minutes






Yes



Yes



Yes



No Only to IT Manager and to system specialist from supplier organization.




Yes



No



No




No Only a project schedule



No Only time management (project schedule)



No Only project schedule



Yes Central portal




Yes In the requirement document



Yes Regular progress meetings twice a week.



Yes


P5 – Define Scope



Yes



Yes By email, central portal



No Only reflected in project schedule if applicable



� Case description: The project is concerned with automating and improving the store reporting process of a retail firm.

� Industry: Retail � Type of project: Internal project � Respondent’s contact details: Anonymous � Respondent’s job role: Project Manager � Interview date: 08 Mar 2010. � Interview duration: 45 minutes






Yes Agreement letter between the client and the organization supplying project management services, authorizing the project to start. This includes details such as the duration of the agreement, and the rate for project management services.



No Only by 2 individuals (1 from the client and 1 from the organization supplying the project manager).



No Project started on verbal agreement. Signature followed later, due to legal reviews and admin from either side etc.



No Not communicated to all identified stakeholders, due to the confidential info included, such as service rates and other terms and conditions.




Yes



No Only briefly listed in the original project overview document.



No Not officially. Ad hoc management. Formal management of stakeholders is seen as unnecessary given the relatively small size and the tight deadline of the project




Yes



No All except procurement management (not seen as relevant) and quality management (dangerous oversight)



No Only project schedule (time management) is updated at all time, as deadlines are tracked more strictly by the client.



Yes Meetings, email and central portal.


12 Are stakeholder requirements Verify whether there is a formal process for Yes Included in the original project


defined and documented? collecting, defining and documenting stakeholders’ expectations on the project.

outline.



Yes This is a pre-requisite for payment of project management services by the client



Yes Kick-off workshop

P5 – Define Scope



Yes Included in the original project outline



Yes



No Not always, as key focus is placed on meeting deadlines. Changes are only communicated to the 2 signatories of the project authorization document (see question 1 above).



� Case description: The project is concerned with the upgrade of desktop software and licenses across the organization

� Industry: Telecommunications � Project type: Internal � Respondent’s contact details: Anonymous � Respondent’s job role: Project Manager � Interview date: 09 Mar 2010. � Interview duration: 45 minutes






Yes Email from IT Director authorizing the project



No



No



No Email only sent to project manager and IT administrators




Yes Desktop users



No Not in the context of this project.



No Not deemed necessary seeing the relatively straightforward nature of the project




No Only project schedule. The rest is not deemed necessary



No Only project schedule. Other knowledge areas are seen as good to have if time permitted, but not critical.



No Only the deployment schedule.



No Deployment plan is communicated to relevant users a few days in advance.




Yes



Yes

14 Have the documented stakeholder requirements been collected from all

Verify whether all identified key stakeholders have been consulted, and have had their

No Project dictated by IT Director. No further consultation was done.


identified key stakeholders?

requirements documented.

P5 – Define Scope



No Only the authorization email from IT Director



No



No Not deemed applicable



� Case description: The project is concerned with the development of a web site for a large customer. The project includes enabling e-commerce facilities.

� Industry: Information and Communications Technology � Respondent’s contact details: Anonymous � Respondent’s job role: Project Manager � Interview date: 09 Mar 2010. � Interview duration: 45 minutes






Yes



Yes



Yes



Yes




Yes



No Briefly highlighted in various documents where applicable, but not formally documented.



No




No Only a project schedule



No Only time management (project schedule)



No



No Only the project schedule exists and is communicated to all.




Yes



Yes This is a pre-requisite for payment.



Yes Project workshop


P5 – Define Scope



Yes



Yes



No Only reflected in the project schedule.