513.txt

Governance of the Pre-Development Activities for Information Systems Projects
A Thesis

Presented to the Faculty of Computers and Information, 
Information Systems Department,

In Partial Fulfillment of the
 Requirments for the PhD Degree
In 
Information Systems

Submitted by: 
Mohamed Ahmed Hamada 


Supervised by:
Dr. Sherif A. Mazen 			Dr. Ehab E. Hassanein 
IS Department, Faculty of Computers & Information
Cairo University- Egypt

September 2012



Certify
I certify that this thesis has not previously been submitted for a degree or diploma in any University, and that to the best of my knowledge and belief it does not contain any material previously published or written by another person except where reference is made in the text. I also certify that, the thesis has been written by me, any help that I have received in my research work has been acknowledged.
























Governance of the Pre-Development Activities for Information Systems Projects
A Thesis

Presented to the Faculty of Computers and Information, 
Information Systems Department,

In Partial Fulfillment of the
 Requirments for the PhD Degree
In 
Information Systems

Submitted by: 
Mohamed Ahmed Hamada 


Approved by the Examination committee
   Name 				   	                                      Signature 
1- Prof. Dr. 
2-Prof. Dr. 
3-Prof. Dr. 

FACULTY OF COMPUTERS & INFORMATION
Cairo University- Egypt
September 2012






﴿يُرِيدُ اللَّهُ لِيُبَيِّنَ لَكُمْ وَيَهْدِيَكُمْ سُنَنَ الَّذِينَ مِنْ قَبْلِكُمْ وَيَتُوبَ عَلَيْكُمْ وَاللَّهُ عَلِيمٌ حَكِيمٌ (26) وَاللَّهُ يُرِيدُ أَنْ يَتُوبَ عَلَيْكُمْ وَيُرِيدُ الَّذِينَ يَتَّبِعُونَ الشَّهَوَاتِ أَنْ تَمِيلُوا مَيْلًا عَظِيمًا(27) يُرِيدُ اللَّهُ أَنْ يُخَفِّفَ عَنْكُمْ وَخُلِقَ الْإِنسَانُ ضَعِيفًا (28)﴾
سورة النساء (26-28)












Table of Contents
List of tables ………………………………………………………………………….	viii
List of figures …………………………………………………………………………	x
List of abbreviations ………………………………………………………………….	xi
Acknowledgement ……………………………………………………………………	xii
Abstract ………………………………………………………………………………	xiii
Research publications...………………………………………………………………	xiv
Chapter (1) Introduction …………………………………………………………... 	1
1.2. Research Background ……………………………………………………………	1
1.3. IS Projects’ Development Phases and the Pre-development Activities ………….	4
1.4. Research Problem statement …………………………………………………….	5
1.5. Research Objectives ……………………………………………………………..	5
1.6. Research Scope …………………………………………………………………..	6
1.7. Research Constraints (Limitations) ………………………………………………	6
1.8. Research Methodology …………………………………………………………..	6
1.9. Research plan …………………………………………………………………….	7
Chapter (2) Pre-development Activities and the Failure of IS Projects …………	9
2.2. Why Information Systems Projects Fail? ………………………………………..	10
2.3. Pre-development Activities ………………………………………………………	13
2.3.1. System Service Request (SSR) Assessment …………………………………..	14
2.3.2. Project Scope Definition ……………………………………………………….	15    
2.3.3. Project Feasibility study ………………………………………………………. 	15
2.3.4. Project Requirements Elicitation ………………………………………………	16
2.3.5. Commercial Off-The-Shelf (COTS) Selection …………………………….. …	17
2.3.6. Project Charter and Statement of Work (SOW) ……………………………….	17
2.3.7. Project Work Breakdown Structure (WBS) ……………………………………	18
2.3.8. Project Risk Management   …………………………………………………….	19
2.3.9. Project Cost Estimation ………………………………………………………..	21
2.3.10. Project Contract   ……………………………………………………………..	21
2.3.11. Communication Plan development …………………………………………..	22
2.3.12. Project Plan development and schedule ………………………………………	22
2.4. Expressive Case Study for the role of the pre-development activities …………...	24
2.5. Chapter Conclusions ……………………………………………………………..	25
Chapter (3) Information Systems (IS) Project Governance …………………..…	28
3.2. IT Governance is the Origin of Project Governance ……………………………	29
3.3. IT Governance and Project Governance Harmonize ……………………………	31
3.4. IS Project Governance ……………………………………………………………	33
3.4.1. Why Adopting Governance for IS Projects ……………………………………	33
3.4.2. Main Characteristics and Benefits of IS Project Governance …………………	34
3.5. Exploring the Previous Researches of IS Project Governance ………………….	35
3.6. Chapter Conclusions ……………………………………………………………..	40
Chapter (4) Governance Framework for the Pre-development Activities ………	42
4.2. Pre-development Activities Governance as Specific Approach …………………	43
4.3. Governance Framework for the Pre-development Activities…………………….	45
4.3.1. Capability Maturity Model Integration (CMMI) …………………………........	47
4.3.2. IEEE Standards for Software Projects Development …………………………..	49
4.3.2.a. IEEE Standards for System Planning …………………………………………	49
4.3.2.b. IEEE Standards for System Analysis …………………………………………	50
4.3.2.c. IEEE Standards for System Design ………………………………………….	51
4.3.2.d. IEEE Standards for System Implementation …………………………………	51
4.4. Chapter Conclusion ………………………………………………………………	52
Chapter (5) Application of Pre-development Activities Governance ……………..	54
5.1. Determine the most significant pre-development activities ……………………...	54
5.2. IS Project Feasibility Study Governance …………………………………………	61
5.2.1. Policy’s actions and principles to Execute the Project Feasibility Study.……...	62
5.2.2. Well-defined procedures of Executing the Project Feasibility Study …..……..	62
5.2.3. Best practices within the project feasibility study …………………………….	67
5.2.4. Suggested practices and Checklists for the project feasibility study ………….	68
5.2.5. Define the expected deliverables for the project feasibility study.……………..	72
5.3. IS Project Requirements Elicitation Governance ………………………………..	73
5.3.1. Why Requirement Elicitation is difficult ………………………………………	74
5.3.2. Main Types and Characteristics of Project Requirements ……………..………	77
5.3.3. Policy’s actions and principles to implement requirement elicitation governance……………………………………………………………………………..	79
5.3.4. Well-defined procedures of Executing the Project Requirements Elicitation......	79
5.3.5. Best practices within the project Requirements Elicitation ……………….……	85
5.3.6. Suggested practices and Checklists for the project Requirements Elicitation.....	87
5.3.7. Define the expected deliverables for the project Requirements Elicitation ……	93
5.4. IS Project Risk Management Governance ………………………………….…….	93
5.4.1. Risk Management definition and its literature review ………………….….......	94
5.4.2. Importance of Risk Management …………………………………………........	96
5.4.3. Policy’s actions and principles to Execute the Project Risk Management ……..	97
5.4.4. Well-defined procedures of Executing the Project Risk Management……........	98
5.4.5. Best practices within the project Risk Management …...……………………….	102
5.4.6. Suggested practices and Checklists for the project Risk Management ……….	103
5.4.7. Define the expected deliverables for the project Risk Management …………..	111
5.5. IS Project Cost Estimation Governance ………………………………………….	112
5.5.1. Policy’s actions and principles to Execute the Project cost estimation… ……..	113
5.5.2. Importance of Project Cost Estimation Governance …………………………...	114
5.5.3. Well-defined procedures of Executing the Project cost estimation ………........	115
5.5.4. Best Practices of Executing the Project Cost Estimation ………………………	116
5.5.5. Suggested practices and Checklists for the project Cost Estimation………….	118
5.5.6. Define the expected deliverables for the project Cost Estimation ……………...	122
5.6. IS Project Plan and Schedule Governance ……………………………………….	123
5.6.1. Policy’s actions and principles to Execute the Project Plan and Schedule …….	124
5.6.2. Well-defined procedures of Executing Project Plan and Schedule …….............	125
5.6.3. Best practices within the project Plan and Schedule …………………………...	136
5.6.4. Develop Checklists for the project Plan and Schedule ……………………….	137
5.6.5. Define the expected deliverables for the project Plan and Schedule ……….....	141
Chapter (6) Research Results and Discussions  ....................................................... 	146
6.2. Examine to what extent the governance framework components are applied…	147 
6.3. Examine the Reliability of the Governance Framework …………………………	148
6.4. Explain the main results of IS project Governance ……………………………...	157
6.5. Governance the Project Scope Definition ………………………………………..	160
6.6. Research Findings ………………………………………………………………..	167
Chapter (7) Conclusions and Future Work …………………………………….. ... 	171
7.1. Research Conclusion …………………………………………………………….	171
7.2. Research Recommendations ……………………………………………………..	173
7.3. Future work ………………………………………………………………………	173
References ……………………………………………………………………………	175
Annexes ………………………………………..……………………………………..	191




















List of Tables
Table Number and Name
Page
 (2-1) Failure Reasons Statistics for IS Projects 
11
 (2-2) Failure reasons for seventy failed projects 
11
 (2-3) Correlation between pre-development activities and the failure reasons 
12
 (2-4) Risks dimensions of IS projects 
20
 (2-5) Failure reasons with the attributed pre-development activity of FBI
25
 (3-1) IT governance frameworks and best-practice 
31
 (4-1) outcome of dividing two projects’ development phases 
45
 (4-2) CMMI and projects process 
48
 (5-1) the Standish Group survey on IS projects 
54
 (5-2) Failure Reasons Statistics for IS Projects 
56
 (5-3) Failure reasons for seventy failed projects 
57
 (5-4) Correlation between pre-development activities and the failure reasons
57
 (5-5) Main failure reasons related to Project Feasibility Study
58
 (5-6) Main failure reasons related to Project Requirements Elicitation
58
 (5-7) Main failure reasons related to Project Risk Management
58
 (5-8) Main failure reasons related to Project Cost Estimation
59
 (5-9) Main failure reasons related to Project plan development and schedule
59
 (5-10) Percentages of main Pre-development Activities of IS Projects
59
 (5-11) Policy’ actions and procedures of project feasibility study governance
62
 (5-12) Main classifications of all benefits and costs
66
 (5-13) Main criteria of the project viability checklist
71
 (5-14) Difficulties of requirements elicitation difficulties
75
 (5-15) Summary of difficulties of requirement elicitation
76
 (5-16) Policy’ actions and procedures of requirement elicitation governance
79
 (5-17) Main requirements elicitation techniques
84
 (5-18) critical success factors of project requirement elicitation checklist
89
 (5-19) Main policies and procedures of project risk management governance
98
 (5-20) Comprehensive list for project identification risk factors
108
 (5-21) Percentages of risk factor probability
109
 (5-22) Coefficient impact scale for the risk factors of IS projects
110
 (5-23) Calculate the Risk Reserve for IS Projects 
110
 (5-24) Example to explain the calculation of project Risk Reserve
110
 (5-25) Policy’ actions and procedures of project cost estimation governance
113
 (5-26) Benefits of conducting accurate cost estimation, ISE, 
115
 (5-27) Main procedures to execute IS project cost estimation
116
 (5-28) Main success factors for implementing the project cost estimation
122
 (5-29) Policy’ actions and procedures of project Plan development and Schedule
124
 (5-30) Roles and Responsibility for the Project Manager
126
 (5-31) Technical Actions for the project plan
139
 (5-32) Main schedule critical success factors
141
 (6-1) the average of the applied governance components in local environment
148
 (6-2) Main failure reasons related to project feasibility study
149
 (6-3) General percentages for each question of project feasibility study 
149
 (6-4) Statistics and measure of central tendency for feasibility study governance
150
 (6-5) Main failure reasons related to Project Requirements Elicitation
151
 (6-6) General percentages for each question of requirement elicitation
151
 (6-7) Statistics and the measure of Central Tendency for requirement elicitation Governance
151
 (6-8) Main failure reasons related to Project Risk Management
152
 (6-9) General percentages for each question of risk management governance
153
 (6-10) Statistics and the measure of Central Tendency for risk management Governance
153
 (6-11) Main failure reasons related to Project Cost Estimation
154
 (6-12) General percentages for each question of cost estimation governance
154
 (6-13) Statistics and the measure of Central Tendency for cost estimation Governance
155
 (6-14) Main failure reasons related to Project Plan and schedule
155
 (6-15) General percentages for each question of plan development and schedule governance
156
 (6-16) Statistics and the measure of Central Tendency for plan development and schedule 
156
 (6-17) Comparison between the international and local environment
159
 (6-18) Policy’ actions and procedures of project scope definition
161
 (6-19) Best practices of project scope definition checklist
164
 (6-20) Project Scope Definition Checklist
165
(6-21) Relation between the framework components and CMMI capability levels
169
 (7-1) suggested practices  for the main issues of the pre-development activities 
172
















List of Figures
Figure Number and Name
Page
Fig.(1-1) Main phases of software projects’ development
4
Fig. (2-1) pre-development activities of IS projects
14
Fig. (2-2) Sample of project charter components.
18
Fig. (2-3) Simple model for project Work Breakdown Structure (WBS)
19
Fig. (2-4) Categories of the pre-development activities of IS projects.
24
Fig. (3-1) Governance as an encapsulated component
28
Fig. (3-2) the position of the pre-development governance
32
Fig. (3-3) IT governance maturity model 
32
Fig. (4-1) the flow of the specific governance approach for IS projects 
44
Fig. (4-2) key stone of the governance framework of the pre-development activities
45
Fig. (4-3) Main governance components of the Pre-development activities
46
Fig. (4-4) Theoretical Governance framework for IS Project 
47
Fig. (5-1) Most significant Pre-development activities of IS projects
60
Fig. (5-2) road map of main procedures for the conceptual governance framework
61
Fig. (5-3) Main Components of QFD
92
Fig. (5-4) Main governance components of projects risk management
98
Fig. (5-5) Procedures of project risk management process
99
Fig. (5-6) the structure of cost estimation governance 
114
Fig. (5-7) Algorithm for Comprehensive Cost Estimation Model (CCEM)
121
Fig. (5-8) Building WBS for the main activities and functions of project life cycle
131
Fig.(5-9) the common components of the project plan 
142
Fig. (5-10) Conceptual Governance framework for the main pre-development activities
143
Fig. (5-11) Project Feasibility Study Governance
143
Fig. (5-12) Project Requirement Elicitation Governance
144
Fig. (5-13) Risk Management Governance
144
Fig. (5-14) Cost Estimation Governance
145
Fig. (5-15) Project plan development and schedule Governance
144
Fig. (6-1) the average of the applied governance components in local environment
148
Fig. (6-2) the average percentages of all responses of feasibility study governance
150
Fig. (6-3) Average percentages of all responses of requirement elicitation 
152
Fig. (6-4) the average percentages of all responses of risk management governance
153
Fig. (6-5) the average percentages of all responses of cost estimation governance
155
Fig. (6-6) Average percentages of all responses of plan development and schedule 
156
Fig. (6-7) the summary of the General Average values of the main Pre-development activities governance 
157
Fig. (6-8) the average percentages of IS projects failure 
157
Fig. (6-9) Average percentage of IS projects’ failure in the Egyptian environment
158
Fig. (6-10) percentages of most common requirements elicitation techniques
158
Fig. (6-11) Estimate the impact of project risk factors
159
Fig. (6-12) Main Pre-development activities which have influence to cause the projects failure
160
Fig. (6-13) Suitable governance framework for the local environment
166
Fig. (6-14) Governance the project scope definition 
166

List of abbreviations
CCB
Change Control Board 
CCEM
Comprehensive Cost Estimation Model
CLRI
Comprehensive List of Risks Identification
CM
Configuration Management
CMMI
Capability Maturity Model Integration 
COBIT
Control Objectives for Information and related Technology
COTS
Commercial Off The Shelf
CSEF
Critical Success Estimation Factors 
CSF
Critical Success Factors
FP
Function Points
HOQ
 House of Quality Matrix 
IS
Information Systems
ITGI
Information Technology Governance Institute
PMI
Project Management Institute 
QFD
Quality Function Deployment 
RE
Requirements Elicitation 
SLOC
Source line of Code
SSR
System Service Request 
WBS
Work Breakdown Structure 







Acknowledgement
Before, after and above all, I thank my God for all that was achieved in this thesis, and enlightening my way and helping me to accomplish this thesis. Words are not apt enough to express my sincere gratitude to Dr. Sherif Mazen for his supervision, encouragement, motivation, immense knowledge and unlimited support throughout the whole work. Also, my great appreciation, deepest thank and grateful to Dr. Ehab Hassanein for his kindness, his valuable comments, his fruitful assistance, constructive opinion and valuable advice.
Special thanks and respects to my professors, all Lecturer Staff and the Project Managers who are helped me to achieve my empirical study and provided me with their knowledge and experiences.




















Abstract
IS projects encompass many challenges and difficulties of all development phases, with high risks of such projects end in failure, at the same time the failure rates for major IS projects appear to linger around 70%. In spite of many researches discussed the failure of IS projects and listed a huge number of failure reasons, IS projects still have considerably high failure rates. Through investigating the failures of IS projects, it has been detected that, a significant failure reasons are attributed to the Pre-development activities which are gathered and classified in this research. they begin with the System Service Request (SSR) assessment to assess the project’s idea and end with developing the project plan which represents a road map to explain how the project will progress through all development phases. 
IS project governance can introduce many advantages and benefits in the area of pre-development activities governance so; a governance framework is developed for the main pre-development activities as solution to decrease the projects’ failure and enhance their success. The targeted framework is based on five main governance components; Define the main policies, Well-defined procedures, Best practices, suggested best practices and checklists, and Define the expected deliverables for the pre-development activities. The governance framework is applied on the most significant pre-development activities which have a great influence to cause the projects’ failure; Project Feasibility Study, Project Requirements Elicitation, Project Risk Management, Project Cost Estimation, and Project Plan development and schedule.
Furthermore, an empirical study is applied in this research to investigate the application extent for the governance components of the targeted framework in local environment, also it examines the reliability of this framework to decrease the failures of IS projects, whereas the empirical study proves the ability of the targeted framework to decrease the majority of failure reasons of IS project in high percentage and appears the accordance between the international and the local environment to assign the most significant pre-development activities. This research concluded with creating many organizational structures and the imperative of executing governance the project scope definition to make the designed framework suitable for the local environment.    

 







Publications are emerged from this thesis
    1. Mohamed A. Hamada, Sherif A. Mazen , Ehab E. Hassanein, (2012), “Pre-development Activities Governance as New Approach to Enhance Information Systems (IS) Projects Success” First International Conference for Computing and Informatics ICCI 2012, Helwan University, December 2012
    2. Mohamed A. Hamada, Sherif A. Mazen , Ehab E. Hassanein, (2012), “Cost Estimation Governance Approach to Enhance Information Systems (IS) Projects Success” 2nd International Conference on Computer Science: Innovation & Technology (CCSIT 2012), Faculty of Science - Alexandria University - Egypt.
    3. Mohamed A. Hamada, Sherif A. Mazen , Ehab E. Hassanein, (2011), “The Role of the Pre-development Activities in Information Systems Projects’ Failure” 46th Annual Conference on Statistics, Computer Science, and Operations Research, ISSR, Cairo University, Egypt, pp: 56-72. 
    4. Mohamed A. Hamada, Sherif A. Mazen , Ehab E. Hassanein, (2011), “Towards to Specific Approach for Information Systems (IS) Projects Governance” (ICICIS 2011), Fifth International Conference on Intelligent Computing and Information Systems, July 2011, Faculty of Computer &Information Science (FCIS), Ain Shams University, Egypt, pp: 213-219.

























Chapter (1) 
INTRODUCTION

Chapter (1) Introduction
1.1. Introduction:
IS projects development is a complex process and comprises many challenges in all development’ phases (Mahring et al, 2008), (Yan et al, 2009), they are capital intensive requiring the investment of substantial capital and human resources, so they have become increasingly critical to support and sustain organization’s survival, growth and achieve the organization’ goals. IS projects demand technical competence and some structure that be imposed on the development effort to help guide the system to successful completion (Mensah, 1997). 
They are developed to encapsulate and integrate a number of areas of business with an aim to increase efficiency and effectiveness of business practices. It is widely accepted that, information systems improve productivity through streamlining of process and boost efficiency and effectiveness of individual worker and groups through connectivity that it offers. The implementation of an information system involves a number of challenges and difficulties that, threats to the success of achieving its objectives and providing its intended functionality within the constraints of time and cost (Al-Ahmad et al., 2009).
Furthermore, they have become widely integrated into most organizations and provide them with many opportunities to obtain competitive advantages such as operational efficiency, cost savings, reduction of human errors and offer a means for increasing productivity. Also increase the accuracy and speed of transaction processing and became one of the main assets and an integral part of the business organizations (Lee et al., 2008), (Xue et al., 2008), (Abu-Musa, 2009), (Dameri, 2009).
At this time, there is a considerable interest in IT Governance because of its potential impact on IS investment returns and the growing significance of corporate governance and accountability within corporations. IS governance becomes even more important because companies with better than average governance earn at least 20% higher return on assets than organizations with weak governance (Willson and Carol, 2008). So, effective IS governance helps ensure that IS supports business goals, optimizes business investment in IS, and appropriately manages IT-related risks and opportunities (ITGI, 2007)
1.2. Research Background:	 
IS projects are often difficult to estimate and manage, lots of projects are canceled or reduced in scope because of overruns in cost and time or failure to produce anticipated benefits (Ram, 2002). Most significant of all projects’ failure reasons belong to the projects initiation and planning phases, these two project phases contain a group of activities charged with high risky attributes and consider the main focus of the project problems.
 Absolutely, the pre-development activities have strength effect on IS projects success, they contain the most of all project problems for instance, the problems of project cost estimation and schedule, the problem of economic feasibility assessment, traditional appraisal methods and measuring the intangible benefits of IS project, how to identify accurate project requirements, the problem of identifying the project risk factors, and the problems of the nature of IS projects such as the unclear definition, scope creep, poor project practices, inaccurate project plan, don’t meet deadlines and overrun budgets (Gunasekaran, 2001), (Shang and Seddon, 2002), (Sherer, 2004), (Hallikainen and Chen, 2005), (Lin et al., 2005), (Kailash and Somendra, 2008), (Kim et al., 2008), (Parent and Blaize, 2009).
Moreover, IS projects have distinct characteristics and special nature, which make them difficult to manage and control. Also, they have many differences from other projects in many aspects such as constructions and industrial projects. The following section introduces the main distinct and the interrelated differences between software development projects and the other common business projects (Hughes and Cotterell, 2004), (Stepanek, 2005).
1. Software projects are complex
Software project can accumulate frightening complexity. A small program can easily run into tens of thousands of lines of code. Significant products, like the latest versions of modern software, run into tens of millions SLOC. It appears as a sequence of Instructions which usually appear as a single line in the text, but very complex instructions sometimes span two or more lines. There are also blank lines to separate groups of instructions, comments that explain to other programmers what these instructions are intended to accomplish, and elements that help define the structure of the program. So, “The drive to reduce complexity is at the heart of software development”
2. Software projects are abstract (invisible) 
Software project is invisible, it can't physically touch. It is a codification of a huge set of behaviors. Once the system has been completely described, then the software has been created. The same things that make it hard to visualize software make it hard to draw blueprints of that software and the project progress is not immediately visible.  
3. Requirements are incomplete
It is uniquely difficult to define a complete set of requirements for software before beginning development. Software is normally commissioned for the needs of users and managers, not professional developers. These individuals are experts in their own roles, but they rarely have as much experience as professional developers in dealing with the abstraction and complexity of software. They understand the business processes much better than the developers, of course, but even when someone has a good grasp of the main flows of behavior that are required, it's still very difficult to take into account all of the alternative flows and error conditions, and how different sets of requirements relate to each other.
Moreover, it is impossible to accurately blueprint software, or draw up a complete set of requirements before the software has been completed in some form or another. This means that any specification of requirements for software is likely to be incomplete in important ways. To be successful, users and developers must work together to refine the requirements for the software. As the software grows in functionality, the users can revise the remaining features based on their testing of the system under construction. 
4. Technology changes rapidly
Software development technologies change faster than other construction and industrial technologies. Thus, software changes quickly and there is a difficulty to be aware of just how quickly it changes. In the other hand, cost of software update and project technology equipment is very high. 
5. Best Practices are not mature
Most software development technologies are not mature enough to have a set of proven best practices. Technologies can be used skillfully or unskillfully. For software, this distinction can often only be assessed some time after the software has been completed. The presence or lack of software quality shows up most clearly in its extensibility. Wherever extensibility is the ability to add new functions or modify the existing functionality without impact on the existing system functionality. Extensibility cannot be measured when the system is deployed, but it shows up the first time you must extend the functionality of the system. 
6. Technology experience is incomplete
Expertise with particular software development technologies is very quickly outdated. Whenever software technologies change rapidly, new technologies supplant older ones every few years, and even more frequently, new versions of existing technology appear that radically change the functionality and use of that technology. This change is necessary and inevitable. Moreover, developers work with an enormous range of specialized third-party software components. 
7. Software development is research
Software development isn't just a process of creating software; it's also a process of learning how to create the software that is best suited for its purpose. This means the development process is a process of discovery progressively finding out the exact character of the software that will meet the customer's needs. Developers must combine analytical and creative skills to find out what their customer really wants. So software development is also a process of discovering whether and how the chosen technology can be made to perform the role that's required of it. Sometimes it will work as expected. 
8. Software project is flexible 
The easy with which software can be changed is usually seen as one of its strengths. It can be modified rapidly, and this step is expected, but it's better to implement the changes properly. 
9. Change is inevitable
Software is not perfect as first envisioned; it will always require changes to make it best suit its role. Change is inevitable, and if a piece of software isn't built to support change then it will fall apart even as it is being built. The quality of software shows itself when the software is first extended or modified. Poor changes are more likely to generate defects or bugs, and will make the code fragile and hard to debug.
Additionally, IS projects are unique in that they require the intense collaboration of many groups of stakeholders, IS staff, end users, and management. Hence IS projects are group-oriented activities, organized and executed in teams, and therefore subject to all the vagaries of group dynamics, interactions, coordination, and communication (Mensah, 1997). 
1.3. IS Projects’ Development Phases and the Pre-development Activities 
Through the presentation of the previous characteristics of IS project, It is evidentially that IS project development is not a routine and traditional operation, but it contains a lot of risks and difficulties. These difficulties require a set of professional experience and project management competences to achieve the project objectives and success. Especially, a particular attention must be paid to the pre-development activities which are the main origins of IS project failure and defects. 
Discussing the phases of a software projects development is a common issue. It’s well known that,  there is a great agreement for managing IS project development process which consists of five phases; initial phase, planning phase, design phase, execution phase, and closing phase (Hughes and Cotterell, 2004), (Bekker, and Steyn, 2008), (PMI, 2008). In the other hand, a broader perspective of IS project development phases can be described according to Fig., (1-1) which encompasses the following phases:-
1- Software Project Initiation 
2- Software Requirements Analysis 
3- Functional Specification and Prototyping 
4- Design Software Architecture and Test Plan 
5- Software Implementation (Coding) and Testing 
6-Software Delivery and Installation 
7- Software Operation and Maintenance 

Fig.(1-1) Main development phases of software projects 
Pre-development activities, which are derived from the initiation and planning phases, are the main critical success factors for IS projects. Though, if the planning activities are implemented accurately, the projects will achieve success in high percentages (Katainen and Nahar, 2008). Pre-development activities begin with the System Service Request (SSR) assessment to initiate the projects and end with developing the project plan which represents a road map to explain how the project will progress through all project phases and outlined objectives.
The occurrence of enormous costs and losses makes the high failure rates of IS projects a major problem. Pre-development activities are valuable and more significant, they can provide a solution for the high rates of projects’ failure, if these activities are accurately completed, they can contribute to improve projects success through address the projects’ defects and faults, such of projects’ defects are; (Cerpa and Verner, 2009)
    • Inability to measure the intangible benefits and hidden costs.
    • Deadlines that are not met and overrun budgets.
    • A lack of project planning 
    • The problem of risk identification
    • High risks of IS investments which represent the largest expenditures in the firm’s capital budget.
    • Understanding the complex factors involved in projects appraisal techniques.
    • The occurrence of "black hole" projects and wrong (IS) investment
    • Limited resources of organizations.
1.4. Research Problem statement:
Lots of researches demonstrated the failure of IS projects and listed a huge number of the projects failure reasons, but the IS projects still fail and have high failure rates. Through investigating the failure reasons of IS projects, it has been detected that the most significant of IS projects failure reasons are derived from the pre-development activities which begin with the System Service Request assessment (SSR) to initiate the projects and end with developing the project plan which represents a road map to how the project will progress through all phases. This problem creates an obligatory case to search for new solutions in order to decrease the failure probability of IS projects and improve IS projects success. 
1.5. Research Objectives:
This research aims to develop a governance framework for the main pre-development activities of IS projects to address the failure reasons and increase the probability of IS projects success. Furthermore, surveying and gathering the pre-development activities which have a great correlation with the failure reasons of IS projects. Actually, there is a great anticipation that developing the project governance framework will help to achieve the following features:-
    • Help to estimate the IS project cost estimation 
    • Implement accurate  project schedule and duration 
    • Design a quality documentation and fit plan for IS projects. 
    • Eliminate the costs of  wrong investments in IS project
    • Increase the probability of IS projects successful 
    • Effective management of IS projects Risks. 
    • Solve the problem of measuring the intangible benefits of IS projects.
    • Setting good structure to perform the feasibility of IS projects. 
    • Eliminate the defects of the traditional appraisal techniques of IS projects feasibility assessment.
    • Attain the maximizing of IT benefits and save the organization’s resources.    
    • Help to decide if an information system project can be implemented or not.
    • Strength the project control and management  
1.6. Research Scope:
This research focuses on Governance main the pre-development activities of IS projects which begin with the System Service Request (SSR) assessment to initiate the projects and end with the developing of the project plan that represents a road map to how the project will progress through all phases and outlined objectives. The application of the governance framework will expose the main pre-development activities which have a great influence to cause the projects’ failure, whereas the pre-development activities of IS projects are:-
    1. System Service Request (SSR) Assessment, 
    2. Project Scope Definition    
    3. Project Feasibility study  
    4. Project Requirements Elicitation
    5. Commercial Off-The-Shelf (COTS) Selection   
    6. Project Charter and Statement of Work (SOW)
    7. Project Work Breakdown Structure (WBS)
    8. Project Risk Management  
    9. Project Cost Estimation
    10. Project Contract  
    11. Communication Plan development  
    12. Project Plan development and schedule
1.7. Research Constraints (Limitations): 
This research will focus on the pre-development activities of the large scale projects, and the governance frameworks will expose to the main pre-development activities which have a great influence to cause IS project failure. Also, this research interested in the custom building systems and examining the reliability of the governance frameworks will be applied in local environment (Egyptian Software companies).
1.8. Research Methodology:
A quantitative research methodology is adopted to seek illumination and understanding through extrapolation of the findings at hand, this methodology was selected to gain an in-depth understanding. This research methodology based on extrapolation the literature review supported with a quantitative survey for the previous researches that investigated the failure and success of IS projects. Therefore, statistics of the failure reasons for IS projects are examined in order to explore the origins of the failures for IS projects, this with shed light and focus on the pre-development activities as a critical success factors for IS projects which begin with the System Service Request (SSR) to initiate the projects and end with the developing the project plan.
 The research methodology is used to explain and prove many issues in this research; the first issue, there is no project suffered from just one failure reason, but all projects had multiple problems and many of the failure reasons are related to each other. The second issue, most significant of IS project failure reasons are attributed to the pre-development activities. The third issue, it is very important to highlight and focus on the pre-development activities to decrease the failure probability for IS projects. Fourth, project governance is suitable solution to improve the IS project success. Furthermore, a research questionnaire will be applied to examine the effectiveness of the project governance framework as a solution for the research problem. Statistical analysis will be introduced to explain the final results of this research.
1.9. Research plan:
This thesis encompasses seven chapters to achieve the main objectives of this research, the following sequence explains the proceeding of this research:-
    1. Chapter 1: “Introduction”, explains the main outlines of the research, such as research background, research problem statement, research objectives, research scope and constrains, research methodology and research plan. 
    2. Chapter 2: “Pre-development Activities and the Failure of IS Projects”, investigates the pre-development activates of IS projects in details, looks for the main reasons and the origin of IS project failures. Also, proves the great correlation between the pre-development activities and the failures of IS projects. 
    3. Chapter 3: “IS Project Governance”, demonstrates the main concepts of IS project governance, main characteristics and its benefits, relation between IT governance and project governance, also, investigates the previous researches of IS project governance. 
    4. Chapter 4: “IS Project Governance Framework” illustrates the design of project governance framework, by concentrated on the governance components, and explains the project governance as a specific approach.  
    5. Chapter 5: “Application of Governance Framework”, provides a demonstration of the application methodology for governance the pre-development activities according to the governance framework.
    6. Chapter 6: “Results and Discussions”, introduces the main results and findings of the research correlated with the analysis of research questionnaire in order to validate the project governance framework. 
    7. Chapter 7:” Conclusion, Recommendations and Future Work” provides a brief conclusion for the main procedures which used to achieve IS project governance. Finally, provides suggestions for the future work on IS projects governance and lists the main recommendations of this research.











Chapter (2)
Pre-development Activities and the Failure of IS Projects 

















Chapter (2)
Pre-development Activities and the Failure of IS Projects 
2.1. Introduction:
IS projects development encompasses many various risks, they are often perceived to be troubled venture, and a high percentage of such projects end in failure. There is a significant body of evidence that many IS projects implementation end in failure, so this failure rate for major systems appears to linger around 70% (Pan et al, 2008). Projects’ failure can take many forms; it has consistently been defined in terms of projects that could not be completed on time or within budget, did not meet stakeholders’ expectations or that were cancelled (Yan et al, 2009).
High failure rate of IS projects is considered a major problem because the occurrence of enormous costs and losses (Zhang et al, 2003). Recent studies, which are concerned with the failure of IS projects, reveal a number of interesting patterns of IS projects’ failure. For instance, failure may be caused by multiple factors such as unrealistic expectations, lack of resources, uncooperative customers and weak management of contractors, failure could also be caused by the political rivalry in organizations. Other patterns also include the technical aspects of the systems such as failure in meeting predefined design objectives and achieving the technical purposes. However, many information systems’ studies indicate that failure is largely due to organizational and social, rather than technical factors (Pan et al, 2008).
 Although lots of researches have investigated why the failures of IS projects take place and listed a huge number of projects failure reasons, IS projects still fail in high percentages. Through examining and investigating the projects’ failure reasons, it has been detected that most significant failure reasons of IS projects are originated from the pre-development activities which begin with the System Service Request (SSR) assessment to initiate the projects and they end with developing the project plan which represents a road map for the project progress through all project phases and outlined objectives.
These consequences  confirm the necessity of shedding light and concentrating more on the pre-development activities as focal points to decrease the failure probability for IS projects. Actually in case of giving these activities a reasonable care, through the sufficient time and efforts, to be completed in accurate form, this will contribute to decrease the failure percentages and improve IS projects success. In the context of investigating the relation between the pre-development activities and the failure reasons of IS projects, this chapter will examine three significant issues:-
    1- Examining the main failure reasons of IS projects.
    2- Proving the correlation between the pre-development activities and the failure reasons of IS projects. 
    3- Gathering and categorizing the pre-development activities which are the main origin of IS projects failures and play a significant role to enhance projects’ success.
2.2. Why Information Systems Projects Fail?
In general Information systems projects have a high failure rate, completing projects on time and within budget and quality is a major challenge (Mahaney and Lederer, 2010). Standish Group survey proved that 65% of IS projects which started in 2006 failed (Cerpa and Verner, 2009). Another study conducted in the UK by Oxford University and Computer Weekly in 2003 reported, strikingly, that only16% of the IS projects reviewed were considered successful (Al-Ahmad et al, 2009).
Failure reasons of IS projects have been attributed to technological difficulties, organizational and functional problems, managerial issues, and many other reasons. Projects’ failure is defined as any project that is set to support the operations of an organization by exploiting the resources of information technology, that fails to deliver the intended output within the originally allocated cost, time schedule, or initially-approved functionality, as well as failing to satisfy the stakeholders and the end users (ibid, 2009).
The fundamental focus of project management has been to deliver projects on time, within budget and meet specifications with all required functions and features which had been initially specified. However, many major projects still fail to meet these targets, especially on cost and schedule. The failure reasons have often been blamed on poor project definition, incomplete information, poor productivity, inadequate communications, uncertainties around labor and material costs, and the failure to use timely and appropriate project management practices and controls (Uppal, 2008). 
Normally, IS projects are often difficult to estimate and manage and some projects are canceled or reduced in scope because of overruns in cost and time or failure to produce anticipated benefits (Ram, 2002). It is widely recognized that poor project planning plays a major role as one of the significant causes of project failure (Hartman and Ashrafi, 2004).So IS projects are considered successful if they attain the following issues:-
    • Accomplishing its business objectives (strategic, technical and operational).
    • Being satisfying and profitable for the sponsor/owner and contractors.
    • Meet its expected requirements and objectives.
    • Attaining a reasonable quality. 
    • Being produced to specification, within budget and on time.
In fact, lots of researches listed many failure reasons of IS project only (Hartman and Ashrafi, 2004), (Herroelen, 2005), (Uher and Toakley, 1999), (Verner et al, 2008), (Al-Ahmad et al, 2009), (Cerpa and Verner, 2009), (Lepage, 2009), but this research commences an effort to look for the origins of the failures for IS projects. In this respect, it’s important to recognize that there is no project suffered from just one failure reason, but most IS projects had various problems and the failure reasons are related to each other. Observing and perceiving and the overlaps between the projects failure reasons are evidential through examining the following statistics in (Table 2.1) that was published in (2008) by the two famous independent research organizations for IS/IT projects (PM Hut, 2008), and (Table 2.2) whereby Cerpa and Verner in (2009) demonstrated the failure reasons of seventy failed projects that developed in house at U.S., Australia, and Chile (Cerpa and  Verner, 2009), with considering, symbol column is added for both two tables to indicate the failure reasons at the residual sections of this research.
Symbol
The Standish Group Statistics
Percentage
A1
Incomplete Requirements 
13.1%
A2
Lack of User Involvement 
12.4%
A3
Lack of Resources 
10.6%
A4
Unrealistic Expectations 
9.9%
A5
Lack of Executive Support 
9.3%
A6
Changing Requirements & Specifications 
8.7%
A7
Lack of Planning 
8.1%
A8
Didn’t Need It Any Longer 
7.5%
A9
Lack of IT Management 
6.2%
A10
Technology Illiteracy 
4.3%
A11
Other 
9.9%
Symbol
Bull Survey Statistics
B1
Bad Communications 
57%
B2
Lack of Planning 
39%
B3
Poor Quality Control 
35%
B4
Missing Interim Deliverables 
34%
B5
Poor Budget Management 
29%
B6
Poor Project Management 
20%
Table: (2-1) Failure Reasons Statistics for IS Projects (source: PM Hut, 2008)
Symbol
Failure reasons
Percentage
C1
Delivery date impacted the development process 
93.9%
C2
Project under-estimated 
83.7%
C3
Risks were not re-assessed, controlled, or managed through the project
73.4%
C4
Staff were not rewarded for working long hours 
81.6%
C5
Delivery decision made without adequate requirements information
83.7%
C6
Staff had an unpleasant experience working on the project 
83.7%
C7
Customers/ Users                
69.4%
C8
Risk not incorporated into the project plan 
65.3%
C9
Change control not monitored, nor dealt with effectively 
63.3%
C10
Customer/Users had unrealistic expectations 
69.4%
C11
Process did not have reviews at the end of each phase 
75.5%
C12
Development Methodology was inappropriate for the project 
71.4%
C13
Aggressive schedule affected team motivation 
69.4%
C14
Scope changed during the project 
67.3%
C15
Schedule had a negative effect on team member’s life 
71.4%
C16
Project had inadequate staff to meet the schedule 
63.3%
C17
Staff added late to meet an aggressive schedule 
61.2%
C18
Users did not make adequate time available for requirements gathering
61.2%
Table: (2-2) Failure reasons for seventy failed projects (source: Cerpa and Verner, 2009)
Pre-development Activities
Related Failure Reasons
1-System Service Request (SSR) assessment
Poor project specification 
Project problem is not clarified 
2-Project Scope Definition
A4, C10, C14,
Scope, objectives unclear 
Failure to manage changes 
Changing scope and objectives 
3-Project Feasibility study
A3,A10,C6,C11
Projects are started for the wrong reasons
4- Commercial Off-The-Shelf (COTS)
Software integration problem
Wrong evaluation and selection of COTS
5-Develop a Project Charter and Statement of Work (SOW).
C12
Unclear project charter 
Failure to adequately identify, project document, and track requirements.
SOW doesn't accordance the extend of the project scope
Poor project documentation 
6- Project Requirements Elicitation
A1, A2, A6, C7, C18.
7-Work Breakdown Structure (WBS).
A9, C16,
Conflict between departments
Lack of required team knowledge / skills
8-Project Risk Management.
C3,C8,
Risks were not re-assessed, controlled, or managed through the project.
9-Project Cost Estimation 
B5,C2, C4,
Poor estimation efforts 
Inability to accurately size a software project
Improper assessment of staffing levels 
Lack of well-defined requirements for the software activity estimated
10-Project Contract
B4, C1,C5,
Poor contract management
Deadlines and resources not adjusted accordingly
11-Develop a Communication Plan.
B1,
Failure to communicate and act as a team
Lack of proper communication
12- Project Plan Develop and schedule.
A5,A7,B2,B3,B6,C9, C13,C15,C17,
Risks not incorporated into the project plan 
Failure to manage to the project plan 
Poor planning processes
Too long or unrealistic schedules
Table: (2-3) Correlation between pre-development activities and the failure reasons 
According to the previous statistics in Tables (2-1), (2-2) which explain the main failure reasons of IS projects and the common failures that are listed in the previous sections (Yeo K.T., 2002), (Humphrey, 2005), (Yongyi and Ying, 2005), (McManus and Wood-Harper, 2007), (Tesch et al, 2007), (Al-Ahmad et al, 2009), (Lepage, 2009), (Ahonen and Savolainen, 2010), it has been detected that a significant failure reasons of IS projects are originated from the pre-development activities. This correlation is illustrated in Table (2.3) whereby each failure reason is classified according  to its own pre-development activity as an evidence of proving the relation between the pre-development activities and the failure reasons of IS projects. 
Actually, this correlation confirms the necessity of highlighting and concentrating on the pre-development activities as focal points to decrease the failure probability of IS projects and enhance their success, which can be attained if these activities are given the sufficient time and efforts to be completed in an accurate form. Importantly, in the case of interested in the pre-development activities, this will contribute to enhance IS projects success.
2.3. Pre-development Activities:-
Pre-development activities are the Activity Groups that explore concepts and allocate system requirements before software development can begin, they are main critical success factors for IS projects (Demirors et al, 2006), (IEEE, 1997). If these activities are executed accurately, this will contribute to achieve projects’ success in high percentages (Katainen and Nahar, 2008). Pre-development activities begin with the System Service Request (SSR) assessment to initiate the projects and end with developing the project plan which represents a road map for explaining how the project will progress throughout all development phases and outlined objectives. The high risks of the pre-development activities are a result of the certainty of happening the projects’ failure if these activities missed the accuracy and are performed in an improper form. Also, IS projects lose the great benefits from the pre-project planning, which yields the following advantages (Griffith and Gibson, 2001); 
    • Fewer scope changes
    • Increase the predictability of cost and schedule
    • Improve the operational performance for projects
    • Better achievement of business goals
    • Better definition of risks
In fact, the previous researches in the area of IS projects didn’t gather the pre-development activities in one framework, but they discussed it in many scattered areas (Bachy and Hameri 1997), (Uher and Toakley 1999), (Furumo et al, 2006), (Jeffrey et al, 2007), (Whitten and Bentley, 2007), (Rodney, 2008), (Finnveden et al, 2009), (Greer and Conradi, 2009). In this research, the pre-development activities will be gathered and categorized to prove the high correlation between them and the most failure reasons of IS projects, also to explain the way in which these activities are implemented. 
Contextually, surveying the pre-development activities, which determine in high percentage the fate of success or failure of IS projects, concluded with extracting twelve  pre-development activities that are; System Service Request (SSR) assessment, Project Scope Definition, Project Feasibility, Commercial Off-The-Shelf (COTS), project Requirements Elicitation, Develop Project Charter and Statement of Work (SOW), Work Breakdown Structure (WBS), Project Risk Management, Project Cost Estimation, Project Contract, Develop Communication Plan, and Develop the Project Plan and schedule. Figure (2-1) explains the sequence of the pre-development activities.  

Fig. (2-1) pre-development activities of IS projects
The following section demonstrates the pre-development activities in details from the System Service Request assessment to the project plan development and schedule, which clarifies the significant role of these activities within the projects development in order to enhance the projects’ success and decrease the failure rates.
2.3.1-System Service Request (SSR) Assessment
Most of IS projects are initiated in response to a request from a client or manager who has an idea or need (Malkinson, 2001), System Service Request (SSR) is a standard form for requesting development or maintenance of an information system within an organization, it includes the contact person, a problem statement, a service request statement, and the relational contact information (Jeffrey et al, 2007). SSR assessment means the process of assessment to decide if there is a real problem needs to develop an information system or not. It includes studying the project’s problem completely.
2.3.2-Project Scope Definition
Project Scope can be defined as the process by which projects are defined and prepared for execution. Defining the project scope is more significant within developing IS projects because poor project specification can lead to numerous requirement changes and scope creep (Zhang et al, 2003). Thus, unclear and incomplete scope and objectives have been shown to contribute to the perception of project failure (Barclay and Osei-Bryson, 2010). The project scope is relatively determined by three major factors; Project size, Project duration and Project key interdependencies. Project Management Institute listed the main features to define the project scope (PMI, 2008) as follows:-
    • Project Justification: the project justification encapsulates the business need for undertaking the project while providing a basis for future trade-offs.
    • Project Product: the project product section summarizes the product description which is a compilation of characteristics of product or service to be created upon completion of the project.
    • Project Deliverables: Project deliverables refer to a list of finished products to be delivered by the service provider. 
    • Project Objectives: The project objectives define quantifiable criteria that must be met for the project to be considered successfully completed.
2.3.3- Project Feasibility study
Project Feasibility study is a crucial matter to determine the significance of proceeding the projects. It refers to an assessment of the project against technical, operational, financial and social/political criteria; such activity allows the early cancellation of projects with minimal cost or, if the project proceeds, assists in the estimation of required funding and further planning (Greer and Conradi, 2009). Basic data to conduct the project feasibility is obtained by the client through a series of queries, questions and meetings, wherein the client provides some of the research, other data and facts need to be gained from a variety of sources.
Feasibility study determines whether the requested information system makes economic and operational sense for an organization or not; it includes five feasibility tests: economic feasibility, technical feasibility, operational feasibility, schedule feasibility and legal and political feasibility (Jeffrey et al, 2007), (Whitten and Bentley, 2007).
Operational Feasibility, is a measure of how well a specific solution will work in the organization. It is also a measure of how people feel about the IS project. It examines the following issues;
            ▪ Does management support the system?
            ▪ How do the end-users feel about their role in the new system?
            ▪ What end-users or managers may resist or not use the system?  Can this problem be overcome? If so, how?
                • Usability analysis, Ease of use, Ease of learning, and User satisfaction
Technical Feasibility, is a measure of the practicality of a specific technical solution and the availability of technical resources and expertise. It examines the following issues;
            ▪ Is the proposed technology or solution practical? Is the technology mature?
            ▪ Does the organization currently possess the necessary technology? 
            ▪ Does the organization possess the necessary technical expertise, and is the schedule reasonable?
Schedule Feasibility, is defined as the likelihood of a project being completed within its scheduled timetable.
Economic Feasibility, the bottom line of any project is the economic feasibility it’s a measure of the cost-effectiveness of a project or solution. This is often called a cost-benefit analysis. 
Legal and Political Feasibility, is the understanding of significant internal and external political trends and opposition which encompass the project environment.  
2.3.4- Project Requirements Elicitation
It must be considered, the determination of the Initial Project’s requirements is critical issue, whereas it defines not only the project product, but also support the estimation of a project’s budget, resources, and schedule (Greer and Conradi, 2009). Requirements elicitation (RE) is the most important and critical phase in IS projects requirements engineering, where user and business needs of a system are identified and captured, (Razali and Anwar, 2011). Quality of requirements elicitation decides the correctness of customer’s feedback on completeness and validity of requirements, it showed that between 40% and 60% of software failures and defects are the result of poor software management and requirements definition (Huang et al., 2010) 
Requirements elicitation is a set of actions preformed to assess the desired functionality in the proposed information system (Browne and Ramesh, 2002). Resources of initial project requirements are preliminary ideas. Documents providing a complete overview of the project components and functionalities are written. Such documentation, also called informal requirements, which consists of natural language documents, are possibly supported with tables, algorithms, finite state machines and even sometimes implementation considerations (Gorse et al, 2007). To determine initial project’s requirements carefully, the following issues must be considered; 
    • Eliminating inadequate or vague requirements
    •  Proper management of  user expectations
    • Avoiding system changing according to  discovering new requirements during the project development
    • Project stockholders should be involved 
    • Assuring that no wrong business requirements have been addressed
    • Complete understanding of the main project’s requirements 
2.3.5- Commercial Off-The–Shelf (Cots) Selection
COTS has the ability to reduce time and cost of IS project development. Moreover, they enable software buyers to get software made up of components which have been tested many times by other users, and hence ensure improved software quality. In order to realize the benefits which COTS brings to software development, it is imperative that the “right” COTS is selected for a project because selecting inappropriate COTS may result in increased time and cost of software development. A COTS product can consist of one or many components, selection of COTS is a complex decision-making problem that is represented by the following: - (Wanyama and Far, 2005)
    1. Uncertainty: There is uncertainty about the requirements of the software under development, about the correctness of the available information, and about the impact of COTS on the quality of the system.
    2. Complexity of the decision-making problem: COTS selection decisions are multileveled, different decisions are required to be made at different stages of the COTS selection process
    3. The use of COTS products creates a software integration problem: whether a single COTS software component is being integrated into a software system
    4. Multiple Stakeholders: COTS selection process usually involves multiple stakeholders, each with a set of needs, preferences and constraints, which may be in conflict with those of other stakeholders and thus lead to a negotiations problem. 
    5. Multiple Objectives: COTS selection is carried out with a variety of objectives. These objectives are a result of the need to evaluate products in various non-comparable aspects such as cost, quality and viability of vendor. 
2.3.6- Project Charter and Statement of Work (SOW)
A project charter is the process of developing a document that formally authorizes a project and documents the initial requirements that satisfy the project stakeholders’ needs and expectations (PMI, 2008). It is a simple signed agreement between a project team and a representative for those who will use the output (customers). A charter forces the project team and champion to develop a common understanding about the project and creates enough visibility that if a project approach is not sound, the project can be cancelled before it progresses any further (Tesch et al, 2007).
The primary purpose of the project charter is to name the project manager and to give him the authority to initiate the project. The project charter usually is short, not more than three pages, and often only one page long. The format varies from an organization to another, but generally it contains a brief scope statement describing the project, how the project supports the strategic goals of the organization, who the project manager is and finally, if possible, the project’s priority within the company. 
A good project charter should include clear objectives and measurable goals, as well as important assumptions and constraints to guide the project. The lack of a clear project charter increases uncertainty (lack of information), ambiguity (the absence of clarity) and confusion in a project (Mahring and Keil, 2008). Figure (2-2) shows a sample of the main components of project charter that can be adapted to any organization. 

Fig. (2-2) Sample of project charter components.
Statement of Work (SOW) is a formal document that captures and defines the work activities, deliverables, timeline and time estimates for information system development (Jeffrey et al, 2007). It is a narrative description of the deliverables or services required to fulfill a contract; this is accompanied by specified project requirements at high-level (PMI, 2008). Statement of Work comprises the following statements:-
    • Scope of project, describes the work to be done at a high level.
    • Location, specifies where the work is to be performed. Identifies the location of hardware, software, and office space.
    • Period of Performance, specifies the allowable time for the project, i.e. start and finish time and key scheduling considerations.
    • Reporting, identifies the reports you expect from the vendor, including content, format and frequency.
    • Deliverables Schedule, lists the specific deliverables, describing what is due and when.
    • Applicable standards, project standards or other standards imposed on the project deliverables. These should include any standards such as ISO, CMM, CMMI, etc. 
    • Acceptance criteria, these would include any quality standards that must be met.
2.3.7- Project Work Breakdown Structure (WBS)
Work breakdown structure (WBS) is the process of breaking down the project into manageable chunks that can be effectively estimated and supervised; it can organize and define the total work scope of a project (Scasso and Larenas,1991). Figure (2-3) depicts the main components of a simple model for work breakdown structure (Whitten and Bentley, 2007).
In fact, any (WBS) consists of three different structures, including “Project Control Work Breakdown Structure” (PCWBS), “Functional Work Breakdown Structure” (FWBS) and “Relational Work Breakdown Structure” (RWBS) (Golpayegani and Emamizadeh, 2007);
    1. The “Project Control Work Breakdown Structure” (PCWBS) is the hierarchical structure which shows the overall components of a project’s main deliverable or subject. The deliverable of a project is usually a product, a service or a combination of them. Therefore, the PCWBS demonstrates the project scope of work, which contains all the subjects or deliverables that should be considered to complete the project.
    2. The “Functional Work Breakdown Structure” (FWBS) is the second project structure that shows the scope of functions and operations that should be performed to achieve the main subject or deliverable of a project. With respect to definition, the FWBS can be considered as the hierarchical structure of a project’s main operation.
    3. The “Relational Work Breakdown Structure” (RWBS) is the third project structure which represents the relationship among the components of PCWBS and FWBS. In other words, the RWBS of a project shows which components of the FWBS should be performed to obtain each component of the PCWBS.
















Fig (2-3) Simple model for project Work Breakdown Structure (WBS)
2.3.8-Project Risk Management
Risk management is the process of identifying and controlling any activity or event that can negatively influence the success of IS projects, whereby risks are all issues that may affect the delivery of benefits to be gained from the IS projects (Elkington and Smallman, 2002). A systematic process of risk management is normally divided into three activities; (Mojtahedi et al, 2010)
        1- Risk identification and classification which determines risks that might affect the project and register their characteristics.
        2- Risk analysis which measures the impact of the identified risks on a project.
        3- Risk reduction to reduce the risks’ effects on a project’s success.
In the context of determining the project risk factors, Han and Huang summarized the main dimensions of projects’ risks with their factors which can endanger the success of IS projects in Table (2-4), (Han and Huang, 2007). 
Risk Dimension
IS project Risks
Users
Resistant to change
Conflict between users
Users with negative attitudes toward the project
Users not committed to the project
Lack of cooperation from users
Requirement
Continually changing system requirements
System requirements not adequately identified
Unclear system requirements
Incorrect system requirements
Project complexity
Project involved the use of new technology
High level of technical complexity
Immature technology
Project involves use of technology that has not been used in prior projects
Planning & Control
Lack of an effective project management methodology
Project progress not monitored closely enough
Inadequate estimation of required resources
Poor project planning
Project milestones not clearly defined
Inexperienced project manager
Ineffective communication
Team
Inexperienced team members
Inadequately trained development team members
Team members lack specialized skills required by the project
Organizational environment
Change in organizational management during the project
Corporate politics with negative effect on project
Unstable organizational environment
Organization undergoing restructuring during the project
Table (2-4), Risks dimensions of IS projects, (source: Han and Huang, 2007)

2.3.9- Project Cost Estimation 
Project cost estimation is more difficult and predictable, but it is considered a significant development activity for the successful software projects. It refers to the prediction of the likely amount of effort, staffing level, time, and materials necessary to accomplish the required development activities in early stage of a project’s life cycle. Thus, effort prediction of software cost estimation is concerned with the prediction of the required person-hours to accomplish the project activities (Muzaffar and Ahmed, 2010).
Constructive Cost Model (COCOMO) is the famous analytical method to estimate the project cost estimation which using parameters derived from initial projects (Zheng, 2009). Cost estimation is a recurring process, in which the quality of outputs is heavily dependent on the quality of inputs. Estimates of a project’s budget, resources, and schedule - which represent the outputs, need to be updated periodically (Malik and Boehm, 2009). There are four basic steps in project cost estimation;
    1- Estimating the size of the product development; this generally ends up in either Source Lines of Code (SLOC) or Function Points (FP), or other possible units of measure. 
    2- Estimating the effort in person-months or person-hours.
    3- Estimating the project duration and schedule in month-calendar.
    4- Estimating the project cost in dollars (or local currency).
It can be obvious that cost estimation depends on three important factors:  effort, time, and project scope. In the other words, "Cost is a function of efforts, time, and project scope as the expression of the following equation:
C = f (E, T, S), whereas (C) indicates Cost, (E) effort, (T) time and (S) project scope.
2.3.10-Project Contract
Project contract is an agreement between two or more parties to create mutual business relationships or legal obligations. It defines a set of activities to be performed by different parties satisfying a set of terms and conditions (clauses). The contract is valid for a specified time duration defined in the contract; this duration defines the active life stage of the contract and is expected to last until the contract is completed. A contract completion may not occur when some clauses beyond completion of activities need to be adhered to, for example, maintenance and warranty period (Krishna et al, 2004).
IS Project Contract Model determines the relationships among IS project owners, contractors, managers/consultants and subcontractors. The owner should select the contract model according to the situation and the demand of the project; IS project contract model can help ensure the organization implementation measure of every phase during the whole project life cycle, the roles played by every part and relation among them. It must be considered that IS project contract model should be designed to meet the following projects requirements (Zheng et al, 2009).
    1. To meet the requirements regarding the characteristics of IS project and the owner’s situation.
    2. To fulfill the aim of IS project construction and IS project maintenance that are inseparable.
    3. To meet the requirement of IS project risk management.
    4. To fulfill the interface management during IS project construction.
    5. Meet the project duration and budgets 
2.3.11- Project Communication Plan
Lack of proper communication is one of the major reasons for the failure of many projects to meet their expectations (Hartman and Ashrafi, 2004). Efficient and clear communication builds trust among different parties and participants of IS projects that lead to improved collaboration, better team spirit and eventually better results (Katainen and Nahar, 2008). Communication can be written and verbal, and it can also be formal and informal. It is also closely linked to emotion in projects. Although people would like to collaborate on projects and empower the project manager, there is a trend to make some deviations (Turner and Muller, 2004). 
The communication plan should take into consideration all dimensions of the communication among the project participants. The contents of the plan could include the communication inside and outside the project environment, what the communication risks are and how to prepare for them. Besides, the methods and interval of communication should be included in the plan, e.g. weekly meetings. Meanwhile, the communication plan should include work authorization and deliverable approval methods (Tesch et al, 2007).
Actually, when the communication is more sufficient, the coordination and collaboration among the project participants are possible and help to conduct the project objectives. Also, effective communication, through information and knowledge sharing, enables the project participants to coordinate and collaborate on tasks, and it helps project managers to achieve benefits associated with IS projects development (Katainen and Nahar, 2008).
2.3.12- Project Plan Development and schedule
Poor planning may promote escalation behavior for IS projects; if a project isn’t properly planned, there may not be a shared understanding of the project’s charter or scope and there may be a lack of contingency plans for handling problems  arising during the project execution (Zhang et al, 2003). A project plan is a formal and approved document which guides the project implementation (based on the project requirements and the established estimates), and is used to manage and control its execution. It is considered a road map for the progress of the project throughout the whole project phases and outlined objectives, metrics, and milestones. Project plan should encompass the following specific practices; (PMI, 2008), (Calvo-Manzano et al, 2009)
    • Documenting the project  assumptions, constraints and alternatives
    • Setting project scope, cost, and scheduling baselines for progress measurement and control
    • Establishing project milestones and deliverables
    • Establishing the budget and schedule.
    • Identified project risks.
    • Planning for data management.
    • Planning for project resources.
    • Identifying functional responsibilities.
    • Work Breakdown structure (WBS)
    • Planning for needed knowledge and skills.
    • Planning for stakeholders’ involvement.
At the same time, the project plan describes the technical and managerial approach to be followed for the projects. It typically describes the work to be done, the resources required, the methods to be used, the procedures to be followed, the schedules to be met and the way that the project will be organized.
Scheduling and sequencing are concerned with the optimal allocation of scarce resources to activities throughout the time of the project. The main project scheduling problem involves the scheduling of project activities as a subject to precedence and/or resource constraints (Herroelen, 2005). The conventional program evaluation and review technique (PERT) and the critical path methods (CPM) techniques are very common and widely adopted as management tools being used in project schedule after doing the cost estimation (Omar, 2009), project schedule includes:-
    • Identifying all the resources that will be necessary to the project and select them in a way that they will be available to perform the projects activities.
    • Estimating time and resources required for project tasks and activities to complete each task.
    • Assigning the dependency for projects’ tasks. 
    • Organizing tasks concurrently to make optimal use of workforce.
    • Minimizing task dependency to avoid delays caused by one task waiting for another to complete
In the end, after investigating and discussing the pre-development activities of IS projects, these activities can be classified into three categories for the purpose of highlighting and giving them more concentration. Figure (2-4) explains the classification of the pre-development activities into three main categories; 
    1- Initial activities that comprise System Service Request (SSR) assessment, Project Scope Definition, project Requirements elicitation  and the Project Charter with Statement of Work (SOW) 
    2- Assessment activities that comprise IS Project Feasibility, Commercial Off-The-Shelf (COTS) selection, project Cost Estimation, and Project Risk Management
    3- Planning Activities that comprise Work Breakdown Structure (WBS), Project Contract, Develop a Communication Plan, and Develop a Project Plan and schedule.












Fig. (2-4), Categories of the pre-development activities of IS projects.
2.4. Expressive Case Study for the role of the pre-development activities, Virtual Case File Project for the United States Federal Bureau of Investigation (FBI)
 The Virtual Case File was delivered by Science Application International Corporation (Friden, 2005) and it was aimed at facilitating case file management by integrating data from older system, including the Automated Case support system, and eventually replacing them. The FBI had admitted that. The Virtual Case File Technology project had failed to meet the bureau’s requirements and that: 
    • Five years of development and
    • $US 170 million in cost had been lost (National Research Council, 2004)
Case study analysis 
At the report of The National Research Council “Review of the FBI’s Trilogy Information Technology Modernization Program” (NRC, 2004), the National Research Council saw no evidence that backup and contingency plans had been formalized. The transition plan did not include the availability of the Automated Case Support system after the cut over to the Virtual Case File. Also it found that the requirements for the FBI mission were not included in the Virtual Case File design. Science Application International Corporation said that it delivered the first phase of the project ahead of schedule and under budget, but the requirements for the software changed more than once after September 11, in the USA. 
The office of the Inspector General found that FBI was still defining the requirements after two years since the start of the project. It also said that the communication with FBI was difficult because of the high turnover of top IT managers. Through examining the previous project, the main reasons that cause the project failure and prevent FBI requirements to be met can be determined as follows:
    1- Backup and contingency plans had been formalized.
    2- The transition plan did not include the availability of the Automated Case after cut over.
    3- Requirements for the FBI mission were not completed. 
    4- Requirements for the software changed more than one time.
    5- The first phase of the project was ahead of schedule and under budget.
    6- FBI was still defining the requirements after two years since the start of the project.
    7- Communication with FBI was difficult because of the high turnover of top IT managers.
In fact, the previous failure reasons are attributed to the following pre-development activities in table (2-5) which confirms the research objective, the necessity of giving more concern and focus to the pre-development activities that are the main origins of most significant failure reasons of IS projects.
Failure Reasons
Pre-development Activity
Backup and contingency plans had been formalized
Develop Project Plan
Project Risk Management
The transition plan did not include the availability of the Automated Case 
Develop Project Plan
Requirements for the FBI mission were not completed
Project Requirements Elicitation
Requirements for the software changed more than one time
Project Requirements Elicitation
Change of project scope 
At the first phase of project ahead of schedule and under budget
Project Cost Estimation 
Project schedule
FBI was still defining the requirements after two years 
Project Requirements Elicitation
Continuous Change of project scope 
Communication was difficult because of the high turnover of top IT managers
Develop Communication Plan
Table:(2-5) Failure reasons with the attributed pre-development activity of FBI
2.5. Chapter Conclusions 
In this chapter, a survey was conducted to investigate the pre-development activities which play an important role to achieve the IS projects success. It also explains the failure reasons of IS projects that are attributed to the pre-development activities. Pre-development activities are critical factors which determine the fate of projects success or failure. They begin with the System Service Request (SSR) assessment which initiates the projects and they end with the developing of the project plan which represents a road map to show how the project will progress throughout all the project phases and outlined objectives.
twelve pre-development activities were introduced in details and classified into three categories, 1-Initial activities, 2-Assessment activities and 3-planning Activities; these activities need more care and consideration from IS project developers because they are significant to achieve IS projects success and have the ability to decrease most  project failures and defects. Furthermore, lots of outcomes are concluded in this chapter which are;
    • IS projects have distinct characteristics and special nature, and they differ from the other business projects which make them difficult to manage and control.
    • There is no project suffering from just one failure reason, but all projects have multiple problems and many of the failure reasons are related to each other.
    • The most significant of project failure reasons are attributed to the pre-development activities. 
    • Pre-development activities can play an important role to enhance IS project success if these activities are executed in proper aspects with sufficient time and effort to be completed accurately. 
    • There is an obligatory case to look for solutions for the problems of high failure rate of IS projects, whereas governance the pre-development activities can contribute to fulfill this task.
    • At the remaining part of this thesis, “Pre-development activities Governance” - based on developing a governance framework, will be adopted as a solution for the research problems.    


























Chapter (3)
Information Systems (IS) Project Governance
















Chapter (3)
IS Project Governance 
3.1. Introduction:
Governance is a multi-dimensional concept, encompassing elements of organizational stewardship, accountability, risk management, compliance, control, propriety, functional oversight, resource allocation and capability. It tends to be defined from one of two perspectives: functionally, in terms of what governance does (e.g., assigning and administering decision rights, responsibilities and accountabilities), or structurally, in terms of what it looks like (a framework of interrelated boards, councils, and committees (Bannerman, 2009). It’s considered with respect to mechanisms for achieving efficiency over the product life cycle in new product development (Teck-Yong and Wong, 2006). 
The famous known use of governance is at the corporate level, ‘Corporate Governance’, as the set of processes, customs, policies, laws and institutions affecting the way a corporation is directed, administered or controlled. Corporate governance also includes the relationships among the many stakeholders involved and the goals for which the corporation is governed; therefore, the critical role for governance is to monitor and control the behavior of management, who are hired to preside over the day-to-day activities of running the organization (Kooper et all, 2010).
Governance can be conceptualized as an encapsulated component consists of four elements as showing in (figure 3-1); Purpose; the anticipated outcome that is intended and motivates the actions of the unit, Structures; one or more organizational entities through which the work of the unit is enacted, such as a board, steering committee, council or working party, Processes; a collection of interrelated tasks that are enacted to accomplish the purpose of the unit, and Relational mechanisms; Arrangements that support and enable the purpose of the unit by facilitating interaction and communication with stakeholders and interested parties (Bannerman, 2009)
	

Fig. 3-1: Governance as an encapsulated component
In fact, there is a considerable interest in IT governance because, on one hand, it potentially impacts on IT projects returns and, on the other, it enhances the efficiency of corporate governance and accountability within corporations. IT governance becomes even more important when one considers that companies with better average governance earn at least 20% higher return on assets than other organizations with weaker governance (Willson and Carol, 2008). Effective IT governance helps to ensure that IT supports business goals, optimizes business investment of IT, and appropriately manages IT-related risks and opportunities (ITGI, 2007). 

3.2. IT Governance is the Origin of Project Governance 
IT governance is the structure of relationships and processes to develop, direct and control IS/IT resources in order to achieve the goals of any enterprise (Hussain, and Siddiqui, 2005). It is perceived that the project governance has been derived from the IT governance which has a potential impact on information systems development and ensures that IT supports business goals and objectives (Bannerman, 2010),(Marnewick, and Labuschagne, 2011). According to the significance of IT governance as the origin of project governance, the definition, importance and the structures of IT governance must be shed light on. 
IT governance is a continuous process, requiring ongoing review and adjustment. It also involves several concepts including risk management, security, business continuity, change management amongst several others. IT Governance Institute (2004) claims that IT governance is by no means an isolated discipline. IT governance must become a fundamental element of corporate governance and, thus, requires board-level attention in order to ensure that IT-related risks and returns on IT investments are adequate in terms of the organization's business needs. Corporate governance and IT governance are intimately interrelated (Posthumusa and Solms, 2005).  Previous literature has presented different definitions of IT governance, indicating the variety and multiplicity of ways to define this concept (Dahlberg and Lahdelma, 2007), (Paul et al., 2007), (Beimborn et al., 2009), (Parent and Blaize, 2009). Also Marten and Mathias (2006) introduced lots of IT governance definitions based on their comprehensive literature study to explore IT governance. 
ITGI definition is the most famous one which defines IT Governance as “the responsibility of the board of directors and executive management. It is an integral part of enterprise governance and consists of the leadership and organizational structures and processes that ensure that the IT of an organization sustains and extends the organization’s strategies and objectives” (ITGI, 2003).This widely cited and used definition includes the structural aspect of IT governance, e.g. the structure of IT decision-making rights for key IT decisions - besides, the process aspect of IT governance, e.g., the managerial planning, execution, evaluation, and feedback process of IT governance. 
Furthermore, researches and IT practitioners have introduced lots of IT governance structures, best-practices and governance frameworks that organizations can deploy. Such frameworks as COBIT (Control Objectives for Information and Related Technology), Val IT, a framework for the governance of IT investments, Application Services Library (ASL), Capability Maturity Model (CMM), 6-Sigma, IT Infrastructure Library (ITIL) and Microsoft Operations Framework, which has been proposed to guide IT operations and services (Ronnie et, al., 2008). Table (3-1) explains the most famous IT governance structures, frameworks and best-practices including their origins and descriptions (Parent and Blaize, 2009). 
 

Framework
Origin / Definition
Description
CoBIT

Control Objectives for Information and related Technologies, developed by the IT Governance Institute (ITGI. (www.itgi.org) for the Information Systems Audit and Control Association, (ISACA). 
(www.isaca.org)
First published in 1996, and now in its fourth version, it is a best practices framework that  lists 34 high-level objectives covering 215 control objectives grouped into 4 domains: Plan & Organize; Acquire & Implement; Deliver & Support; and Monitor & Evaluate.
IT GAM

IT Governance Arrangements Matrix. Peter Weill and W. Ross, IT Governance: How Top Performers Manage IT Decisions Right for Superior Results (Cambridge, MA: Harvard Business School Press, 2004)
A set of 5 IT Decision Domains (principles, architecture, infrastructure, business applications, investment). Weill and Ross show how to govern each domain for optimal value creation.
ITGDF / GAM

IT Governance Design Framework Governance Arrangements Matrix. 
P.Weill and J. Ross, (Cambridge, MA: Harvard Business School Press, 2004)
Part of the ITGAP process, in which managers first map IT-related processes in their organizations before changing them to conform to one or more governance archetype.
CMM / CMMI

Capability Maturity Model Integration Software Engineering Institute at Carnegie-Mellon University (www.sei.cmu.edu/cmmi/)

CMM was developed in1980s to aid in managing large software development projects. It posits 5 maturity levels. CMM was replaced by CMMI, which is broader in scope to include most business processes.
ITIL V3

IT Infrastructure Library. (www.itilitsm-world.com/- or (www.itil.co.uk)

ITIL is a guiding framework of best practices for service and asset management. In its 3rd version, it currently consists of 5 best practice volumes focused around the service lifecycle and continuous service improvement.
ASL

Application Services Library
(www.aslfoundation.org

Provides a framework for IT applications development that centers on three management areas: functional, application, and technical management.
SAS 70

Statement on Auditing Standards no. 70, American Institute of Certified Public Accountants (AICPA)  (www.sas70.com)

Developed in 1992 as a follow-on to SAS 55 (internal controls), this is an auditing standard to assess the internal controls on transaction processing. Became the basis of the standard eventually advocated by COSO.
ISO/IEC 20000

International Organization for Standardization / International Electro technical Commission Standard 20000 
(www.20000.standardsdirect.org)

Specifications and Code of Practice for IT Service Management. It is the first international standard for IT service management and is aligned with ITIL best practices.
6-Sigma

Improving business processes to within 6 standard deviations (+/-) from perfection.
(www.motorola.com)

Developed by Motorola in 1986, and widely used and adapted since, 6-sigma is a business improvement methodology aimed at measuring and correcting process and product defects. This may include IT services.
AS 8015
(2005)

Australian Standard for Corporate Governance of Information &Communication Technology (ICT—(www.standards.org.au)

The world’s first national standard for governing ICTs, introduced in March 2003 and subsequently revised in 2005. It prescribes a 3-sequential-step approach to governing ICT projects and ICT operations: evaluate (uses of  ICT)—direct (preparation and implementation of ICT plans and policies to best support the  organization)—monitor (conformance to policies and performance against the plans).
Val IT

Information Systems Audit and Control Association (ISACA) (www.isaca.org)

A new framework aimed exclusively at IT governance. Links management of the IT portfolio to the organization’s strategic objectives.
Table (3-1) IT governance frameworks and best-practice (source: Parent and Blaize, 2009)
3.3. IT Governance and Project Governance Harmonize 
Whereas IS project governance has emerged from IT governance, the relation between all governance levels and IS project activities is clearly identified in Fig. (3-2) which illustrates the governance levels as the main keystone of the pre-development activities governance. Generally, IT governance and IS project governance have the same objectives which concentrate on maximizing the delivered business value from IS/IT investments by analyzing business-IT alignment and risk management with a reasonable accountability and controls. In the context of illustrating the relation between IT governance and project governance, it’s a favorable phenomenon that project governance is based on IT governance principles and its structures, whereas IT governance encompasses many advantages and principles which have ability to establish a good projects governance framework such as; 
    • IT Governance is a structure of relationships and processes that direct and control an organization and help it achieve its goals by adding value while balancing risk against  return over IT and its processes (Leslee and Debra, 2008)
    • IT Governance can be defined as the process of decision-making 
    • IT governance consists of “the leadership and organizational structures and processes that ensure that the IT of an organization sustains and extends the organization’s strategies and objectives” (Kooper et al,2010)
    • IT governance can be deployed by using a mixture of structures, processes and relational mechanisms. Structures involve the existence of responsible functions such as IT executives and a diversity of IT committees while processes refer to strategic decision making and monitoring, and the relational mechanisms include business/IT participation strategic dialogue, shared learning and proper communication (De Haes and Grembergen, 2005)

Fig. (3-2): the position of the pre-development governance
Moreover, IT governance has accordance with the capability maturity model integration (CMMI) which supports and motivates the quality of IS project development and directs to enhances their chance to make success, Fig. (3-3) shows the consistent between IT governance structure and CMMI principles.  











Fig. (3-3): IT governance maturity model (source: De Haes and Grembergen, 2005)
Nowadays, there is an interest in project governance more than IT governance, but it’s not yet well-established as a stream of research or a formally prescribed discipline in practice. Whereas the overall aim of project governance is “a consistent and predictable delivery of projects and programs in accordance with their planned contribution to corporate strategy and stakeholder expectations”, project governance provides a comprehensive, consistent method of controlling the project and ensuring its success. The project governance approach should be described in the project management plan (Bannerman, 2010).
3.4. IS Project Governance
Governance of IS projects is interested in those areas of governance the projects’ activities (Williams et al, 2010); it provides a comprehensive and consistent method of controlling projects and ensuring their success. Project governance provides the structure, through which the objectives of a project are set, and both of the means of attaining those objectives and monitoring performance are determined. IS Project governance is a newborn theory and plays an important role to improve the performance of IS project development. Lambert defined project governance as a series of structures, systems and processes of a project that can ensure the effective delivery and achievement of the due utility (Du and Yin, 2010). 
With no one accord, there is no generally unanimous definition for project governance, but many efforts have been done to define it. Hence, it’s a set of management systems, rules, protocols, relationships and structures that provide the framework which decisions are made within the development and implementation of a project to achieve the intended business or strategic motivation (Bekker and Steyn, 2007). Also, Muller has defined project governance as “the value system, responsibilities, processes and policies that allow projects to achieve organizational objectives and foster implementation that is in the best interests of all the stakeholders”. Its overall aim is “a consistent and predictable delivery of projects and programs in accordance with their planned contribution to corporate strategy and stakeholder expectations” (Bannerman, 2010).
Consequently, good project governance ensures that relevant and sustainable alternatives are chosen and delivered efficiently, In other words, there are three main aims of project governance; choosing the right projects, delivering the chosen projects efficiently and ensuring sustainability for projects. Choosing the right projects means the critical decisions are made through achieving the right objectives, the second of these aims, delivering the projects efficiently is important to avoid wasting public resources, it involves the framework established around the project execution and ensuring the projects and their effects are sustainable (Williams et al., 2010).
3.4.1. Why Adopting Governance for IS Projects 
Practically, there are many benefits and motivations to adopt governance as a solution to decrease the high failure rates of IS projects and address their common defects. Whilst the main purpose of project governance is to enhance the project success by achieving its intended business and strategic motivation, supported by performance and capability of accurate implementation of development activities. So, adopting IS project governance can introduce the following significant features (Bannerman, 2010), (Du and Yin, 2010), (Williams et al, 2010); 
    1. Project governance provides a comprehensive and consistent method of controlling the projects and ensuring their success.
    2. A critical role for project governance is to monitor and control the behavior of management.
    3. It increases the behaviors of accountability and responsibility of project environment.
    4. It provides a structure to monitor the performance to ensure that the intended objectives are attained.
    5. It improves the added value of IS projects and manage IT risks.
    6. It is a critical success factor to define the expected projects’ deliverables.
    7. It can realize the value of a project through the existence of limited resources.
    8. It can achieve strategic alignment between the business and IT 
    9. It considers a standard process and best practices for proper management of IS projects.
    10. It provides good documentations to support IS projects development.
    11. It is still an emergent field in research and practice.
    12. It can improve the quality of the delivered projects. 
On the other hand, the anticipated purpose of executing project governance is to achieve IS projects goals and objectives with maximizing their benefits, taken into consideration the following constraints which define the project success;
    • Proceeding the projects according to specifications, within budget and on time
    • Satisfying and profitable for both the sponsor/owner and contractors.
    • Meet their expectation requirements and objectives with a reasonable quality. 
3.4.2. Main Characteristics and Benefits of IS Project Governance 
         IS project governance can capture the application of new methods, techniques, guidelines, and control tools, this combination of governance components can create a new structure that has the ability to set the optimal scenario to conduct IS projects’ development. It’s a good chance that governance has lots of general characteristics and principles suitable for IS projects to help them to achieve their intended goals and objectives; it can also help delineate the outlines of the way in which the pre-development activities governance can be achieved. General characteristics and principles of governance include; (Abednego and Ogunlana, 2006)
    1. Participation, through involving all parties of projects.
    2. Rule of law, means fair legal frameworks required to be enforced impartially.
    3. Transparency, means all decisions and their implementation must always adhere to the rules and regulations.
    4. Responsiveness, which requires all of the stakeholders to be provided with a reasonable timeframe.
    5. Consensus oriented, which requires mediation of the different interests in the society to understand what the best interest for the whole community is and how it can be achieved.
    6. Equity and comprehensiveness, means all parties are equal and have the same opportunities to improve or maintain their purpose
    7. Effectiveness and efficiency, which means having the ability to obtain results that meet the needs of the society while still making the best use of available resources.
    8. Accountability, means all parties are accountable to those who will be affected by their decisions or actions and be enforced through transparency and rule of law.
Additionally, IS governance has many significant advantages help to improve the performance of IS project development process as follows;  
    • Monitor and controlling the behavior of project management as a critical role for governance.
    • Having the ability to accelerate the project development process.
    • Decreasing costs and idle time.
    • Improving the added value of IT investments and managing IT risks.
    • Realizing the value of the project.
In fact, demonstrating the previous facts and advantages of project governance through defining their characteristics and principles gives a clear evidence that the project governance can contribute to solve the main problems of IS projects and can make improvement through the performance of project development process, accordingly these benefits of project governance justify the necessity of adopting the pre-development activities governance as a solution to decease the failure percentages and enhancing IS project success.
3.5. Exploring the Previous Researches of IS Project Governance 
In fact, the previous researches confirm the lack of guidance and governance framework that interested in IS project governance, IS projects governance is consider a newborn theory, it’s not yet well-established as a stream of research, relatively new and evolving field of research, It has been emerged from the IT governance arena. A small number of researches have discussed the main aspects and definitions of IS project governance. Investigating and surveying those researches confirm the lack of guidance and frameworks in regard to IS projects governance (Bekker, Steyn, 2008), (Bannerman, 2009), (Williams et al., 2010). Also, there is a lack of governance tools, techniques, best practices and frameworks to conquer the main failures and defects of IS projects; the inspection of the following researches will confirm these consequences.
Sherer A. Susan, (2004,) explored the role of governance in prioritizing and justifying IS projects by developing a model of IT selection process based on the influence of a strategic vision. The influence of strategic vision associated with both the type of projects considered, the resources allocated for information systems, and the processes and mechanisms of justifying IT investments. He suggested that IT governance plays a role in influencing IT project selection.
De Haes and Grembergen,( 2005), showed how to implement IT governance by using a mixture of various structures, processes, and mechanisms. They explained the harmony between Governance and CMMI. In this research, they introduced many governance structures, mechanisms, and processes which applied on many case studies in practical environment. They concluded with demonstrating the Top 10 most significant IT Governance structures and practices which include:-
    1. IT steering committee (IT investment evaluation, prioritization at executive, senior management level)
    2. CIO on executive committee
    3. Portfolio management (including business cases, information economics, ROI, payback)
    4. IT budget control and reporting
    5. IT strategy committee at level of board of directors
    6. IT leadership
    7. Strategic information systems planning
    8. IT project steering committee
    9. CIO (Chief Information Officer) reporting to CEO (Chief Executive Officer) and/or COO (Chief Operational Officer)
    10. Project governance / management methodologies.
Larsen et al, (2006), explored how IT Governance is adopted in the practical environment of IS projects based on reviewed of different seventeen IT Governance Tools that are:-
    1. ITIL: Information Technology Infrastructure Library
    2. COBIT: Control Objectives for Information and Related Technology
    3. ASL: Application Services Library
    4. Six Sigma: Six sigma stands for Six Standard Deviations from mean
    5. CMM/CMMI: Capability Maturity Model
    6. IT Service CMM
    7. SAS70: SAS70 is an auditing standard
    8. ISO 17799: The ISO 17799 or the counterpart of British Standard
    9. SOX: The Sarbanes-Oxley Act of 2002
    10. SysTrust: The SysTrust service is an assurance Service
    11. PRINCE2: PRINCE, which stands for Projects IN Controlled Environments
    12. IT Audit: Sisco (2002) 
    13. IT Due Diligence: Sisco (2002b) 
    14. IT Governance Review
    15. IT Governance Assessment
    16. IT Governance Checklist
    17. IT Governance Assessment Process (ITGAP) Model
     Wang and Chen (2006) examined the influence of governance on ERP projects’ success by implementing an empirical analysis based on the implementation of 122 ERP projects, which showed a significantly positive relationship between governance and ERP projects’ success. They concentrated on four certain governance mechanisms for ERP projects that show to be particularly important in determining how the project might be executed; these mechanisms are explicit contracts, implicit contracts, reputation and trust. They submitted that governance of ERP implementation can be understood as a balanced concept. This perspective may be extended to analyze the governance evolution over the ERP system lifecycle (e.g., over the phases of pre-implementation, implementation, and post-implementation). 
Bekker and steyn (2008) provided a brief overview of ‘Project Governance’ definitions, how the Concept Project Governance Framework (CPGF) was derived and how the governance principles were applied and evaluated against two primary case studies with fifteen secondary case studies. They investigated the influence of application or non-application of project governance principles on projects outcomes and also confirmed the need for a formal definition of project governance.
Besides, they explained the difference between project governance and project control that lies within the internal project environment and is one of the key responsibilities of the project manager. The internal environment is surrounded by an external environment, which comprises of external organizational forces, stakeholders, economic and political forces, etc that could have an effect on the overall project performance. Hence, project governance is a set of management systems, rules, protocols, relationships and structures that provide the framework, within which decisions are made for project development and implementation, to achieve the intended business or strategic motivation.
They drew to a conclusion that a formal project governance framework is needed, and they also indicated that the skill level of the steering committee, as well as the adherence to ethical and responsible conduct, and conflict of interests could have a profound impact on the project performance. Thus, there are many aspects must be considered when applying project governance such as: 
        ◦ Project governance must support, and be aligned with, all aspects of corporate governance.
        ◦ Project governance should be generally applicable in the developed and developing world.
        ◦ Project governance should be practical to implement and monitor.
        ◦ The management of project finance and associated risk should be crucial to project governance.
Ding and Wang (2008) introduced governance as a critical success factor for IS/IT projects; they designed a questionnaire based on critical success factors in project governance. This questionnaire is formed with the help of former theory and empirical result. Candidates include project managers (project team), project customers, project suppliers and sub- contractors. The designed questionnaire includes two parts: background of candidates and 71 questions. According to the result analysis, they defined the top ten factors for projects governance as follows:
    • Requirement Analysis
    • Constrain and Prompting Mechanism
    • Risk Management
    • Project Organization and Coordination
    • Process Control
    • Objective Setup
    • Communication and Information Issuance
    • Conflict Management
    • Input and Commitment from stakeholders
    • Project Management Environment
Bekker and steyn (2009) introduced Project Governance Framework (PGF) that offers practical guideline and checklist for project governance (including auditing). The proposed framework provides a guideline and serves as reference for project stakeholders to establish their own governance principles and protocols. The framework supports corporate governance principles and incorporates views from both developed and developing countries regarding governance. The (PGE) base on four factors:
    1. Project Steering Committee 
    2. Cost and Benefit Management
    3. Project Reviews and Audits
    4. Ethical, responsible conduct and conflict of interest 
Thus, they provided many answers for many questions relate to the context of project governance such as;
    1. What is define/describe the concept ‘project governance’?
    2. Do current project management frameworks and practices fail to address project governance? 
    3. What are the similarities between corporate governance and project governance?
    4. What are the differences between corporate governance and project governance?
    5. What are the differences between project control and project governance?
    6. To what extent should a project governance model for large capital projects be project specific and/or company specific?
They concluded with defined Project governance as: a set of management systems, rules, protocols, relationships and structures that provide the framework within which decisions are made for project development and implementation to achieve the intended business or strategic motivation. 
 Bannerman (2009) confirmed that software projects governance is a nascent field of research, which extends governance principles down from the corporate and IT domains to the software project development in software-developing organizations. Viewing governance as meta-management avoids the limitations of functional and structural approaches and forces a clear distinction between governance and management. The major purpose of software project governance is to establish how the organization’s software development capability is sustained to meet its engineering and business needs.
Jaafar and Ernest (2009) explained that IT/IS projects fail for several reasons. According to the study performed in Canada of 1,450 public and private sector organizations, IT/IS project failures are due to three common reasons:
    1. Poor project planning, which is attributed to inadequate risk management and weak project plan.
    2. A weak business case; whereas systems should be justified directly to the organization’s business needs.
    3. Lack of top management involvement and support
They have declared that there is still no correct way of IT governance in an organization, more specifically in IT/IS projects. Also, there are few issues of Information Technology Governance (ITG) at IT project level. the implementation of many IT projects in organizations worldwide may face the risk of being cancelled or cost overruns.
Sharma et al, (2009) presented the results of a qualitative study of information technology (IT) project management and governance. They explained how important the IT governance is and how good projects governance can be assured. The results are supportive of the idea that project governance and project management are closely related but not identical. Organizations may have good project management but not good project governance. Governance of IT projects is of course facilitated by having experienced, well-trained senior project management and by the organization having an established methodology for managing projects. 
Governance sometimes needs undergoing a challenge and ‘shake-up’. It may require investment and work to ensure senior management commitment, as well as an injection of governance skills and possibly even articulation or re-articulation of governance culture. Governance should also address IT strategy alignment, return on investment, project completion, as well as the notion focusing on project governance increases the chances of better project delivery.
USAID (2010) declared that IT/IS project governance emphasizes the best practices and decision processes that enhance the effectiveness of system development projects and the delivery of IT systems. project governance identifies a methodical progression of the best practices that are to be systematically and uniformly performed throughout the life cycle of an IT project. IT project governance incorporates project, configuration, security, and portfolio management processes, as well as complementary enterprise disciplines, including- but not limited to- Capital Planning and Investment Control (CPIC), Enterprise Architecture (EA), and  Automated Directives System’s (ADS). 
They concluded that IT project governance focuses on delivering IT systems that: 
    • Meet or exceed customer needs and expectations. 
    • Work effectively and efficiently within the current and planned technical infrastructure 
    • Offer production-quality reliability and performance 
    • Are inexpensive to maintain and cost-effective to enhance. 
The strategic objectives for the IT Project Governance framework are as follows: 
    • Predictably deliver consistent systems when promised and within cost estimates 
    • Institutionalize policies, procedures, standards, and the best practices. 
    • Facilitate cross-functional communication, coordination, and collaboration 
    • Provide for on-going process improvement and a means to reflect “lessons learned” 
Williams et al, (2010) investigated four case studies which form a key part of an investigation into public investment project governance frameworks in Norway and UK. These four case studies are examined to see how the implemented governance frameworks actually affect project management and how consistent they are with the stated aims. They provide three main objectives for project governance; choosing the right projects, delivering the chosen projects efficiently and ensuring that projects are sustainable. They introduced a number of conclusions that are drawn from the four cases such as; 
    • The importance of governance was apparent, particularly in the early stages of projects where concepts are established.
    • There is a great difference between a straightforward statement of the  governance process and the actualities of projects.
    • All cases confirmed the importance of a governance framework. It is clear that the complexity involved in the decision-making, technology and contracts means that a governance framework is particularly important, although it may be a challenge for quality assurance. 
      Marnewick and Labuschagne, (2011): this research reports on the investigation of IT/IS projects in South African organizations to determine whether generally accepted governance principles were applied in the project domain. They proved that non-adoption of governance principles might contribute to little or no organizational add value for IS projects, despite substantial investments being made. They tested this statement, through 16 semi-structured interviews. Using the findings of the investigation, a conclusion is drawn that the majority of the organizations do have corporate governance but they do not comply with IT and IT/IS project governance.
3.6. Chapter Conclusions 
In this chapter, an investigation study has been represented to explain the main concepts of IS project governance besides the characteristics, importance, principles and structures of project governance. The relation between IT governance and project governance is also illustrated as they are consistent and congruous with each other. Project governance is emerged from IT governance, Surveying the previous researches that interested in the areas of project governance and IT governance are conducted; additionally, there are more significant results are concluded in this chapter that are:-
    1. Governance of IS projects is considered a new born theory, relatively new and evolving field (it’s not yet well-established as a stream of research). It has emerged from the IT governance arena
    2. Previous researches in this topic concentrated on high level project governance (general perspective) viewing the project as one block; they did not implement project governance in a specific perspective according to the projects development’ phases and activities. 
    3. There is a great anticipation that pre-development activities governance can contribute to enhance the IS projects success and decrease the projects failure rates through attaining most intended objectives and goals of IS projects. 
    4. Surveying the previous researches in this topic shows the lack of tools, techniques, frameworks and guidance regarding to IS projects governance, it, further, shows the lack of quantitative models and techniques to perform the project governance.
    5. Most researches described the project governance as a part of project controls.
    6. Governance is defined as the process to empower people to make decisions through chains of responsibility, authority and communications.
    7. IS project governance has emerged from IT governance.
In conclusion, it must emphases on, the main objective to adopt IS project governance in this research is to achieve IS project goals and objectives with high-quality output which due to decrease the projects’ failure, this can be achieved by setting a chart describing the main procedures to attain the project success, taking into account the main constraints to achieve the projects’ success. 











Chapter (4)
Governance Framework 
for the Pre-development Activities
















Chapter (4)
Governance Framework for the Pre-development Activities
4.1. Introduction:
Essentially, good governance framework should sustain IS projects to be fluid and move ahead to fulfill their strategic and intended business objectives,  not to delay by too much obstacles and unnecessarily events in development’ phases. It should provide a logical, robust and repeatable best practices and controls by the purpose of governing the projects’ activities. Also, it should be simple and straightforward to lead IS projects to realize success. So, a set of distinct characteristics are essential and should be established to build good governance framework as the main purpose of this research, that are;
    • Confirm that the intended objectives of the completed projects are attained. 
    • Identify all projects’ stakeholders with their interested issues and the method of communication between them.
    • Has clear policies and objectives
    • Define business and system requirements as agreed by all stakeholders
    • Comprise clear assignment of project roles and responsibilities
    • Contain a current, published project plan that extents all project stages
    • Contain a central document repository for the project with glossary of project terms
    • Define standards for quality review of the key governance processes and of the projects’ deliverables
    • Encompass Control tools to verify the project success throughout all development’ activities
    • Has a strategy to avoid the previous failures and communicates the lessons learned for the successful projects.
    • Determine the best expected deliverables of all project’ activities   
It has been deduced from the previous researches in the topic of project governance that, the application of IS project governance was represented in adopting IT governance frameworks which are based on processing a set of IT governance controls that are probably used in projects development, and the most common of these framework are; (Ridley et al, 2004), (Ronnie et, al., 2008), (Parent and Blaize, 2009).
    • PRINCE2, contains Directing a Project process (DP), targeting a project board that is “accountable for the project’s success by making key decisions and exercising control while delegating day-to-day management of the project to the Project Manager” DP process covers initiation, authorization, stage boundaries, ad hoc direction, and project closure.
    • COBIT, designed by IT Governance Institute, COBIT introduces good practices, representing the consensus of experts, to optimize IT-enabled investments, ensure service delivery, and provide detailed metrics. 
    • 6-Sigma, developed by Motorola in 1986, and widely used and adapted since, 6-sigma is a business improvement methodology aimed at measuring and correcting process and product defects. 
    • COSO (The Committee of Sponsoring Organizations) provides a widely accepted control framework for enterprise governance and risk management.
    • CMM / CMMI, was developed in1980s to support managing the large software development projects. It posits five maturity levels. CMM was replaced by CMMI, which is broader in scope to include most business processes.
    • IT GAM (IT Governance Arrangements Matrix) A set of 5 IT Decision Domains (principles, architecture, infrastructure, business applications, and investment). 
On the subject of developing a governance framework for the pre-development activities in this research, it must emphasis on establishing the following principles, which depict the main outlines of IS project governance framework:-
    1. The main purpose to apply IS project governance, is to enhance IS projects’ success through achieving the intended business and strategic motivations, also sustain the projects performance and the methodology to implement the project development activities.
    2. Project governance in this context means, a set of policies, procedures, protocols, tools, and structures that provide a comprehensive and consistent method of controlling projects to achieve their organizational and business objectives, also encourage the implementation toward the best interests of all the project’ stakeholders.
    3. The lack of projects governance frameworks and guidelines are the incentive trigger and motivation to develop the project governance framework as a solution in order to decrease the high failure rates of IS projects. 
    4. The purposed framework will expose to the most significant Pre-development activities which have a great influence to cause projects’ failure in high percentages.
Undoubtedly, the purposed governance framework will generate a good governance structure represents the keystone of the project’ development, also it explains the main components of IS projects governance and how governance procedures will be designed and executed. 
4.2. Pre-development Activities Governance as Specific Approach 
By looking at the previous studies which concerned with IS projects governance, it’s evidential that, there is a consensus of IS projects governance is consider relatively new and evolving field (it’s not yet well-established as a stream of research), It has been emerged from the IT governance arena. Also there is a lack of guidance and frameworks regarding to IS projects governance, these consequences are confirmed throughout the few researches which discussed IS project governance (Johnstone et al, 2006), (Bekker, Steyn, 2007), (Ding and Wang 2008), (Bannerman, 2009), (Parent and Blaize, 2009), (Bannerman, 2010), (Du and Yin, 2010), (Kooper et al, 2010), (Williams et al., 2010).
 Furthermore, these researches concentrated on high level project governance (In general perspective) by meaning view the project as one block; they didn’t address the project governance in a particular perspective in details according to its development’ phases and activities. In fact, there is a great anticipation in the case of adopting the specific project governance, it will contribute to enhance IS projects success and decrease the projects failure rates through achieving the project intended objectives and manage its IT risks. 
The main structure of projects governance as specific approach depends on execution of project governance in deep, according to the project development’ phases and activities in details (Hamada et al, 2011)a. Not to consider the project as one entity (as one block), also analyze the projects into their phases and divide each phase into its activities. It is well known, there is an agreement that, IS project management life cycle consists of five phases; initial phase, planning phase, execution phase, and closing phase (Hughes and Cotterell, 2004), (Bekker, and Steyn, 2008), (PMI, 2008), in this approach all project’ phases will be divided into consistent activities to facilitate governance implementation in accurate form. Fig. (4-1), explains the flow of the specific governance approach for IS projects. 

                  
Fig. (4-1) the flow of the specific governance approach for IS projects 
Essentially, after partitioning IS projects into their phases and activities, governance process is applied for each development activity in details. It should perceive that governance framework at this approach will be compatible with the common governance framework (PRINCE2, COBIT, COSO, 6-Sigma, and CMM/ CMMI), also, it will be integrated with implementing a mixture of governance mechanisms such as (Arrangements, Structures, policies, Best practices, Strategies, Controls, Rules, Relationship, Guidelines Standards, and Checklists).  
Embedded the suggested governance mechanisms and tools can generate a new model of project activities governance that have ability to decrease the project defects and lead to enhance IS project success. Fig. (4-2) explains the key stone of the suggested governance framework for the pre-development activities through incorporate the governance mechanisms and tools. 




                                  Install                                       output 



Fig. (4-2), key stone of the governance framework for the pre-development activities
According to the great correlation between the occurrence of IS project failure and the pre-development activities, whereas the most significant failure reasons are originated from the pre-development activities (Hamada et al, 2011)b. Governance of the pre-development activities in this research introduced to explain the application of specific governance approach for IS projects. Pre-development activities are critical success factors for IS projects development, they begin with the System Service Request Assessment (SSR) which initiates IS projects and end with the project plan development and schedule. Table (4-1) illustrates the main pre-development activities which the outcome of dividing two main development phases of IS projects (initial and planning phase).
Project phase 
Pre-development activities
Initial phase
Pre-development Activities
    1. System Service Request assessment (SSR).
    2. Project Scope Definition.
    3. Project Feasibility study.
    4. Commercial Off-The-Shelf (COTS) selection.
    5. Project Requirements Elicitation
Planning phase

    1. Develop project Charter and Statement of Work (SOW).
    2. Work Breakdown Structure (WBS).
    3. Project Cost Estimation 
    4. Project Risk Management. 
    5. Develop a Communication Plan.
    6. Project Contract
    7. Develop a Project Plan and Schedule.
Table (4-1) outcome of dividing two projects’ development phases (initial and planning) 
4.3. Governance Framework for the Pre-development Activities 
Designing the project governance framework is going through two different development phases, the theoretical and conceptual framework. The theoretical framework      represents the main outlines of the governance methodology which depicts how IS project governance will be executed and shows the main components of project governance. In the other hand, Conceptual framework represents the main steps and procedures of applying governance.  
In fact, COBIT encourages the creation, evaluation, and continuing improvement of IT services in order to achieve business objectives (Abu-Musa, 2009). It enables the development of clear policies and good practice for IT control throughout enterprises. According to the definition of (COBIT v4.1) for Control, “which is defined as the policies, procedures, practices and organizational structures designed to provide reasonable assurance that business objectives will be achieved and undesired events will be prevented or detected and corrected” (ITGI, 2007). The purposed governance framework should include the previous aspects of control to sustain the projects’ objectives and prevent any undesired events that can influence the projects’ success.
 Therefore, the main governance components which are the backbone of the purposed governance framework are illustrated in Fig. (4-3), they encompass policies, procedures, best practices, checklists, and define the expected deliverables of projects’ activities. These governance components as encapsulated are consider the main structure of the theoretical IS projects governance framework. So, based on the structures in figures (4-1, 4-2 and 4-3) the theoretical framework of pre-development activities governance is clearly constituted as showing in Fig. (4-4) 

Fig. (4-3) Main governance components of the Pre-development activities
Throughout the purposed governance framework, it must emphases on giving more attention to the governance components which are the base to achieve the intended objectives of adopting governance the pre-development activities, they incorporate;
    • Policies and procedures; Policies are general principles and a set of actions put in place to govern the projects’ processes and activities, they consist of a set of principles, purposes or objectives and strategies. These principles and objectives ensure compliance and enhance the project’s mission. Whereas procedures provide step-by-step actions and detailed descriptions of what is needed to carry out policies.
    • Best practices; a set of guidelines and well-defined process that can guide and support the management of projects’ resources and contribute to achieve projects’ success. They also involved experiences and the most lessons learned from the previous successful projects. These guidance instructions must be considered during the project development. They can help to prevent the problems that can cause the project failure which reduce the failure rates of IS project. CMMI best practices for systems and software development will be integrated widely in this framework (CMMI, 2001)   
    • Suggested practices and checklists are governance components help to improve the performance the pre-development activities and support the projects’ success. 
    • Define the expected deliverables define the best output that should be existed after conducting each pre-development activity 
Taking into account, the designed governance framework is integrated with the Capability Maturity Model Integration (CMMI) which interested in development process improvement. Also, it is integrated with the common recommended Software Development Standards such as IEEE standards that are the famous software development standards, these as an assistant guidance for IS project development governance. In addition to, the mixture of policies, procedures, critical success factors checklists, best practices and organizational structures at this framework are designed to work as a bulwark to prevent the undesired events and help to provide reasonable assurance that the project objectives will be achieved. 



















Fig. (4-4) Theoretical governance framework for the pre-development activities 
As the result of  the purposed governance framework is consistent with the objectives of CMMI, and is integrated with software projects development standards as IEEE standards (IEEE, 1998)a. a particular attention should be paid to investigate (IEEE standards for software project development) and CMMI which has a great reliability and suitability with the IS project governance and control principles. 
4.3.1. Capability Maturity Model Integration (CMMI)
CMMI (Capability Maturity Model Integration) models are collections of best practices that help organizations to improve their processes (CMMI, 2010). It was originally proposed by the Software Engineering Institute, It provides a framework to continuously measure, evolve and improve the processes for software development. It consists of best practices that address development and maintenance activities that cover the product lifecycle from conception through delivery and maintenance (Sun and Oza, 2008). CMMI Product Suite concerned with projects development, in which, project is defined as a managed set of interrelated resources which delivers one or more products to a customer or end user. A project has a definite beginning and typically operates according to a plan, such a plan is frequently documented and specifies what is to be delivered or implemented, the resources and funds to be used, the work to be done, and its schedule (Von et al, 2010). 
The main objective of CMMI is to provide guidance for improving an organization’s processes and its ability to manage the development, acquisition, and maintenance of products or services. CMMI constellations have being generated supporting specific areas of interest including; CMMI for Services (CMMI-SVC), CMMI for Acquisition (CMMI-ACQ) and CMMI for Development (CMMI-DEV) which focuses on software development. The main purpose for these structures is to help organizations to improve their development and maintenance processes for both products and services. Furthermore, CMMI models are basically composed of a process area dimension and a capability/maturity dimension, in which a process area is a cluster of related practices in an area that, when implemented collectively, satisfy a set of goals considered important for making improvement in that area (Von et al, 2010). 
Level
Level Key Process Areas
1. Initial
Process is informal and ad hoc
2. Managed
Requirements Management
Project Planning
Project Monitoring and Control
Supplier Agreement Management
Measurement and Analysis
Process and Product Quality Assurance
Configuration Management
3. Defined
Requirements Development
Technical Solution
Product Integration
Verification
Validation
Organizational Process Focus
Organizational Process Definition
Organizational Training
Integrated Project Mgmt
Risk Management
Decision Analysis and Resolution
Integrated Teaming Org. Environment for Integration
Integrated Supplier Management
4.Quantitatively
Managed
Organizational Process Performance
Quantitative Project Management
5. Optimizing
Organizational Innovation and Deployment
Causal Analysis and Resolution
Table (4-2) CMMI and key process areas (source: Caballero et al, 2009)
CMMI is best known for its five levels of organizational maturity namely initial, managed process, defined process, and quantitatively managed process and optimizing process. Each level represents a coherent set of best practices organizations are expected to implement as they become better at what they do. Regarding to the consistent between CMMI and IS project development, CMMI has many arrangements and standards organize the most of projects development activities such as; configuration management, measurement and analysis, organizational process, project monitoring and control, process and product quality assurance, risk management, supplier agreement management and the form of the project plan, table (4-2) explains the relation between CMMI levels and projects’ activities and the key process area. Whereas, Maturity levels are conceived as well-defined evolutionary road to a continuous improvement of the software process, and Capability levels are well defined evolutionary plateaus describing the organization’s capability relative to a process area. So, continuous representation of CMMI establishes four process areas; project management, support, engineering and process management, in which they help to define the outline of projects’ goals (Caballero et al, 2009). 
4.3.2. IEEE Standards for Software Projects Development 
IEEE Standards are developed within the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The standards developed within IEEE represent a consensus of the broad expertise on the subject within the Institute as well as those activities outside of IEEE that have expressed an interest in participating in the development of the standard (IEEE, 1998)b. The following section surveys the main issues of IEEE standards which concerned with the main development phases of software projects.    
4.3.2.a. IEEE Standards for System Planning
1058-1998	IEEE standard for software project management plans
The format and contents of software project management plans, applicable to any type or size of software project, are described. The elements that should appear in all software project management plans are identified.
1058.1-1987 	IEEE standard for software project management plans
This standard specifies the format and contents of software project management plans. It does not specify the exact techniques to be used in developing project plans, nor does it provide examples of project management plans. This standard is applicable to all types of software projects; applicability is not limited to projects that develop operational versions of new products. Application of this standard is not limited by project size. It contains three sections. In most instances, project plans based on this standard will be developed by repeated iteration and refinement of the various elements in the plan.
828-2005 	IEEE Standard for Software Configuration Management Plans
Describes the IEEE standard for software configuration management plans, establishes the minimum required contents of a software configuration management plan and defines the specific activities to be addressed and their requirements for any portion of a software product's life cycle.
730-2002 	IEEE Standard for Software Quality Assurance Plans
Uniform, minimum acceptable requirements for the preparation and content of software quality assurance plans (SQAPs) are provided. This standard applies to the development and maintenance of critical software. For non-critical software, or for software that has already been developed, a subset of the requirements of this standard may be applied
1012-2004 	IEEE Standard for Software Verification and Validation
Software verification and validation processes, which determine whether development products of a given activity conform to the requirements of that activity, and whether the software satisfies its intended use and user needs, are described. This determination may include analysis, evaluation, review, inspection, assessment, and testing of software products and processes. V&V processes assess the software in the context of the system, including the operational environment, hardware, interfacing software, operators, and users
1074-2006 	IEEE Standard for Developing a Software Project Life Cycle Process
A process for creating a software life cycle process is provided. Although this standard is directed primarily at the process architect, it is useful to any organization that is responsible for managing and performing software projects.
1061-1998 	IEEE standard for a software quality metrics methodology
A methodology for establishing quality requirements and identifying, implementing, analyzing and validating the process and product software 	quality metrics is defined. The methodology spans the entire software life-cycle.
1028-1997	IEEE Standard for Software Reviews
The IEEE standard for software reviews defines five types of software reviews, together with procedures required for the execution of each review type. This standard is concerned only with the reviews; it does not define procedures for determining the necessity of a review, nor does it specify the disposition of the results of the review. Review types include management reviews, technical reviews, inspections, walk-throughs, and audits.
1062-1998	IEEE recommended practice for software acquisition
A set of useful quality practices that can be selected and applied during one or more steps in a software acquisition process is described. This recommended practice can be applied to software that runs on any computer system regardless of the size, complexity, or criticality of the software, but is more suited for use on modified-off-the-shelf software and fully developed software.
4.3.2.b. IEEE Standards for System Analysis	
830-1998	IEEE recommended practice for software requirements specifications
The content and qualities of a good software requirements specification (SRS) are described, and several sample SRS outlines are presented. This recommended practice is aimed at specifying the requirements of software to be developed, but can also be applied to assist in the selection of in-house and commercial software products. Guidelines for compliance with IEEE/EIA Std 12207.1-1997 are also provided.
4.3.2.c. IEEE Standards for System Design
1016-1998	IEEE recommended practice for software design descriptions
The necessary information content and recommendations for an organization for Software Design Descriptions (SDDs) are described. An SDD is a representation of a software system that is used as a medium for communicating software design information. This recommended practice is applicable to paper documents, automated databases, design description languages, or other means of description.
4.3.2.d. IEEE Standards for System Implementation
829-1998	IEEE standard for software test documentation
A set of basic software test documents is described. This standard specifies the form and content of individual test documents. It does not specify the required set of test documents.
1008-1987	IEEE standard for software unit testing
An integrated approach to systematic and documented unit testing is described. The approach uses unit design and unit implementation information, in addition to unit requirements, to determine the completeness of the testing.
1044-1993	IEEE standard classification for software anomalies
A uniform approach to the classification of anomalies found in software and its documentation is provided. The processing of anomalies discovered during any software life cycle phase are described, and comprehensive lists of software anomaly classifications and related data items that are helpful to identify and track anomalies are provided. This standard is not intended to define procedural or format requirements for using the classification scheme. It does identify some classification measures and does not attempt to define all the data supporting the analysis of an anomaly.
1063-2001 	IEEE standard for software user documentation
Minimum requirements for the structure, information content, and format of user documentation, including both printed and electronic documents used in the work environment by users of systems containing software, are provided in this standard.
At the next chapter, the application of IS project governance framework on the pre-development activities will be taken place, particularly, on the critical ones which have a great effect to cause IS project failure. Governance framework application will be explained in details through the mixture of governance principles and mechanisms. In which new structures of IS project governance tools and techniques will be implemented.
4.4. Chapter Conclusion
A set of good characteristics that are essential issues and should be established for the effective project governance framework are explained. There is a great anticipation that, specific perspective of IS project governance can contribute to enhance IS projects success and decrease projects failure rates through attaining the intended projects’ objectives. Project governance as specific approach depends on the execution of project governance in deep, based on projects development’ phases and activities 
This chapter illustrates the main structures of building the theoretical IS project governance framework, the initial framework to governance the project’ pre-development activities as a specific approach is the keystone of governance framework. Also, IS project governance framework is harmonizing with the main objectives of (CMMI) and is integrated with the software projects development standards especially (IEEE standards). Furthermore, the governance framework is based on four main components depict the implementation methodology of governance the pre-development activities of IS projects that are; 
    • Policies and procedures of executing the pre-development activities.
    • Best practices to prevent the failure within the pre-development activities
    • Tools and Checklists to improve the performance of the pre-development activities.
    • Define the expected deliverables for the pre-development activities.
Also, this chapter explains the importance of (CMMI) and IEEE standards for software projects development, in which the governance framework has accordance with them. The significance of (CMMI) and IEEE standards is attributed to the great suitability of the two models with the project governance and control principles, which can be used as assistant tools for the implementation framework. whereas IT governance is the root of project governance and it concerned with the structure of relationships and processes which can direct and control the project activities and help to achieve the projects’ goals.

















Chapter (5) 
The Application of Pre-development 
Activities Governance 
















Chapter (5) 
Application of Pre-development Activities Governance 
Introduction:
The application of governance framework is the most important phase in this research. There is a great anticipation that, the implementation of the designed governance framework will achieve the intended objectives to enhance IS project success and decrease the project failure rates. It should be taken into consideration; the application of governance framework will focus on the main pre-development activities which have a great influence to cause IS projects’ failure in high percentage. 
5.1. Determine the most significant pre-development activities
In fact, through analyzing the previous researches and statistics which investigate the failure reasons of IS projects. It can discover the main pre-development that have a great influence to cause IS projects’ failure  (Uher and Toakley, 1999), (Ram, 2002), (Yeo K.T., 2002), (Hartman and Ashrafi, 2004), (Kwak and Stoddard, 2004), (Herroelen,2005), (Humphrey, 2005) (Kutsch and Hall, 2005), (Rajagopal et al, 2005), (Yongyi and Ying, 2005), (McManus and Wood, 2007), (Lin et al, 2007), (Davey and Cope, 2008) (Verner et al, 2008), (Pan et al, 2008), (Uppal, 2008), (Al-Ahmad et al, 2009), (Cerpa and  Verner, 2009), (Lepage,2009), (Ashra and Ahsan, 2010), (Kausar, et al., 2010), (Huang et al., 2010), (Liao, 2010), (Stern and Arias, 2011). 
    1- There is a significant body of evidence that, lots of implementation information systems projects end in failure, this failure rate for major systems appears to linger around 70% (Pan et al, 2008)
    2- A Study was conducted in the UK by Oxford University and Computer Weekly in 2003 reported, strikingly, that only16% of the IS projects reviewed were considered successful (Al-Ahmad et al, 2009).
    3- Table (5-1) explains the Standish Group survey for IS projects which indicates to the low percentages of the successful projects on the contrary the high percentages of the failed and challenged projects is appeared clearly (Yong et al., 2007)

1994
1996
1998
2000
2004
2009
Successful projects 
16%
27%
26%
28%
29%
32%
Challenged projects
31%
40%
28%
29%
53%
44%
Failed projects
53%
33%
46%
43%
18%
24%
Table (5-1) the Standish Group survey on IS projects (source: Yong et al., 2007)
    4- The failure reasons have often been blamed on poor project definition, incomplete information, poor productivity, inadequate communications, uncertainties around labor and material costs, and the failure to use timely and appropriate project management practices and controls (Uppal, 2008).
    5- According to practitioners surveyed, IT/IS project failure was most commonly attributed to lack of top management involvement, a weak business case and inadequate risk management. The highest ranked factor for project failure was risk management (Kutsch and Hall, 2005).
    6- IS projects are often difficult to estimate and manage and some projects are canceled or reduced in scope because of overruns in cost and time or failure to produce anticipated benefits (Ram, 2002).
    7- It is widely recognized that poor project planning plays a major role as one of the significant causes of project failure (Hartman and Ashrafi, 2004)
    8- Lots of information systems projects studies indicate that failure is largely due to organizational and social, rather than technical factors (Pan et al, 2008).
    9- Project failures are the result of the multiplicity of risks inherent in software project, there are three key software risk factors; (Kwak and Stoddard, 2004)
    • Risks associated with inaccurate estimating and schedule planning
    • Risks associated with incorrect and optimistic status reporting
    • Risks associated with external pressures, which damage software projects.
    10- Software projects may encounter various types of risks that are; Technical risks, Management risks, Financial risks, Contractual and legal risks, Personnel risks and Other resource risks (Stern and Arias, 2011)
    11- According to Standish report, success rate of software project is only 28%. An unclear and imprecise requirement is a major contributing factor in such a low rate of success. Another survey also pointed out that only 12.7% out of 1027 software projects were successful and top reason for the failure was “unclear objectives and requirements” (Kausar, et al., 2010)
    12- Studies by (Beichter et al, 1993) indicate that, 70% of the system errors are due to the inadequate system specification and 30% of the system errors are due to design issue (Rajagopal et al., 2005)
    13- Errors in requirements elicitation are, overall, the most serious in software development, and the hardest to repair. 70% of the systems errors are due to inadequate system specification and 30% of the system errors are due to design issues (Rajagopal et al, 2005)
    14- It’s appeared that between 40% and 60% of software projects’ failures and defects are the result of poor software management and requirements definition (Huang et al., 2010)
    15- The most of software projects failed due to inadequate requirements. As an important part of Requirements Engineering is requirements elicitation which is the process involving some activities, such as seeking, uncovering, acquiring, and elaborating requirements (Liao, 2010)
    16- In 2006 (Davis et al), found that “inaccurately capturing system requirements is the major factor in the failure of 90% of large software projects,” also, (Lindquist) in 2005, concluded poor requirements management can be attributed to 71 percent of software projects that fail; greater than bad technology, missed deadlines, and change management issues” (Davey and Cope, 2008)
    17- At Savant Institute, a study found that, 56% of errors in installed systems were due to poor communication between user and analyst in defining requirements and that these types of errors were the most expensive to correct using up to 82% of available staff time (Ashra and Ahsan, 2010)
    18- According to  (Verner et al, 2008),  Standish Group in 1999 indicated, 20% of software projects failed, and that 46% experienced cost and schedule overruns are the main causes. (Verner et al, 2008).
    19- Furthermore, examining the projects failure reasons within the statistics in the following tables:-
    A. Table (5-2), that published in (2008) by the two famous independent research organizations for IS/IT projects (PM Hut, 2008).
    B. Table (5-3), whereas Cerpa and Verner in (2009) demonstrated the failure reasons of seventy failed projects developed in house at U.S., Australia, and Chile (Cerpa and  Verner, 2009).
    C. Table (5-4), explains the correlation between the projects’ failure reasons and their related pre-development activities. 
    D. Table (5-5), explains the main failure reasons related to Project Feasibility Study
    E. Table (5-6), explains the main failure reasons related to Project Requirements Elicitation
    F. Table (5-7), explains the main failure reasons related to Project Risk Management
    G. Table (5-8), explains the Main failure reasons related to Project Cost Estimation
    H. Table (5-9), explains the main failure reasons related to Project plan development and schedule
The Standish Group Statistics
Percentage
Incomplete Requirements 
13.1%
Lack of User Involvement 
12.4%
Lack of Resources 
10.6%
Unrealistic Expectations 
9.9%
Lack of Executive Support 
9.3%
Changing Requirements & Specifications 
8.7%
Lack of Planning 
8.1%
Didn’t Need It Any Longer 
7.5%
Lack of IT Management 
6.2%
Technology Illiteracy 
4.3%
Other 
9.9%
Bull Survey Statistics
Bad Communications 
57%
Lack of Planning 
39%
Poor Quality Control 
35%
Missing Interim Deliverables 
34%
Poor Budget Management 
29%
Poor Project Management 
20%
Table: (5-2) Failure Reasons Statistics for IS Projects (source: PM Hut, 2008)
Failure reasons
Percentage
Delivery date impacted the development process 
93.9%
Project under-estimated 
83.7%
Risks were not re-assessed, controlled, or managed through the project
73.4%
Staff were not rewarded for working long hours 
81.6%
Delivery decision made without adequate requirements information
83.7%
Staff had an unpleasant experience working on the project 
83.7%
Customers/                 
69.4%
Risk not incorporated into the project plan 
65.3%
Change control not monitored, nor dealt with effectively 
63.3%
Customer/Users had unrealistic expectations 
69.4%
Process did not have reviews at the end of each phase 
75.5%
Development Methodology was inappropriate for the project 
71.4%
Aggressive schedule affected team motivation 
69.4%
Scope changed during the project 
67.3%
Schedule had a negative effect on team member’s life 
71.4%
Project had inadequate staff to meet the schedule 
63.3%
Staff added late to meet an aggressive schedule 
61.2%
Users did not make adequate time available for requirements gathering
61.2%
Table: (5-3) Failure reasons for seventy failed projects (source: Cerpa and Verner, 2009)
Pre-development Activities
Projects’ Failure Reasons
System Service Request Assessment (SSR)
Poor project specification 
Project problem is not clarified 
Inaccurate assessment of project problem 
Project Scope Definition
Scope, objectives unclear 
Failure to manage changes 
Changing scope and objectives (Al-Ahmad et al, 2009)
Project Charter development and Statement of Work (SOW)
Unclear project charter 
Failure to adequately identify project document 
SOW doesn't accordance the extend of the project scope
Poor project documentation 
Commercial Off-The-Shelf selection (COTS)
Software integration problem
Wrong evaluation and selection of COTS
Work Breakdown Structure (WBS)
Conflict between departments
Lack of required team knowledge / skills
Project Contract
Poor contract management
Deadlines and resources not adjusted accordingly
Develop a Communication Plan
Failure to communicate and act as a team
Lack of proper communication
Table: (5-4) Correlation between pre-development activities and the failure reasons 
Main failure reasons related to Project Feasibility Study
Underestimate the gap between technology and ability (Yongyi and Ying, 2005)
Inability to provide investment capital (McManus and Wood-Harper, 2007) or Sponsorship is lost (Al-Ahmad et al, 2009)
Misusing of financial resources and weak financial management (McManus and Wood-Harper, 2007)
Higher cost of capital investments and failing to get it back (McManus and Wood-Harper, 2007) 
Development cost exceeds any benefits that the system may bring throughout its useful life (Yongyi and Ying, 2005)
Inconsistency between the organization's business needs and the Information System functionalities (Yongyi and Ying, 2005)
Usage of inappropriate technology (immature, new, .), (Al-Ahmad et al, 2009)
Low IS project viability and priority (Verner et a  l, 2008)
Losing control of the project resources (Lin et al, 2007)
Ignoring intangible benefits and costs (Myrtidis and Weerakkody 2008)
Inability  to achieve the desired benefits and critical services (Lin et al, 2007)
Ignoring one or more types of projects feasibility studies (technical, operational, legal, economical, and schedule)
Table (5-5) Main failure reasons related to Project Feasibility Study
Main failure reasons related to Project requirements Elicitation
Misunderstanding of user requirements and real customer needs (Ahonen and Savolainen, 2010)
Lack of user involvement (Wood, 2008) (Al-Ahmad et al, 2009) (Lepage, 2009). 
 Changing requirements during the project’ development phases,  (Wood, 2008) (Cerpa and Verner, 2009) (Humphrey, 2005)
Customer/Users had unrealistic expectations (Pan et al, 2008), (Yongyi and Ying, 2005)
 Incomplete and Inappropriate Requirements (Wood, 2008),  (McManus and Wood-Harper, 2007) (Yeo K.T., 2002) (Lepage, 2009)
Unclear/misunderstood project’ scope, goals and objectives (Verner et al, 2008)
Users did not give adequate time for gathering requirements (Cerpa and Verner, 2009)
Lack of top management involvement and support (Yongyi and Ying, 2005)
Ambiguous business needs and unclear vision (Yeo K.T., 2002)
Conflicts of interest between different user’s groups (Myrtidis and Weerakkody 2008)
No method for requirements gathering (Verner et al, 2008)
Size of project affected requirements elicitation (Verner et al, 2008)
Table (5-6) Main failure reasons related to Project Requirements Elicitation
Main failure reasons related to Project Risk Management 
Conflict between system’ user (Al-Ahmad et al, 2009)
Risks were not re-assessed, or managed through the project development (Cerpa and Verner, 2009)
Risks’ impact is not incorporated into the project plan (Verner et al, 2008)
Lack of required team knowledge, experience and skills (Al-Ahmad et al, 2009) 
Failure to achieve all end-user expectations (Al-Ahmad et al, 2009) (Pan et al, 2008)
 inappropriate Development Methodology  (Al-Ahmad et al, 2009)
Project Managers do not consider the best practices and lessons learned (Al-Ahmad et al, 2009) 
Users are resistant (Al-Ahmad et al, 2009)
Insufficient and poor risk management (McManus and Wood-Harper, 2007) (Lepage, 2009)
Incorrect assumptions regarding risk analysis (Yeo K.T., 2002)
Poor communication among customers, developers and users (Al-Ahmad et al, 2009)
Changing of technology (Al-Ahmad et al, 2009) (Lin et al, 2007)
No change controls (Lepage, 2009)
Applying improper risk response strategy 
Insufficient allocating the project Risk Reserve 
Table (5-7) Main failure reasons related to Project Risk Management
Main failure reasons related to Project Cost Estimation
Overruns in cost and time (Hartman and Ashrafi, 2004) 
Underestimated project scope (Verner et al, 2008) 
Staff were not rewarded for working long hours (Cerpa and Verner, 2009)
Unrealistic estimation efforts and budget (Verner et al, 2008) (Yeo K.T., 2002)
Fail to meet project costs (Uppal, 2008)
Poor estimation methods (McManus and Wood-Harper, 2007) (Verner et al, 2008)
Developers not involved in the estimation process (Verner et al, 2008)
Inexistence of historical database to retain the estimated data 
Ignoring the indirect costs estimation of the non-technical activities 
Weak estimation competencies  and bad Budget Management (Wood, 2008)
Project estimation depending on only one estimation technique   
Overspends in excess of agreed budgets (McManus and Wood-Harper, 2007)
Estimation is based on insufficient and incomplete requirements
Table (5-8) Main failure reasons related to Project Cost Estimation
Main failure reasons related to Project Plan development and schedule
Imprecise and ambiguous project plan (Humphrey, 2005),  (Yongyi and Ying, 2005) 
Lack of Resources (Wood, 2008) (Pan et al, 2008)
Poor project contract Management (McManus and Wood-Harper, 2007) (Wood, 2008)
Poor competencies of project planners (skill/experience shortages) and Insufficient management support (McManus and Wood-Harper, 2007) (Verner et al, 2008)
Unrealistic schedules and deadlines (Verner et al, 2008), (Cerpa and Verner, 2009) 
Project had inadequate staff to meet the schedule (Cerpa and Verner, 2009) (Al-Ahmad et al, 2009)
Project changes are managed poorly (Al-Ahmad et al, 2009)
Poor change and configuration management procedures (McManus and Wood-Harper, 2007) 
Improper definitions of roles and responsibilities (Al-Ahmad et al, 2009)
Poor test planning (McManus and Wood-Harper, 2007)
No reviews at the end of each phase (Verner et al, 2008) (Cerpa and Verner, 2009)
Lack of Contingency plan to handle problems that arise during the project development 
Ineffective internal communication (Yongyi and Ying, 2005)
Table (5-9) Main failure reasons related to Project plan development and schedule
According to the analysis of the previous statistics and Tables from (5-2) to (5-9) which explained the main failure reasons of IS projects that are derived from the pre-development activities , these failures can be translated into the statistic as shown in table (5-10) which expresses the number of failure occurrence for the failed projects according to their pre-development activities.
Pre-development activities of IS Projects
Number of failure occurrence
Percentage
System Service Request Assessment (SSR) 
3
2.97%
Project Scope Definition    
5
4.95%
Project Feasibility study  
12
11.88%
Project Requirements Elicitation
16
15.84%
Commercial Off-The-Shelf (COTS) Selection   
2
1.98%
Project Charter and Statement of Work (SOW)
4
3.96%
Project Work Breakdown Structure (WBS)
4
3.96%
Project Risk Management  
15
14.85%
Project Cost Estimation
13
12.87%
Project Contract  
2
1.98%
Communication Plan development  
6
5.94%
Project Plan development and schedule
19
18.81%
Table (5-10) Percentages of main Pre-development Activities of IS Projects
Through viewing both table (5-10) and figure (5-1); there are five main pre-development activities appeared completely which have a great influence to cause the projects’ failure. These activities deserve our interest because they can contribute in high percentage to improve the projects’ success if they implemented completely and accurately, they are;
    1. Project Feasibility Study 11.88%
    2. Project Requirements Elicitation 15.84%
    3. Project Risk Management 14.85%
    4. Project Cost Estimation 12.87%
    5. Project Plan Development and schedule 18.81%



Fig. (5-1) Most significant Pre-development activities of IS projects
After determining the most significant pre-development activities, the theoretical governance framework must be transformed into conceptual framework to explain the application of governance for the main pre-development activities in details, Fig.(5-2)  explains the road map which depicts the main procedures of the conceptual governance framework to conduct the pre-development activities governance. 












Fig. (5-2) the road map of main procedures for the conceptual governance framework

5.2. IS Project Feasibility Study Governance
Project feasibility study is basically a preliminary study to determine the viability and the importance of proceeding IS projects (it provides a vision to make a decision whether or not to go on with a new project). It’s the initial success factor for IS project, there’s a main problem, whereas many of IT managers still don’t understand the importance of the evaluation of IT investments and benefits realization methodologies (Lin et al, 2007). Feasibility study is considered the main step to explain the project worthy and viability to assist decision-makers in determining whether or not to proceed the intended IS project. Also, it allows the early cancellation of projects with the minimal costs (Greer, Conradi, 2009). Furthermore, feasibility study provides IS projects with many significant advantages such as; (Khoong and Ku,1994), (Myrtidis and Weerakkody 2008)
    • Helping to analyze the Cost/Benefit for IS project
    • Helping to obtain a detailed understanding of the problem domain.
    • Allowing the early cancellation of projects with the minimal costs.
    • Helping in cost estimation, funding and other important financial decisions. 
    • Convincing the users that the intended IS project that they get actually meets their functional requirement.
    • Avoiding the stakeholders to fell in "black hole" projects.
    • Confirming the project effectiveness to match the organizational environment and attain the intended objectives.
    • Explaining whether the final product is beneficial to the intended users or not.
5.2.1. Policy’s actions and principles to implement the Feasibility Study Governance
In the purpose of implementing the project feasibility study governance according to the designed governance framework, it is very important to emphases on defining a clear policy with actions and principles to implement feasibility study governance which explain the main procedures, practices and techniques that are needed to verify the defined policy’s actions and principles. Table (5-11) explains the required procedures, practices and techniques for the defined policy’s actions and principles to implement the project feasibility study governance.
The policy is: Integrated feasibility study governance based on tangible and intangible costs and benefits. 

Policy’s actions and principles for  Project feasibility study governance
Procedures, Practices and Techniques to verify the policy’s actions and principles
- Define the most favorable scenario to guarantee proper implementation of project feasibility study
Determining well-defined procedures to execute the project feasibility study
- Decrease IS projects’ failure which are derived from the project feasibility study
Setting Best practices to reduce the failure within project feasibility study
- Consider the qualitative costs and benefits within project feasibility study
- Quantifying the Cost/Benefit Analysis which classify and estimate the intangible benefits and costs to create a real Cost/Benefit Analysis.
- Improve the performance of project feasibility study
- Check the Project viability” which examines three groups of critical success factors to assure if the project worth to implement or not
- Calculate the traditional appraisal techniques” to analyze the financial aspects of IS project
- Setting Feasibility Checkpoints” to reassess the project feasibility at many points in all project’ phases
- Enhance the best possible deliverables for IS projects 
Defining the best expected deliverables for the project feasibility study  
Table (5-11) Policy’ actions and procedures of project feasibility study governance
5.2.2. Well-defined procedures to execute the Project Feasibility Study
Well-defined procedures of executing the project feasibility study means a set of guidelines and well-defined procedures that used to provide the most efficient and effective way of completing the project feasibility study. Based on understanding and analyzing the previous researches and standards that focused on projects feasibility study, the following are the well-defined procedures to execute the projects feasibility study; (Khoong and Ku, 1994), (IEEE Std 1074, 1997), (Jeffrey et al, 2007), (Whitten and Bentley, 2007), (Greer and Conradi, 2009), (PMI, 2008). 
Procedure 1: Study the main characteristics of the existing system (old system, if it manual or computerized), particularly emphases on the following issues;
    a) The involved organizational system; users, policies, functions, and objectives.
    b) Check the “PIECES” Framework which is the checklist for identifying problems with the existing information system which includes (performance, information, economic, controls, efficiency and services).
    c) Technical problems at the existing system (inconsistencies, inadequacies in functionality, and performance)
    d) The analysis of new project’s idea or need and all life cycle constraints and benefits
    e) Objectives and other requirements for the new system (what needs to change?)
    f) Availability of possible alternatives 
Procedure 2: Explain and understand the advantages and disadvantages of the intended IS project.
Procedure 3: Verify the main objectives, purposes, constrains and the scope of the intended IS project
Procedure 4: Examine the traditional Evaluation Techniques for the intended project, the evaluation of these traditional evaluation techniques is built on the costs of an investment and their related benefits, they include; (Ballantine and Stray, 1998)
    a) ROI, Return on Investment
    b) IRR, Internal Rate of Return 
    c) Payback Period
    d) NPV, Net Present Value
Procedure 5: Test the stability of the intended project with the following features: 
    • The human and organizational mechanisms of the organization’ investments 
    • Strategic objectives of the organization 
    • The political issues associated with capital budgeting and decision making.
    • The natures of IT/IS benefits (intangible, tangible; financial and non-financial).
    • Identify, manage and control investment-related costs (direct and indirect).
    • Expected risks associated with project investment.
    • Developing the needed IT infrastructure (The scope and its impact).
    • Resources Management and the appropriate technology.
    • The methods of justifying the IS projects investment. 
    • The ability to achieve the strategic, operational, technical, and financial benefits of IS investments.
Procedure 6: Perform the five types of feasibility study for the intended project:
There are five main types of projects’ feasibility study, Economic feasibility, Technical feasibility, Legal/Cultural feasibility, Operation feasibility and Schedule feasibility. These types represent the backbone of the IS projects’ investment evaluation; (Jeffrey et al, 2007), (Whitten and Bentley, 2007)
Procedure 6.1.Economic Feasibility (Cost/Benefit Analysis)
Economic feasibility is the most frequently used method to evaluate the effectiveness of a new project and it is the most commonly known as cost/benefit analysis. It includes the main procedures to determine the benefits and costs that are expected from the intended project and makes a comparison between them. When the benefits exceed the costs, then the decision is to initiate the project. In fact, estimating the economic feasibility comprises a main problem which is how to quantify the qualitative costs and benefits (Intangible costs and benefits). The classification of costs and benefits in table (5-12) can contribute to facilitate the process of quantifying the qualitative aspects within the Cost/Benefit Analysis as the following procedures:- 
    1- Governance Committee can assistant as judge expert to quantify the qualitative aspects of costs and benefits by weighing them as a percentage of any constant variable value related to the project such as Capital Investment of the project;
Example: If the expectations determine the new project will attain accuracy improvement as an intangible benefits, and the governance committee estimated it as 0. 2% from the Capital Investment, If Capital Investment of the project = 2000000 $, Then, the value of Accuracy Improvement = 0. 2% * 2000000 = 4000$
    2- Estimate the Total benefits which classified in table (5-12) into, Monetary Benefits (MB), Tangible Benefits (TB) and Intangible Benefits (INTB). 
    3- Estimate the Total costs which classified in table (5-12) into, Direct Costs (DC), Indirect Costs (INDC), and Hidden Costs (HC).
    4- Calculate the Present Value for all Total Benefits and Costs 
  (Iloiu, 2008),
 (i) is the interest rate and (Ft) is the cash flow in period (t).
    5- Match  of Total benefits with  of Total costs, whereas  of total benefits must be exceed  of total costs to continue proceeding the project. Table (5-12) explains the main categorizing of benefits and costs in details. 
Procedure 6.2.Technical Feasibility 
Technical feasibility is the measure of the practicality of a specific technical solution. It examines the availability of technical resources and knowledge to complete the intended project. It also looks for function, performance, and constraints that may affect the ability to implement an acceptable system. Moreover, it’s trying to answer the technical question "Can it actually be built?" within investigating the technologies to be used on the project.  Technical feasibility investigates the following technical aspects that must be satisfied; 
    • Does the organization currently possess the necessary technology?
    • Does the organization possess the necessary technical expertise and knowledge?
    • Is the project possible with current technology?
    • Is the proposed technology or solution practical?
    • Is the required technology available “in house”?
    • Determine main types of technology that the project will need?
    • Does the project improve performance, ease of learning, ease of deployment, ease of support and reduced manufacturing lead-times?
Type
Definition
Example
Monetary Benefits (MB)
the actual revenue of the system in Cash Money 
-Increased revenue from additional sales of organizations products and services
-Increase cash flow 
Tangible Benefits (TB)
Benefits are easy quantified and translated into Monetary Benefits.  
-Reduced operating costs
-Reduced personnel costs, staff reduction 
-Cost Savings;
-Cost Avoidance;
-Cycle time reduction
-Increased productivity 
-Reduced delivery lead-times 
-Reduced manufacturing lead-times 
Intangible Benefits (INTB)
Benefits are difficult to be quantified  and translated into Monetary Benefits  
-Improve accuracy 
-Improve competitive advantages 
-Improved quality of output
-Improved communication
-Improved decision-making and planning
-Reduced paperwork
-Reduced bottlenecks
-Improved management and exchange data
-Improved response time to queries
-Improved forecasting and control
-Reduce business risk 
-Productivity improvement
-Customer service improvement 
-Better resource management
-Performance improvement
-Improved flexibility 
-Improved organizational teamwork 
Direct Costs
(DC)
Costs can be allocated to a particular service and have direct relation to the project. 
-Hardware and software costs
-Operational costs
-Purchase costs for systems software and infrastructure 
-Hardware and software upgrade
-Training costs for developers and users in new updated technologies
-Manpower costs for operating and development the system 
-System testing costs
-Cost of system installation, and consultancy 
-Manpower costs for the system
-system maintenance costs
-Network architecture and associated hardware
-File server facilities
-Network security such as firewalls.
-Purchase costs for applications support software 
Indirect Costs (INDC)
Additional overhead costs have indirect relation to the project. 
-Additional cost to Increase the employee for project change anticipation
-Administrative overhead, including costs of services and legal procedures
-System support and Vendor support
-Trouble shooting costs
-Cost of security breaches 
-Communication costs 
-Cost of Loss time and the need to recover data
-Cost of data theft, loss of productivity
-Cost of  system damage and corporate trust
-Project costs for travel and living 
-Project costs for external consulting
-Cost of recruiting extra staff
Hidden Costs (HC)
Costs that are difficult to load and hardly expected to occur, their values are not known and related to risks.
-Change management and workers 
-Software changes
-Work after testing
-Process rework 
-losses of productivity during implementation, such as re-training
-losses of productivity through poor user support
-Data conversion
-User support both technical and business issues
-Accidental software and hardware maintenance
-Overhead of average production time
-Cost of Lack appropriate skills
-Cost of redefining roles Lack of leadership
-Organizational restructuring costs 
Table (5-12), Main classifications of all benefits and costs
Procedure 6.3.Operational Feasibility
Operational feasibility is the measure of how the proposed system solves the actual problems, how it attains the advantage of opportunities that are identified during the project scope definition and how it satisfies the requirements that are identified during the project requirement elicitation. Also, it’s a measure of how people feel about the project’s product. Not only the economic and technical feasibility are interested sense, but also the operational feasibility is required. Critical issues should be taken into consideration during executing the project operational feasibility that are;
    • Does the project sustains, ease of use, ease of learning, and user satisfaction?
    • How the end-users and managers feel about solution? 
    • Does the organization’ management support the project?
    • Is the project’ problem worth solving?
    • Are all the system’ operations needed?
    • What are the main types of processes need to be created and updated?
    • What are the needed skills for system operators to be trained in?
    • What are the needed tools to support system operations?
Procedure 6.4.Schedule Feasibility
Schedule Feasibility is the measure of how the project being completed within its scheduled timetable. The project will fail if it is delayed too long to be completed. It is also interested in estimating how long the project will need to be developed by drawing a relationship between the project’s tasks and the time they need. Project schedule feasibility must determine the following issues; 
    • Is it possible to build a solution in time to be useful?
    • What are the consequences of delay?
    • Are the project deadlines reasonable?
    • Are the deadlines mandatory or desirable?
    • Are there any constraints on the project schedule? Can these constraints be met?
    • Can the project deadlines be met?
    • Are there any additional costs needed to accelerate the project development?
    • The ability to implement the project according to its timetable.
Procedure 6.5. Legal and Cultural Feasibility
Legal and Cultural feasibility are the measure of how the project can be implemented through the existing legal, social and contractual obligations. In this stage, projects are evaluated for their impact on the local and general culture. Study the environmental and social variables are required to estimate their effects on IS projects, whereas the organization’s own culture can conflict with the project’ results. On the other hand, Cultural feasibility deals with the compatibility of the proposed project with the cultural environment that is inside and outside the organization. For instance, the planned functions must be integrated with the local cultural practices and beliefs in labor-intensive projects. 
5.2.3. Best Practices to reduce the failure within the project feasibility study
A set of best practices must be considered during the execution of project feasibility study. These practices are used as guidance controls to prevent the problems that cause the project failure to some extent in order to reduce the failure rates and enhance IS project success. These practices are based on many projects’ critical success factors and the most lessons learned from the previous projects. Also, the best practices of CMMI for systems and software development in the area of project feasibility study are merged here (CMMI, 2001), (CMMI, 2010). These practices must be taken into account during the project development. Within the project feasibility study, projects’ managers and developers must consider the following practices; 
    1. Strengths, weaknesses, and improvement opportunities for the projects should be identified periodically and as needed
    2. Appraise the projects periodically and as needed to maintain an understanding of their strengths and weaknesses
    3. Establish and maintain guidelines to determine which issues are subject to a formal evaluation process
    4. Assure that all intangible costs and benefits are completely estimated and considered during evaluation the economic feasibility of IS projects
    5. Study and explain the viability of business needs completely  
    6. Keep away from to initiate the projects according to inaccurate reasons and trivial needs
    7. Confirm the consistency between the organization's business needs and the Information System functionalities 
    8. Confirm that all types of feasibility studies (technical, operational, legal, economical, and schedule) are implemented completely 
    9. Assess the gap between technology and the existing ability
    10. Realize the ability to measure the feasibility during the project development phases
    11. Stop to proceed the project if it isn’t viable 
    12. Remove disagreement between the project costs and the budget.
    13. Estimate all types of projects’ costs and benefits completely
    14. Early determine the technical and operational needs for the projects 
    15. Eliminate poor competencies experiences, skill shortages and improper financial management techniques
    16. Avoid as much as possible the higher costs of capital investment 
    17. Avert the ambiguous identification for the margin between project costs and benefits 
    18. Don’t fear from project cancelation, if it isn’t feasible at any point 
    19. Be aware to distinguish the "black hole" projects
    20. Realize the ability to assess the project viability
    21. Recognize and use the financial appraisal techniques during economic feasibility 
    22. Taking into account the project which is feasible (now) maybe  infeasible at any later point and time
    23. Avoid the long payback period for the cost of capital investments 
    24. Assure that development costs don’t exceed any benefits that the system may bring throughout its useful life 
5.2.4. Suggested practices to improve the performance of Project Feasibility study
IS projects development need more suggested practices to improve the performance of project feasibility study which leads to eliminate the projects’ failure probability and enhance their success through increasing the performance of implementing the projects’ development process. Checklists also at this framework represent a critical component of projects’ governance, in the context of project feasibility study governance; the following practices and checklists are designed to ensure the validity and accuracy of the project feasibility study;
1.	Quantifying Cost/Benefit Analysis
2.	Examine the project viability 
3.	Calculate the traditional appraisal techniques 
4.	Feasibility Checkpoints
5.2.4.1. Quantifying Cost/Benefit Analysis
There are lots of qualitative factors that must be considered during the projects feasibility study assessment which cause many problems for the projects’ appraisal and justification. Qualitative benefits and costs must be quantified to ensure an equilibrium and comprehensive representative for all costs and benefits to create a real Cost/Benefit Analysis. Quantifying the qualitative benefits and costs can be estimated as weighted percentage by the assistant of the governance committee as judge expert. The qualitative aspects of benefits and costs can be quantified by weighing them as a percentage of any constant variable value related to the project such as Capital Investment of the project. According to the detailed classification of all types of costs and benefits in table (5-12), the following equations explain the way to Quantify Cost/Benefit Analysis:
Cost/Benefit Analysis     
 =    (Iloiu, 2008)     
 Total Benefits  



 Total Costs 



So, Cost/Benefit Analysis   
Where; PV is the present value 
, is the present value of estimated total Monetary Benefits of the project
is the present value of estimated total Tangible Benefits of the project
is the present value of estimated total Intangible Benefits of the project
is the present value of estimated total Direct Costs of the project
, is present value of the estimated total Indirect Costs of the project
, is the present value of estimated total Hidden Costs of the project
R, is the Rate of Interest, n is the number of time periods and A, indicate to the amount of Benefits and Costs.
Decision: IF Cost/Benefit Analysis   
Then, continue to proceed the project, Else, project should be canceled or modified  
5.2.4. 2- Checking the Project Viability (Viability Checklist)  
Project viability means the method to determine if the project is worth to continue proceeding or not, whereas checking the project worthy depends on verifying a set of critical criteria which reflect the worthiness and the viability of the IS project (if it is worth to implement). Project viability checklist encompasses three groups of selected criteria that are classified according to their importance. The first group (Essential Criteria) must be existed to decide that the project is viable. The absence of one or more of these criteria creates a negative impact to the project viability. 
The second group represents the project success factors which can be customized and modified during the project implementation (project success criteria). The third group represents the criteria that add more benefits and improvements to the project. This group doesn’t affect the project failure or success, but it increases the project viability (Improvement criteria). Table (5-13) explains the main criteria of the project viability checklist. This checklist is designed as a practical indicator to assure that the project is worth and viable, so the intended project must attain an acceptable degree to become feasible. 
No.
Type of criteria
Project viability Criteria
Yes
No
1
The first group (Essential criteria) must be existed to decide that the project is viable, the absence of one or more of these criteria creates a negative impact to the project viability.
Assist to achieve the organization goals


2

Sustain service improvement


3

Enhanced competitive/strategic advantage


4

Enhance employee productivity and business efficiency


5

Enhance organization vision


6

Enhance user satisfaction  and customer services


7

Enhance information quality and delivered reports


8

Support increasing the cash flow


9

Enhance decision making and planning


10

Enhance organization growth and success


11

Enhance integration with other business functions


12

Enhance response time to queries


13

Enhance services quality and delivery to customers


14

Reduce operation costs and bottlenecks


15

Reducing communication costs


16

Sustain Security protection


17

Enhance organizational teamwork


1
The second group represents the project succeeded factors that can be customized, redressed and modified during the project implementation (project succeeded criteria). 

Eliminates unnecessary functions


2

Support accountability and responsibility


3

Enhance the organization credibility


4

Enhance communication between all parties


5

Enhance data availability and reporting


6

Enhance organization flexibility	


7

Enhance manufacturing control	


8

Improve market share and product quality


9

Enhance reliability or accuracy of information


10

Increases process efficiency


11

Sustain the ability to perform maintenance faster


12

Reduce business risk


13

Avoiding the need to increase the work force


14

Reducing system modification


15

Support management decision making


16

Reduce transaction costs	


17

Enhance accuracy of decisions


18

Enhance data management	


19

Sustain strategic objectives of organization


1
The third group represents the criteria that increase the project improvement; these criteria don’t affect the project success, but increase the project viability (Improvement criteria). 
Support operating procedures


2

Improve ability to exchange data	


3

Enhance capacity planning 	


4

Enhance information flow	


5

Enhance internal operations	


6

Improve product tractability	


7

Enhance response to changes	


8

Enhance trading partner relations	


9

Enhance disaster recovery	


10

Increases access to new technologies	


11

Decrease learning time and training costs	


12

Reduce delivery lead-times	


13

Reduce lead times for financial planning	


14

Reduce manufacturing lead-times and product cycle


15

Reduce paperwork and employee costs	


16

Reducing travel costs	


17

Support explicit business objectives	


Table (5-13) Main criteria of the project viability checklist
5.2.4. 3- Calculate Traditional Appraisal Techniques 
Although the traditional appraisal techniques are often unable to capture lots of qualitative benefits and costs that IT brings, it’s very important to be calculated during the project feasibility study in order to analyze the financial aspects of IS project. The main traditional appraisal techniques are; Net present value, Internal rate of return, Rate on investment and Payback period (Ballantine and Stray, 1998), (Iloiu, 2008).
Net present value 
   , Where ( i) is the interest rate and ( Ft ) is the net cash flow in period (t).
Rate on investment 


Payback period 
The length of time required to recover the cost of an investment Calculated as:


OR

5.2.4. 4-Feasibility Checkpoints 
Feasibility checkpoints mean reassess the project feasibility at many points in all project life phases during the project development. That is because the project that is feasible at one point and time may become infeasible in other phases. So, the feasibility study for IS projects should be reassessed at many points through the project life cycle. 
5.2.5. Define the Expected Delivered for the Project Feasibility Study  
Feasibility Study Report is the main output for the project feasibility study as it explains the decision basics and principles to determine whether to proceed the project or not. Furthermore it comprises many details about the intended project such as the evaluation criteria, the study findings, and the recommendations. Moreover, the feasibility study report should contain the following significant issues:
    1. Define the project business problem clearly to be more understanding. 
    2. Define the project subject and scope clearly.
    3. Define the technology that will be used in project development.
    4. State the project objectives and explain whether they will be met or not.
    5. List all the economic costs and benefits.
    6. Provide a suggested time table for the project implementation.
    7. List detailed feasibility assessment at technical, economic, schedule and operational aspects.
    8. Give a brief description for business organization.
    9. Predict any critical risk factors such as defects in economic stability. 
    10. Comprise an appendix that shows any flowcharts, Data Flow Diagrams, and graphs.
    11. Outline the final decision and recommendations for the intended project.
    12. In the case of the project feasibility study decision is proceeding IS project, an explanation to follow-up the project development should be declared such as;
    a. Indications on the key hardware and software technologies that are needed for successful implementation of the system.
    b. Expected hardware, software, manpower resource requirements, and estimated project schedule.
5.3- IS Project Requirements Elicitation Governance  
It should be considered that the determination of the initial project’s requirements is a critical issue, whereas it defines the project product and support the estimation of a project’s budget, resources, and schedule. Also, having stable and explicit user requirements makes the project planning process more simple (Greer and Conradi, 2009). Requirements elicitation (RE) is the most important and critical phase in IS projects requirements engineering where user and business’ needs for a system is identified and captured. An ineffective elicitation process produces poor requirements which later leads to low system quality, extension of schedule and increase in budget (Razali and Anwar, 2011). The goal of requirements elicitation is to identify as many requirements as possible to prepare several alternate solutions for the stated problem (Kasirun, 2005)
RE is the base building block for a software project and has a very high impact on subsequent design and other development phases as well. If it is done properly, it can help in reducing requirement changes and rework. Additionally, the quality of requirements elicitation decides the correctness of customer’s feedback on the completion and validity of requirements. It showed that between 40% and 60% of software failures and defects is the result of poor software management and requirements definition (Huang et al., 2010); also Studies by (Beichter) indicate that Errors in requirements elicitation are, overall, the most serious in software development and the hardest to repair, 70% of the system errors are due to the inadequate system specification and 30% of the system errors are due to design issue (Rajagopal et al., 2005). In general, requirements elicitation the most significant part of requirements engineering which comprises four specific processes: (Raghavan et al., 1994)
    • Requirements Elicitation, the process through which the customers, buyers, or users of a software system discover, reveal, articulate, and understand their requirements.
    • Requirements Analysis, the process of reasoning about the requirements that have been elicited; it involves activities such as examining requirements for conflicts or inconsistencies, combining related requirements, and identifying missing requirements.
    • Requirements Specification, the process of recording the requirements in one or more form, including natural language and formal, symbolic, or graphical representations
    • Requirements Validation, the process of confirming the customer or the user of the software that the specified requirements are valid, correct, and complete.
5.3.1. Why Requirement Elicitation is difficult 
The process of requirement elicitation comprises lots of difficulties. In (2006) Davis et all, found that “exactly capturing system requirements is the major factor in the failure of 90% of large software projects”. In addition, Lindquist (2005) confirmed “poor requirements management can be attributed to 71% of software projects that fail, greater than bad technology, missed deadlines, and change management issues”. The cost of this failure is enormous. Another study found that failed or abandoned systems cost $100 Billion in the USA only in 2000. These consequences prove the difficulties of requirements elicitation (Davey and Cope, 2008). That is not the whole thing, but there are lots of researches demonstrated the difficulties of requirement elicitation which reflects the critical role for requirement elicitation to be the major activity causes the project failure; table (5-14) provides a summary of these researches with their difficulties:
Studies
Main difficulties of requirement elicitation
(Gottesdiener, 2005)
    • Differing and sometimes conflicting needs among different types of users. 
    • Unstated or assumed requirements on the part of stakeholders.
    • Gaining access to knowledgeable stakeholders.
    • A (disability) to envision new or different ways to use software.
    • Uncertainty about how to adapt to change business needs.
    • Having a large number of high interrelated requirements.
    • Having limited time to elicit requirements from busy stakeholders.
    • Overcoming resistance to change
(Vijayan and Raju, 2011)
(Huang et al, 2010)
(Ashra and Ahsan, 2010)
(Rajagopal et al, 2005)
    • Problems of scope. The boundary of the system is ill-defined or the customers/users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives.
    • Problems of understanding. The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain, and have trouble communicating needs to the system engineer. Different stakeholders may speak literally different languages.
    • Problems of volatility. The requirements change over time. The rate of change is sometimes referred to as the level of requirement volatility.
(Raghavan et al., 1994)
A. Articulation Problems
The first class of difficulties includes those related to the articulation of the user’s needs. These include problems both with the user’s expression of needs and the developer’s understanding.
1. The users of a proposed software system may be aware of their needs, but they are unable to articulate them appropriately. 
2. The users may not be aware of their needs also they may not understand how the technology may help them. 
3. The user may be aware of a need but be afraid to articulate it. 
4. Users and developers misunderstand concepts or relationships because they have different meanings for common terms. 
5. Users cannot make up their minds on some issues because they don’t understand the consequences of the decision or they don’t understand the alternatives.
6. No single person has the complete picture. for complex systems where each individual user may have only limited view or perspective of the system to be built. 
7. Developers may not really listen to the users. 
8. Developers may fail to understand, appreciate, or relate to the users.
9. Developers tend to overrule or dominate the users. 
B. Communication Barriers
Many requirements elicitation difficulties are (direct results) of differences in communications among users and developers.
1. Users and developers come from (different countries- places) and have different professional vocabularies. 
2. The users have different concerns from those of developers; these are usually high-level attributes like usability and reliability. In contrast, developers are concerned with low-level technical issues such as resource utilization, algorithms, and hardware/software tradeoffs.
3. Problems exist with each form or medium of communication. Natural languages, such as English, are inherently ambiguous. 
4. Requirements elicitation has significant social interaction and the people involved are all different.
5. There are different personality types and different value systems among people. This can lead to unexpected difficulties in communication as was discovered by a company that contracted to build an information system for a university. 
C. Knowledge and Cognitive Limitations
Buyers, users, and developers are human beings and each brings some knowledge and cognitive limitations to the process, but they vary from person to person.
1. The requirements elicitor must have adequate domain knowledge. A common error is that the team of users and the developers don’t have adequate domain knowledge, so they make wrong decisions. 
2. No person has perfect memory. The users and developers may not remember exactly what was said or decided. 
3. We often try to use quantitative information and statistics to express needs and requirements. However, informal or intuitive statistics are frequently interpreted differently by different people because of their own experiences and biases.
4. People sometimes have difficulty with scale and complexity. 
5. We often have a preconceived approach to the solution of a problem that affects our ability to state the problem clearly. 
D. Human Behavior Issues
Requirements elicitation is a social process, so human behavior issues are involved.
1. There are sometimes conflicts and ambiguities in the roles that the users and developers play in the requirements elicitation process.
2. The development of a software system to support an organization usually results in an expectation or fear that installation of the software will necessitate all kinds of changes in behavior of individuals and groups
E. Technical Issues
There are many other difficulties that might characterized as technical that must be overcome by the requirements elicitation process if it is to be successful. 
1. Problems to be solved by software systems become increasingly complex. The requirements of these systems are based on increasingly detailed knowledge of the user’s domain. 
2. Requirements change over time. 
3. Software and hardware technologies are changing rapidly. 
4. There are many sources of requirements. The users of a system are not necessarily aware of all the requirements that the system must satisfy.
5. The nature or novelty of the system often imposes constraints on the elicitation process. 
Table (5-14) Difficulties of Requirements Elicitation 
In other words, the difficulties of requirement elicitation can be summarized according to their subjects as shown in table (5-15). 
No.
Main area
Main difficulties of requirement elicitation
1
Scope problems
The boundaries of the system are ill-defined
The context of the system is ill-defined
Hardware and software constraints
System’s role in a larger system
Maturity of the system’s domain
Attributes of the actors: management style, hierarchy, domain experience, computer experience, etc.
Unnecessary or restrictive design information is given
2
Problems related to the process itself

Requirements change over time
There are many sources of requirements
The nature of the system imposes constraints on the elicitation process
The cross-referencing and heterogeneity of information gathered complexities its management
3
Knowledge and cognitive limitations

Developer must have adequate domain knowledge
Actors have selective memories
Actors use intuitive statistics to express ideas
Actors have difficulties with scale and complexity
Actors have preconceived ideas to the solution
Actors focus on some narrow aspects of the problem
Actors are not willing to undertake extensive exploration
4
Articulation problems
Users are aware of their needs, but unable to express them
Users are not aware of possible solutions available to them
Users may be aware of some needs but afraid to articulate it
Actors have different meanings for common terms
Users are not aware of the consequences of their needs
No actor has the complete picture of the system
Developers might not be really listening to the user’s needs
Developers fail to understand, appreciate or relate to users
Developers overrule or dominate users
5
Communication barriers 

Actors have different vocabularies
Users often have very grounded concerns
All media of communication have their problems
Actors have incompatible styles of interaction
Actors have different personalities
6
Human behavior issues
There are ambiguities in the roles that each actor has to play in the elicitation process
Users fear that the introduction of the system will necessitate changes in their behavior
Users fear the system will make them lose their Jobs
Table (5-15) Summary of Requirements Elicitation Difficulties


5.3.2. Main Types and Characteristics of Project Requirements 
 Most of software projects failed due to inadequate requirements. Requirements elicitation is the process involving some activities such as seeking, uncovering, acquiring, and elaborating requirements. Whereas, the successful requirement elicitation largely depends on what degree the project requirement scope can be defined clearly to establish a clear functional requirements and control the scope changes (Liao, 2010). So, there are three main types of project requirements; (Soaresa et al., 2011)
    • User requirements are high-level abstract requirements based on end users’ and other stakeholders’ viewpoint. They reflect the problem domain for users and the required solution. They are usually written using natural language, occasionally, with the help of domain specific models such as mathematical equations, or even informal models that are not related to any method or language. The fundamental purpose of user requirements specification is to document the needs and constraints gathered in order to develop software based on those requirements.
    • Business Requirements are the result of requirements definition; they have reflected the goal and the demand of the high-level system's requirements for the organization or client and are described in the view and documents of IS project. 
Business Requirement = Goal + Scope.
    • Systems requirements which are derived from user requirements but with a detailed description of what the system should do to satisfy user requirements and business requirements in detail with the language of software engineering and usually is modeled using formal or semi-formal methods and languages. Moreover, it includes functional requirements, non-functional requirements and design constraints.

    • Functional: describe what the system should do, how the system should react to (with) particular inputs, and how the system should behave in particular situations (the functionalities).
    • Non-functional: are related to emergent system properties such as reliability and performance. These requirements do not have simple yes/no satisfaction criteria. Instead, it must be determined whether a non-functional requirement has been satisfied.
    • External: a detailed description of all inputs and outputs from the software system such as system, user, hardware, software and communication interfaces. It is (they are) an important classification to decompose the system into subsystems and facilitating the identification of system architecture.
In fact, the hardest single part of building a software system is to decide what to build. So, requirements elicitation is both the hardest and most critical part of software development; it is the first phase of the software development process, since errors at this initiation stage are propagated through the development process. Software requirements have been clarified by IEEE as, (1) a condition or capability needed by a user to solve a problem or achieve an objective, (2) a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document, (3) a documented representation of a condition or capability as in (1) or (2) (Rajagopal, et al., 2005). Because of projects requirements elicitation is very important activity within IS project development, the following aspects and characteristics explain this significance of project requirements elicitation:-
    1. Requirements elicitation has several dimensions including understanding the problem and its domain, identifying clear business objectives for the project, and finally understanding the needs and constraints of system stakeholders. It is the process that seek, uncover, acquire, and elaborate requirements for software
    2. It is the process of discovering that purpose by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation (Nuseibeh and Easterbrook 2000).
    3. Requirements elicitation is both the hardest and most critical part of software development since errors at this beginning stage propagate through the development process and are hardest to be repaired later. As a result, 70% of the system’s errors are due to inadequate system specification and 30% of the system’s errors are due to design issues. (Rajagopal et al, 2005)
    4. Ivy Hooks, shown that 80% of the requirements errors that remain in delivered software are the result of incorrect facts (Young, 2006)
    5. Requirements elicitation is recognized as the first stage in many requirements engineering (RE) process definitions. The success of the requirements elicitation activity gives high impact on the achievement of the goals set for RE (Kasirun, 2005)
    6. One of the most important goals of elicitation is to find out what problem needs to be solved, and hence identify system boundaries. These boundaries define, at a high level, where the final delivered system will fit into the current operational environment. (Nuseibeh and Easterbrook 2000)
    7. Elicitation is all about determining the needs of stakeholders and learners, uncovering extracting and /or discovering needs of the users and other potential stakeholders (Mohd et al., 2010)
    8. “The most difficult part of requirements gathering is not to document what the users ‘want’; it is the effort of helping users figure out what they ‘need’ that can be successfully provided within the cost and schedule parameters available to the development team. (Young, 2002)
    9. Requirement Elicitation is a crucial part of Requirement Engineering; using an appropriate method can help in producing a consistent and complete set of requirements with reduced cost and time (Kausar, et al., 2010)
    10. RE is defined by CMMI as: “Using systematic techniques like prototypes and structured surveys to proactively identify and document customer and end-user needs" (Ashra and Ahsan, 2010)
    11. Requirements Engineering can be divided into two main groups of activities; (i) requirements development, including activities such as eliciting, documenting, analyzing, and validating requirements; (ii) requirements management includes activities related to maintenance such as tracing and changing management of requirements (Soaresa et al., 2011).
    12. Poorly defined requirements in many cases may cause the following failure reasons; cost overruns, expensive rework, poor quality, late delivery, dissatisfied customers, and Exhausted and demoralized team members (Gottesdiener, 2005). 
5.3.3. Policy’s actions and principles to implement the Project Requirement Elicitation Governance
In the purpose of implementing the project requirement elicitation governance according to the designed governance framework, it is very important to emphases on defining a clear policy with actions and principles to implement requirement elicitation and explain the main procedures, practices and techniques that are needed to verify the policy’s actions and principles. Table (5-16) explains the required procedures, practices and techniques for the policy’s actions and principles to implement the project feasibility study governance.
The policy is: Elicit complete project’s requirements depend on multiply sources. 

Policy’s actions and principles for Project Requirement Elicitation Governance
Procedures, Practices and Techniques to verify Policy’s actions and principles
- Define the most favorable scenario to guarantee proper implementation of project requirement elicitation
Determining well-defined procedures to execute the project requirement elicitation
- Decrease IS projects’ failure which are derived from the project requirement elicitation
Setting Best practices to reduce the failure within project requirement elicitation
- Improve the performance of project requirement elicitation
- Design the Checklist of “Critical success factors of Requirement Elicitation” which contains the most critical success factors to achieve accurate requirement elicitation
- Adopting “Quality Function Deployment (QFD)” Customizing QFD to facilitate the requirement elicitation and manage requirements changes through providing a visual connective process and translate the customer’ needs into technical characteristics for the project’ product.  
- Enhance the best possible deliverables for IS projects 
Defining the best expected deliverables for project requirement elicitation
Table (5-16) Policy’ actions and procedures of project requirement elicitation governance
5.3.4. Well-defined Procedures to Execute the Project Requirement Elicitation 
Requirements elicitation is recognized as one of the most critical and knowledge-intensive activities of software development. Poor execution of elicitation will almost guarantee that the final project is completely failed. Since project failures are so extensive, it is quite likely that improving how the industry performs elicitation could have a dramatic effect on the success record of the industry, as mentioned earlier, elicitation is all about determining the needs of stakeholders (Hickey and Davis, 2003)b. Several researchers have developed specific process models that define how to use scenarios for requirements elicitation such as Sutcliffe and Ryan who presented a model of elicitation that combines scenarios, prototypes and design rationale (Hickey and Davis, 2003)b. The following Procedures describe the most favorable scenario to perform accurate requirement elicitation. These Procedures are based on processing many literatures such as (Nuseibeh and Easterbrook 2000), (Hickey and Davis, 2003)b, (Rajagopal, et al., 2005), ( (Liao, 2010), (Huang et al., 2010), (Razali and Anwar, 2011).
Procedure 1: Collect information about the user’s needs and expectations
Lack of user input and unrealistic user expectations have long been considered very serious problems in the requirements elicitation process. This stage addresses these problems by compiling information about;
    • Project’s Stakeholders (developers, software engineers, domain experts, and system users) abilities and domain knowledge.
    • Limitations of resources, functionality and availability of other resources.
Careful compilation of information will be used in the next stage to direct the clients/users and make them aware of what they can and they cannot expect from the project. With considering the problem statement is the start point for requirements elicitation which is developed by the client as a description of the problem addressed by the system; good problem statement should describe the following issues:-
    • The functionality that the new system should support
    • The environment in which the system will be deployed
    • Deliverables expected by the client
    • Delivery dates
    • A set of acceptance criteria
Procedure 2: Determine the participants in the system to be developed (project stakeholders)
Identifying stakeholders is essential matter, they are individuals or organizations who stand to gain or lose from the success or failure of IS project. Stakeholders include customers or clients (sponsor who pay for the system), developers (who design, construct and maintain the system), and users (who interact with the system to get their work done). For interactive systems, users play a central role in the elicitation process as usability can only be defined in terms of the target user population (Nuseibeh and Easterbrook 2000). Selecting the appropriate stakeholders from the right subject at the right time is one of the major factors of software success because selecting inappropriate stakeholders will lead to the capturing of requirements which are not relevant to the system’s real needs. Missing stakeholders implies missing essential requirements which subsequently increases project costs and promotes project failures (Razali and Anwar, 2011). Potential stakeholders are great, they can be Legal or Negative Stakeholders, Public Opinion, Government, Special-Interest Groups, Technical Experts, Cultural Interests, Adjacent Systems, Clients, Customers, Users, Consultants, Managers, Development Team, Inspectors and Market Forces.
Procedure 3: Coach the Project Stakeholders
Project team must elicit requirements from the system’s stakeholders. There are several definitions available for defining the concept of stakeholders. For example, stakeholders are defined as “any group or individual who can affect or is affected by the achievement of the organization objectives”; on the other hand, the term also means “all those who have a share in the change being considered according to the intended project. Training the clients, users and managers with the information collected or compiled in the previous stage makes the users aware of what they can expect from the developers or software engineers involved in the project. 
Procedure 4: Analyzing the project’ stakeholders
Stakeholders in general can be classified into four types: primary, secondary, external and extended stakeholders. Primary stakeholders are vital since the outcomes of the project affect them directly and their interests in the proposed system are high. Missing any primary stakeholder can affect the project development and influence the achievement of the project goals. Primary stakeholders normally include individuals who have the power, authority and responsibility over the resources such as the finance. Secondary stakeholders embrace those who are affected by the project outcomes indirectly. They may be the consumers of a product or service. Although they do not participate in project development matters, they monitor the fulfillment of their interests. External stakeholders are not directly a part of the project team, but they add values to the project from outside. Extended stakeholders could be anyone who is often helpful in assisting above-mentioned stakeholders to reach their visions (Razali and Anwar, 2011)
Procedure 5: Write descriptions of user needs
Each stakeholder involved will write a description of his/her needs for the proposed system and for the exact purpose of the system according to the understanding of each stakeholder. Since the clients and customers are already knew about the system limitations and availability of resources through the training sessions. Realistic expectations at this stage will also reduce volatility, since expectations are less likely to change as the realities of the development process become clearer.
Procedure 6: Understanding the application domain
Understanding the application domain is the knowledge of general area where the system will be applied. It should include understanding more details about the specific customer problems where the system will be applied, understanding how the systems will interact and contribute to overall business goals, understanding the needs and constraints of system stakeholders, and understanding ,in details, the specific needs of people who require system support in their work. Also it should include; 
    • Identify the various business scenarios through investigating each business work flow, functions and processing rule indicate information about what the software system should provide 
    • Describe ,in detail, and confirm various functions of the system and the relationships between them
    • Make the relationships between participants and every business scenario clear
    • Make clearly the communication relation between participants and each function
Procedure 7: Classify and Prioritize the Project Requirements
After creating well-defined operational definitions, clear and explicit system requirements should start to be built as it becomes necessary to prioritize and classify each requirement. The classification is usually based on the project’s cost, schedule and also the amount to resolve conflicting in expectations among stakeholders and any remaining ambiguity or lack of clarity in the system requirements. Quality Function Deployment (QFD) that will be illustrated later is very suitable to complete this Procedure.
Procedure 8: Choose Suitable Elicitation Techniques, Approaches and Tools to Use 
 Requirements elicitation techniques are methods used by analysts to determine the needs of customers and users. The success or failure of a system development effort depends heavily on the quality of the requirements and at the same time the quality of the requirements is greatly influenced by techniques employed during requirements elicitation (Hickey and Davis, 2003)a. There are varieties of elicitation techniques, but it is a difficult task for an organization to decide which technique or combination of different techniques are most suitable for the given stakeholders, organizational structure and project to be developed. This is normally because of the lack of understanding about the available techniques. Inadequate understanding of elicitation technique leads to a selection of improper elicitation technique for a given project which ultimately can result in the failure of the project. Therefore, it can be very helpful for the requirement engineers to know about the selection of appropriate elicitation techniques. There is a number of requirement elicitation techniques currently used by the software requirement engineers (Kausar, et al., 2010).  
In fact, traditional requirements elicitation techniques do not have any detection alarm available to avoid requirements volatility which is a major problem in the elicitation process. Elicitation starts with data requirement phase which is based on structured or unstructured interviews and brainstorming, but these techniques often lead to lack of user input or unrealistic user input due to poor understanding of resources and time constraints. To overcome this problem, modern elicitation techniques should be activated and used such as Prototyping, Model-driven Techniques and Cognitive techniques or to use a combination of them. Also, the choice of elicitation technique depends on the time and resources available to the requirements engineer and, of course, the kind of information that needs to be elicited (Vijayan and Raju, 2011). Table (5-17) explains the main elicitation techniques which are classified into nine categories (Raghavan et al., 1994), (Nuseibeh and Easterbrook 2000), (Young, 2002), (Hickey and Davis, 2003)a ,(Tuure, 2003), (Davey and Cope, 2008), (Mohd et al., 2010), (Soaresa et al., 2011).
No
Elicitation Techniques
Description of Elicitation Techniques
Example
1
Traditional Techniques
These early elicitation methods are nowadays called traditional techniques. These include a broad class of generic data-gathering techniques such as questionnaires, surveys, and interviews. They are mainly single-directional and most of them are based on the assumption that the analyst-designer team studies material already produced
Questionnaires,
Surveys, Interviews, 
Analysis of existing such as organizational charts, PIECES Framework
2
Group Elicitation
Contain a wide range of methods, the purpose of all of which is to elicit requirements from groups of end-users. Group techniques aim to foster stakeholder agreement, while exploiting team dynamics to elicit a richer understanding of the needs. It involves all stakeholders 
Brainstorming,
Focus groups,
RAD/JAD
Workshops
3
Prototyping
It has been used for elicitation where there is a great deal of uncertainty about the requirements or where early feedback from stakeholders is needed. When there is no similar existing system, prototyping can be used to create a system that illustrates the relevant features. Prototyping can also be readily combined with other techniques, for instance, by using a prototype to provoke discussion in a group elicitation technique or as the basis for a questionnaire. Prototyping is a good method for getting feedback from end-users and they are exceptionally useful because for very little cost. 
- Early versions of User interface.
-Higher fidelity prototypes
-Low fidelity prototypes
- Iteration
4
Contextual Techniques
Contextual techniques emerged in the 1990’s as an alternative to both traditional and cognitive techniques. These include observing the way users interact with an existing system through the using of ethnographic techniques such as participant observation. They also include conversation analysis as both of which applies fine grained analysis to identify patterns in conversation and interaction. 
Ethnographic
techniques
such as
participant
observation
5
Cognitive Techniques
A series of techniques originally developed for knowledge acquisition of knowledge-based systems. Such techniques include protocol analysis, card sorting (asking stakeholders to sort cards in groups, each of which has name of some domain entity), repertory grids (constructing an attribute matrix for entities, by asking stakeholders for attributes applicable to entities and values for cells in each entity).
Protocol analysis,
Task analysis
Knowledge acquisition techniques 
, card sorting, and
repertory grids
6
Model-driven Techniques
Model-driven techniques provide a specific model of the type of information to be gathered and use this model to drive the elicitation process
Goal-based methods
Scenario based method
Data Flow Diagrams 
Use Cases
7
Documentation and Checklists of NFRs
-Documentation can provide significant insights into possible requirements. These come in a variety of shapes and sizes such as problem reports, memos, user manuals from existing systems, existing designs and specifications, reports output from existing systems, documentation from competitors’ products, and even previously written contracts
-Checklists of NFRs can be used to help stakeholders identifying the non-functional needs of the system. It is often much easier to think about what the system needs to do than to identify its critical qualities such as performance, usability, and security etc, therefore a checklist is a useful tool for triggering discussions in this area.
Reports
NFRs Checklist
8
Ontology Framework
Ontology Framework: Researchers in the requirements engineering community have been studying and developing a number of ontology based approaches in order to elicit system requirements unambiguously and correctly. In the multiple ontology frameworks, there are four types of ontology top level ontology, domain ontology, task ontology, and application ontology
Top level ontology, domain ontology,
 task ontology, application ontology
9
Web Surveys
Web Surveys: Survey represents one of the most common types of quantitative and social sciences research. Web-survey tool for software requirements elicitation solves shortfalls of paper- surveys. One of the most common shortfalls is 
an unanswered question, the lack of desired information. Web-survey tool solves it by not allowing the user to proceed to the next question until he answers the previous one. Possibility of the invalidated answers is also prevented by the tool interface [Requirement elicitation is recognized as one of the most critical knowledge intensive activities of the development of software
Web-survey tool,
Social websites, forums, queries by E-mails 
Table (5- 17) Main requirements elicitation techniques
Procedure 9: Eliciting requirements from stakeholders and other sources
After determining the suitable elicitation techniques, approaches and tools to use, based on the users’ written descriptions and understanding the application domain and the user expectation, the elicitation process will be flexible through elaborating and refine the user needs and expectations.  
Procedure 10: Determine non-functional requirements and the system’s constraints
Non-functional requirements should be determined in this stage to provide integrated view for the project requirements. Non-functional requirements can add value to the projects and support their success. It encompasses determining the system’s availability, maintainability, reliability, performance; also, specify hardware, management, testing, interface and other constraints.
Procedure 11: Develop and Check the Prototype for the project requirements
Building a prototype is the suitable action to examine the correctness of the elicited requirements. Prototype can verify the completion of project’s requirements by answering the questions; “Are requirements sufficient and not excessive?” and “will this set of requirements fulfill the needs and satisfy the clients’ expectations and other stakeholders?”. The developed prototype should be checked for its quality, in other words, every system requirement should be tested for its reliability, quality, unambiguity, and correctness. This will further help developers and software engineers to understand what they are going to build and whether they can fulfill the requirements of the clients.
Procedure 12: Manage the initial requirements changes 
The continuous changing of project requirements can affect the cost, schedule and quality of a software project. Inability to manage the requirements changing may lead to inconsistencies in system requirements and results in failure of IS project. Change Control Board (CCB) should be activated to manage the requirements changes; it determines the acceptable limit for the changes and the maximum percentage of requirements changes. Also, CCB is to keep track of all changes and to take decisions in entire change request cycles of a project. After complete evaluation, the change request should be approved or disapproved by CCB. Wherever change is doable or not doable, if the change request is approved then notification is issued to relevant project team members for implementation of the change requests. 
Procedure 13: Check and judge the results of requirement elicitation
The final step is to analyze the whole set of project requirements to make sure that everything done so far is correct. Hence, start building the system with careful supervision at each phase of project development, as well as the following issues must be reviewed 
    • Control and feedback various activities of the requirement elicitation
    • Analyze and evaluate the consistency among the operators’ requirement, managers’ requirement, and decision-making needs
    • Users’ involvement to judge real demands and examine whether the system goal is in accordance with those goals confirmed by them.
    • Feedback control on system requirements would begin if the prototype doesn’t meet the user’s expectations; else the requirements elicitation should be finished. 
5.3.5. Best Practices to reduce the failure within Requirement Elicitation 
Best practices should be taken into consideration during the project requirements elicitation as guidance statement to eliminate the problems and defects that cause the project failure in order to reduce the failure rates. These practices are based on the critical success factors of IS projects and the most lessons learned from the previous successful projects in the area of project requirement elicitation (Young, 2006), (Costa et al., 2007), (Gursimran and Jeffrey, 2009), (Huang et al., 2010). Also, the best practices of CMMI for systems and software development in the area of project requirement management are merged here (CMMI, 2001), (CMMI, 2010). Therefore, during the projects requirement elicitation, project managers and developers must consider the following best practices; 
    1. Confirm that Coordination and collaboration of the project’s elicitors  with relevant stakeholders is conducted
    2. Elicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product life cycle
    3. Develop an understanding with the requirements providers on the meaning of the requirements
    4. Obtain commitment to the requirements from the project participants
    5. Manage changes to the requirements as they evolve during the project
    6. Maintain the requirements change history with the rationale for the changes
    7. Maintain requirements traceability to ensure that the source of lower level (derived) requirements is documented with Generate the requirements traceability matrix
    8. Identify inconsistencies between the project plans and the requirements
    9. Provide adequate resources for performing the requirements elicitation 
    10. Identify and involve the relevant stakeholders of the requirements elicitation as planned
    11. Review the activities, status, and results of the requirements elicitation with higher level management and resolve issues
    12. Establish and maintain quantitative objectives for the requirements elicitation that address quality and process performance based on customer needs and business objectives
    13. Identify and correct the root causes of defects and other problems in the requirements elicitation
    14. Stakeholder needs, expectations, constraints, and interfaces should be collected and translated into customer requirements
    15. Eliminate misunderstanding and complexity of the problem domain (misunderstanding the domain due to the complex nature of the task; some properties of the problem space are not fully investigated; and, mistaken assumptions are made)
    16. Select the appropriate stakeholders whose will be involved in requirements elicitation from the right subject at the right time
    17. Communicate the allowed changes in requirements to all project’s parties
    18. Exclude Changes in requirements without a permit of Change Control Board (CCB) 
    19. Rectify all Communication problems, lack of communication among developers and between developers and users
    20. Be aware to adjust project costs and timeline to the accepted requirement changes 
    21. Avoid depending on single method to elicit the project requirements 
    22. Elicit the project requirements from unlimited sources of stakeholders.
    23. Set change management with understand the impact analysis of changing requirements
    24. Avoid Inadequate/poor requirement traceability 
    25. Depend on appropriate, complete, and accurate documentations
    26. Confirm as possible that requirements are translating correctly to written natural language
    27. Support adequate training and experience of the requirement engineer
    28. Increase the awareness of all sources of requirements 
    29. Support the communication among groups of people working together
    30. Involve all users at all times during requirement development
    31. Review and update knowledge, skills, or experience to perform tasks 
    32. Establish more mechanisms to resolve the conflicting requirements and needs
    33. Understanding the feasibility and risks associated with requirements elicitation
    34. Complete understanding of hardware and software interface specification 
    35. Good management of people and resources within requirements elicitation
    36. Perceive the impact of technological, historical, organizational, and individual changes  to requirement elicitation   
    37. User needs should be well-understood and interpreted while resolving the conflicting requirements
    38. Users should be given adequate time available for requirements gathering
5.3.6. Suggested practices to improve the performance of requirements elicitation 
In fact, poor requirement elicitation means customers will be dissatisfied, chaotic development process, developers make wrong decisions and loss of many investments, time and confidence for the customers. So, more attention should be paid to requirement elicitation to produce high-quality requirements to attain the intended objectives and achieve projects success. To ensure that the developed requirements are excellent, the following characteristics should be existed: (Gottesdiener, 2005)
    • Complete, they include all of the needed elements, functionality, external interfaces, quality attributes, and design constraints.
    • Completed baseline and tracking requirements
    • Consistent, they do not conflict with other requirements.
    • Correct, they accurately represent the real needs of users and stakeholders.
    • Feasible, they are possible to implement.
    • Identified and executed change control practices
    • Relevant, they are necessary to meet a business need, goal, or objective.
    • Requirements should develop in an iterative manner
    • Verifiable, there is a finite, cost-effective technique for determining whether the requirement is satisfied.
    • Integrated, use a combination of multiple requirements elicitation techniques
Furthermore, IEEE-830 standard [IEEE-830] Recommended Practice for Software Requirements Specification which describes recommended approaches for the specification of software requirements. Among the recommendations it gives a set of characteristics that must be founded at good projects’ requirements, which are: Correctness, Unambiguity, Completeness, Consistency, Importance and/or Stability Ranking, Verifiability, Modifiability, and Traceability (Soaresa et al., 2011)
For this purpose, Suggested practices and checklists in the area of requirement elicitation can play an important role to improve the performance of requirement elicitation which provides good finding. So, Critical success factors (CSF) checklist for requirement elicitation in order to guarantee the completeness and correctness of project requirements elicitation, and Quality Function Deployment (QFD) to facilitate the elicitation of real requirements and manage the requirement changes are introduced.
5.3.6.1. CSF for Requirement Elicitation Checklist 
CSF Requirement elicitation Checklist is a crucial tool that contains the most critical success factors to achieve the project requirement elicitation in accurate and proper form; developers must verify the existence of these factors to confirm the completeness, validity, reliability and credibility of project requirement elicitation. The following factors in table (5-18) are extracted from the researches that focused on requirement elicitation and the lesson learned from the previous successful projects (Young, 2002), (Gottesdiener, 2005), (Young, 2006), (Costa et al., 2007), (Romero et al., 2009), (Huang et al., 2010).
No.
Critical success factors to attain the project requirement elicitation
Yes
No
1
Verify that reliability and availability requirements are allocated to the project


2
Verify that requirements are understood as they have been written


3
Assign attributes to each requirement.


4
Anticipate and manage any requirements changes.


5
Concern with the organizational and political considerations


6
Choose a suitable combination of elicitation techniques (e.g., interviews, focus groups, team meetings, prototype, ….)


7
Collect Requirements from Multiple Viewpoints


8
Define the technical environment (e.g., computing architecture, operating system) into which the system or product will be placed.


9
Detecting and defining functional and non-functional requirements 


10
Develop a clear vision for the end product.


11
Develop a well-defined and shared understanding of the project scope.


12
Develop requirements using multiple short cycles or iterations. Each cycle or iteration is a self-contained period of time with a set of activities to learn and improve requirements process


13
Distinguishing between systems requirements and software requirements 


14
Document the rationale for each requirement (why it is needed).


15
Document the requirements clearly and consistently.


16
Ensure that the facts concerning the requirements are accurate and important requirements are not omitted.


17
Establish a mechanism to control changes to requirements and new requirements.


18
Identify “domain constraints” (i.e., characteristics of the business environment specific to the application domain) that limit the functionality or performance of the system or product to be built.


19
Identify ambiguous requirements as candidates for prototyping


20
Identify and consult system stakeholders


21
Identify the people who will help specifying requirements and understanding their organizational bias


22
Involve stakeholders throughout the requirements process.


23
Install requirements traceability mechanism that tracks requirements from source specification through to test cases


24
Knowledge of specification languages (e.g. structured English, UML, formal languages) 


25
Perform requirements validation and verification activities in the requirements gathering process to ensure that each requirement is testable.


26
Prioritize the real requirements to remove unnecessary ones and determine those that should be met in the first release or product 


27
Provide training for requirements analysts and selected customer/user representatives 


28
Record Requirements Sources and Define the system’s operating environment


29
Solicit participation from many people so that requirements are defined from different points of view


30
The project staff includes a trained and experienced requirements manager or requirements analyst.


31
Use an effective automated of requirements tool to maintain information about the requirements.


32
Use an effective mechanism to control changes to requirements and new requirements.


33
Use Business concerns to drive requirements elicitation


34
Use elicitation techniques that allow customers to validate their requirements as early in the elicitation process as possible 


35
Use of proper communication protocols 


36
Use scenarios to elicit requirements and a requirements repository


37
Validate the project requirements with all stakeholders 


38
Verify the quality of the requirements early and frequently.


Table (5- 18) critical success factors of project requirement elicitation checklist
5.3.6.2. Customizing the Quality Function Deployment (QFD)
Referring to the difficulties of requirements elicitation which were explained earlier and investigating the failure reasons related to requirement elicitation, Misunderstanding of user requirements and changing requirements during the project development are the main problems of requirement elicitation which generate inconsistencies in system requirements and cause the project failure. Also, errors in requirements elicitation are overall the most serious in software development and the hardest to repair; 70% of the systems errors are due to inadequate system requirements and 30% of the system errors are due to design issues. (Rajagopal et al, 2005).
This problem creates an essential need to develop new techniques that have ability to address the defects and faults of requirements elicitation. Quality Function Deployment (QFD) can contribute to attain this objective because it ensures that requirements are relevant to the task and to the users’ needs. QFD was developed by Yoji Akao in Japan at 1966, while Japanese industries were moving toward original product development (Kenett and Baker, 2010). It was developed in the Kobe shipyards as a way to expand and implement the view of quality as taught by W. Edwards Deming and others. It has been widely applied in many industries worldwide, such as automobile, electronics, food processing, computer hardware, and software. (Sadiq and Shahid, 2009)
QFD is defined by Soto as “a systematic process for motivating a business to focus on its customers”, It is based on market research, understanding customers’ needs and desires, and the effectiveness of relevant products in meeting those needs and desires (Rajagopal, et al., 2005). It’s an overall concept that provides means of translating customer requirements into the appropriate technical requirements for each stage of product development and production. The distinguishing attribute of QFD is the focus on customer needs throughout all product development activities. By using QFD, organizations can promote teamwork, prioritize action items, define clear objectives, and reduce development time. Moreover, QFD can provide the following benefits and improvements which support IS projects’ success; (Tran and Sherif, 1995)
    • Improve product quality by focusing on customer requirements up-front and throughout the development cycle 
    • Improve communications between customers, system engineers, programmers and testers and thus contribute to a better decision-making process 
    • Facilitate the management of change through rigorous rating and systematic traceability of requirements
    • Reduce costs of projects by enabling concurrent engineering and by reducing costs associated with late-in-the lifecycle rework 
    • Enable alignment between customer requirements, product requirements and cost requirements (or constraints)
5.3.6.2.1. Why adopting QFD in requirement elicitation
In fact, QFD has many characteristics can contribute to solve many of requirements elicitation problems. Through providing a visual connective process to help systems’ analysts focus on the customers’ requirements throughout the total development cycle of IS project. Thus, it provides the means for translating customer needs into appropriate technical requirements for each stage of a project development life cycle. It helps to develop more customer-oriented and higher-quality products (Bouchereau and Rowlands, 2000). In addition, there are more advantages justify adopting QFD in requirement elicitation which are:-  
    • It considers a new technique to improve requirements elicitation and ensure the customers’ expectations are exactly satisfied. 
    • It depicts user requirements from word statements into charts, hence it makes complete, consistent, non-ambiguous, non-redundant, and true customer requirements are identified and specified. (Liu, 2000)
    • It is a development method that translates the needs of customers through the stages of projects into a final product (Kim et al, 2000)
    • It ensures that requirements are relevant to the task and to the users’ needs (Rajagopal, et al., 2005)
    • It considers an effective technique to manage changing requirements. Also, keep track of all changes and to take decisions in entire change request cycles of a project.
    • It’s a methodology for analyzing customer needs, priorities, and benchmark information. It requires compiling information and organizing it into seven areas on a matrix (Gottesdiener, 2005).
    • It improves user involvement, management support and involvement, team involvement and shortens the development lifecycle (Sadiq and Shahid, 2009).
    • It can definitely reduce 70% of the systems errors which are due to inadequate system requirements through eliciting the system requirements properly and prioritize requirements according to proposed framework (Sadiq and Shahid, 2009).
    • It helps to introduce the idea of quality in the early phases of the requirements cycle from the customer's perspective (Tran and Sherif, 1995)
    • It enables the tailoring of products to customer needs, through customer interaction and brainstorming with product development, testing, maintenance, quality control team, and system designers (Tran and Sherif, 1995)
    • It ensures the consistency between customer requirements and product’s measurable characteristics (Burcu and Eryilmaz, 2011)
    • It can reduce the development time by 50 percent, and start-up and engineering costs by 30 percent (Bouchereau and Rowlands, 2000)
    • It can achieve various goals such as reduction in customer's complaints, improvement in design reliability and customer satisfaction, easier design change, and reduction in product development cycle (Kim et al, 2000)
5.3.6.2.2. Application of QFD in Requirements Elicitation 
The basic idea of QFD is to translate the customer’s needs into technical characteristics for the project’s product (Kim et al, 2000). Building the house of quality matrix (HOQ) is the backbone of QFD which depicts the technical procedures of QFD. HOQ acts as a comprehensive matrix for documenting customer spoken and interpreted requirements. Each attribute is then mapped to appropriate technical specifications and performance targets. It translates customer requirements into engineering characteristics to be met by a new product design and helps how an organization will meet those requirements. The matrix displays key customer requirements (what’s) and their relationship with technical design requirements (how’s) (Liu, 2000). At each stage of deployment, relationships between “what” is required and “how” it will be accomplished are determined mutually by process stakeholders. 
There are many different forms of the HOQ, but its ability to be adapted to the requirements of a specific problem is significant. Fig. (5-4) illustrates the main components of the common format of HOQ which facilitate the complete proper requirements elicitation process; (Bouchereau and Rowlands, 2000), (Kim et al, 2000), (Liu, 2000), (Karsak et al, 2002), (Gottesdiener, 2005), (Kenett and Baker, 2010), (Burcu and Eryilmaz, 2011)
    1- Whats, (customer’s requirements) "voice of the customer", the house of quality documents customer requirements from multiple Perspectives. It outlines what customers want and represent their requirements
    2- Hows, (Technical Requirements), how to do technically to satisfy customer requirements (technical strategies), initiate technical requirements to satisfy customer's requirements
    3- Correlation Matrix, determine correlation of technical requirements to each other. It specifies trade-off relationships between technical characteristics. There are three types of relationships between them: positively related, negatively related or irrelevant. Two engineering characteristics are negatively related with each other if an increase in the value of one of the engineering characteristics usually decreases the value of another. The peak of the matrix (the "Roof") is used to identify the interactions between different Hows and the relationships that are rated as strong positive ( ), weak positive ( ), weak negative ( ), strong negative ( ), and none. The relative EC importance can be calculated using the relative CR importance and the weights assigned to the relationships between CR's and EC's
    4- Relationship Matrix, determine how technical requirements satisfy each of the customer requirements; relationships within this section are defined using a strong (9), medium (3), weak (1), or none (blank cell) no relationship. Scale correlates what customers want from a product and how the project can meet those requirements. The core matrix of quality function deployment is the relationship matrix of WHATs vs. HOWs. The body of the matrix shows relationship correlations between what the customer wants from the product and how a project team can meet those requirements. The relationship between the CR's and EC's, which is presented in the main body of the HOQ, can be represented in symbol or numerical form
    5- Importance, determining customer importance rating for each of the requirement, the importance rating, and competitive analysis are specified in terms of customer requirement satisfaction. Identifying the relative importance of the various customer requirements plays an important role in discerning those that are critical and helps in prioritizing design effort. 
    6- Customer Competitive Assessment = Competitive Evaluation, determine the best value for each of the customer’s requirements. Illustrate evaluation and prioritization of Whats and assign the Important Weight and the Relative Weight for each requirement
    7- Technical Competitive Assessment = Target value, the bottom of the matrix is the prioritized and the weighted technical requirements. It identifies the requirements that are the most critical for success which is illustrated through a bar chart to provide quick analysis of the key technical requirements. Determine target value for each of the technical requirement and determine the optimal requirements











Fig. (5-3) Main Components of QFD
To increase the interact between QFD components, which generates additional enhancement at the performance of QFD to achieve complete, consistent, non-ambiguous, non-redundant, and true requirements elicitation, the following issues must be considered:-
    1- Use PIECES Framework, often the main problem for an inexperienced requirements analyst is determining how to get started. PIECES framework helps solve this problem by providing a set of categories of issues that can help the analyst structure the elicitation process. PIECES encompasses six issue categories: Performance, Information and data, Economy, Control, Efficiency, and Services. The PIECES framework is best used for analyzing existing systems, It is especially appropriate for eliciting requirements for enhancing or improving information systems. (Davey and Cope, 2008)
    2- Develop requirements using multiple short cycles or iterations. Each cycle or iteration is a self-contained period of time with a set of activities, this to learn and improve requirements process
    3- Document the collected information during the elicitation process, to reduce errors or missing information. 
    4- Revise the documentation based on feedback from the stakeholders
5.3.7. Define the expected deliverables of project Requirement Elicitation     
Good outputs of requirement elicitation is the first step to achieve the project success; it contribute to draw a clear map to determine user’s needs through the following issues  
    • Helps the users in the separation of what they want and what they need
    • Enables all actors to share the same vision of the problem and the solutions that are feasible
    • Increases trust between software developers and customers
    • Minimizes the interactions between developers and customers
After eliciting the project requirement, the following outputs should be delivered:-
    •  User requirements Statements in natural language, included with the diagrams of the services that the system will provide with the operational constraints. 
    • Written for customers System requirements, A structured document with setting out detailed descriptions of the system services Written as a contract between client and contractor
    • High level Software specification, A software description which is written for developers to serve as a basis for a design or implementation 
    • System functions and no-functions requirements, an explanation of all system functions and no-functions requirements which satisfy the users’ needs
    • Assistant elicitation documents, JAD session results, system prototype displays and other reports such as the accepted requirement changes by the Change Control Board (CCB).
5.4- IS Project Risk Management Governance
Software projects development confront many risks which might occur in all developed process. Success of IS projects demands effective management of these risks. It is closely connected with the effective risk management (Ye Tao, 2008). Risk management involves understanding potential problems that might occur during the project development and analyze risks that affect and impede the project success. Keil has proved through a large number of instances that the main reason which cause the failure of IS implementation projects is that people fail to apply appropriate risk management (Keil, 2000). So that, the highest ranked factor for IS/IT project failure was risk management (Kutsch and Hall, 2005).
5.4.1- Risk Management definition and its literature review 
Both practitioners and researchers discussed risk management as one of the key approaches to reduce the likelihood of IS project failure (Hormann et al., 2010). Risk management, is the process of identifying and controlling any activity or event that can negatively influence the success of IS project, wherever risks are all issues that may affect the delivery of benefits to be gained from the IS projects (Elkington and Smallman, 2002). Bannerman defined project risk management as a set of principles and practices aimed at identifying, analyzing and handling risk factors to improve the chances of achieving a successful project outcome and/or avoid project failure (Bannerman, 2008). 
Project Management Institute (PMI) defined risk management in a project environment as the systematic process of identifying, analyzing, and responding to uncertainty as project-related events or conditions which are not definitely known with the potential of adverse consequences on a project objective (PMI, 2008). Risks can be identified and addressed in different developed phases of software project, but it is essential to identify risks as early as possible to address them promptly because the cost connected with exposed risks might be enormous. A Systematic process of risk management is normally divided into three main activities; (Mojtahedi et al, 2010)
    1. Risk identification and classification which determines risks that might affect the project and register their characteristics. 
    2. Risk analysis which measures the impact of the identified risks on a project.
    3. Risk reduction to reduce the risks effects on a successful project.
In the same context, Boehm has defined risk management into six stages: Risk Management planning, Risk Identification, Risk Assessment, Risk Prioritization, Risk Resolution and Monitoring (Boehm, 1991), whereas risk means that some adverse circumstance will occur such as; risks that affect project schedule and resources, risks that affect the quality or performance of the software being developed and affect the organization that develops or procures the software project. In most software projects, risks can occur due to five main reasons; the use of new and unproven technologies, system requirements, system architecture, system performance, and organizational or non-functional affairs (Ye Tao, 2008). So that, unsystematic and arbitrary risk management can endanger the success of the IS project since most of the risks are very dynamic throughout the project life cycle. In fact, Risks can be distinguished and identified through verifying the following properties: (Nieto and Ruz, 2011)
    • Risk is a future event that may or may not occur.
    • Risk must be also an uncertain event or condition that, if it occurs, has an effect on, at least, one of the project objectives such as scope, schedule, cost or quality.
    • The probability of the future event occurring must be greater than 0%, but less than 100%.
    • Future events that have a zero or 100% chance of occurrence are not risks.
    • Risks in different projects have individual differences.
Developing an efficient and suitable risk management strategy depends on estimating two main components; the probability of risk occurrence and its impact on project performance. In spite of several articles that have already identified various software risks, there is a lack of how to calculate the probability of risk occurrence and the impacts of different software risks across the projects. Han and Huang summarized the main previous studies which investigated the risk management problems for IS project as follow; (Han and Huang, 2007)
Boehm (1991) developed top 10 risks identification checklist through the survey of several experienced project managers. Barki et al. (1993) conducted a comprehensive review of software risks from 120 projects in 75 organizations; they proposed 35 measures for software risks which were further classified into five dimensions: technological newness, application size, expertise, application complexity and organizational environment. Karolak (1997) proposed a method called Software Engineering Risk Management (SERIM) to predict risks and to provide corrective action in the software development; SERIM identified 10 software risks and came up with 81 related questions that contained metrics to measure the software risks. The relationship between software risks was identified using three of the risk elements: cost, schedule and technical performance. 
Sumner (2000) used a structured interview to compare the differences between software risks within MIS and ERP projects, and proposed nine risks that were unique in ERP projects. Longstaff et al., (2000) proposed a framework named Hierarchically Holographic Modeling (HHM) and identified seven visions in systems integration that included 32 risks. Kliem (2001) identified 38 risks in ERP projects which were classified into four categories: people, management, business, and technical. Addison (2003) used a Delphi technique to collect the opinion of 32 experts and proposed 28 risks for E-commerce projects. Carney et al. (2003) designed a tool called COTS Usage Risk Evaluation (CURE) to predict the risk areas of COTS products in which he identified four categories comprising 21 risk areas (Han and Huang, 2007).
Wallace et al., (2004) pointed out that the assessment scale of each risk was excessively complex. To reduce the bias of a single-culture viewpoint, Schmidt et al. conducted a Delphi survey to integrate the options of experts from Hong Kong, Finland, and the United States. They identified 53 risk items which were grouped into 14 types (Wallace et al., 2004). At the conclusion of Han and Huang study, they extracted the top 10 risks which cause IS projects failures that are:-
    1. Continually changing system requirements 
    2. System requirements not adequately identified
    3. Unclear system requirements 
    4. Lack of an effective project management methodology 
    5. Incorrect system requirements 
    6. Poor project planning 
    7. Inadequate estimation of required resources 
    8. Project involved the use of new technology 
    9. Project progress not monitored closely enough 
    10. Corporate politics with negative effect on project 
In addition, lots of recent researches introduced various methods to identify the project risks through introducing lists contain the most common risk factors for IS projects, (Yong et al, 2009), (Costa et al., 2007), and (Hoermann et al., 2010). Through investigating the previous researches that exposed project risk management, it can define the main problems at the area of IS project risk management that are;
    1. Probability of risk occurrence and the impacts of different software risks for IS projects are predictable.
    2. The difficulty of identify the project risk factors
    3. The difficulty to determine the probability of risk occurrence. 
    4. How to estimate the cost of project risks.
    5. Inability to mitigate and confront the risks after they happened.  
    6. No validated lists are available to help the project manager to understand the nature and types of risks typically faced in a software project.
    7. Previous attempts to produce a comprehensive list have been limited by the lack of a cross-cultural perspective.
    8. Necessity of risk assessment should be measured in the early project phase.
    9. Risks affect the projects’ success in high percentages.
5.4.2. Importance of Risk Management 
In fact, project risk management is beneficial if it is implemented in a systematic manner from planning stage through the project completion. It plays an important role in software development, whereas, Microsoft’s research stated that an investment of merely 5% of the total budget into risk management could result in a probability of 50-70% to complete the project on time (Yong et al, 2009). Boehm defines four major reasons for implementing software risk management (Stern and Arias, 2011)
    • Avoiding software project disasters, including run away budgets and schedules, defect-ridden software products, and operational failures.
    • Avoiding rework caused by erroneous, missing, or ambiguous requirements, design or code, which typically consumes 40-50% of the total cost of software development.
    • Avoiding overkill with detection and prevention techniques in areas of minimal or no risk.
    • Stimulating a win-win software solution where the customer receives the product they need and the vendor makes the profits they expect.
Risk management can provide projects with many organizational benefits including; Increased confidence in achieving project objectives, Improved chances of success, Reduced surprises, More precise estimates through reduced uncertainty, Identification of favorable alternative courses of action, and Reduced duplication of effort (Bannerman, 2008). In general, there are lots of direct benefits as consequence of implementing proper risk management throughout all projects’ development phases, they are:- 
    1. Risk management can help to avoid software disaster, rework and overkill.
    2. Risk management provides a number of professional skills to the project team.
    3. Project risk management focuses on the  reduction and the prevention of risks
    4. Project risk management is the art and science of identifying, analyzing, and responding to risk throughout the life of a project and in the best interests of meeting project objectives.
    5. Identify managerial and technical problems before they occur so that actions can be taken to eliminate or mitigate their impact.
    6. The objectives of project risk management are to minimize the probability and impact of potential risks while maximizing the probability and impact of potential opportunities.
    7. Effective risk management has become critical success factor of the IS project because it has the ability to detect and remove risks in early stages of software development life cycle.
5.4.3. Policy’s actions and principles to implement Risk Management Governance
In the purpose of implementing the project risk management governance according to the designed governance framework, it is very important to emphases on defining a clear policy with actions and principles to implement project risk management governance and explain the main procedures, practices and techniques that are needed to verify the policy’s actions and principles. Table (5-19) explains the required procedures, practices and techniques for the policy’s actions and principles to implement the risk management governance.
The policy is: Minimum level of project’s risks through efficient risk management governance 

Policy’s actions and principles for  
Risk Management Governance
Procedures, Practices and Techniques to verify policy’s actions and principles
- Define the most favorable scenario to guarantee proper implementation of project risk management
Determining well-defined procedures to execute the project Risk Management
- Decrease IS projects’ failure which are derived from the project risk management
Setting Best practices to reduce the failure within project Risk Management
- Improve the performance of project risk management
- Developing “Comprehensive Project Risk Identification Tool” to facilitate the process of identifying the project risk factors through classifying the project risks into thirteen main categories, these thirteen categories are branched into 170 sub-risk Factors.
- “Assigning the Risk Probability” to estimate the probability of project’ risk factors. 
- “Assigning Risk Reserve” is an estimation value expresses the cost of project risks in monetary form, this value must be added to the project cost estimation to keep the chance of project’s success if the expected risks are done. 
- Enhance the best possible deliverables for IS projects 
Defining the best expected deliverables for project Risk Management
Table (5-19) Policy’ actions and procedures of project risk management governance
According to the critical role of risk management to support IS projects’ success, risk management governance can contribute to decrease the side effects and faults of IS projects development which increases the project chance to achieve success. Figure (5-4) explains the governance components to apply the project risk management governance.  

Fig. (5-4), Main governance components of risk management governance
5.4.4- Well-defined procedures to executing the Project Risk Management  
Risk management of IS projects should focus on risks reduction and prevention, continuously assess possible problems and define potential risks that infuluance the project success. These issues require describing a whole picture for the project to achieve successful risk management (Ye Tao, 2008). In order to increase the probabilites of IS projects success, managers must assess risks early throughout the project life cycle. So that, proper risk assessment requires understanding what the risks are and which of these risks are most critical (Tesch et al, 2007). Based on the previous literatures in the topic of project risk management, well-defined procedures for risk management can be developed and encompass the best procedures to execute a proper risk management of IS projects; they incloude the following procedures; (Boehm, 1991), (Heemstra et al, 2003), (Lu, and Ma, 2004), (Kasap and Kaymak, 2007), (Tesch, et al., 2007) (Mojtahedi et al, 2010), (Nieto and Ruz, 2011), (Stern and Arias, 2011). Sequence of risk management procedures is represented in Fig. (5-5)











Fig. (5-5) Main procedures of project risk management governance
Procedures 1: Risk Management Planning, is the initial phase of risk management process which decides how to approach, plan, and execute risk management activities for the intended project. Thus ensures that project objectives are clearly stated and understood, focuses the risk process around the specific requirements of the project, and documents the results in a risk management plan. Risk planning is clearly significant before embarking on risk identification. It is necessary to define roles and responsibilities, methodology and approach, review and reporting frequency for the main objectives of risk management process to be agreed. Also, risk management plan provides the following critical inputs to risk identification: (Kasap and Kaymak, 2007)
    • Assignments of roles and responsibilities; identifying the main tasks of risk management that will be  implemented by assigning the handling of specific tasks and roles to specific individuals.
    • Budget provisions for risk management activities; approved funds available for risk management activities. 
    • Schedule for risk management; revised schedule including the time needed for risk management activities over the duration of the project’s life cycle.
    • Categories of risk; identify the risk categories that are used during risk identification to organize and prioritize risks as they are identified. 
Procedures 2:Risk Identification, is the important phase in project risk management. It can discover, determin, define, describe, document and communicate with risks before they become problems and adversely affect the project (Kasap and Kaymak, 2007). It is also the most commonly used techniques of identifying risk are, brainstorming, workshops, checklists and prompt lists, questionnaires, interviews, Delphi groups or nominal group technique (NGT), and diagramming approaches such as cause-effect diagrams, systems dynamics, and influence diagrams (Mojtahedi et al., 2010). In the context of how to identify the risk factors, Boehm introduced some software risk factors to be considered during determine  software development risks that are:( Fauzi et al, 2008) 
    • Personnel shortfalls
    • Unrealistic schedules and budgets
    • Developing the wrong functions and properties
    • Developing the wrong user interface
    • Gold plating (adding more functionality/features than is necessary)
    • Continuing stream of requirements changes
    • Shortfalls in externally furnished components
    • Shortfalls in externally performed tasks
    • Real-time performance shortfalls
    • Straining computer-science capabilities
Procedures 3:Risk Analysis, once the project risks are identified, they should be analyzed and evaluated in terms of estimating the probability of occurrence and the seriousness of impact if they occur. Through the risk analysis, each risk is assessed to determine; (Stern and Arias, 2011)
    • Likelihood: the probability that expresses the risk that will occur.
    • Impact: is the degree to which the risk will negatively affect the project success. It’s the cost of risks if they occur and turn into a problem. 
    • Timeframe: determines the time when risks need to be addressed. 
Procedures 4: Risk Assessment and Prioritization, risk assessment is the process of prioritizing risks for further analysis by assessing and combining their probability of occurrence and impact. The purpose of risk assessment is to measure the impact of the identified risks on a project depending on the available data. Prioritization can be based on quantitative methods, qualitative methods, or a combination of both (Mojtahedi et al., 2010). The qualitative methods described rely on a holistic response or common sense ranking and the quantitative approaches rely more on comparative analysis that can be translated into mathematical scores. 
Risk exposure is one of the famous quantitative methods to make risk prioritizing through prioritized risks in a list which ranks risks on their exposure value to determine the arrangement in which risks will be addressed in risk mitigation strategy. Boehm defines the Risk Exposure Equation to facilitate creating the risks priorities. Risk exposure can be calculated as follows, (Stern and Arias, 2011).
Risk Exposure (RE) = P × C
Where P = probability of occurrence for a risk and C is the impact of risks, the cost of risks if they occur and turn into a problem. For example, if the probability of a risk is 10 percent and the impact of the risk is $10,000, the risk exposure = (0.1)*($10,000) = $1,000. If RE is calculated for each risk, the prioritization is based upon a numerical ranking of the risk exposures.
Procedures 5:Risk Response, is the process of developing options and actions to enhance opportunities and to reduce threats to the project objectives. It helps project manager to develop procedures and techniques to mitigate the identified risks, and enables the project manager to identify new risks during the project. It also explains how to implement risk response plan (PMI, 2004). Risk response strategies aim to either reduce or eliminate the likelihood of threats occurring, limit the impact of the risk if it is realized, or a combination of both. Risk response strategies are formulated and implemented in response to new risks whenever they are identified and assessed as a threat that must be controlled. There are four common risk response strategies are found to address the risks of IS projects;( Bannerman, 2008) 
    I. Avoidance; Avoidance strategies aim to prevent negative effects that influence  the project. This may involve, for example, changing the project design so that the circumstance under which a particular risk event might occur cannot arise, or so that the event will have little impact on the project if it occurs. Also, more agile development methods might be applied to determine complete project requirements. 
    II. Transference; This strategy involves converting the responsibility of a risk to a third party. This action does not eliminate threats to the project, but it just transfers the responsibility to someone else. Theoretically, this implies a principal (agent relationship) wherein the agent is better able to manage the risk which results in a better overall outcome for the project.This can be a high risk strategy because the risk’ threats to the project remains. Common risk transfer strategies include insurance, contracts, warranties, and outsourcing.
    III. Mitigation; Risk mitigation is one or more reinforcing actions designed to reduce a threats to a project by reducing its likelihood and/or potential impact before the risk is realized. Ultimately, the aim is to manage the project in such a manner that the risk event does not occur or, if it does, the impact can be contained to a low level (that is, to ‘manage the threat to zero’). For example, using independent testers and test scripts to verify and validate software progressively throughout the development and integration stages of a project. This may reduce the likelihood of defects being found post-delivery and minimize project delays due to software quality problems.
    IV. Acceptance; Risk acceptance can include a range of passive and active response strategies. One is to passively accept that the risk exists but choose to do nothing about it, other than monitor its status. This may be an appropriate response when the threat is low and the source of the risk is external to the project’s control, In this case, contingencies can be established to handle the condition when and if it occurs.
Procedures 6:Risk Monitoring and Control, the process of implementing a risk response options and actions, tracking identified risks, monitoring residual risks, identifying new risks, and evaluating the risk process and risk strategies effectiveness throughout the project life cycle. Also, monitor the risk items in an on-going basis by addressing them on a weekly, monthly or quarterly basis. In this process, the risk items will be reassessed for their likelihood of occurrence and impact, new risk items will be identified, and existing ones may be retired once a resolution is reached. Risk monitoring and control is a continuous process (Kasap and Kaymak, 2007). 
5.4.5- Best practices to reduce the failure within the project risk management 
Set best practices should be taken into consideration during the implementation of the project risk management as guidance statement to eliminate the problems that cause the project failure in order to reduce the failure rates and enhance IS project success. These practices are based on guidance instructions and the most significant critical success factors of IS projects that must be considered during the project development. These practices comprise the most lessons learned from the previous projects and the Roberts’ lessons learned for project risk management (Kwak and Stoddard, 2004). Also, the best practices of CMMI for systems and software development in the area of project risk management are merged here (CMMI, 2001), (CMMI, 2010). Risk management best practices can be used as a risk mitigation to mitigate the risk impact; within the project risk management implementation projects’ managers and developers must consider the following best practices; 
    1. Monitor risks against those identified in the project plan
    2. Collect and analyze the risk issues and determine the corrective actions necessary to address the issues
    3. Define the parameters used to analyze and categorize risks, and the parameters used to control the risk management effort
    4. Establish and maintain the strategy to be used for risk management
    5. Risks should be identified and analyzed to determine their relative importance and impact
    6. Identify and document the risks associated with cost, schedule, and performance in all appropriate product life-cycle phases
    7. Review all elements of the work breakdown structure as part of identifying risks to help ensure that all aspects of the work effort have been considered
    8. Review all elements of the project plan as part of identifying risks to help ensure that all aspects of the project have been considered
    9. Evaluate and categorize each identified risk using the defined risk categories and parameters, and determine its relative priority
    10. Risks should be handled and mitigated, where appropriate, to reduce adverse impacts on achieving objectives
    11. Develop a risk mitigation plan for the most important risks to the project, as defined by the risk management strategy.
    12. Identify the persons or group responsible for addressing each risk, also Determine the cost-to-benefit ratio of implementing the risk mitigation plan for each risk 
    13. Monitor the status of each risk periodically and implement the risk mitigation plan as appropriate
    14. Establish a schedule or period of performance for each risk handling activity that includes the start date and anticipated
    15. Risks should be re-assessed, controlled, and managed through the project development 
    16. Eliminate as much as possible the conflict between project’s departments and functions  
    17. Consider the necessity of increasing the risk management efforts exponentially, according to the increase of project size and complexity.
    18. Give equal attention to all risk factors, not to one risk factor over each others
    19. Depend on both qualitative and quantitive risk analysis methods
    20. Give more interest to risk identification which is the most critical phase in risk management. 
    21. Calculate the Risk Reserve for the project and adjust the cost according it
    22. Do best efforts with  obtaining sufficient details within the project’s risk planning 
    23. Incorporate the Risks’ impact into the project plan 
    24. Satisfy the required knowledge, experience and skills for the project team 
    25. Work to achieve all end-user expectations as much as possible
    26.  Use the appropriate development methodology and avoid Changing of technology as much as possible
    27. Project Managers should consider the best practices and lessons learned from the previous projects
    28. Constitute  sufficient and good risk management practices and documentations
    29.  Set the correct assumptions regarding risk analysis 
    30. Support good communication among customers, developers and users 
    31. Provide adequate training for persons’ responsible of risk management process.
    32. Establish explicit definition for the quality standards of software project 
    33. Make redesign business processes to match the project risks as much as possible
    34. Make good expectation as much as possible to estimate the probability of project risk factors.  
    35. Use the mathematical models to evaluate the risk exposure 
    36. Prepare good and consistent project risk plan 
    37. Confirm that  the suitable risk response strategy is chosen and applied  
    38. Continue to make risk evaluation during the project life phases 
    39. Eliminate the conflicts between system users
5.4.6- Suggested practices for Project Risk Management Governance 
Quantitive Suggested practices are important components in the structure of IS project risks management. They can contribute to solve lots of risk management problems and enhance the performance of risk management. According to investigating the previous researches that discussed the project risk management, the main difficulties in this area are represented in the following issues:-
    1. Difficulty of project risk identification 
    2. Difficulty to determine the probability of risk occurrence
    3. Difficulty to confront the two types of risks; risks that are identified, and risks that are unidentified.
    4. Difficulty to estimate the costs of risks and risk reserve
    5. Difficulty to determine the risk strategy response 
Suggested practices and lists can be established to reduce the previous risk management problems. This research introduces; Comprehensive List of Risk Factors to facilitate the project risk identification, Assigning the Likelihood of Project Risk Factors (Risk Probability) to calculate the expected risk probability, and Assigning the Risk Reserve to estimate the cost of risks which might threaten IS projects.
5.4.6-1. Comprehensive List of Risk Factors (CLRF)
Comprehensive list of project risk factors can facilitate the risk identification; it includes the most significant project risks which can threaten the project success. Through the Comprehensive list as showing in Table (5-20), the project risks are classified into thirteen main categories of risk factors that are;
    1. Project Planning and Control 
    2. New and Unproven Technologies
    3. System Requirements
    4. System Architecture
    5. System Performance
    6. Policies and Structure
    7. Customer Risks
    8. Organizational and Managerial Risks
    9. Project Skills
    10. Project Communications
    11. Cost Estimation and Schedule
    12. Project Quality
    13. Project Coding and Testing
Furthermore, these main categories of risk factors are branched into 170 sub-Factors to help the project managers and facilitate their task to identify the risks that can be occurred. Designing the comprehensive list is based on collecting the risk factors within the following researches; (Jiang and Klein, 2000), (Ropponen and  Lyytinen, 2000), (Sumner, 2000), (Schmidt, et al., 2001), (Lu and Ma, 2004), (Wallace et al., 2004), (Costa et al., 2007), (Han and Huang, 2007), (Tesch, et al., 2007), ( Yong et al., 2007), (Ye Tao, 2008), (Al-Rousan et al, 2009), (Yong et al, 2009), (Hormann et al., 2010), (Stern and Arias, 2011). 







No
Main Risk Factors
Risk sub-Factor
1
Project Planning and
 Control
    1. Inadequate or Poor project planning
    2. Changing  project scope and objectives 
    3. Contract defects in any aspect of the project
    4. Does not exist the contingency plans for known risks  
    5. Ambiguities in the subcontractor task definitions
    6. Inadequate scope control
    7. Incomplete Contract Requirements
    8. Lack detailed work breakdown structure for all activities
    9. Lack of a documented project plan 
    10. lack of review at the end of each phase
    11. Poor definition of scope
    12. Risk management plan not exist 
    13. Project goals are not well defined 
    14. Bad documentation of the development system
    15. Undefined metrics for the project
    16. Weak work breakdown structure with conflict
2



New 
and Unproven Technologies

    1. Dissimilarity to previous projects
    2. Hardware is being developed in parallel with project software
    3. Hardware limit the ability to meet any requirements
    4. High level of technical complexity
    5. Immature technology
    6. Inability to avoid technological bottlenecks
    7. Inadequate Technical and technology Infrastructure
    8. Project involved the use of new technology that has not been used in prior projects
    9. Relying on vendors for deliveries of critical components (Compilers, Hardware, COTS)
    10. Introduction of new technology

3

System Requirements

    1. Continuing stream of requirements changes
    2. Incomplete definition of quality requirements
    3. Incorrect system requirements
    4. lack of customer involvement
    5. Not understanding the same thing by reading the requirements
    6. Requirements are unstable and invalidate
    7. Requirements creep and volatility
    8. Requirements reliability not allocated to the software projects
    9. Requirements that are technically difficult to implement
    10. System requirements not adequately identified and Not Understood
    11. The team doesn’t know the client’s organizational culture
    12. Unable to understand the requirements as they have been written
    13. Unclear system requirements
    14. Undefined business requirements 
    15. Users lack understanding of system capabilities and limitations

4
System Architecture
    1. Adding more functionality and features than is necessary
    2. Change  of external interfaces 
    3. Choosing wrong development strategy 
    4. Complex System Architecture
    5. Depend on  one development methodology
    6. Developing wrong functions and properties
    7. Developing wrong user interface
    8. External interfaces are not completely defined
    9. Inadequate configuration management system
    10. Inappropriate  software technical design and documentation 
    11. Problems with using COTS (commercial off-the-shelf) software
    12. Software requirements specification inadequate for designing the system
    13. System design depend on unrealistic or optimistic assumptions
    14. System design doesn’t include features to aid testing
    15. System integration has not been specified
    16. There are requirements and functions difficult to design
    17. Use of an inappropriate methodology 

5
System Performance
    1. Conflicts between development team members
    2. Defects of Expected Performance Issues
    3. Difficulty in defining the inputs and outputs of the system
    4. Lack of system integration
    5. Product is complex to implement
    6. Project progress monitored loosely 
    7. Real-time performance shortfalls
    8. Resistant to change
    9. Shortfalls in externally performed tasks
    10. The application developed is not reliable
    11. The system doesn’t meet the intended functional requirements

6
Policies
 and 
Structure
    1. Corporate politics have negative effect on project
    2. Difficult to establish standard project policies 
    3. Government rule changes
    4. Improper definition of roles and responsibilities
    5. Lack of proper management control structure
    6. Non-Conducive Political Environment
    7. Poor or nonexistent control
    8. Project Policies are affecting technical decisions
    9. Role of each person involved in the project is not clearly Defined
    10. There are internal conflicts affect the project
    11. Unclear Governance Model
    12. Unclear Roles and policies
    13. Undefined project success criteria

7
Customer Risks
    1. All customer factions are not represented in decisions regarding functionality and operation
    2. Breach of customer financial obligations
    3. Conflict between users
    4. Customer not understand the technical aspects of the system
    5. Difficult to identify all stakeholders 
    6. Failure to manage end user expectations
    7. Lack of cooperation from users
    8. Lack of sensitivity to user resistance
    9. Many external suppliers involved in the development project
    10. Overstatement of Customer Expectations
    11. Unclear Customer Objectives
    12. Users are not an integral part of the development team
    13. Users not committed to the project
    14. Users resistant to change
    15. Users with negative attitudes toward the project

8
Organizational and 
Managerial Risks
    1. Change in organizational management during the project
    2. Inexperienced team members
    3. Lack of effective project management methodology
    4. lack of formal management practices
    5. Lack of top management support for the project
    6. Steering Committee not found 
    7. Organization undergoing restructuring during the project
    8. Poor conflict management
    9. Poor integration management
    10. Poor project organization and definition of responsibilities
    11. Poor resource allocation
    12. Project management doesn’t present a realistic or optimistic picture to the customer
    13. Project milestones unclearly defined
    14. Project progress not monitored closely enough
    15. The project size require a larger organization than usual for your organization
    16. There is not a formal project management methodology
    17. Unstable organizational environment

9
Project Skills
    1. Defects of team work cooperative across project functional boundaries
    2. Inadequately trained development team members
    3. Inappropriate staffing and personnel shortfalls
    4. Inexperienced project manager
    5. Insufficient training and reskilling
    6. Insufficient and inappropriate staffing
    7. lack of the project staff  and consultation
    8. lack trained in skills required for this project
    9. people don’t understand their own and others’ roles in the project
    10. Personnel shortfalls
    11. Project members don’t implement systems as it draw
    12. Team members lack specialized skills required by the project
    13. the team doesn’t know software engineering

10
Communications
    1. Bad communication among the members of the project
    2. Carelessness in communicating
    3. Ineffective communication
    4. Ineffective communications with users
    5. Poorly communicated goals and deliverables
    6. The team doesn’t feel free to ask for the managers’ help

11



Cost Estimation and 
Schedule
    1. Budget based on a unrealistic estimate
    2. Budget changes don’t accompany requirement changes
    3. Cost Estimating errors; inadequate productivity, cost, change, or contingency and control
    4. Deviation from timetable and budget
    5. Errors in estimating time or resource  availability
    6. Estimation method based on historical data only
    7. Excessive schedule pressure
    8. Failure to identify complex functionalities and time required to develop those functionalities
    9. Inadequate estimation of project schedule
    10. Inadequate estimation of required resources
    11. Insufficient resources
    12. Lack of mechanisms of validation and verification 
    13. No resource planning
    14. Project schedule is unstable
    15. Resources are not tracked properly
    16. Schedule changes  don’t accompany requirement changes
    17. Time overrun and cost overrun
    18. Unexpected project scope expansions
    19. Unrealistic schedules and budgets
    20. Wrong time estimation and budget

12
Project Quality
    1. Inadequate quality assurance
    2. Inadequately software quality assurance function 
    3. No explicit definition about the standard of product quality 
    4. Poor attitude toward quality
    5. The overall quality of the developed application is low
    6. The standard of project quality is not clearly defined
    7. Undefined mechanisms for assuring quality
13
Project Coding and Testing
    1. Design specifications  detail are insufficient to write the system code
    2. Inadequate time is allocated for system integration and testing
    3. Selected algorithms and system designs are difficult to implement
    4. Source codes are not reusable
    5. Test specifications are inadequate to test the system fully
    6. Testing plans and procedures are not updated as part of the change process
    7. Tests are not perform by different people from the development team
    8. There are system constraints make the code difficult to write
    9. Formal testing plan not exist 
    10. Use multiple languages in the project coding
Table (5-20) Comprehensive list for project identification risk factors
5.4.6-2. Assigning the Likelihood of Project Risk Factors (Risk Probability)
  Estimating the probability of project risk factors is the main problem after they are identified. In this area of project risk management, the project governance committee does its efforts to estimate the probability of the identified risk factors. These values   determine the probability of occurrence for each risk factor; the following procedures explain a simple method to assign the risk probability:-
    1- Identify the project risk sub-Factors that can be occurred by using the Comprehensive list of risk factors in Table (5-20)
    2- Estimate the initial probability of risk factors by calculating the percentages of their sub-Factors that are identified to all sub-factors at the comprehensive list through the following formula  
Initial probability of risk factors =%
    3- Project governance committee can estimate the average probability for all identified sub-factors depending on the equation of the Expected Value (Saunders, 1990), whereas it depends on Optimistic estimation (the best case), Pessimistic estimation (the worst case), and Realistic estimation (most likely).
  , (EV) Expected estimation Value, (OE) Optimistic Estimation, (PE) Pessimistic Estimation, and (RE) Realistic Estimation “most likely”.
    4-  Also, Project governance committee can depend on the percentages in Table (5-21) to estimate the probability of risk factors as a relationship between risks and the expected rate of occurrence (Xiaosong et al, 2009). Percentages in this table can unify and approximate the estimation among the members of project governance committee.
    5- Probability of risk factor equals the average of two estimated values in steps (2) and (3).
Probability of risk factor %
Description
0-20%
Very unlikely the risk will occur
21-40%
unlikely the risk will occur
41-60%
Even likelihood the risk will occur
61-80%
Likely the risk will occur
81-100%
Very likely the risk will occur
Table (5-21) Percentages of risk factor probability
5.4.6-3. Assigning the Risk Reserve for IS Projects 
Risk Reserve is an estimation value that expresses the cost of project risks in monetary form. This value must be added to the project cost estimation to keep the chance of IS project success if the risks have been done. Calculate the risk Reserve depends on the likelihood of project risk factors and its impacts. The following steps explain the method of calculating the risk Reserve for IS projects:-
    1- Based on determining the risk sub-Factors which can threaten the intended project through examining the Comprehensive List of Risk Factors and calculating the probability of risk factors as shown in the previous section. Risk impact has to be assigned (the degree to which the risk will negatively affect the project success) for each risk factor to the project in term of the Coefficient impact which takes values from 1% -100% as shown in table (5-22). 
    2- Coefficient impact reflects the strength of causing losses and failure for each risk factor. It can be estimated through the average values of project governance committee and project management staff according the impact levels in table (5-22). 
    3- The sum of Coefficient impact for all thirteen risk factors should equal one by calculating the weighted percentages. 
    4- Determine the Total Losses if the project failed (IS/IT investment)
    5- Calculate the Cost of project risk factors (Risk Reserve ) as shown in table (5-23)  
    6- Cost of project risks (Risk Reserve ) can be calculated by these equations:-
Cost for each risk factor (V4) = Probability of risk factor (V1)* Coefficient Impact (V2)* Total losses if the project failed (V3)
Cost of risks (Risk Reserve) = ∑ Cost for each risk factor (V4)
Impact level for the risk factors
Description
Coefficient Impact %
 Critical Impact 
If the risk factor occurs, the project will fail.  Minimum acceptable requirements will not be met
81-100%
High Impact
If the risk event occurs, the project will encounter major cost/schedule increases. Minimum acceptable requirements will be met. Secondary requirements may not be met
61-80%
Moderate Impact
If the risk event occurs, the project will encounter moderate cost/schedule increases. Minimum acceptable requirements will be met. Some secondary requirements may not be met
41-60%
Weak Impact
If the risk event occurs, the project will encounter small cost/schedule increases. Minimum acceptable requirements will be met. Most secondary requirements will be met
21-40%
Negligible Impact
If the risk event occurs, it will have no effect on the project. All requirements will be met
0-20%
Table (5-22) Coefficient impact scale for the risk factors of IS projects 
No
Identified Risk Factors
Probability of Risk Factors = (V1)
weighted percentage of Coefficient Impact = (V2)
Total losses if the project failed = (V3)
Cost of risk factors
V4=V1*V2*V3
1






Total Cost of project risk factors
∑ V4
Table (5-23) Calculate the Risk Reserve for IS Projects
Example: If the total losses for XMD software project were estimated with 200000$, and the identified risk factors with their likelihood and impacts as table (5-24), the Cost of project risks (Risk Reserve) for this project would equal 34900$
No
Identified risk factors
Probability of Risk Factors
Probability of risk Impact
Average Value of losses if the project failed
Impact for each risk factor
1
Failure to manage the end of the user’s expectations
0.23
0.30
200000
13800$
2
Lack of effective project management methodology
0.15
0.25
200000
7500$
3
Inexperienced project manager
0.08
0.15
200000
2400$
4
Budget based on an unrealistic estimation
0.22
0.20
200000
8800$
5
Inadequate quality assurance
0.12
0.10
200000
2400$
Cost of project risks (Risk Reserve ) for this projects =
34900$
Table (5-24), Example to explain the calculation of project Risk Reserve


5-4.7- Define the expected deliverables of project Risk Management
In fact, governance can contribute to enrich the effective deliverables of IS project risk management. The application of governance procedures and techniques which were explained can provide the following deliverables:-
    1- List of identified project risk factors, depending on the Comprehensive List of Risk factors, the governance committee can identify the risk factors which can threaten the intended project.
    2- The probability of the identified risk factors 
    3- Risk Impact (magnitude of the loss) of each identified risk factors
    4- Risk Exposure, which is the simple calculation to give a numeric value of risk factors. it enables different risks to be compared and prioritized
Risk Exposure for any risk factor = Probability of risk occurrence * Total loss if risk occurs
    5- Project Risk Reserve, expresses the cost of project risks in monetary form to keep the chance of IS project success if the risks are occurred. 
Cost of risks (Risk Reserve) = ∑ Cost for each risk factor
    6- Contingency plan that describes what to do if certain risks are materialized. 
    7- the suggested risk response strategies, 
Risk response strategies aim at either reducing or eliminating the likelihood of the threats occurrence, or limit the impact of the risk if it is realized, or a combination of both. These strategies are formulated and implemented in response to new risks whenever they are identified as a threat that must be controlled. There are five common risk response strategies to confront the projects’ risks; (Kasap and Kaymak 2007), (Bannerman, 2008)
    A. Avoidance, Avoidance strategies aim at preventing negative effects that occur or affect a project. This may involve, for example, changing the project design so that the circumstance under which a particular risk event might occur cannot arise, or so that the event will have little impact on the project if it does.
    B. Transference, This strategy involves shifting the responsibility of a risk to a third party. This action does not eliminate the threats to the project; it just passes the responsibility of its management to someone else.
    C. Mitigation, Risk mitigation is one or more reinforcing actions designed to reduce the threats on a project by reducing its likelihood and/or potential impact before the risk is realized in order to make it more acceptable to the project and organization
    D. Acceptance, Risk acceptance can include a range of passive and active response strategies, recognizing that residual risks must be taken, and responding either actively by allocating appropriate contingency, or passively doing nothing except monitoring the status of the risk. 
    E. Risk protection, the organization can buy insurance to cover any financial loss in the case the risk becomes real. 
5.5. IS Project Cost Estimation Governance 
In early days of computing, IS projects were relatively much simpler and the entire software development cost were often less than $5000. Today, software exceeds 25 million source code statements. In addition, Software development organizations require technical staff of more than 1000 personnel, and development costs of such software projects may exceed more than many millions of dollars. Hence, errors in software cost estimation produce high failure loses because it impacts on project’ budgeting, risk analysis, planning and software improvement analysis (Zia et al., 2011).
Project cost estimation is more difficult and predictable, but it is considered a significant development activity for the successful software projects. It refers to the prediction of the likely amount of effort, staffing level, time, and materials necessary to accomplish the required development activities in early stage of a project’s life cycle. Thus, effort prediction of software cost estimation is concerned with the prediction of the required person-hours to accomplish the project activities (Muzaffar and Ahmed, 2010). The difficulty of project cost estimation can appear in wide range throughout the following risks which represent the main characteristics of cost estimation; (Agarwal et al., 2001)
    • Use of historical data has some limitations because predictors and relationships used to predict software development effort can vary over time, and differ among software development environments.
    • Difficulty in capturing complex sets of relationships that are present in many software development environments.
    • It is often done hurriedly without an appreciation for the effort required.
    • Difficulty in drawing conclusions or making judgments based on available data.
    • Need more experience at developing estimates, especially for large projects.
    • Costs and schedules are often pre-determined by an outside source.
    • There is a general lack of acceptance of how developing software is an expensive endeavor.
    • Software cost estimation requires a significant amount of effort to perform it correctly.
    •  It is a recurring process in which the quality of outputs is strongly dependent on the quality of inputs.
 Estimates of a project’s budget, resources, and schedule which represent the outputs need to be updated periodically as more and more information about a project’s cost-drivers (Malik and Boehm, 2011). Generally, there are four essential elements that must be existed to fulfill proper project cost estimation:
    1. Estimate the project size; this generally ends up in either Lines of Code (LOC) or Function Points (FP), or other possible units of measure. 
    2. Estimate the effort in person /months or person /hours.
    3. Estimate the schedule in calendar months.
    4. Estimate the project cost in dollars (or local currency) 
As a result, three important coefficients can determine the quality of project cost estimation; Efforts, Time, and project Scope in other words "Cost estimation is a function of Efforts, Time, and project Scope as the following equation;  C = f (E, T, S),  
 Whereas, (C) indicates to cost, (E) indicates to efforts, (T) indicates to time and (S) indicates to project scope. Taken into account, accurate cost estimation helps to complete a project on-budget, on time. Over- or under-estimation of software costs may result in costly errors such as projects are rejected as too expensive; projects may omit important features; projects are abandoned. Accurate project estimation can reduce these unnecessary costs and increase the organization's efficiency and effectiveness. 
5.5.1. Policy’s actions and principles to implement Cost Estimation Governance
In the purpose of implementing the project Cost Estimation governance according to the designed governance framework, it is very important to emphases on defining a clear policy with actions and principles to implement project Cost Estimation governance and explain the main procedures, practices and techniques that are needed to verify the policy’s actions and principles. Table (5-25) explains the required procedures, practices and techniques for the policy’s actions and principles to implement the Cost Estimation governance.
The policy is: Comprehensive and balanced project’s cost estimation integrating supplemental costs. 

Policy’s actions and principles for  Project Cost Estimation Governance
Procedures, Practices and Techniques to Verify Policy’s actions and principles
- Define the most favorable scenario to guarantee proper implementation of project Cost Estimation
Determining well-defined procedures and define the importance of executing the project Cost Estimation
- Decrease IS projects’ failure which are derived from the project Cost Estimation
Setting Best practices to reduce the failure within project Cost Estimation
- Improve the performance of project Cost Estimation
- Develop the “Comprehensive Cost Estimation Model (CCEM)” to make the cost estimation more accurate and eliminate the problems of depending on one cost estimation technique by using mixture of estimation techniques.
- Setting the checklist of “Critical Success Estimation Factors (CSEF)” to produce realistic and accurate cost estimation
- Enhance the best possible deliverables for IS projects 
Defining the best expected deliverables for project Cost Estimation
Table (5-25) Policy’ actions and procedures of project cost estimation governance
According to these policies and IS project governance framework; the application of cost estimation governance can be realized through implementing the four governance components in Fig. (5-6) which formalizes the main structure of cost estimation governance. 

Fig. (5-6) the structure of cost estimation governance 
5.5.2. Importance of Project Cost Estimation Governance 
In fact, the occurrence of common software failure was caused by the poor cost and schedule estimation (Bin Mansor et al, 2010). Consequently, cost estimation helps to complete a project on-budget and on time. On the other hand, over- or under-estimation of software costs may result in costly errors such as that projects are rejected as too expensive, projects may omit important features, and projects are abandoned. Park Robert at the Institute of Software Engineering (ISE) demonstrated the main benefits of conducting accurate cost estimation in table (5-26) wherever thirty-nine benefits are listed as the implications of accurate project cost estimation (Park Robert, 1995). It should emphases on the cost estimation is a part of the larger plan and design process, and the software sizing is the main driver and main input of software estimation effort. If the project’s size is estimated correctly, the estimation effort will be realistic and can be translated into realistic duration and schedule.
In the context of implementing the project cost estimation, there are two software sizing measurements that are widely used; source lines of code (SLOC) and function points (FP). (SLOC) is software metric used to measure the amount of code in a program. It is typically used to estimate the amount of effort that will be required to develop a software project as well as to quantify productivity or effort once the software is produced. Function points measure the delivered functions in a way that is independent on the technology used to develop the system. It computes the project size by counting the functional components (inputs, outputs, external interfaces, files, and inquiries) (Galorath and Evans, 2006).
SLOC is the oldest metric for calculating the project efforts and it is the primary input for most of the types of cost estimation models. Constructive Cost Model (COCOMO) is the famous analytical method to estimate the project cost estimation. It’s based on SLOC and uses parameters that are derived from the projects initiation (Zheng, 2009). The COCOMO model is more prevalence than other measures because it’s well understood and ease of use to collect SLOC. Estimation of SLOC for any software project can be obtained from the prior experience, the size of previous systems, the size of a competitor’s system and breaking down the system into smaller pieces and estimate SLOC for each piece (Zia et al., 2011). 
  No
Benefits of IS project cost Estimation
No
Benefits of IS project cost Estimation
1
Scope proposed software tasks
21
Identify uncertainties and quantify risks
2
Avoid underestimating the magnitude and complexities of software projects 
22
Evaluate the consequences of internal and external constraints
3
Explore alternative system concepts
23
Establish achievable objectives
4
Explore alternative design concepts
24
Establish a basis for quality service
5
Set priorities
25
Establish commitments
6
Identify key design elements
26
Bound the risk of commitments
7
Identify key process parameters
27
Prepare successful proposals
8
Identify key assumptions
28
Explore the affordability of a system
9
Provide a basis for successful risk management 
29
Balance levels of risk against customer needs
10
Inform a customer of the potential cost of services from a fee-for-service organization
30
Provide a quantitative basis for presenting proposed costs and schedules to customers
11
Help plan the necessary steps for completing a project
31
Identify key cost drivers, so they can be properly managed
12
Identify and manage major risk items
32
Evaluate proposals from competing bidders
13
Plan for staffing profiles and manpower buildups that meet project needs
33
Support independent reviews of proposed projects (independent cost estimates)
14
Identify tasks and their relationships
34
Predict life-cycle costs 
15
Assess schedule feasibility
35
Establish baselines for project tracking
16
Identify and evaluate cost and schedule tradeoffs
36
Serve as a basis for negotiating cost agreements
17
Explore alternative proposals for enhancements and upgrades
37
Provide information for establishing business strategies
18
Allocate and schedule resources
38
Predict returns on investments
19
Establish budgets
39
Assess an organization's ability to perform within targeted costs
20
Get funding


Table (5-26) Benefits of conducting accurate cost estimation, ISE, (Park Robert, 1995)
5.5.3. Well-defined Procedures to execute the Project Cost Estimation
Project cost estimation is a systematic process comprises a set of consistent procedures. The most significant procedure to perform accurate cost estimation is to predict the project’s size precisely. There are also many factors in addition to project size that can affect the accuracy of project cost estimation such as imprecise requirements, inaccurate tasks duration and improper estimation methods (Galorath and Evans, 2006). COCOMO, Analogy, Expert judgment, Top-down estimation, Bottom-up estimation are widely used techniques of project cost estimating; In addition, the parametric models which can be used in some cases such as; linear regression estimation models, and the artificial neural networks models (ANNs); Fuzzy logic and case based reasoning to realize the project cost estimations. 
Based on the previous researches which addressed the project cost estimation, (Park Robert, 1995), (Agarwal et al., 2001), (Galorath and Evans, 2006), (Zhang, 2008), (Keung, 2009), (Zheng, 2009), (Bin Mansor et al, 2010), (Muzaffar and Ahmed, 2010), (Malik and Boehm, 2011), (Zia et al., 2011) the most favorable scenario included with the best procedures to execute the project cost estimation can be developed as showing in table (5-27). It begins with defining the project scope correctly to initiate cost estimation and ends with the validation and reconciliation of the project estimates, budget, and schedule. 
No.,
Name of Procedure
Description
Procedure 1:
Review and validate  the Project Scope  properly  and accurately  
It is the process by which the project is defined and prepared for execution. It determines the main set of developed activities that are going to be carried out.
Procedure 2:
Validate the project requirements elicitation with analyzing the functional and non-functional requirements
Determining the needs of stakeholders and clarifying the project requirements where user and business needs of a system are identified and captured through the formal descriptions of the requirements such as the customer’s requirements specification or request for proposal, and software requirements specification. 
Procedure 3:
Develop the project work breakdown structure  (WBS)
Breakdown a project into manageable chunks that can be effectively estimated and helpful to define the total efforts of the project. Also, WBS identifies the project’s subsystems or elements (units or project’ components) that fulfill a specific function in the project.
Procedure 4:
Estimate the project size 
Based on WBS, Estimate the project size in Source Lines of Code (SLOC) or function point by using one or more cot estimation techniques.
Procedure 5:
Convert the project size into Efforts 
Calculate the project effort in person-months (PM)
Project effort =
Procedure 6:
Estimate the efforts of Project Supplemental activities and add it 
Add the efforts for the project supplemental activities in SLOC to the project effort after it calculated
Procedure 7:
Calculate the project duration based on available resources and project efforts
Determine duration of time needed to complete the project effort, for example: 
Project duration = 
Procedure 8:
Estimate the Project Costs 
Estimate the total costs of software project to provide the work elements and  the procurements of WBS
Procedure 9:
Assess the Impact of the identified Risks
Identify project risks to assess their impact on the project where the risk impact is the degree to which the risk will negatively affect the project success (refer to project risk management)
Procedure10:
Adjust the project cost to risks   
Add the cost of the project risks to the total project cost estimation whereas Total Costs = Project labor cost + Additional project costs+ Cost of project Risks
Procedure11:
Validate and verify project estimations, budget, and schedule with estimate documentation 
Review and confirm the integrity of the estimation. Ensuring that the estimation was performed properly with respect to the project-imposed budget and schedule and resolve the differences. 
Table: (5-27) Main Procedures to execute IS project cost estimation
5.5.4. Best practices to prevent the failure within the Project Cost Estimation
Set of best practices must be taken into consideration during the implementation of project cost estimation as guidance statements to reduce the problems and defects that can cause the projects’ failure. These practices are based on IS projects critical success factors and guidance instructions that must be considered during the project development process; they comprise the most lessons learned from the previous successful projects. Also, the best practices of CMMI for systems and software development in the area of project cost estimation are merged here (CMMI, 2001), (CMMI, 2010). These practices can lead to reduce the failure rates and enhance IS project success. During the project cost estimation, IS projects’ managers and developers must consider the following practices; 
    1. Establish and maintain estimates of the attributes of the projects’ work product and tasks
    2. Use appropriate methods to determine the attributes of the work products and tasks that will be used to estimate the resource requirements
    3. Estimate, as appropriate, the labor, machinery, materials, and methods that will be required by the project
    4. Estimate the project effort and cost for the work products and tasks based on estimation rationale
    5. Include supporting infrastructure needs when estimating effort and cost
    6. Collect the models or historical data that will be used to transform the attributes of the work products and tasks into estimates of the labor hours and cost
    7. Consider the indirect costs estimation for the non-technical activities 
    8. Adjust the project costs to risks 
    9. Support the consistent between desired capabilities to available budgets, schedules, and skilled
    10. Project estimation should based on more than one estimation technique   
    11. Create a historical database to retain the estimated data 
    12. Confirm to proper usage and analysis of the historical estimation data 
    13. Develop the estimation competencies  for project leadership and management
    14. Establish well-defined requirements for the project estimated activity 
    15. Avoid to perform cost estimate based on imprecise requirements
    16. Consider the amplification of project requirements at the late of project life-cycle 
    17. Exclude  the frequent user change requests without change controls
    18. Developers should be involved during the project cost estimation process 
    19. Assess the staffing levels and skills accurately 
    20. Avoid to force the estimation to match the resources available
    21. Do best efforts as much as possible to meet the project costs 
    22. Consider and expect to some extent the project’ size growth in estimates 
    23. Establish a proper and integrated WBS
    24. Keep the estimate current and updated  
    25. Give sufficient time on software sizing
    26. Use the suitable estimation methodologies 
    27. Gather sufficient and complete project requirements  
    28. Consider the historical estimates as basis for analogy due to differences in languages and methodologies
    29. The schedule and effort allocations should consistent with historical experience
    30. Avoid unrealistic estimation efforts 
    31. Use previous knowledge to estimate software size, cost, and schedule
    32. Always enrich  cost estimation competencies for project estimators and establish good Budget Management 
5.5.5. Suggested practices to improve the performance of project cost estimation  
Sitting suggested practices and checklist within the project cost estimation is an essential to verify and validate the accuracy of cost estimation process and make it more realistic which improve the performance of estimation process. Comprehensive Cost Estimation Model (CCEM) to conquer the problems of depending on one cost estimation methodology, and the Critical Success Estimation Factors checklist (CSEF) to produce realistic cost estimation are developed in the purpose of improving the performance of projects’ cost estimation. Taking into account, developing CCEM is based on the most common cost estimated techniques of IS projects that are; 
    1- Top down, is a hierarchical decomposition of the project that divide the project into progressively smaller components to estimate the project size (Galorath and Evans, 2006)
    2- COCOMO, is the famous analytical method to estimate the project cost estimation which uses the Effort Equation to estimate the number of Person/Months required to develop a project. 
EFFORT = 		(Agarwal et al., 2001)
Where A is proportionality constant (productivity Parameter), and B represents economy or diseconomy of scale. B depends on the developed mode which COCOMO is defined in terms of three different models; the basic model, the intermediate model, and the detailed model. In this model, the project’s size measure is SLOC.
    3- Analogy, Compare the intended project with the past similar projects (similar historical projects) whereby the estimation process based on the actual experiences (i.e. projects with known characteristics, effort and schedule) (Keung, 2009). 
    4- Expert Judgment, is a judgment provided by a subject matter expert in a specific application area through consulting with one or more experts. It is based on the accumulated experiences of a team of expert’s judgment (Bin Mansor et al, 2010). 
    5- Bottom-up estimation, Individuals assess for each project’s components; estimates are summed to calculate the total project’s estimation, accurate estimates are possible by the detailed basis of estimating and promoting individual responsibility (Galorath and Evans, 2006).
    6- Program Evaluation and Review Technique (PERT), is the technique that uses optimistic estimation which is the best case, pessimistic estimation which is the worst case, and realistic estimation ‘most likely’ to calculate the expected time or size for a particular activity (Saunders, 1990)

Where, EV = expected estimation Value, OE = optimistic estimation, PE = pessimistic estimation and RE = realistic estimation “most likely”
5.5.5.1- Comprehensive Cost Estimation Model (CCEM)
In fact, in the case of predicting the project estimation according to one estimation technique, the project cost estimation will not be accurate and unrealistic in high percentage. So that, CCEM is based on calculating the project cost estimation through a mixture of estimation techniques and considering the Source Line of Code (SLOC) as a project size metric. These hybrids of estimation techniques can generate a new model contributes to make project cost estimation more accurate and more realistic. Analogy, Expert judgment, Top-down Estimation, Program Evaluation and Review Technique (PERT) which will be explained later, are used to develop CCEM. Furthermore, transforming the total SLOC for the project activities into person/hours depending on Expert Judgment consultants is the main contribution of this model, the following procedures explain the main steps to develop CCME:-   
Main steps of Comprehensive Cost Estimation Model (CCEM)
Step 1: Determine the project scope definition, boundaries, main edges, and state the main constrains.    
Step 2: According to Top down methodology, divide the project into their main activities through specifying and analyzing the project requirements. Examples of dividing the project activities are; Elicit the project requirements, Refine project requirements, Software Analysis, Software Design, Software Coding, Interface Specification, Software Testing, Other activities such as project risk management, Project support and software quality, and Software Quality Assurance .
Step 3: Building work breakdown structure (WBS) to organize the project elements into a hierarchy that simplifies the tasks of budget estimation and control. It can be designed as the following structures (Golpayegani and Emamizadeh, 2007):- 
    • “Project Control Work Breakdown Structure” (PCWBS) is the hierarchical structure which shows the overall components of the project deliverables or subjects.
    • “Functional Work Breakdown Structure” (FWBS) shows the scope of functions and operations that should be performed to achieve the main subject or deliverable.
    • “Relational Work Breakdown Structure” (RWBS) represents the relationships between the components of PCWBS and FWBS.
Step 4: Estimate the size of all the project activities in source line of code (SLOC) according to WBS by using:-
    A- Analogy methods to estimate the size of all the project activities. 
    B- PERT equation to calculate the size of all the project activities in SLOC, 

    C- Calculate the average of A and B for all the project activities. 
    D- Calculate the total Average size of project activities in SLOC
Step 5: Transfer the total SLOC for the project into Person/Hours depending on Expert Judgment consultants. Example: if one SLOC= 0.2 P/hours 
Then, Total P/h for the project = Total SLOC for the project activities* 0.2
Step 6: Estimate the work productivity per month (WPM)
WPM= Actual work hours per day * Actual days per week * Weeks per Month 
WPM= 7.5*5*4 = 150 W/h    (Approximation value)
Step 7: Estimate the project effort = 
Step 8:  Estimate the additional efforts for the supplemental project activities through the Expert Judgment consultants as a percentage to the project effort 
Example:-
Project management                                                           add 7% from the project effort
Project change configuration management		        add 5%
Administration and Support Costs			        add 10% 		
Project maintenance for first three years 		        add 13%	and so on 
Step 9:  Calculate the total project effort 	 
Total project efforts = Estimated project effort + Estimated additional efforts
Step 10:  Calculate the Project Duration 
Project Duration =   or
Project duration =   (Zhang, 2008)
Step 11: Assess the Impact of the project Risks
    A. Identify the software of the project risks and Assess risks impact on the cost estimation
    B. Transfer project risks into costs by calculate the risk reserve or estimate a percentage by Expert Judgment consultants
Step 12: Calculate the Total Project Cost 
    A. Project labor cost =  
    B. Calculate the additional project costs such as hardware and software purchases, travel for meeting or testing purposes, telecommunications (e.g., long distance phone calls, video-conferences, dedicated lines for testing, etc.), training courses, office space, and so on.
    C. Calculate the Total Costs by the following equation 
Total Project Cost = Project labor cost + Additional project costs+ Costs of project Risks (risk reserve)
Figure (5-7) illustrates the algorithm for the comprehensive methodology to calculate the project cost estimation by using Comprehensive Cost Estimation Model (CCEM).

Fig. (5-7) Algorithm for Comprehensive Cost Estimation Model (CCEM)
5.5.5.2. Critical Success Estimation Factors (CSEF)
Actually, good application of cost estimation methodologies is not sufficient to achieve accurate project cost estimation, but there are many critical success factors must be established to produce realistic cost estimation. Table (5-28) explains the main critical success factors that must be verified and validated during implementing the project cost estimation. IS projects developer must review the existence of the following issues.    
No
Critical Success Estimation Factors
Exist
Not Exist
1
Use more than one cost estimation techniques to verify the accuracy of the estimated process   


2
the project tasks have been sized appropriately and identified clearly 


3
The organization has a historical database for organizing and retaining the estimated data 


4
Consistent between WBS and the project activities without conflicts 


5
Estimate the cost of project’s supplemental activities 


6
Information of completed projects is captured and stored into the historical Database


7
Sufficient time is provided to conduct a proper project estimation


8
The purpose and objectives of estimation are clearly understood by all the project stakeholders which they are involved  


9
Include the cost of the project risks into cost estimation 


10
Re-estimate the project several times throughout its lifecycle


11
Clearly descript the project scope and objectives 


12
Establish good documentation based on the previous projects’ data 


13
Analogy estimated data must be updated currently


14
Experts from related and different projects or disciplines must be involved in the estimating process


15
Ensure that, the project efforts estimation are implemented according to accurate sizing 


16
The results of estimates are integrated with project planning 


17
Follow a standardized estimation procedure that all involved s…… can understand 


18
Potential costs and schedule impacts are estimated for all identified risks


19
Factors that affect the estimation are identified and explained


20
Cautious steps must be taken to ensure the integrity of the estimating process


21
As much as possible use at least one software estimation tool


22
Building cost estimation via gathering complete and sufficient requirements 


23
Estimated costs and schedule should harmonize and consistent with the previous successful projects


Table (5-28) Main success factors for implementing the project cost estimation.  
5.5.6. Define the expected deliverables of project cost estimation
Project cost estimation outputs are more significant to determine the size of IS project investment. It provides vital information to all project stakeholders. For instance;
    • Introduce a predicted cost estimation to support bids competing 
    • Facilitate the implementation of  project schedule 
    • Help to determine the availability of project resources
    • Knowing the expected duration of a project activities  
    • Be useful in projects’ bids evaluation
Therefore, the following delivery must be established as project documentations to support all project developed phases. The best expected delivered for project cost estimation should include:-  
    1. Refined project requirements and constraints
    2. Refined software functional requirements
    3. Software architecture hierarchy 
    4. Project-work breakdown structure (WBS) including the attributes of work elements
    5. List of identified Project Risks 
    6. Methods that used to estimate software sizing
    7. Estimation of Software sizing for all project functions and activities in SLOC
    8. Methods that used to estimate project efforts
    9. Complete estimation for project efforts for all work elements of WBS (in person-months)
    10. Total project Effort estimation
    11. Methods that used to estimate project costs
    12. Costs of project procurements
    13. Costs of additional and supplemental project activities
    14. Cost estimates for identified project risks
    15. Total cost estimation (in dollars)
    16. Problems that are founded through the project cost estimation
5.6. Project Plan Development and Schedule Governance 
It is extensively known that poor project planning plays a major role as one of the significant causes of project failure. Numerous methods and techniques have been developed over the years on various aspects of managing projects from initiation to completion. Despite efforts are done for IS projects planning, a significant number of projects still fail in one way or another through a propensity to run over budget, take longer to complete than was originally anticipated or fail to deliver on expectations in terms of quality, scope, safety or some other key stakeholder expectation (Hartman, and Ashrafi, 2004). It should be taken into consideration that well planned and documented development projects are more likely to result in systems that meet the expectations of both the intended users and the software engineers (Nasution and Weistroffer, 2009). 
Unfortunately, project managers, sometimes, don’t give the opportunity to project a plan because time pressure from senior management takes most of the time. In such cases, people see planning as a kind of wasting time because they believe that time is better spent doing something rather than planning (Taimour, 2005). Preproject planning is “the process of developing sufficient strategic information with which owners can address risk and decide to commit resources to maximize the chance for a successful project” it considers a key practice necessary for achieving excellent project performance (Wang and Gibson, 2010). 
The project plan is the backbone of the planning phase. It represents a road map to explain how the project will progress through all development phases and outlined its objectives, metrics, and milestones. It is a formal and approved document that guides project implementation (based on the project requirements and the established estimates), and used to manage and control its execution. The main purpose of project plan development is to create a useable, flexible, consistent, and logical document that will guide the work or the activities of the project. Also, it provides a control mechanism for coordinating changes across the entire project. 
5.6.1. Policy’s actions and principles to implement Project Plan Development and Schedule Governance
In the purpose of implementing the project Plan Development and Schedule governance according to the designed governance framework, it is very important to emphases on defining a clear policy with actions and principles to implement project Plan Development and Schedule governance and explain the main procedures, practices and techniques that are needed to verify the policy’s actions and principles. Table (5-29) explains the required procedures, practices and techniques for the policy’s actions and principles to implement the Plan Development and Schedule governance.
The policy is: Comprehensive and unambiguous project planning for all projects’ activities
 
Policy’s actions and principles for Plan Development and Schedule Governance
Procedures, Practices and Techniques to Verify Policy’s actions and principles
- Define the most favorable scenario to guarantee proper implementation of project Plan Development and Schedule
Determining well-defined procedures to execute the project Plan Development and Schedule
- Decrease IS projects’ failure which are derived from the project Plan Development and Schedule
Setting Best practices to reduce the failure within project Plan Development and Schedule
- Improve the performance of project Plan Development and Schedule
- Develop the “Project Plan Components Checklist” to verify the most technical components of the project plan are completely incorporated.
- Develop the “Schedule success factors Checklist” to guarantee a realistic schedule for the project activities progress against the overall project plan
- Enhance the best possible deliverables for IS projects 
Defining the best expected deliverables for project Plan Development and Schedule
Table (5-29) Policy’ actions and procedures of project Plan Development and Schedule
The project plan typically describes the work (that has to be done), the resources required, the methods has to be used, the procedures has to be followed, the schedules has to be met, and the way that the project will be organized. Governance can add a great value to the project plan and schedule through implementing the main components of governance which sustain and support verifying the main policies to govern the project plan development and schedule:-
    1. Well-defined procedures to execute the project plan development and schedule.
    2. Best practices to reduce the failure within the project plan development and schedule.
    3. Develop governance checklists to improve the performance of the project plan and schedule.
    4. Define the best expected deliverables for the project plan and schedule.
5.6.2. Well-defined procedures to execute the project plan development and schedule
One of the main critical success factors for IS project is to establish a well-developed project plan; it provides a roadmap for project managers to follow and it is considers the main guide throughout the project development (Larson, 2008). Building the project plan requires many project management skills and competences because it involves more details about all project development processes and scheduling. IEEE introduced standard for the project plan (IEEE Std 1058, 1998); it is considers the common framework, but it concentrates on the managerial processes more than technical aspects (IEEE, 1998). 
The following Well-defined procedures provide an integrated scenario to explain what the project plan must be contain in order to guarantee a reasonable extent of project planning. This scenario keeps the balance for both technical and managerial aspects; also, it’s supported by IEEE standard and the previous propositions of project planning (IEEE, 1998), (Larson, 2008), (PMI, 2008), (Calvo-Manzano et al, 2009), (Wang and Gibson, 2010).          
Procedure 1:  Describe the Project Outline
Project outline explains the main principles and data items of IS project such as:- 
    • Project name and the customer exposure
    • Main purpose for the project 
    • Main deliverables for the project
    • Name the project sponsor 
    • Expected period to achieve the project and its timeline
    • Main stakeholders
    • Define high level scope of the projects
    • Main project Constraints and exclusions  
Procedure 2:  Define the project organization with roles and responsibilities
Describe the project structure and its organization supported with explaining the main areas of responsibility. Graphical illustrations such as hierarchical organization charts or matrix diagrams are used to depict the lines of authority, responsibility, and communication within the project. Defining the project organization should include;
    • Identify all steering functions, project management functions, and execution functions. 
    • Identify the project manager who has the overall responsibility of the project. 
    • Describe the environment that the project is embedded in.
    • Identify external stakeholders that the project is dependent on and who are affected by the project result. 
    • Describe the internal project organization and all organizational issues 
    • Describe the administrative and managerial boundaries between the project and other parties such as: the parent organization, the customer organization, subcontracted organizations, and any other organizational entities that interact with the project
    • On the other hand, describing the project roles and responsibilities must include the roles of project manager, project team members, and the main stakeholders who will approve which parts of the plan satisfy project needs. Table (5-30) shows an example to define roles and responsibility for the project manager. 
Title of project member
Roles

Project Manager
The Project Manager ensures that the project is delivered on time, budget and to the required quality standard (within agreed specifications). He/she ensures the project is effectively resourced and manages relationships with a wide range of groups (including all project contributors).
The Project Manager is also responsible for managing the work of consultants, allocating and utilizing resources in an efficient manner and maintaining a co-operative, motivated and successful team.
Responsibilities
    • Managing and leading the project team.
    • Recruiting project staff and consultants.
    • Managing co-ordination of the partners and working groups engaged in project work.
    • Detailed project planning and control including:
    • Developing and maintaining a detailed project plan.
    • Managing project deliverables in line with the project plan.
    • Recording and managing project issues and escalating where necessary.
    • Resolving cross-functional issues at project level.
    • Managing project scope and change control and escalating issues where necessary.
    • Monitoring project progress and performance.
    • Providing status reports to the project sponsor.
    • Managing project training within the defined budget.
    • Liaises with, and updates progress to, project board/senior management.
    • Managing project evaluation and dissemination activities.
    • Managing consultancy input within the defined budget.
    • Final approval of the design specification.
    • Working closely with users to ensure the project meets business needs.
    • Definition and management of the User Acceptance Testing programs.
    • Identifying user training needs and devising and managing user training programs.
Table (5-30) Roles and Responsibility for the Project Manager
Also, define the project organization includes identifying the organizational units that are responsible for project processes and activities, some of the project’ key players are:-
    • Project sponsor, who owns and funds the entire project, Sponsors need to review and approve all aspects of the plan. 
    • Project manager, who creates, executes, and controls the project plan. Since project managers build the plan, they do not need to approve it. 
    • Project team, who build the end product. The team needs to participate in the development of many aspects of the plan, such as identifying risks, quality, and design issues, but the team does not usually approve it. 
    • End users, who use the end product. They too, need to participate in the development of the plan, and review the plan, but rarely do they actually need to sign off. 
    • Governance committee, which are responsible for governance all project activities 
    • Others parties, such as auditors, quality and risk analysts, procurement specialists, and so on may also participate on the project.
Procedure 3: Define the Project Goals and objectives
Unclear project goals and objectives also change the project objectives during the project as key factors in project failures (Taimour, 2005). A project manager should understand the compromise between what they want to accomplish and what they are actually able to deliver. When goals exceed the ability to deliver timely results, the project will surely fail. Successful projects always have a well defined scope that states realistic goals, attainable objectives, establish clear milestones, define benefits and deliverables, and conduct regular technical reviews and measurements (INTOSAI, 2008). 
Goals and objectives describe what the project is striving to accomplish. Goals depict the general programmatic outcomes, while objectives specify more specific outcomes. It is common to have several objectives for each project goal. The project goals define the expected project results together with the required development constraints. It can be extracted from the project proposal, project feasibility study and the project requirements elicitation. 
Several categories of IS projects’ goals must be well defined such as functional and nonfunctional goals, strategic goals, business goals, technological goals, quality goals, and the organizational goals (e.g. competence development, testing of new methods, techniques, and application of new processes.). It should perceive that the project goals are general guidelines that explain what the project must achieve and deliver. However, project objectives define main strategies or implementation procedures to attain the identified goals, specific objectives, measurable, and have a defined completion date. 
Procedure 4:  Develop the Project Charter
A project charter is the process of developing a document that formally authorized a project and documenting initial requirements that satisfy the project stakeholders’ needs and expectations (PMI, 2008). It is a simple signed agreement between a project team and a representative for those who will use the output (customer). A charter forces the project team and champion to develop a common understanding about the project and creates enough visibility that if a project approach isn’t effective, the project can be cancelled before it progresses any further (Tesch et al, 2007). 
The primary purpose of the project charter is to give the project manager the authority to initiate the project, also documents the project’s mission, history, and background, describes the business problem the project is intended to resolve, and lists the benefits to be realized by the performing organization as a result of implementing the product or service. The project charter usually is short not more than three pages and often only one page long. The format varies from organization to another, but generally it contains a brief scope statement describing the project, how the project supports the strategic goals of the organization, who the project manager is, and finally, if possible, the project’s priority within the company. 
A good project charter should include clear objectives and measurable goals, as well as important assumptions and constraints to guide the project. The lack of a clear project charter increases uncertainty (lack of information), ambiguity (the absence of clarity), and the confusion in a project (Mahring and Keil, 2008). Therefore, developing the project charter is a collaborative effort. Project Charter can include the following information:-  
    • Project purpose (scope statement)
    • Project establishment (business reasons for the project and how it can support the organization's strategies and goals)
    • Project manager designation and authority (name of project manager with providing the range and limit of his authority)
    • Project team organization (describes where the project team is within the organizational hierarchy)
    • Project manager's reporting chain
    • Project organization and structure
    • Project team composition
    • Support organizations and support requirements (describes which functional groups are required to support the project)
    • Communication requirements and reports 
Procedure 5:  Organize a kickoff meeting. 
When the project charter is complete, Kick-off Meeting should take place. It is the event that formally marks the beginning of the project and most likely the first opportunity for the sponsor to assemble the entire project team to discuss their visions for the project, demonstrate support, and advocate project success. Project Team members are introduced to each other and given the opportunity to discuss their areas of expertise and how they will contribute to the project. Kickoff meeting is an effective way to bring stakeholders together to discuss the project and initiate the planning process. It can be used to start building trust among the team members and ensure that everyone's idea is taken into consideration. Kickoff meetings also demonstrate commitment from the sponsor for the project. The following are some topics that can be included in a kickoff meeting:
    • Business vision and strategy (from sponsor) 
    • Project vision (from sponsor) 
    • Roles and responsibilities 
    • Team building 
    • Team commitments 
    • How team makes decisions 
    • Ground rules 
    • How large the group should be and whether sub-groups are necessary 
At the conclusion of the meeting, project team members will understand their “next steps,” and will leave the meeting ready and excited to begin project activities.
Procedure 6: Develop the project Scope Statement. 
Defining the Project scope is the process by which projects are defined and prepared for execution. When developing IS projects, the project scope definition is more significant because poor definition can lead to numerous requirement changes and scope creep (Zhang et al, 2003). Also, unclear and incomplete objectives have been shown to contribute to the perception of project failure (Barclay and Osei-Bryson, 2010). Project scope is very much driven by three major factors; project size, project duration and project key interdependencies. It documents the project assumptions, constraints, user expectations, business requirements, technical requirements, and project deliverables. Project Management Institute (PMI) represented the main features to define the project scope (PMI, 2008) that are:-
    • Project justification: the project justification encapsulates the business need for undertaking the project while providing a basis for future trade-offs.
    • Project product: the project product section summarizes the product description which is a compilation of characteristics of product or service to be created upon completion of the project.
    • Project deliverables: Project deliverables refer to a list of finished products to be delivered by the service provider, EPC or contractor upon full implementation and execution of the project.
    • Project objectives: The project objectives define quantifiable criteria that must be met for the project to be considered successfully completed.
The scope should be clearly defined because it will form the baseline against which potential changes are assessed and against which the project’s performance is measured. The concept of well-defined scope is affected by many factors, for example, the goal of the project may be partially clear because of poor requirements gathering in the definition stage of project, goals and objectives might be unclear because project users lack the experience to describe what they really require (INTOSAI, 2008). 
Project Scope Statement is the main deliverable for the project scope definition; it clearly describes what the outcome of the project will be. It is the basis for agreement between the sponsor and other stakeholders and decreases the chances of miscommunication. This document can include the following issues:
    • Business need and business problem 
    • Project objectives, stating what will occur within the project to solve the business problem 
    • What the project will accomplish with a list of project deliverables.
    • Benefits of completing the project, as well as the project justification 
    • Project scope, stated as which deliverables will be included and excluded. 
    • Explain the main project boundaries.
    • Key milestones, the approach, and other components as dictated by the size and nature of the project. 
    • Describe the relationship of this project to other projects and how this project will be integrated with other projects.
Procedure 7: Develop work breakdown structure (WBS) 
Work breakdown structure (WBS) is the process of breaking down the project into manageable chunks that can be effectively estimated and supervised; it can organize and define the total work scope of the project (Scasso and Larenas, 1991). Once the project goals and scope are defined and the deliverables are confirmed in the Scope Statement, Work Breakdown Structure should be established through decomposing the project into work units or work packages. Decomposing the project into some controllable parts that is in lower level and have more specific resource and characteristic can facilitate efficiently management the entire IS project and reflecting the technical, organizational, resource relations and work flow (Feng et al, 2009). WBS composes the project scope baseline through the following fundamentals:
    • Identifies all deliverables that are produced on the project, and therefore, identifies all the work that has to be done. 
    • Takes large deliverables and breaks them into a hierarchy of smaller sections, where each section starts at a high level and is broken into subsequently lower levels of detail. 
    • The lowest level is called a "work package" and can be numbered to correspond to activities and tasks. 
WBS is the primary tool for managing the scope of the project. This simply means if the work is included within WBS, this means it will be considered within the project scope. On the other hand, if work is not contained within WBS, this means “out of scope” and should not be included in the project’s end product. Using the information from WBS as input is the beginning to document effort estimates, roles and dependencies in preparation for creating a project schedule using a project management tool. Also, WBS is the base for IS project objective control; WBS Structure can well and truly ensure the functional targets and controllable targets such as cost, schedule and quality for Work Units or Work Packages (Feng et al, 2009). Fig. (5-xx) represents an example illustrates how to build WBS through decomposing the project into their work units or work packages represent the main activities and functions for the project life cycle. 


 
Fig. (5-8) Building WBS for the main activities and functions of project life cycle
Procedure 8: Define Activity specifications and planning the Staff
Project activities specifications include project activities identification, activity sequence, activity resources, activity duration and staff planning. After work breakdown structure is established, the project activities are specified. Activities identification is the process of identifying the specific actions to be performed to achieve the project. Activities sequence is the process of identifying the relationships between the project activities. Estimate Activities resources include the quantities of materials, people, and equipments that are required to fulfill each activity. Activities duration determines approximately the needed work periods to complete each activity according to the available project resources (PMI, 2008).        
Planning the project Staff means specify the number of required staff, providing number of personnel by skill level, numbers and skill levels in each project phase, and duration of personnel requirement. Also, Specifying the sources of staff personnel (e.g. internal transfer, new hire, contracted, etc.) and consider using resource Gantt charts, resource histograms, spreadsheets and tables to depict the staffing plan by skill level, by project phase, and by aggregations of skill levels and project phases. Also, specifying the training needed to ensure that necessary skill levels in sufficient numbers are available to successfully conduct the project. Identifying training as needed in technical, managerial and supporting activity skills.
Procedure 9: Planning the Project Risks Management.
Project Risks are events that may or may not happen, but could have a significant effect on the outcome of a project, if it were to occur. For example, there may be a 40% chance of a significant change in sponsorship in the next few months. Risk management is the process of identifying and controlling any activity or event that can negatively influence the projects’ success, whereby risks are all issues that may affect the delivery of benefits to be gained from the IS projects (Elkington and Smallman, 2002). Risk management includes not just assessing the risk, but developing risk management plans to understand and communicate how the team will respond to the high-risk events. 
Risk Management Planning is the initial phase of the risk management process deciding how to approach plan and execute risk management activities for a project, thus ensures that project objectives are clearly stated and understood, focuses the risk process around the specific requirements of the particular project, and documenting the results in a risk management plan. Moreover, analyzing risks includes making a determination of both the probability that a specific risk may occur and if it does, assessing its impact. Estimating of both the probability and impact will lead to determining risks priorities. 
Procedure 10: Planning the project Cost Estimation and Budgeting
Project cost estimation is the process of predicting the amount of effort required to build a software system. (Li et al, 2008). It refers to the prediction of the likely amount of effort, staffing level, time, and materials necessary to accomplish the required development activities at an early stage of a project’s life cycle. Effort prediction of software cost estimation is concerned with the prediction of the person-hour required to accomplish the project activities. It is a recurring process in which the quality of outputs is heavily dependent on the quality of inputs. Estimates of a project’s budget, resources, and schedule which represent the outputs need to be updated periodically as more and more information about a project’s cost-drivers which represent the inputs (Malik and Boehm, 2011). Based on the Cost Estimation and Budget, the following issues are done for the project.
    • Review the main project’ activities and tasks 
    • Identify resources for each task, if known. 
    • Estimate the size of all project activities in source line of code (SLOC) according to WBS 
    • Estimate cost of each task, using an average hourly rate for each resource. 
    • Estimate the additional efforts per month for the supplemental project activities
    • Identify the software project risks and Assess risks impact on the cost estimation
    • Consider resource constraints, or how much time each resource can realistically devoted to this project. 
    • Determine which tasks are dependent on other tasks, and develop critical path. 
    • Develop the cost baseline, which is a time-phased budget, or cost by time period. 
    • Identify project cost estimation outputs.
Project Budget, calculates the preliminary budget that will be required to complete project activities. All aspects of the project, including the cost of human resources, equipment, travel, materials and supplies, should be incorporated. At this point, information will be presented at a summary level to be refined during Project Planning. Cost estimating checklists can help to ensure that all preliminary budgeting information is known and all bases are covered. 
Procedure 11: Develop Project Schedule and timelines 
Project Scheduling is one of the most important tasks of project planning. In very large projects, it is possible that several teams work on developing the project; they may work on it in parallel. However, their work may be interdependent. The time schedule for the project can be arrived at based on the activities, interdependence and effort required for each of them. The schedule may influence the cost estimates, the cost benefit analysis and so on. Scheduling and sequencing are concerned with the optimal allocation of scarce resources to activities over time; main project scheduling problem involves the scheduling of project activities subject to precedence and/or resource constraints (Herroelen, 2005), project schedule should include:-
    • Identifying all the resources that will be necessary to the project and select them in a way that they will be available to perform the projects activities
    • Estimating time and resources required for project tasks and activities to complete each task
    • Organizing tasks concurrently to make optimal use of workforce
    • Minimizing task dependencies to avoid delays caused by one task waiting for another to complete
The conventional Program Evaluation and Review Technique (PERT) and Critical Path Methods (CPM) are very common and widely adopted management tools being used in project schedule (Omar, 2009). 
Procedure 12: Establish the Project Repository
Project repository is a very important component; it provides an audit trail documenting for the history and evolution of the project. All relevant project-related material, documents produced, decisions made, issues raised and correspondence exchanged must be captured for future reference and historical tracking. The project repository can be kept as hard copy in a binder or notebook, or as electronic files and email folders, or both at the discretion of the project manager in accordance with organizational records management policies. 
All files related to the project should be grouped by categories within project-specific folders. The structure should be intuitive so that anyone browsing the directory can easily locate needed information. Within the primary hard copy repository, information should be organized in indexed volume to enable easy access. An index should provide reference to all material maintained electronically (e.g., a file directory or email folder by drive, directory, and filename). The most current hard copy of documentation should be kept in the primary hard copy repository with earlier versions in the electronic file. At the end of the project, a project repository may include the following materials:
    • Project Proposal and supporting documentation, including the business case
    • Project description, definition, documents such as project charter, and project plan
    • Any working documents or informal documents defining Cost, Scope, Schedule and Quality of the project
    • Project Schedules (baseline and current)
    • Project financials
    • Project Scope changes and requests log
    • Project Status Reports
    • Team member progress reports and timesheets
    • Project acceptance log by deliverable
    • Risk identification and model documentation
    • Correspondence, including any crucial or decision-making, letters, email…etc.
    • Kick off Meeting notes, results, and actions
The project repository should be available to everyone involved in the project and must be considered “public information”. It is not advisable to keep sensitive information concerning individuals on the project such as salaries or evaluations in the project repository. However, a confidential project repository should be established in a separate location to secure sensitive information.
Procedure 13: Setting reviews at the end of each phase
In the case of software project is impacted by its delivery date and it doesn’t have enough time to review at the end of each phase, this increases the incidence of project failure in high percentage. Therefore, a formal review should be held at the end of each phase of IS project to gain consensus that the intended phase is done completely and accurately. The review at the end of each phase determines whether or not the project has met the objectives that were set; it helps to document the project outcome and provides an indicator to come to the next phase or to modify the current phase according to the feedback. For this purpose, the main objectives of project’s phase review are:
    • Verify that the phase objectives have been met
    • Evaluate the performance of doing project’s phase in terms of (the schedule been met, the required scope been delivered and the planned costs equal actual costs)
    • Verify that budget allocated was sufficient at this point
    • Confirm that deliverables have been produced and approved
    • Risks have been controlled and mitigated
    • Changes were properly managed
    • Identify process improvements
Procedure 14: Define the project Communications 
Lack of proper communication is one of the major reasons for the failure of many projects to meet their expectations, so Communication skills are crucial to the successful completion of IS projects. It includes the ability to interact with all potential stakeholders and the project’s team members. Managing the project communications refers to the processes for planning, information distribution, performance reporting and administrative closure, together with the social and integrative characteristics of communication which link people, ideas and necessary information for project success (Muller, 2003). 
 The communications plan is the core of communication process; it’s a document describing the means by which project communications will occur. It should be developed early in the project lifecycle and reviewed regularly throughout the route of the project and updated as necessary to ensure it remains current and applicable. Understanding the communication process is the first step in communication plan with considering the following factors; 
    • Who is involved in the communication process, the identified stakeholders, such as project team members, project management and staff, customer management, and external stakeholders. 
    • What is being communicated the message and the information being communicated. 
    • When the information is communicated weekly, monthly, quarterly, as needed, or as identified. 
    • Who will provide the information being communicated
    • How the information is distributed, in a meeting, a memorandum, an email, a newsletter, a presentation, etc. 
Procedure 15: Determine project quality specifications
Project quality is the process of identifying quality requirements and standards for the end product of the project (PMI, 2008). It consists of ensuring that the end product not only meets the customer specifications but also is one that the sponsor and key business experts actually want to use. The emphasis on project quality is on preventing errors rather than inspecting the product at the end of the project and then eliminating errors. Project quality also recognizes that quality is a management responsibility and needs to be performed throughout the project. Creating the quality plan involves setting the standards, acceptance criteria, and metrics that will be used throughout the project. It becomes the foundation for all the quality reviews and inspections performed during the project and used throughout the project execution.
Procedure 16:  Specify Change and Configuration Management: 
In fact, a configuration management system with integrated change control provides a standardized, effective, and efficient way to centrally manage approved changes and baselines within the project (PMI, 2008). Configuration Management ensures that project’ functional, performance, and physical characteristics are properly identified, documented, validated, and verified; also, changes in these project characteristics are properly identified, reviewed, approved, documented, and implemented. Configuration Management consists of four basic functions:
    • Identification, specifying and identifying all components of the final product
    • Control, the ability to agree and ‘freeze’ configuration items and then to make changes only with the agreement of appropriate named authorities. Once a product has been approved, the motto is ‘Nothing moves, nothing changes without authorization’
    • Status accounting, the recording and reporting of all current and historical data concerned with each configuration item
    • Verification, a series of reviews and audits to ensure that there is conformity between the project’s products and the authorized state of configuration items as registered in the Configuration Management records.
Change Management is also necessary to accommodate the implementation of the project currently under development. Overall change controls must: (1) ensure that a process is in place to evaluate the value of a proposed change, (2) determine whether an accepted change has been implemented, (3) include procedures for handling emergencies, and (4) help the project manager managing change so that change does not disrupt the focus or work of the project team.
5.6.3. Best practices to reduce the failure within the project plan development and schedule 
A set of best practices should be taken into consideration during establishing the project plan and schedule as guidance to reduce the problems that cause the project failure. These practices are based on a set of instructions and critical success factors that must be considered during the project development. They encompass the most lessons learned of the previous successful projects. Also, the best practices of CMMI for systems and software development in the area of project plan are merged here (CMMI, 2001), (CMMI, 2010). So, Projects’ managers can position themselves to reduce the possibility for project failure by considering and applied the following practices;
    1- Plan for necessary resources, knowledge and skills needed to perform the project
    2- Plan and manage the involvement of identified stakeholders
    3- Review all plans that affect the project to understand project commitments
    4- Reconcile the project plan to reflect available and estimated resources
    5- Monitor and control the project planning process against the plan for performing the process and take appropriate corrective action
    6- Actual performance and progress of the project are monitored against the project plan
    7- Integrate the project plan and the other plans that affect the project to describe the project’s defined process
    8- Incorporate into the project plan the definitions of measures and measurement activities for managing the project
    9- Define and document measurable quality and process performance objectives for the project and Establish traceability to the project’s quality
    10- Define clear objectives and goals for the project earlier.
    11- Rectify the imprecise and ambiguous components of the project plan 
    12- Eliminate the Lack of Resources & inadequate staff to meet the schedule
    13- Encourage and sustain the competencies of project planners (skill/experience) 
    14- Prepare good plan to organize kickoff meeting 
    15- At all times manage the project according to the project plan
    16- Define completely the project roles and responsibilities 
    17- Avoid Unrealistic schedules and deadlines 
    18- Project changes should be managed efficiently  
    19- Activate the role of configuration management and control procedures 
    20- Establish well-define test planning 
    21- Make reviews at the end of each phase 
    22- Establish Contingency plan to handle problems that appear during the project development 
    23- Set effective internal communication 
    24- Give more interest for tasks in the critical path.
    25- Depending on appropriate planning, communication, and technology skills.
    26- Confirm to establish accurate estimating of project durations to create realistic schedule
    27- Minimizing task dependencies to avoid delays caused by one task waiting for another task to complete
    28- Review the structure of WBS according to the project scope statement
    29- Define correct assumptions regarding resource availability 
    30- Establish review and approval activities within the project
    31- Consider and organize the interdependencies between tasks 
    32- Beware that the delivery date impact the project schedule 
5.6.4. Suggested Checklists to improve the performance of project plan development and schedule 
In the course of examining the failure reasons that are related to the project plan development and schedule, it is found that, the imprecise construction of the project plan and unrealistic schedules and deadlines are the main failure reasons. Therefore, “Project Plan Components Checklist” to verify the most technical components of the project plan are incorporated completely, and “Project Schedule Success Factors Checklist” to guarantee a realistic schedule for the project activities progress against the overall project plan. These are the appropriate Checklists to improve the performance of project plan development and schedule. 
6.5.4.1. Project Plan Components Checklist
The project plan is a road map to explain how the project will progress through all development phases and outlined its objectives, and milestones. It should encompass many technical components to guarantee a complete and accurate project plan is developed. According to the main procedures of executing the project plan, the following checklist in table (5-31) represents the main Technical Actions for the project plan development. 
procedures
Technical Actions for the project plan
Yes
No
Describe the project outlines
Define the main purpose and deliverable for the project



Describe the internal structure of the project organization



Produce an organizational chart for the project



Define the project high level scope 


Define project roles and responsibilities
Identify the project manager 



Identify the project sponsor



Assign the project team member 



Identify all functional responsibilities for all project’s members 



Identify the customer representative



Plan stakeholder involvement 


Define the project goals and objectives
Define the project’s goals and objectives 



List the project assumptions and constraints



Define the  business goals 



Document and refine the project’s goals and objectives  


Develop the project charter
Write the project charter 



Review the project charter according to project’s goals and 



responsibility 


Organize a kickoff meeting
Schedule time and location of kickoff meeting



Conduct kickoff meeting 



Review and analyze kickoff meeting


Develop the project Scope Statement
Define the project’s scope and limitations 



Write the project scope 



Review the project scope statement 



Describe the organizational boundaries between the project and external entities



Define the project deliverables 



Set project scope, cost, and schedule baselines for progress



Assure that project’ s scope is estimated clearly


Develop work breakdown structure (WBS)
Use organizational charts and diagrams to depict the project's WBS



Decompose the project into clear sub-systems 



Design Work Breakdown structure (WBS)


Establish the project repository
Plan for data management



Define the project documentation 



Review the project repository 



Update repository with current data 


Define activity specifications and planning the Staff
Assigning and leveling project resources



Plan for project resources



Plan for needed knowledge and skills



Identify the required staff   



Clarify all types of project’s resources


Planning the project risks management
Define project risks and identify actions to mitigate them



Define Contingency plans to handle the expected problems



Define the risk response strategy 



Describe the Contingencies for dealing with risks 



Assign the impact of the identified risks  



Assure that risk management plan is completed


Planning project cost estimation and budgeting
Construct a list of activities and cost components



Estimate efforts and costs of all resource



Assure that project Cost Estimates and Budget have been estimated according to WBS



Estimate project’s task duration 



Align the budget and schedule to the client requirements



Assure that all project’s activities are decomposed to an individual effort estimate



Estimate resource requirements, hardware/additional software costs 



Establish the project budget 


Planning the project schedule
Preparing a schedule and milestones



Establishing dependencies between activities



Building Gantt chart 



complete the Functional Schedule Critical Path Analysis 



Establish the project schedule


Define the project communications
Planning for communications



Define who is involved in the communication process



Define the optimal tool to communicate with stakeholders



Define communication requirements



Write the communication plan



Define various types of reports, their contents, frequency, and the communication methods of the project team


Setting reviews at the end of each phase
Define monitoring and reporting mechanisms



Define project’s milestones 



Define the performance evaluation rules and test plan



Verify that the phase objectives have been met



Determine the best deliverables for each phase 



Assure that changes were properly managed and controlled 


Determine project quality specifications
Setting standards, acceptance criteria, and metrics that will be used 



throughout the project to achieve the required quality 



Identify how the project’s quality will be managed



Assure that metrics are sufficient to assess the quality of software project



Define the quality assurance plan 



Create the quality plan for the intended project


Specify Change and Configuration Management
Define the change control process and its principles



Constitute the Change Management Board to manage the changes 



Assure that project  plan is established under configuration management



Assign the functions of Configuration Management 


Table (5-31) Main technical actions of the project plan development for IS projects 
5.6. 4.2. Project Schedule Success Factors Checklist
Project schedule is project management tool that used to measure progress against the overall project plan; it is a basic parameter of software project management which has a direct impact on the success or failure of any project. It is a calendarization of all project’s tasks and estimates (Zhang, 2008). The main objectives of project scheduling are; completing the project as early as possible by determining the earliest start and finish of each activity, calculating the likelihood a project will be completed within a certain time period, and finding the minimum cost schedule needed to complete the project by a certain date.  So, “Project Schedule Success Factors Checklist” can guarantee a realistic schedule for the project activities progress against the overall project plan. Schedule success factors checklist at table (5-32) represents a guide to execute accurate and realistic schedule for IS projects.
No
Schedule Critical Success Factors
Yes
No
1
Schedule the tasks in a sequence that accounts for critical development factors and project risks


2
Emphases on WBS is designed accurately and in accordance with the schedule activities 


3
Confirm that project’s efforts are estimated accurately and completely 


4
Efforts are calculated by the measure of Person /Month


5
Review schedule dependencies and look for opportunities to overlap tasks or make serial tasks concurrent or parallel activities 


6
Confirm that minimize dependencies and maximize parallelism are consistent with a reasonable level of risk


7
Identify and evaluate alternative strategies to minimize or avoid the time intensive and difficult tasks 


8
Identify task dependencies, involves the identification of predecessor and successor tasks to determine the optimal ordering


9
Emphases on task duration is properly estimated 


10
Project’s activities sequences is ordered accurately  


11
Identify the resources needed to complete the project clearly    


12
Depend on experienced people to implement the schedule 


13
Establish Timeline and Sequences of tasks


14
Taking into account the project staff and resources situation of different stages


15
Eliminate users’ new requirements which may lead schedule to delay


16
Eliminate the resources changing all the time to stop cause a delay in certain tasks.


17
Specify the methods and tools that will be used to measure and control schedule progress


18
Specify the schedule control activities to measure the progress of work completed at the major and minor project milestones


19
Specify the schedule control activities to compare actual progress to planned progress


20
Specify the schedule control activities to implement corrective action when actual progress does not conform to planned progress


21
The schedule must be constantly updated


22
The remaining effort must be appropriately distributed among team members 


23
Review the project scope and remove or delay features or functionality from the project critical path


24
Consider innovative approaches such as different development methodology, alternative technologies, or out-sourcing options.


25
Depend on PERT for complex projects to explain the interdependency 


26
Gantt is suitable to use for small and medium projects 


27
Consider the availability of both labor and non-labor resources    


28
Documentation of assumptions must be existed before the schedule start


29
Add additional time to tasks where risks are inherent 


30
Control the schedule by identifying, monitoring and influencing factors that cause schedule change  


31
Specify the budget control activities to measure the cost of work completed


32
Identify the schedule milestones and objective to assess the work completed at those milestones.


33
Make the schedules easy to read, simple, straightforward and uncluttered to produce clarity rather than confusion


34
Schedule should include allowance for statutory holidays and vacation time


35
Schedule should include elapsed time for deliverable review and turnaround


36
Appropriate schedule contingency must be existed around the critical points (e.g., major milestones, customer dependencies, subcontractor dependencies, resource start dates, acceptance periods, customer decision points)


37
Consideration should be given to transferring resources from non-critical activities to activities on or near the critical path to shorten the duration of critical activities


38
Schedule should eliminate deliverables or activities that can be omitted or combined without endanger the project


39
Assure that dependencies are appropriately addressed


40
Identify schedule constraints that limit the flexibility as early as possible. 


41
Depend on schedule techniques such as Critical Path Method (CPM), Program Evaluation and Review Technique (PERT), and Resource-limited scheduling


42
Define activities of appropriate duration


43
Use appropriate historical data to verify the schedule


44
Schedule of activities should based on a realistic start date 


45
Resources/skills must available in sufficient quantities when it needed


46
Schedule should allow adjusting the timing and allocation of activities to spread the load evenly


47
Initiate and recommend schedule corrective actions when needed


48
Recording, reporting, and incorporating changes in the project control schedule


49
Understand the methods for managing schedule contingency


Table (5-32) Main schedule critical success factors
5.6.5. The expected deliverables for the project plan development and schedule 
Developing the project plan introduces more deliverables because it exposes to most project development activities; also it depicts the road map of project development life cycle. Detailed project plan is the main deliverable at the end of planning phase accompanied by a set of sub-plans such as communication plan, quality plan and risk management plan. In fact, there is no standard form for the detailed project plan, but in most cases, the project plan should encompass the following specific procrsses: (PMI, 2008), (Calvo-Manzano et al, 2009)
    • Document the assumptions, constraints, and alternatives
    • Set project scope, cost, and schedule baselines for progress measurement and control
    • Establish project milestones and deliverables
    • Establish the budget and schedule.
    • Identified project risks.
    • Plan for data management.
    • Plan for project resources.
    • Identify functional responsibilities.
    • Work Breakdown structure (WBS)
    • Plan for needed knowledge and skills.
    • Plan stakeholder involvement and project organisation
    • Guide the execution of the project
    • Provide a tool to communicate with stakeholders
    • Establish project milestones and deliverables
    • Monitoring and reporting mechanisms
Also, many technical components must be founded at any project plan; Fig. (5-9) explains the most common technical components of the detailed project plan. In addition to, there are sub-plans must be completed at the end of the planning phase; these plans represent the main outlines of IS project’s functions which are, 
    1. Quality Plan
    2. Risk management plan 
    3. Communication Plan
    4. Logistics plan
    5. Quality Assurance Plan 
    6. Kick-off Meeting plan
    7. Project schedule plan
    8. Project resource plan
    9. Contingency Plan
    10. Delivery Plan
    11. Installation Plan
    12. Test Plan
    13. Support Plan
    14. Training Plan
    15. Configuration Management Plan


























Fig.(5-9) Common components of the project plan development 
After conducting governance for the main pre-development activities according to the designed governance framework; figures (5-10) to (5-15) explain the charts which describe the main procedures and process of the conceptual governance framework in details; 













Fig. (5-10) Conceptual Governance framework for the main pre-development activities 

Fig. (5-11) Project Feasibility Study Governance

Fig. (5-12) Project Requirement Elicitation Governance

Fig. (5-13) Risk Management Governance

Fig. (5-14) Cost Estimation Governance

Fig. (5-15) Project plan development and schedule Governance










Chapter (6) 
Results and Discussions


















Chapter (6) Results and Discussions
6-1.Introduction:
The main objective of this chapter is to represent and clarify the main results of this research which contains the results of examining to what extent the governance framework components are applied for IS projects in local environment also, verifying the reliability and capability of the this framework to decrease the failures of IS projects. For this purpose an empirical study is implemented through designing two research questionnaires which are applied to variety of IS projects in the Egyptian software companies. The two research questionnaires examine the effectiveness of the governance components as an encapsulated component to reduce the failure reasons of IS projects; whereas the main governance components that have been adopted in this research are:-
    • Governance Policies which contains a set of actions and principles  
    • Well-defined procedures to execute the pre-development activities. 
    • Best practices to reduce the failure within the pre-development activities.
    • Suggested practices and Checklists to improve the performance of the pre-development activities.
    • Define the expected deliverables for the pre-development activities.
In addition to, this research examines a variety of significant issues of IS projects such as, investigating the main pre-development activities which have a great influence to cause IS projects’ failure in local environment, the importance of the pre-development activities to enhance IS project success, estimating the impact of risk factors of IS projects, checking the most common techniques of requirement elicitation and determining the top five pre-development activities which cause the projects’ failure in the Egyptian environment. Eventually, this research demonstrates lots of important findings which are deduced and extracted from the theoretical study in this research.     
6.2. Examine to what extent the governance framework components are applied 
In the purpose of verifying the application extent of the designed governance framework components through developing IS projects in the Egyptian software companies. A research questionnaire contains five groups of governance components is designed and introduced to the project managers of the common software companies in Egypt. Project managers were asked to give objective responses according to the followed procedures and practices that are used in their organizations to develop IS projects. The responses analysis based on Frequencies Analysis appears that, the application of all governance components of the targeted framework is not exceed than 31% in total average at the software companies in local environment which explains the need for the governance framework to enhance and sustain IS projects’ success. Low percentages of the applied governance components for IS projects in local environment are illustrated clearly in   Table (6-1) and Fig. (6-1).  


                             Pre-development
Governance              activities
Components
Feasibility Study
Requirements Elicitation
Risk Management
Cost Estimation
Project Plan and Schedule
Total Average
Policies
24%
26%
15%
18%
45%
26%
procedures
37%
35%
32%
40%
48%
38%
Best practices
25%
33%
25%
36%
34%
31%
Suggested  practices
17%
10%
12%
13%
28%
16%
Expected deliverables
46%
44%
32%
49%
43%
43%
Table (6-1) the average of the applied governance components in local environment

Fig. (6-1) the percentages of the applied governance components in local environment
6.3. Examine the Reliability of the Governance Framework 
In the purpose of examining the reliability of the governance framework to decrease the failures of IS projects, a research questionnaire is designed and introduced through the interviews to the project managers of the common software companies in Egypt. Project managers were asked to give objective responses to a series of questions covering the relationship between the governance framework as an encapsulated components and the main failure reasons of IS projects. The analysis of responses depends on the Likert Scales to measure the acceptance degree of responses, Frequencies Analysis, and calculating the Measures of Central Tendency such as (Arithmetic mean, Weighted mean, Geomean, Median, Mode and the Skewness which represent the relation between mode, mean and the median). The responses analysis revealed a number of significant results that can be showed as follow:-
6.3.1. Examine the Application of “Governance Framework” to the failures of Project Feasibility Study
Project managers were asked to answer twelve questions examine the ability of the governance framework to decrease the main failure reasons in the area of project feasibility study as showing in table (6-2). According to the Likert scales and the frequencies analysis, the general average of responses for the twelve questions is %80.0, this indicates to the responses agreement for the ability of the purposed framework to decrease the failure reasons that are related to the project feasibility study, the following tables and figures illustrate and support this result. Also, the average of the Standard deviation for all values equal 0.9, this confirms the harmony and the consistency of responses. Table (6-3) illustrates the general percentages for each question, Standard deviation for the answers and the general average of all responses which equal %80.0.  
symbol
Main failure reasons related to project feasibility study
F1
Underestimating the gap between technology and ability
F2
Inability to provide investment capital  
F3
Misusing of financial resources and weak financial management 
F4
Long payback period for the cost of capital investments 
F5
Development cost exceeds any benefits that system may bring throughout its useful life
F6
Inconsistency between the organization's business needs and the Information System functionalities 
F7
Usage of inappropriate technology (immature, new, …….tech) 
F8
Losing control of the project resources
F9
Low IS project viability and priority 
F10
Ignoring intangible benefits and costs 
F11
Inability  to achieve the desired benefits and critical services 
F12
Ignoring one or more types of feasibility studies (technical, operational, legal, economical, and schedule)
Table (6-2) Main failure reasons related to project feasibility study
Questions
Strongly Agree
Agree
N/A
Disagree
Strongly disagree
Degree
Average
Standard deviation
General Percentage
F1
5
6
2
3
0
61
3.81
1.11
%76.3
F2
6
4
4
2
0
62
3.88
1.90
%77.5
F3
5
8
2
1
0
65
4.06
0.85
%81.3
F4
4
7
3
2
0
61
3.81
0.98
%76.3
F5
7
7
1
0
0
66
4.13
0.63
%82.5
F6
5
9
1
1
0
66
4.13
0.81
%82.5
F7
5
9
1
1
0
66
4.13
0.81
%82.5
F8
3
8
3
2
0
60
3.75
0.93
%75.0
F9
5
8
2
1
0
65
4.06
0.85
%81.3
F10
5
7
2
2
0
63
3.94
1.00
%78.8
F11
5
7
2
2
0
63
3.94
1.00
%78.8
F12
9
6
0
1
0
71
4.44
0.81
%88.8
Geomean






4.00
0.9
%80.0
Table (6-3) General percentages for each question of project feasibility study 
Also, table (6-4) illustrates the main statistics and the measure of Central Tendency for all responses to the twelve questions of feasibility study governance. 
Feasibility Study Governance Statistics


F1
F2
F3
F4
F5
F6
F7
F8
F9
F10
F11
F12
Mean
3.81
3.88
4.06
3.81
4.38
4.13
4.13
3.75
4.06
3.94
3.94
4.44
Median
4.00
4.00
4.00
4.00
4.00
4.00
4.00
4.00
4.00
4.00
4.00
5.00
Mode
4
5
4
4
4
4
4
4
4
4
4
5
Std. Deviation
1.109
1.088
.854
.981
.619
.806
.806
.931
.854
.998
.998
.814
Skewness
-.588
-.433
-.863
-.547
-.421
-1.118
-1.118
-.567
-.863
-.782
-.782
-1.891
Sum
61
62
65
61
70
66
66
60
65
63
63
71
Table (6-4) statistics and the measure of Central Tendency for project feasibility study governance
In addition to, Fig. (6-2) depicts a chart to illustrate the average percentages of all responses which indicates to the ability of the governance framework to decrease the defects and the failures of project feasibility study.   

Fig. (6-2) the average percentages of all responses of feasibility study governance
6.3.2. Examine the Application of “Governance Framework” to the failures of Project Requirement Elicitation
Project managers were asked to answer eleven questions examine the ability of the governance framework to decrease the main failure reasons in the area of project requirement elicitation as showing in table (6-5). According to the Likert scales and the frequencies analysis, the general average of responses for the eleven questions is %78.1, this indicates to the relative responses agreement for the ability of the purposed framework to eliminate the failure reasons that are related to the project requirement elicitation, the following tables and figures illustrate and support this result. Also, the average of the Standard deviation for all values equal 1.00, this confirms the harmony and the consistency of responses. Tables (6-6) illustrates the general percentages for each question, Standard deviation for the answers and the general average of all responses which equal %78.1.

Symbol
Main failure reasons related to Project Requirements Elicitation
RE1
Misunderstanding of user requirements and real customer needs 
RE2
Lack of user involvement 
RE3
Changing requirements during the project’ development phases 
RE4
Customer / Users had unrealistic expectations 
RE5
 Incomplete and Inappropriate Requirements 
RE6
Unclear/misunderstood project’ scope, goals and objectives 
RE7
Users did not give adequate time for gathering requirements
RE8
Lack of top management involvement and support 
RE9
Ambiguous business needs and unclear vision 
RE10
Conflicts of interest between different user’s groups 
RE11
No method for requirements elicitation 
Table (6-5), Main failure reasons related to Project Requirements Elicitation
Questions
Strongly Agree
Agree
N/A
Disagree
Strongly disagree
Degree
Average
St.Dev
General Percentage
RE1
4
8
3
1
0
63
3.94
0.85
78.8
RE2
5
8
2
1
0
65
4.06
0.85
81.3
RE3
4
6
2
3
1
57
3.56
1.26
71.3
RE4
6
7
1
2
0
65
4.06
1.00
81.3
RE5
4
8
1
3
0
61
3.81
1.05
76.3
RE6
4
8
2
2
0
62
3.88
0.96
77.5
RE7
2
9
3
2
0
59
3.69
0.87
73.8
RE8
5
7
2
2
0
63
3.94
1.73
78.8
RE9
5
9
1
1
0
66
4.13
0.81
82.5
RE10
4
8
2
2
0
62
3.88
0.96
77.5
RE11
7
6
1
1
1
65
4.06
1.18
81.3
Geomean
1.0
78.1
Table (6-6) General percentages for each question of requirement elicitation
Also, table (6-7) illustrates the main statistics and the measure of Central Tendency for all responses to the twelve questions of requirement elicitation governance. 
Requirement Elicitation Governance  Statistics


RE1
RE2
RE3
RE4
RE5
RE6
RE7
RE8
RE9
RE10
RE11
Mean
3.94
4.06
3.56
4.06
3.81
3.88
3.69
3.94
4.13
3.88
4.06
Median
4.00
4.00
4.00
4.00
4.00
4.00
4.00
4.00
4.00
4.00
4.00
Mode
4
4
4
4
4
4
4
4
4
4
5
Std. Deviation
.854
.854
1.263
.998
1.047
.957
.873
1.731
.806
.957
1.181
Skewness
-.605
-.863
-.614
-1.058
-.774
-.765
-.662
-.067
-1.118
-.765
-1.521
Sum
63
65
57
65
61
62
59
63
66
62
65
Table (6-7) statistics and the measure of Central Tendency for requirement elicitation Governance
Additionally, Fig. (6-3) depicts a chart to illustrate the average percentages of all responses which indicates to the ability of the governance framework to decrease the defects and the failures of project requirement elicitation.   

Fig. (6-3) the average percentages of all responses of requirement elicitation governance
6.3.3. Examine the Application of “Governance Framework” to the failures of Project Risk Management
Project managers were asked to answer fourteen questions examine the ability of the governance framework to decrease the main failure reasons in the area of project risk management as showing in table (6-8). According to the Likert scales and the frequencies analysis, the general average of responses for the fourteen questions is %81.1, this indicates to the responses agreement for the ability of the purposed framework to decrease the failure reasons that are related to the project risk management, the following tables illustrate and support this result. Also, the average of the Standard deviation for all values equal 0.9, this confirms the harmony and the consistency of responses. Tables (6-9) illustrates the general percentages for each question, the Standard deviation for the answers and the general average of all responses which equal %81.1  
symbol
Main failure reasons related to Project Risk Management
RM1
Conflict between system’ users
RM2
Risks were not re-assessed, controlled, or managed through the project development 
RM3
Risks’ impact isn’t incorporated into the project plan 
RM4
Lack of required team knowledge, experience and skills 
RM5
Failure to achieve all end-user expectations 
RM6
Inappropriate development methodology 
RM7
Project Managers don’t consider the best practices and lessons learned 
RM8
Insufficient and poor risk management 
RM9
Incorrect assumptions regarding risk analysis 
RM10
Poor communication among customers, developers and users 
RM11
Changing of technology 
RM12
No change controls 
RM13
Applying improper risk response strategy 
RM14
Insufficient allocating the project’ Risk Reserve 
Table (6-8) Main failure reasons related to Project Risk Management
Questions
Strongly Agree
Agree
N/A
Disagree
Strongly disagree
Degree
Average
St.Dev
General Percentage
RM1
6
7
2
1
0
66
4.13
0.89
82.5
RM2
5
8
2
1
0
65
4.06
0.85
81.3
RM3
7
7
1
1
0
68
4.25
0.86
85.0
RM4
7
6
1
2
0
66
4.13
1.02
82.5
RM5
5
7
3
1
0
64
4.00
0.89
80.0
RM6
8
4
2
2
0
66
4.13
1.09
82.5
RM7
6
7
2
1
0
66
4.13
0.89
82.5
RM8
6
6
2
2
0
64
4.00
1.03
80.0
RM9
6
7
2
1
0
66
4.13
0.89
82.5
RM10
5
8
1
2
0
64
4.00
0.97
80.0
RM11
5
7
2
2
0
63
3.94
1.00
78.8
RM12
2
9
3
2
0
59
3.69
0.87
73.8
RM13
5
8
2
1
0
65
4.06
0.85
81.3
RM14
7
6
2
1
0
67
4.19
0.91
83.8
Geomean
0.9
81.1
Table (6-9) General percentages for each question of risk management governance
Also, table (6-10) illustrates the main statistics and the measure of Central Tendency for all responses to the twelve questions of risk management governance. 
Risk management Governance Statistics


RM1
RM2
RM3
RM4
RM5
RM6
RM7
RM8
RM9
RM10
RM11
RM12
RM13
RM14
Mean
4.13
4.06
4.25
4.13
4.00
4.13
4.13
4.00
4.13
4.00
3.94
3.69
4.06
4.19
Median
4.00
4.00
4.00
4.00
4.00
4.50
4.00
4.00
4.00
4.00
4.00
4.00
4.00
4.00
Mode
4
4
4a
5
4
5
4
4a
4
4
4
4
4
5
Std. Deviation
.885
.854
.856
1.025
.894
1.088
.885
1.033
.885
.966
.998
.873
.854
.911
Skewness
-.927
-.863
-1.274
-1.129
-.639
-.988
-.927
-.830
-.927
-1.014
-.782
-.662
-.863
-1.019
Sum
66
65
68
66
64
66
66
64
66
64
63
59
65
67
Table (6-10) statistics and the measure of Central Tendency for risk management Governance
In addition to, Fig. (6-4) depicts a chart to illustrate the average percentages of all responses which indicates to the ability of the governance framework to decrease the defects and the failures of project risk management.   

Fig. (6-4) the average percentages of all responses of risk management governance
6.3.4. Examine the Application of “Governance Framework” to the failures of Project Cost Estimation 
Project managers were asked to answer ten questions examine the ability of the governance framework to decrease the main failure reasons in the area of project Cost estimation as showing in table (6-10). According to the Likert scales and the frequencies analysis, the general average of responses for the ten questions is %81.4, this indicates to the responses agreement for the ability of the purposed framework to decrease the failure reasons that are related to the project cost estimation, the following tables illustrate and support this result. Also, the average of the Standard deviation for all values equal 0.9, this confirms the harmony and the consistency of responses. Tables (6-12) illustrates the general percentages for each question, the Standard deviation for the answers and the general average of all responses which equal %81.4
symbol
Main failure reasons related to Project Cost Estimation
CE1
Overruns in costs and time 
CE2
Unrealistic estimation efforts 
CE3
Failing to meet the project costs 
CE4
Poor estimation methods 
CE5
Developers not involved in the estimation process 
CE6
Inexistence of historical database to retain the estimated data 
CE7
Ignoring the indirect costs estimation of the non-technical activities 
CE8
Weak estimation competencies and bad Budget Management 
CE9
Project estimation is based on only one estimation technique   
CE10
Ignoring to adjust the project cost to risks
Table (6-11) Main failure reasons related to Project Cost Estimation
Questions
Strongly Agree
Agree
N/A
Disagree
Strongly disagree
Degree
Average
St.Dev
General Percentage
RM1
8
4
2
2
0
66
4.13
1.09
82.5
RM2
6
7
1
1
1
64
4.00
1.15
80.0
RM3
5
7
1
3
0
62
3.88
1.09
77.5
RM4
7
7
1
1
0
68
4.25
0.86
85.0
RM5
6
7
2
1
0
66
4.13
0.89
82.5
RM6
5
8
1
2
0
64
4.00
0.97
80.0
RM7
6
8
2
0
0
68
4.25
0.68
85.0
RM8
3
8
3
2
0
60
3.75
0.93
75.0
RM9
8
6
1
1
0
69
4.31
0.87
86.3
RM10
5
8
2
1
0
65
4.06
0.85
81.3
Geomean
0.9
81.4
Table (6-12) General percentages for each question of cost estimation governance

Table (6-13) illustrates the main statistics and the measure of Central Tendency for all responses to the twelve questions of cost estimation governance. Also, Fig. (6-5) depicts a chart to illustrate the average percentages of all responses which indicates to the ability of the governance framework to decrease the defects and the failures of project cost estimation.   
Statistics


CE1
CE2
CE3
CE4
CE5
CE6
CE7
CE8
CE9
CE10
Mean
4.13
4.00
3.88
4.25
4.13
4.00
4.25
3.75
4.31
4.06
Median
4.50
4.00
4.00
4.00
4.00
4.00
4.00
4.00
4.50
4.00
Mode
5
4
4
4a
4
4
4
4
5
4
Std. Deviation
1.088
1.155
1.088
.856
.885
.966
.683
.931
.873
.854
Skewness
-.988
-1.485
-.788
-1.274
-.927
-1.014
-.358
-.567
-1.397
-.863
Sum
66
64
62
68
66
64
68
60
69
65
Table (6-13) statistics and the measure of Central Tendency for cost estimation Governance

Fig. (6-5) the average percentages of all responses of cost estimation governance
6.3.5. Examine the application of “Governance Framework” to the failures of Project plan development and schedule
Project managers were asked to answer twelve questions examine the ability of the governance framework to decrease the main failure reasons related to the project plan development and schedule as showing in table (6-14). According to the Likert scales and the frequencies analysis, the general average of responses for the twelve questions is %80.0, this indicates to the responses agreement for the ability of the framework to decrease the failure reasons that are related to the project plan development and schedule, the following tables illustrate and support this result. Also, the average of the Standard deviation for all values equal 0.9, this confirms the harmony and the consistency of responses. Tables (6-15) illustrates the general percentages for each question, the Standard deviation for the answers and the general average of all responses which equal (%80.0)  
symbol
Main failure reasons related to Project Plan and schedule
PP1
Imprecise and ambiguous project plan 
PP2
Lack of Resources & inadequate staff to meet the schedule
PP3
Poor competencies of project planners (skill/experience shortages) 
PP4
Failing in managing the project plan
PP5
Unrealistic schedules and deadlines 
PP6
Project changes are managed poorly 
PP7
Poor change and configuration management procedures 
PP8
Improper definitions of roles and responsibilities 
PP9
Poor test planning 
PP10
No reviews at the end of each phase 
PP11
Lack of Contingency plan to handle problems that arise during the project development 
PP12
Ineffective internal communication 
Table (6-14) Main failure reasons related to Project Plan and schedule
Questions 
Strongly Agree
Agree
N/A
Disagree
Strongly disagree
Degree
Average
St.Dev
General Percentage
PP1
10
5
1
0
0
73
4.56
0.63
91.3
PP2
6
9
1
0
0
69
4.31
0.60
86.3
PP3
7
5
2
2
0
65
4.06
1.06
81.3
PP4
7
7
1
1
0
68
4.25
0.86
85.0
PP5
7
6
1
2
0
66
4.13
1.02
82.5
PP6
7
5
2
2
0
65
4.06
1.06
81.3
PP7
5
8
2
1
0
65
4.06
0.85
81.3
PP8
6
6
2
2
0
64
4.00
1.03
80.0
PP9
0
4
7
4
1
46
2.88
0.89
57.5
PP10
8
6
0
2
0
68
4.25
1.00
85.0
PP11
5
8
1
2
0
64
4.00
0.97
80.0
PP12
4
9
2
1
0
64
4.00
0.82
80.0
Geomean
0.9
80.5
Table (6-15) General percentages for each question of plan development and schedule governance
Also, table (6-16) illustrates the main statistics and the measure of Central Tendency for all responses to the twelve questions of feasibility study governance. 
Project plan development  and schedule Governance Statistics


PP1
PP2
PP3
PP4
PP5
PP6
PP7
PP8
PP9
PP10
PP11
PP12
Mean
4.56
4.31
4.06
4.25
4.13
4.06
4.06
4.00
2.88
4.25
4.00
4.00
Median
5.00
4.00
4.00
4.00
4.00
4.00
4.00
4.00
3.00
4.50
4.00
4.00
Mode
5
4
5
4a
5
5
4
4a
3
5
4
4
Std. Deviation
.629
.602
1.063
.856
1.025
1.063
.854
1.033
.885
1.000
.966
.816
Skewness
-1.183
-.205
-.900
-1.274
-1.129
-.900
-.863
-.830
-.392
-1.486
-1.014
-.840
Sum
73
69
65
68
66
65
65
64
46
68
64
64
Table (6-16) statistics and the measure of Central Tendency for plan development and schedule 
In addition to, Fig. (6-6) depicts a chart to illustrate the average percentages of all responses which indicates to the ability of the governance framework to decrease the defects and the failures of project plan development and schedule.   

Fig. (6-6) the average percentages of all responses of plan development and schedule governance
Through analyzing the results of all responses to examine the application of the governance framework, Fig. (6-7) explains the summary of the General Average values of responses for the main pre-development activities governance which equal (%80.5), this means according to Likert Scales that, the designed governance framework has the ability to decrease the main failures of IS projects and contribute to enhance IS projects’ success, which confirms the reliability of the purposed framework.  

Fig. (6-7) General Average values of the main Pre-development governance = (%80.5)
6.4. Explain the related results of IS project Governance 
The empirical study in this research introduces many important results explain the main variables in the area of IS project governance in local environment as the following:-
            6.4.1. The average percentage of responses confirm that, IS projects have high failure rates than the other projects with (88.75%) according to Likert Scales


Fig. (6-8), the average percentages of IS projects failure 
            6.4.2. According to the empirical study, the Average percentage of IS projects’ failure in the Egyptian environment is (36.19% ) 

Fig. (6-9), Average percentage of IS projects’ failure in the Egyptian environment
            6.4.3. The percentages of most common requirements elicitation techniques that are used in the Egyptian environment as Fig. (6-10) which explains the shortage of using the modern elicitation techniques such as model driven techniques, cognitive techniques and ontology framework, this shortage causes more defects in requirement elicitation through incomplete and imprecise requirements which leads to the failures of IS projects. To overcome this problem, modern elicitation techniques should be activated and used such as Prototyping, Model-driven Techniques and Cognitive techniques or to use a combination of them.

Fig. (6-10) percentages of most common requirements elicitation techniques
            6.4.4. The empirical study examined the impact of the main risk factors of IS projects as showing in Fig. (6-11), whereas the risks of project cost estimation, schedule, requirement and communications are recorded the heights impact as risk factors. 

Fig. (6-11) Estimate the impact of project risk factors
            6.4.5. Through the implementation of the empirical study; a comparison between the international and the local environments was conducted to investigate the main pre-development activities which have a great influence to cause the projects failure as shown in table (6-17) and Fig. (6-12). The comparison proves a great accordance between the two environments, whereby there is a set of pre-development activities that have a great influence to cause the project failure which are; Requirements Elicitation, Risk Management, Cost Estimation, and Project Plan development and schedule. But there is a difference between them in two pre-development activities. Project feasibility study has a great influence to cause the failure at the international environment, in contrast, the project scope definition is most significant in local environment. 
pre-development activities
Empirical  study 
International 
System Service Request (SSR) Assessment
1%
2.97%
Project Scope Definition
13%
4.95%
 Project Feasibility study
5%
11.88%
Project Requirements Elicitation 
19%
15.84%
Commercial Off-The-Shelf (COTS) Selection
1%
1.98%
Project Charter and Statement of Work (SOW)
3%
3.96%
Project Work Breakdown Structure (WBS) 
4%
3.96%
Project Risk Management
14%
14.85%
Project Cost Estimation 
15%
12.87%
Project Contract 
4%
1.98%
Communication Plan development
5%
5.94%
Project Plan development and schedule
18%
18.81%
Table (6-17), comparison between the international and local environment

Fig. (6-12) Main Pre-development activities which have influence to cause the projects failure
According to the comparison which investigates the most significant pre-development activities at the international and local environments. It proves the importance of project scope definition in local environment, Governance the project scope definition will be implemented according to the components of the governance framework to conquer the problems of project scope in the local environment as the following; 
6.5. Governance the Project Scope Definition 
Project scope definition is the process by which projects are defined and prepared for execution, defining the project scope is more significant; poor scope definition can lead to numerous requirement changes and scope creep (Zhang et al, 2003). Unclear and incomplete scope and objectives can contribute to the perception of project failure (Barclay and Osei, 2010). Project’ scope is very much driven by three major factors: project size, project duration and project key interdependencies. In fact, project scope definition isn’t a simple task, but it has many challenges and it is complicated, project managers face many problems within the project scope definition such as; Project objectives may be unclear, Difficulty to manage the changes of scope, Changing the scope and objectives during the project and Customer/Users had unrealistic expectations. So, Governance can improve the performance of the project scope definition and reduce the most of its problems which lead to decrease the probability of projects’ failure. According to the governance framework which is designed in this research, the main components to govern the project scope definition are;
    • Define the main policies and procedures to execute the project scope definition
    • Best practices to reduce the failure  within the project scope definition
    • Checklist to improve the performance of the project scope definition
    • Define the expected deliverables of project scope definition
6.5.1. Policy’s actions and principles to implement Scope Definition Governance 
In the purpose of implementing the project scope definition governance according to the designed governance framework, it is very important to emphases on defining a clear policy with actions and principles to implement project scope definition governance and explain the main procedures, practices and techniques that are needed to verify the policy’s actions and principles. Table (6-18) explains the required procedures, practices and techniques for the policy’s actions and principles to implement the scope definition governance.
The policy is: Minimum scope changes through accurate and complete project’s scope definition 
Policy’s actions and principles for  Project Scope Definition Governance
Procedures, Practices and Techniques to Verify Policy’s actions and principles
- Define the most favorable scenario to guarantee proper definition of project scope
Determining well-defined procedures to execute the project scope definition
- Decrease IS projects’ failure which are derived from the project scope definition
Setting Best practices to reduce the failure within project scope definition
- Improve the performance of project scope definition
- Develop the “Project Scope Definition Checklist” to guarantee an accurate and completely scope definition.
- Enhance the best possible deliverables for IS projects 
Defining the best expected deliverables for project scope definition
Table (6-18) Policy’s actions and principles of project Plan Development and Schedule
6.5.2. Well-defined procedures to execute the project scope definition
Define the project scope includes all the work to deliver a project's product or service with the specified features and functions, it encompasses many procedures that must be implemented to guarantee accurate and clear project scope definition, based on the Project Management Institute components to define the project scope (PMI, 2008), and the main researches interested in project scope definition (Zhang et al, 2003), (Khan, 2006), the well-defined procedures to define the project scope are; 
Procedure 1: Define the business needs to initiate and justify the project; Projects are initiated in order to satisfy a business need. The business need may arise to solve an existent problem or to satisfy a new environmental regulation that requires companies to treat. Also, Projects undertaken to improve service factors of a customer service is another example justifying a business need to undertake a project. Once a business need is identified and aligned with a company's strategic objectives, a project may be initiated subject to satisfaction of feasibility criteria. The project justification encapsulates the business need for undertaking the project while providing a basis for future trade-offs.
Procedure 2: Define the main project objectives; The project objective determine the business benefits that an organization expects to achieve as a result of implementing the project. Clear project objectives are both specific and measurable, they define quantifiable criteria that must be met for the project to be considered successfully completed.
Procedure 3: Define the Scope; Project scope identifies those items and activities that are required to meet the needs of the owner. The purpose of project scope definition is to provide sufficient information to identify the work to be performed and to allow the design to proceed without significant changes that may adversely affect project budget and schedule. At the point of scope definition, the framework for project scope has been put in place through determining the project boundaries and the out of scope activities. 
Procedure 4: Determine project product and deliverables: the project product section summarizes the product description which is a compilation of characteristics of product or service to be created upon completion of the project, but Project deliverables refer to a list of finished products to be delivered by the service provider.
Procedure 5: Planning the Scope; Scope planning is all about developing a summary and setting high level WBS, project scope development is not detailed enough at this stage for creation of a comprehensive WBS. After the project has been approved and allowed to proceed, the project manager gets down to work with their project’ team to develop the defined project. At this stage it is useful to work with knowledge of project cost, schedule, and key quality parameters.
Procedure 6: Scope Verification; Scope verification is connected to the scope planning and scope definition. However, the distinguishing feature of this process is the feedback loop it provides in verifying the contents of all work done thus far. Scope verification involves checking all design and engineering deliverables required as part of scope planning and definition. It is important to note that the verification process does not have to wait until completion of its predecessors scope planning and definition. It is a continuous process which starts almost concurrently with its predecessors. 
Procedure 7: Scope Approval; Once the scope is developed, the elements are thoroughly discussed and agreed on by the project team, stakeholders, sponsor, and the customer. The definition is then signed off formally, and any changes are communicated through the project manager unless an advisory committee has been established to lead this effort. With the acceptance and signed approval of the scope, the scope management plan is the formal document that defines the processes outlined in the project plan. The project manager is responsible to ensure that this process is complete and monitored throughout all phases of the project.
Procedure 8: Perceive Scope Change Control; Changes of project scope is considering main problem during the projects development. Scope changes are defined as “the additions, modifications, or deletions made to the end product of IS project, It’s any modification to the agreed-upon project scope as defined by the approved WBS. It often requires adjustments to cost time quality or other project objectives (PMI, 2008). In fact, the reasons of scope changes are various, they can due to neglect at defining the initial scope, wrong understanding to the initial scope or the product that users want is more complicated than the delivered original ones. Practitioners of project management realize that scope change is an inevitable reality for any project. 
Scope changes Management is very importance because scope creep can assume horrendous proportions and may even force project cancellation. Scope creep is a term used to describe unauthorized scope changes. Unauthorized changes may creep into project scope as a result of verbal instructions, e-mail instructions, written instructions that have been issued without realizing the magnitude of change. An effective scope change control mechanism must be put in place as early as the start of the scope planning phase. It is important to classify types of scope change requests and the reason for the change. If any changes occur, all information is documented and then communicated to all members of the project team. The customer is to be kept informed of these or any changes during any parts of the life cycle of the project; otherwise, scope creep will occur and put the project in jeopardy through increased risks and unnecessary costs to the project. So, the project manager must be aware of any discrepancies of project activities or potential risks promptly that deviate from the baseline or work breakdown schedule, in order to minimize any delays to the schedule which can ultimately cause the project failure. 
Procedure 9:  Develop the project Scope Statement; that document is a description of the project’s deliverables, results, critical success factors, and defines what is out of scope. It serves as input to future project planning efforts.
6.5.3. Best practices to reduce the failure within the project scope definition
A set of best practices should be taken into consideration within the project scope definition as a guide to avoid the problems that cause the project failure. These practices are based on a set of guidance instructions and critical success factors that must be considered during the project development, they encompass the most lessons learned from the previous successful projects. Also, the best practices of CMMI for systems and software development in the area of project scope definition are merged here (CMMI, 2001), (CMMI, 2010). So, Project managers can position themselves to reduce the possibility for project failure by considering the best practices in table (6-19):
No
Best practices of project scope definition
Yes
No
1
Establish a top-level work breakdown structure (WBS) to estimate the scope of the project


2
Define the project life-cycle phases upon which to scope the planning effort


3
Define clear project objectives and assumptions  


4
Avoid Imprecise identification  for business needs 


5
Set a proper procedures to manage the scope changes accurately 


6
Exclude the unauthorized scope changes (Scope creep)


7
Avoid Changing scope and objectives during the project as much as possible 


8
Define clear project boundaries and what is out of the scope  


9
Tack care of Customer/Users unrealistic expectations


10
Defining the initial project scope and justification completely 


11
Assure that  initial project scope is completely understanding 


12
Consider that product which users want is more complicated than the delivered original ones


13
Key stakeholders should be informed of scope changes that have effect on project schedule, cost, and quality. 


14
Avoid words and statements that require judgment or invite interpretation, such as ‘improve,” "enhance," "better," "more efficient" and "effective." Use numbers, facts, and concrete results. Use quantifiable terms, and provide target values or ranges. 


15
Consider the overlooked elements of the scope


16
Avoid rework because the scope is poorly defined as much as possible


17
Communicate  scope changes to all project parties


Table (6-19) Best practices of project scope definition checklist
6.5.3. Checklist to improve the project scope definition 
It’s very important to define a clear and complete project scope to enhance project success, the project scope definition has a great influence to many critical activities through the project development phases, it can affect the project schedule, cost estimation, requirement elicitation, and budget. So, project scope definition checklist is developed in table (6-20) to guarantee producing a clear and complete project scope definition.    
No
Project Scope Definition Checklist
yes
No
1
Define the outcomes, objectives, and deliverables


2
Setting realistic project Scope assumptions 


3
Project scope definition has been carefully checked and verified


4
Project scope definition should be sufficiently detailed 


5
Project scope should be agreed by all users, stakeholders, project sponsor, project manager and project team


6
Allowed scope changes should be communicated to all project parties 


7
Project team should participate with the users / stakeholders to define the project scope


8
A formal process for managing the scope changes should be existed 


9
A list of all major deliverables should be existed


10
All stakeholders be involved have a common understanding of project scope 


11
Check the resources to be used and the anticipated team size


12
Quantify the scope wherever it is possible


13
Scope assumptions should be documented


14
Scope statement should clearly list what is included within the project and specify the project boundaries


15
Scope statement should list what is specifically excluded from the project


16
Set the quantifiable criteria for project success including cost, schedule and quality


17
The scope definition should identify the high-level WBS


18
The scope should explain the application areas that are within and outside the project scope


19
The scope should suitably defined for the start of the project


20
The scope statement should be signed off


21
The scope statement should clearly identify the boundaries of the project 


22
Unauthorized scope changes should be reviewed or omitted  


23
Understand the business needs or issues to be resolved by the project


Table (6-20) Project Scope Definition Checklist

6.5.4. Define the Best expected deliverables of the project scope definition
The main output of project scope definition is Project Scope Statement (Khan, 2006), that document is a description of the project’s deliverables, results, critical success factors, and defines what is out of scope. It serves as input to future project planning efforts. The scope statement should include:
    • The business need the project will address.
    • What the project will accomplish, how it will be accomplished and by whom.
    • What the end result of the project will be (e.g., a product, service, other).
    • A list of project deliverables, which, when produced and accepted, indicate project completion. 
    • Critical success factors (usually cost, schedule, and quality measurements) that determine whether or not a project was successful.
    • Include a list of those items/deliverables that are not in scope for the project. 
High-Level Project WBS, which represents the main structure of the project scope, it can help to provide an overview representation of tasks, durations, dependencies, and resources, to the extent that is currently known about the project. Also the project scope definition should provide more details about the following:
    1. A detailed process to determine the project scope, which is based upon the customers' expectations and team's input taken from similar projects.
    2. Identification of project deliverables.
    3. A formalized scope verification process.
    4. A written process to control project scope that is agreed upon by the principal stakeholders.
    5. Identify the project assumptions and constraints that are outside the scope. 
So, the suitable governance framework for the local environment is illustrated in Fig. (6-13) which contains the governance of project scope definition as additional section which is explained in Fig. (6-14). 



















Fig. (6-13) Suitable governance framework for the local environment

Fig. (6-14) Governance the project scope definition 


6.6. Research Findings
There are many important findings are deduced and extracted from the theoretical study in this research, they encompass the following;
    • IS projects have distinct characteristics and special nature, and they differ from the other business projects which make them difficult to manage and control.
    • IS Projects don’t suffer from just one failure reason, but they can face many failure reasons
    • The occurrence of enormous costs and losses makes the failure of IS projects a major problem
    • The most significant of failure reasons of IS projects are attributed to the pre-development activities 
    • Pre-development activities are critical success factors for IS projects, If they are implemented in accurate and proper form. 
    • Pre-development activities are attributed to the initiation and planning phases, they begin with the System Service Request assessment (SSR) to initiate the projects and end with developing the project plan, which represents a road map to explain how the project will progress through all project phases and outlined objectives.
    • IS project governance is a new born theory and a nascent field of research 
    • IS project governance has emerged from IT governance
    • The main role of IS projects governance is to increase the probability of project success through achieving their intended purposes and objectives
    • There is a lack of guidance and frameworks regarding to IS projects governance
    •  Previous researches in projects governance concentrated on high level project governance (view the project as one block), while Specific perspective of IS project governance can contribute to decrease the projects failures through increase the performance of the project development activities
    • Adopting the specific project governance contribute to enhance the IS projects success and decrease the projects failure rates through achieving the intended project objectives and manage IT risks 
    • There are main pre-development activities that have a great influence to cause IS project failure:-
    1. Project Feasibility Study
    2. Project Requirements Elicitation
    3. Project Risk Management
    4. Project Cost Estimation
    5. Project Plan Development and schedule
    6. the project scope definition in local environment
These activities can contribute to decrease the projects’ failure rates and sustain the project’ success
    • The implementation of an information system involves a number of challenges and difficulties that, in many cases, pose threats to the success of IS in achieving its objectives and providing its intended functionality within the constraints of time and cost
    • Accurate Requirement elicitation is the beginning of project success   
    • Project scope definition is the most important activity to save the project fail   
    • Misunderstanding of user requirements and changing requirements during the project development, are the main problems of requirement elicitation which lead to inconsistencies in system requirements and cause the project failure
    • Errors in requirements elicitation are, overall, the most serious in software development, and the hardest to repair. So, changing requirements affect the project’ costs and schedule, the failing to manage these changes may lead to the project failure in high percentage. 
    • IS projects are considered failed if;
    • If they didn’t accomplish their business objectives (strategic, technical and operational).
    • If they didn’t satisfy and profit for the sponsors/owner and contractors.
    • If they didn’t meet their expectation requirements and objectives.
    • If they didn’t proceed to specification, within budget and on time (overrun costs and deadlines) 
    • Also, projects are either abandoned before completion, and did not meet their objectives, or were not accepted by users are consider failed.
Finally, the designed governance framework has a great harmony and satisfies the Capability of CMMI till level 3, this satisfaction is evident at table (6-21) which explains the relation between the requirements of CMMI capability levels and the capability of the designed governance framework. Taking into account CMMI requirements describe the activities that are important in achieving a required CMMI. CMMI components guide to implement improvements or perform appraisals. Specific and generic practices are the most significant CMMI components. 






CMMI levels
Description
CMMI Requirements
Capability of the designed governance framework
Level 1: Performed
A performed activity satisfies the specific goals. Process is informal and Ad hoc. Success depends on individual effort and heroics.  They frequently exceed the budget and schedule of their projects.
Perform the base practices of the process area to develop work products and provide services to achieve the specific goals of the process area

There is a package of well-defined procedures and best practices facilitate the performance of the pre-development activities to satisfy and sustain the projects’ objectives and deliverables.
Level 2: Managed
A managed activity is a performed, also it is planned and executed in accordance with policy. The plan may be part of a more encompassing plan and the performance of the activity is managed against the plan.
Basic project management processes are established to track cost, schedule, and functionality. 
Requirements Management
The framework encompasses requirement elicitation governance which facilitates the process of requirements management.


Project Planning
Project plan is the backbone of this framework which is based on good project planning.


Project Monitoring and Control
The framework is integrating main aspects of COBIT controls and contains many checklists. 


Process and Product Quality Assurance
The framework contains many guidelines define the plan of project quality and quality assurance.


Configuration Management
The framework contains many guidelines define  Configuration Management with its roles and responsibilities 
 Level 3: Defined
A defined activity is a managed, also the standards are established and described. The software process for both management and engineering activities is documented, standardized, and integrated into all processes for the organization. All projects use an approved version of the organizational standard software process for developing and maintaining software
Requirements Development
Requirements elicitation is the right beginning to implement requirement analysis and specifications


Technical Solution
The project plan introduces a road map explains the main phases to implement the technical solution.  


Product Integration
The project plan depict and support the integration of all components of project product 


Organizational Process Definition
The framework explains WBS which is the keystone to define the organizational process.   


Organizational Training
Project management competencies and skills are important components here. So, Training for project team member is organized and is considered.


Risk Management
The framework encompasses risk management governance in details which facilitates the process of risk identifications, calculate the probability of risk factors, estimate the risk impact and Determine the risk response strategy.


Decision Analysis and Resolution
The framework support the decision analysis through conducting the feasibility study to decide proceeding the projects or not. Also it facilitates many decisions in the pre-development phase such as determine the project costs and schedule.  
Table (6-21) Relation between the framework components and CMMI capability levels









Chapter (7)
Conclusions and Future Work  



















Chapter (7)
Conclusions and Future Work  
7.1. Research Conclusion 
Information systems (IS) development projects have high failure rates, there is a significant body of evidence that many IS implementation projects end in failure, this research looks for the origins of the failures as a new approach instead of lists the failure reasons as the most previous researches. This research aims to develop Governance Framework as solution to solve the problem of high failure rates of IS projects. It gathered and categorized the pre-development activities which have a great influence to cause the project failure. Also, it proves the correlation between the pre-development activities and the most of failure reasons of IS projects. 
Through investigating the failure reasons, it has been detected that, most significant failure reasons are attributed to the pre-development activities, which begin with the System Service Request (SSR) to initiate the projects and end with developing the project plan to represent a road map to explain how the project will progress through all its phases. Pre-development activities are derived from the initiation and planning phases for IS projects development. They are main critical success factors for IS projects, they include;
    1. System Service Request (SSR) Assessment, 
    2. Project Scope Definition    
    3. Project Feasibility study  
    4. Project Requirements Elicitation
    5. Commercial Off-The-Shelf (COTS) Selection   
    6. Project Charter and Statement of Work (SOW)
    7. Project Work Breakdown Structure (WBS)
    8. Project Risk Management  
    9. Project Cost Estimation
    10. Project Contract  
    11. Communication Plan development  
    12. Project Plan development and schedule
The purposed Governance Framework was applied on the main pre-development activities which have a great influence to cause the projects’ failure, this framework is  based on four main governance components as a new mixture that are:- 
    • Define the main policies and procedures to execute the pre-development activities. 
    • Best practices to reduce the failure within the pre-development activities.
    • Tools and Checklists to improve the performance of the pre-development activities.
    • Define the best expected deliverables for the pre-development activities
This research examines the reliability of the purposed framework by conducting an empirical study which confirms the reliability of this framework as a solution to eliminate the main failures and defects of IS projects.  
Furthermore, this research describes the best favorable scenario to execute the main pre-development activities through developing a set of procedures and best practices. Also, it introduces many solutions for the main problems of the pre-development activities of IS projects as showing in table (7-1).
No
Main Problems of IS projects 
Solution procedures
1
The difficulty to estimate and trace the intangible benefits and costs  
Quantifying the Cost/Benefit Analysis which classify and estimate the intangible benefits and costs to create a real Cost/Benefit Analysis.
2
The difficulty to decide proceeding the project or not (project worthy)  
“Check the Project viability” which examines three groups of critical success factors to assure if the project worth to implement or not
3
The problem of Reassess the project feasibility 
“Setting Feasibility Checkpoints” to reassess the project feasibility at many points in all project’ phases
4
The problem of inaccurate and incomplete Requirements 
“CSF for Requirement Elicitation Checklist” which contains the most critical success factors to achieve accurate requirement elicitation
5
The problem of communicate and  manage the change of requirements 
“Customize Quality Function Deployment (QFD)” to facilitate the requirement elicitation and manage requirements changes through providing a visual connective process and translate the customer’ needs into technical characteristics for the project’ product.  
6
The problem of identifying the project risk factors 
“Comprehensive Project Risk Identification Tool” whereby the project risks are classified into thirteen main categories, these thirteen categories are branched into 170 sub-Factors 
7
The problem of determine the risk probability 
“Assigning the Risk Probability” to Estimate the probability of project’ risk factors, 
probability of risk factors =%
8
The problem of keeping the chance of project success, if the risks are done
“Assigning Risk Reserve” is an estimation value expresses the cost of project risks in monetary form, this value must be added to the project cost estimation 
Cost for each risk factor = Probability of risk factor * Coefficient Impact* Total losses if the project failed 
9
The problem of inaccurate cost estimation and dependence of one cost estimation technique 
“Comprehensive Cost Estimation Model (CCEM)” to make the cost estimation more accurate and conquer the problems of depending on one cost estimation technique by using mixture of estimation techniques
10
The problem of unrealistic cost estimation
“Critical Success Estimation Factors (CSEF)” to produce realistic and accurate cost estimation 
11
The problem of imprecise and ambiguous project plan   
“Project Plan Components Checklist” to verify the most components of the project plan are completely incorporated. 
12
The problem of unrealistic and inaccurate schedule
“Schedule success factors Checklist” to guarantee a realistic schedule for the project activities progress against the overall project plan
13
The problem of incomplete and unrealistic project scope
“Project scope definition checklist” to guarantee a clear and complete project scope definition.
Table (7-1) solutions for the main problems of the pre-development activities of IS projects
7.2. Research Recommendations
    • There is a necessity to create two organizational structures as complementary components for the purposed governance framework they are:  
1- Governance Committee to solve the main problems within IS projects development and estimates the most of unidentified values as judge experts such as:-
    1. The accepted level of Cost/Benefit analysis to accept the project
    2. The accepted percentage of project scope changing 
    3. The probability of risk factors 
    4. The impact of the identified risk factors
    5.  the constant for weighting  the intangible benefits and costs 
    6. The average value to transform  SLOC  in P/Hours in cost estimation
2- Neutral Committee to receive and deliver IS projects to the concerned parties; this committee is an impartial party between the project sponsors and the organization of software development. The work of this committee begins when the project is initiated. This committee embarks their work upon the project scope statement, the project requirements and the project contract. Also it can be constituted from the Experts of software projects, Professors of Information systems at the governmental Universities, and the Neutral project managers.  
    • Sustain the efficiency of Project Managers through holding seminars, training programs and workshops
    • The costs of project’s risks should be added the cost estimation to keep the chance of achieving the project success if the risks have been done.
 7.3. Future work 
    • Apply the governance framework for the remaining pre-development activities that are not applied in this research , also this governance framework can be applied for the other  development’ phases of IS projects 
    • Develop effective techniques and mechanisms to manage and control the changes of project scope  
    • Develop a technical programming language to transfer the natural speaking during the project requirement elicitation   















References



















    1. Abednego P. Martinus, Ogunlana O. Stephen (2006)"Good project governance for proper risk allocation in public–private partnerships in Indonesia" International Journal of Project Management, Vol., 24, pp: 622–634.
    2. Abu-Musa Ahmad A., (2007) “Exploring Information Technology Governance (ITG) in Developing Countries: An Empirical Study” The International Journal of Digital Accounting Research, Vol. 7, pp: 71-120. 
    3. Abu-Musa Ahmad A., (2009) “Exploring COBIT Processes for ITG in Saudi Organizations: An empirical Study” The International Journal of Digital Accounting Research, Vol.9, pp: 99-126.
    4. Agarwal R., Manish Kumar t, Yogesh, S. Mallick, RM. Bharadwaj, D. Anantwar, (2001), “Estimating software projects”, Software Engineering Notes, Vol., 26 No 4, pp: 60-67
    5. Ahonen Jarmo , Savolainen Paula, (2010) , “Software engineering projects may fail before they are started: Post-mortem analysis of five cancelled projects”, The Journal of Systems and Software, Vol. 83, pp: 2175-2187
    6. Al-Ahmad Walid, Al-Fagih Khalid, Khanfar Khalid, Alsamara Khalid, Abuleil Saleem, Abu-Salem Hani (2009) “A Taxonomy of an IT Project Failure: Root Causes” International Management Review Vol. 5 No. 1, pp:93-104
    7. Al-Rousan T., Sulaiman S., Salam R.A., (2009), “Project Management Using Risk Identification Architecture Pattern (RIAP) Model: A case study on a Web-based application” IEEE, Software Engineering Conference, 2009, APSEC '09, Asia-Pacific, Digital Object Identifier: 10.1109/APSEC.2009.42, pp: 449-456
    8. Ashra I., Ahsan A., (2010), “Investigation and Discovery of Core Issues Concerning Requirements Elicitation in Information Technology Industry and Corresponding Remedial Actions”, IEEE, 17Th International Conference on Industrial Engineering and Engineering Management (IE&EM), pp: 349-353
    9. Bachy G., Hameri A., (1997), “What to be implemented at the early stage of a large-scale project” International Journal of Project Management, Vol., 15, Issue 4, pp: 211-218.
    10. Ballantine J., Stray S., (1998), “Financial appraisal and the IS/IT investment decision making process”, Journal of Information Technology, vol., 14, pp:3–15.
    11. Bannerman Paul (2009) “Software development governance: A meta-management perspective” IEEE, ICSE Workshop on Software Development Governance, SDG '09, pp: 3-8 
    12. Bannerman Paul (2010)" Managing Structure-Related Software Project Risk: A New Role for Project Governance", IEEE, Software Engineering Conference (ASWEC), pp:129-138
    13. Bannerman Paul, (2008) “Risk and risk management in software projects: a reassessment”. The Journal of Systems and Software, Vol., 81, pp: 2118–2133
    14. Barclay Corlane, Osei-Bryson Kweku-Muata (2010) “Project performance development framework: An approach for developing performance criteria & measures for information systems (IS) projects” International Journal of Production Economics Vol.,124 pp:272–292  
    15. Bardhan I., Bagchi S., Sougstad R. (2004), “Prioritizing a portfolio of information technology investment projects”, Journal of Management Information Systems, Vol., 21, No. 2, pp: 33-60.
    16. Beimborn Daniel, Schlosser, Weitzel Tim (2009) “Proposing a theoretical model for IT governance and IT business alignment”, IEEE, the 42nd Hawaii International Conference on System Sciences.
    17. Bekker M.C, Steyn H., (2007) “Defining ‘project governance’ for large capital projects” IEEE,AFRICON2007, Digital Object Identifier: 10.1109/AFRCON.2007.4401604, pp:1-13 
    18. Bekker M.C, Steyn H., (2008) “The Impact of Project Governance Principles on Project Performance” IEEE, Management of Engineering & Technology, 2008. PICMET 2008. Portland International Conference on Digital Object Identifier: 10.1109/PICMET.2008.4599744, pp: 1324 - 1330
    19. Bekker M.C, Steyn H., (2009) “Project Governance: Definition and Framework”, Journal of Contemporary Management, ISSN 1815-7440, Vol., 6 pp: 214 - 228
    20. Bernroider Edward (2002) “Factors in SWOT Analysis Applied to Micro, Small-to-Medium, and Large Software Enterprises; an Austrian Study”,European Management Journal, Vol., 20, Issue 5, pp:562-573
    21. Bhattacharjya J., Chang V., (2007)  “Evolving IT Governance Practices for Aligning IT with Business - A Case Study in an Australian Institution of Higher Education” Journal of Information Science and Technology, 4(1) pp.24-46
    22. Bin Mansor Z., Kasirun Z., Arshad N., Yahya S., (2010) “E-Cost Estimation Using Expert Judgment and COCOMO II” IEEE, International Symposium in Information Technology (ITSim),Vol. 3, pp: 1262 – 1267
    23. Boehm Barry W., (1991), “Software risk management: Principles and practices”, IEEE Software, Vol., 8, pp: 132-41
    24. Bouchereau V., Rowlands H., (2000), “Methods and techniques to help quality function deployment (QFD)”, Benchmarking: An International Journal, Vol. 7, No. 1, pp: 8-19.
    25. Browne J. Glenn, Ramesh V., (2002) “Improving Information Requirements Determination: a Cognitive Perspective” Information & management Journal, Vol., 39, pp: 625-645
    26. Burcu d. Ictenbas, Eryilmaz Hande, (2011), “Quality Function Deployment As A Strategic Planning Tool”, International Journal of Social Sciences and Humanity Studies, Vol. 3, No 2, 2011 ISSN: 1309-8063, pp:73-82
    27. Caballero, I.; Vizcaino, A.; Piattini, M., (2009), “Optimal Data Quality in Project Management for Global Software Developments”, IEEE, Fourth International Conference on Cooperation and Promotion of Information Resources in Science and Technology, Digital Object Identifier: 10.1109/COINFO.2009.49, pp: 210 - 219 
    28. Calvo-Manzano J. A., Cuevas G., Mejia J., Munoz M. A., San Feliu T., (2009) “How is CMMI-DEV applying when using TSPi project planning” IEEE, Electronics, Robotics and Automotive Mechanics Conference, Digital Object Identifier:10.1109/CERMA.2009.53, pp:143 - 148
    29. Cerpa Narciso ,  Verner  M. June (2009),” Why Did Your Project Fail?” Communications of the ACM, vol., 52, No. 12, pp: 130-134.
    30. Chang Hsu-Hsi, Huang Wen-Chih, (2006) “Application of a quantification SWOT analytical method” Mathematical and Computer Modelling journal, Vol., 43, pp:158–169
    31. CMMI Product Team, Software Engineering Institute (2001) “CMMI for Systems Engineering and Software Engineering” (CMMI-SE/SW, V1.1), USA, http://www.sei.cmu.edu
    32. CMMI Product Team, Software Engineering Institute (2010) “CMMI for Development, Version 1.3” CMMI-DEV, V1.3, USA, http://www.sei.cmu.edu.
    33. Costa Helio R., Barros Marcio O., Travassos Guilherme H., (2007)  “Evaluating software project portfolio risks” The Journal of Systems and Software, Vol.,80, pp:16-31
    34. Dahlberg T., and Kivijarvi H., (2006) “An Integrated Framework for IT Governance and the Development and Validation of an Assessment Instrument” IEEE, the 39th Hawaii International Conference on System Sciences.
    35. Dameri R. Paola, (2009) “Improving the Benefits of IT Compliance Using Enterprise Management Information Systems”, Electronic Journal Information Systems Evaluation Volume 12 Issue 1 pp.27-38.
    36. Davey Bill, Cope Chris, (2008), “Requirements Elicitation – What’s Missing?” Informing Science and Information Technology journal, Vol., 5, pp: 543-551
    37. De Haes Steven, Grembergen Wim Van (2005) “IT governance structures, processes and relational mechanisms: achieving IT/business alignment in a major Belgian financial group”, IEEE, Proceedings of the 38th Hawaii International Conf. on System Sciences (HICSS), pp: 237-247
    38. Demirors O., Gencel C., Tarhan A., (2006) “Challenges of Acquisition Planning” IEEE, Conference on Software Engineering and Advanced Applications (32nd EUROMICRO-SEAA'06), pp: 256 - 265
    39. Ding Ronggui, Wang Yanwei (2008)“An Empirical Study on Critical Success Factors Based on Governance for IT Projects in China” IEEE, 4th International Conference on Wireless Communications, Networking and Mobile Computing, “WiCOM 08”,  pp: 1 - 7 
    40. Du Yaling, Yin Yilin (2010) "Effect of governance on management in public project" IEEE,  International Conference on Logistics Systems and Intelligent Management, Vol.,1 Digital Object Identifier:10.1109/ICLSIM.2010.5461430 pp: 230 - 234 
    41. Elkington, P., Smallman, C., (2002), “Managing project risks: a case study from the utilities sector. International Journal of Project Management”, Vol., 20, pp:49–57.
    42. Fauzi S. Mohd,  Ramli Nuraminah, Nasir, M. Hairul Nizam M. (2008), “Assessing Software Risk Management Practices in a Small Scale Project” IEEE, Information Technology, 2008. ITSim 2008, Vol., 4 , Digital Object Identifier: 10.1109/ITSIM.2008.4631858 , pp: 1 – 5
    43. Feng Jingchun, Zhang Fujie, Li Ming, (2009) “Research on Work Breakdown Structure of IT Project” IEEE, International Conference on Management and Service Science, MASS 2009, pp: 1-5
    44. Finnveden Goran, Hauschild Z.Michael, and Ekvall Tomas, (2009), “Recent developments in Life Cycle Assessment” Journal of Environmental Management, Vol., 91, Issue 1, pp: 1-21.
    45. Friden, Terry, (2005) “FBI wasted millions on Virtual Case File” CNN Washington Bureau, 4 February, http://www.cnn.com/2005/US/02/03/fbi.computers
    46. Furumo  Kimberly, Pearson  J. Michael , Martin  L. Nancy (2006 ),“Do Project Management Tools and Outcomes Differ in Organizations of Varying Size and Sector?” Journal of Information, Knowledge and Management Volume 1, pp: 23-36
    47. Galorath Daniel D, Evans Michael W.,(2006), “Software Sizing, Estimation, and Risk Management” Auerbach Publications, Taylor & Francis Group, USA.
    48. Golpayegani S. Alireza Hashemi, Emamizadeh Bahram, (2007) “Designing Work Breakdown Structures Using Modular Neural Networks” Decision Support Systems Journal, Vol., 44, pp:202–222
    49. Gorse N., Belanger P., Chureau A., Aboulhamid E.M., Savaria Y., (2007) “A high-level requirements engineering methodology for electronic system-level design” Journal of Computers and Electrical Engineering Vol.,33 pp: 249–268
    50. Gottesdiener Ellen, (2005), “The Software Requirements, Memory Jogger” First Edition, GOAL/QPC Publisher, ISBN 1-57681-060-7, USA
    51. Gottesdiener Ellen, (2005), “THE Software Requirements, Memory Jogger” First Edition, GOAL/QPC Publisher, ISBN 1-57681-060-7, USA
    52. Greer D., Conradi R., (2009), “Software project initiation and planning – an empirical study” Journal of  IET Software, Vol. 3, Iss., 5, pp: 356–368
    53. Griffith A. F, Gibson G. E., (2001),  “Alignment During Preproject Planning” Journal of Management in Engineering ,Vol. 17, No. 2, pp: 69-76
    54. Gunasekaran A, Ngai EWT, McGaughey RE, (2006), “ Information technology and systems justification: a review for research and applications”, European Journal of Operational Research, Vol., 173, pp: 957–983
    55. Gunasekaran, A., Love, P.E.D., Rahimi, F., Miele, R., (2001), “A model for investment justification in information technology projects”, International Journal of Information Management, vol., 21, pp.349–364.
    56. Gursimran S. Walia a, Jeffrey C. Carver, (2009) “A systematic literature review to identify and classify software requirement errors”, Journal of Information and Software Technology, Vol., 51, pp:1087–1109
    57. Haes Steven , Grembergen Wim, (2008) “An Exploratory Study into the Design of an IT Governance Minimum Baseline through Delphi Research” Communications of the Association for Information Systems, Vol., 22, Article 24, pp. 443-458.
    58. Hallikainen P., Chen L., (2005) “A Holistic Framework on Information Systems Evaluation with a Case Analysis” The Electronic Journal Information Systems Evaluation, Vol., 9 Issue 2, pp 57 – 64, www.ejise.com.
    59. Han Wen-Ming, Huang Sun-Jen, (2007) “An empirical analysis of risk components and performance on software projects” The Journal of Systems and Software, Vol., 80, pp: 42–50
    60. Hartman, F., Ashrafi, R.A.,( 2004), “Development of the SMART Project Planning framework”, International Journal of Project Management  Vol.,22 pp:  499–510
    61. Heemstra, F.J., Kusters, R.J., de Man, H., (2003) “Guidelines for Managing Bias in Project Risk Assessment”  IEEE, Empirical Software Engineering, ISESE 2003, International Symposium on Digital Object Identifier: 10.1109/ISESE.2003.1237988, pp: 272- 280
    62. Herroelen Willy (2005) “Project Scheduling—Theory and Practice” Production and Operations Management Journal, Vol., 14, No., 4, pp: 413–432
    63. Hickey A. M., Davis A.M., (2003)a, “Elicitation Technique Selection: How Do Experts Do It?”, 11th IEEE International Requirements Engineering Conference, Sept 8-12, 2003 pp. 169-180.
    64. Hickey A.M., Davis A.M., (2003)b, “Requirements Elicitation and Elicitation Technique Selection: A Model for Two Knowledge-Intensive Software Development Processes”, IEEE, Proceedings of the 36th Annual Hawaii International Conference on System Sciences (HICSS’03), pp:96-105
    65. Hoermann Stefan, Schermann Michael, Krcmar Helmut (2010), “Towards understanding the relative importance of risk factors in IS projects: A quantitative perspective”, Proceedings of the 18th European Conference on Information Systems (ECIS 2010), pp. 1-18
    66. Huang Longjun, Jiang Changgen, Zhou Caiying, (2010) “The Research of Requirements Elicitation for Project”, IEEE,  Second International Conference on Multimedia and Information Technology Vol.2, pp: 302 – 305
    67. Hughes Bob, Cotterell Mike (2004) “Software Project Management” Tata Mc Graw-Hill, Third Edition. 
    68. Humphrey Watts, (2005) “Why Big Software Projects Fail: The 12 Key Questions” The Journal of Defense Software Engineering, Vol., 18, No.3, pp: 25-29
    69. IEEE Computer Society, (1997 )“IEEE Standard for Developing Software Life Cycle Processes”, IEEE Std 1074-1997, Software Engineering Standards Committee, IEEE Standards Board, September,1997, USA
    70. IEEE, IEEE Computer Society (1998)a, “IEEE Recommended Practice for Software Requirements Specifications” The Institute of Electrical and Electronics Engineers, Software Engineering Standards Committee of the IEEE Computer Society, IEEE Std 830-1998, USA
    71. IEEE, IEEE Computer Society, (1998)b “IEEE Std 1058-1998, IEEE Standard for Software Project Management Plans”, The Institute of Electrical and Electronics Engineers, Inc., New York, USA
    72. Iloiu Mirela, Iloiu Sorin, (2008) “Economic Analysis of E-Business Investment Projects”, Annals of the University of Petroşani, Economics, Vol., 8 No., (1), pp: 267-272 
    73. INTOSAI , National Audit Office, (2008) “Why IT projects fail”, IntoIT Journal , Issue 26, May 2008, UK, www.intosaiitaudit.org  
    74. Irani, Z., Sharif, A., Love, P.D., Kahraman, C., (2002) “Applying concepts of fuzzy cognitive mapping to model:The IT/IS investment evaluation process. International”, Journal of Production Economics vol.,75, pp.199–211.
    75. IT Governance Institute, ITGI (2003) “Board Briefing on IT Governance, 2nd Edition”. Rolling Meadows, IL; www.itgi.org.
    76. IT Governance Institute, ITGI (2005) “COBIT 4.0, Control objectives management guideline maturity models” IT Governance Institute, USA, ISBN 1-933284-37-4, www.itgi.org   
    77. IT Governance Institute, ITGI (2007) “Control Objectives for Information and related Technology (COBIT 4.1)”. USA. www.itgi.org.
    78. Jaafar Noor, Jordan Ernest (2009) “Information technology governance (ITG) practices and accountability of information technology (IT) projects – a case study in a Malaysian government-linked company (GLC)” Pacific Asia Conference on Information Systems (PACIS)2009 
    79. Jeffrey A. Hoffer, Joey F. George, Joseph S. Valacich, (2007) “Modern Systems Analysis and Design”, Prentice Hall, ISBN-10: 0132240769.
    80. Jeffrey W. Merhout, (2008) “Information Technology Auditing: A Value-Added IT Governance partnership between IT Management and Audit”, Communications of the Association for Information Systems, Volume 23, Article 26, pp. 463-482.
    81. Jiang James, Klein Gary, (2000) “Software development risks to project effectiveness” The Journal of Systems and Software, Vol., 52, pp: 3-10
    82. Johnstone David, Huff Sid, Hope Beverley (2006) "IT Projects: Conflict, Governance, and Systems Thinking" IEEE,  39th Annual Hawaii International Conference, Vol., 8  Digital Object Identifier: 10.1109/HICSS.2006.235 pp: 1-9
    83. Kailash J., Somendra P.,(2008) “Development of a framework to assess and guide IT investments :An analysis based on a discretionary–mandatory classification”, International Journal of Information Management, vol., 28 pp. 181–193.
    84. Karolak, D. W, (1997) “Software Engineering Risk Management”, IEEE, Computer Society press, New York 
    85. Karsak E. Ertugrul,  Sozer S., Alptekin S.E.,(2002) “Product planning in quality function deployment using a combined analytic network process and goal programming approach” Computers & Industrial Engineering, Vol. 44, pp:171–190
    86. Kasap D., Kaymak M., (2007), “Risk Identification Step of the Project Risk Management”, IEEE, Management of Engineering and Technology, Portland International Center for Digital Object Identifier: 10.1109/PICMET.2007.4349543, pp: 2116 - 2120
    87. Kasirun M. Zarinah, (2005), “A Survey on the Requirements Elicitation Practices Among Courseware Developers”, Malaysian Journal of Computer Science, Vol. 18, No. 1, pp: 70-77
    88. Katainen Tommi, Nahar Nazmun, (2008) “Using Methods and IT Tools Innovatively for the Management of International IS Development Projects” IEEE, Management of Engineering & Technology, Portland International Conference, Digital Object Identifier: 10.1109/PICMET.2008.4599805, pp:1851-1863
    89. Katainen, T.  Nahar, N. (2008)” Using Methods and IT Tools Innovatively for the Management of International IS Development Projects” IEEE, Issue Date: 27-31 July 2008 pp: 1851 - 1863 Print ISBN: 978-1-890843-17-5
    90. Kausar S., Tariq S., Riaz S., Khanum A., (2010) “Guidelines for the Selection of Elicitation Techniques” 6th International Conference on Emerging Technologies (ICET), 2010 pp:265-269
    91. Keil Mark (2000), “An Investigation of Risk Perception and Risk Propensity on the Decision to Continue a Software Development Project”, Journal of Systems and Software, Vol.53, pp: 145-157
    92. Kenett Ron S., Baker Emanuel R., (2010), “Process Improvement and CMMI for Systems and Software”, Taylor and Francis Group, Auerbach Publications, LLC, USA.
    93. Keung Jacky, (2009) “Software Development Cost Estimation using Analogy: A Review” IEEE, Software Engineering Conference, ASWEC '2009, Australian, pp: 327 – 336.
    94. Khan Asadullah, (2006) “Project Scope Management” Cost Engineering Journal, Vol. 48, No. 6, JUNE 2006, pp: 12-16
    95. Khoong C.M., Ku Y.W., (1994), “A Holistic Feasibility Study Framework for Decision Systems” IEEE Transactions on Systems, Man, and Cybernetics, Vol. 24. No. I, January 1994, pp:100 – 106
    96. Kim S.H. , Jang D.H. , Lee D.H., Cho S.H., (2000), “A methodology of constructing a decision path for IT investment”, Journal of Strategic Information Systems Vol.9, pp:17-38
    97. Kim, Y. Jin., Kang  H., Sanders G. Lawrence and Lee S. Tom, (2008) “Differential effects of IT investments: Complementarily and effect of GDP level”, International Journal of Information Management vol.,28, pp. 508–516
    98. Klakegg Jonny, Williams Terry, Magnussen Morten, Glasspool Helene, (2008), “Governance Frameworks for Public Project Development and Estimation”, Project Management Journal, Vol. 39, pp: Supplement, S27–S42
    99. Kooper M.N., Maes R., Roos Lindgreen E. O., (2010) “On the Governance of Information: Introducing a New Concept of Governance to Support the Management of Information” International Journal of Information Management, Vol., xx, pp: xx
    100. Kris Seeburn (2008), “COBIT as an IT Governance Mechanism” IT Governance Institute , ITGI, USA, www.itgi.org   
    101. Krishna P. Radha, Karlapalem K., Chiu D.K.W., (2004) “An ER framework for e-contract modeling, enactment and monitoring” journal of Data & Knowledge Engineering vol., 51, pp: 31–58
    102. Kutsch, E., Hall, M., (2005), “Intervening conditions on the management of project risk: dealing with uncertainty in information technology projects”, International Journal of Project Management, Vol., 23, pp: 591–599.
    103. Kwak Y., Stoddard J., (2004) “Project risk management: lessons learned from software development environment”, Technovation Journal, Vol., 24, pp: 915–920
    104. Larson Richard, (2008) “10 Steps to Creating a Project Plan” Watermark Learning, Inc, USA, http://www.projecttimes.com/articles/10-steps-to-creating-a-project-plan.html
    105. Lee Junghoon, Chihoon Lee, Young Jeong, (2008) “Governance Inhibitors in IT Strategy and Management: An Empirical Study of Korean Enterprises” Global Economic Review Vol. 37, No. 1, pp. 1-228.
    106. Lepage Darren (2009), “Driving Success in Substation Control and Information System Projects” Utility Automation and Engineering journal, February 2009, pp:34-42, www.utility-automation.com  
    107. Leslee N. Higgins, Debra T. Sinclair, (2008) “A New Look at IT Governance”, The Journal of Corporate Accounting & Finance, Vol.,19, Issue 5,  pp.31-36.
    108. Li Y.F., Xie M., Goh T.N., (2008)“Optimization of Feature Weights and Number of Neighbors for Analogy Based Cost Estimation in Software Project Management”, IEEE International Conference on Industrial Engineering and Engineering Management, IEEM 2008. pp: 1542 – 1546
    109. Liao, Hancheng; (2010), “Requirement Elicitation of Enterprise Informationization from view of VCA”, IEEE, 6th International Conference on Networked Computing (INC), pp: 1- 6
    110. Lin Chad, Huang Yu-An, Cheng Man-Shin, Lin Wo-Chung, (2007) “Effects of Information Technology Maturity on the Adoption of Investment Evaluation Methodologies: A Survey of Large Australian Organizations” International Journal of Management Vol. 24 No. 4, pp: 697- 711
    111. Lin Koong, Lin Chad, Tsao H. Yuan, (2005), “IS/IT Investment Evaluation and Benefit Realization Practices in Taiwanese SMEs”, Journal of Information Science and Technology vol.,2, No.,4 pp. 44-71
    112. Liu Frank, (2000), “Software Quality Function Deployment” Potentials, IEEE , Vol. 19 , Issue: 5 , Digital Object Identifier: 10.1109/45.890072 , pp: 14 – 16
    113. Longstaff T.A., Chittister C., Pethia R., Haimes Y., (2000) “Are we forgetting the risks of information technology?”, IEEE Computer Vol.,33 , Isu.,12, pp:43–51
    114. Love P., Irani Z., Edwards D., (2005) “Researching the investment of information technology in construction: An examination of evaluation practices” Automation in Construction vol.,14 , pp.569– 582.
    115. Love P., Irani, Z., (2004) “An exploratory study of information technology evaluation and benefits management practices of SMEs in the construction industry”. Information & Management journal, vol., 42, No., 1 pp. 227–242
    116. Lu X.N., Ma Q.G., (2004) “Risk Analysis in Software Development Project with Owners and Contractors” Engineering Management Conference 2004, IEEE International, Vol., 2 ,Digital Object Identifier: 10.1109/IEMC.2004.1407488 , pp: 789-793 
    117. Mahaney C. Robert , Lederer L. Albert, (2010) “ The role of monitoring and shirking in information systems project management” International Journal of Project Management, Vol., 28 pp: 14–25
    118. Mahring Magnus, Keil Mark, (2008) “Information Technology Project Escalation: A Process Model” Decision Sciences journal, Vol., 39, No., 2, pp:239-272
    119. Mahring Magnus, Mathiassen Lars,Keil Mark, Pries-Heje Jan (2008)"Making IT Project De-Escalation Happen:An Exploration into Key Roles" Journal of the Association for Information Systems, Vol. 9 Issue 8, pp: 463 462-496.
    120. Malik A. Afzal, Boehm Barry (2011), “Quantifying requirements elaboration to improve early software cost estimation” Information Sciences Journal, Vol, In Press,, Issue: 13, pp: 2747-2760
    121. Malkinson J. Terrance, (2001), “A "toolkit" for information technology proposal and project documentation” Professional Communication Conference, 2001. IPCC 2001. Proceedings. IEEE International Digital Object Identifier: 10.1109/IPCC.2001.971566, pp: 205 - 220
    122. Marnewick Carl,  Labuschagne Les (2011), “An investigation into the governance of information technology projects in South Africa”   International Journal of Project Management, Vol., 29, Issue 6, pp: 661-670
    123. Marten Simonsson,  Mathias Ekstedt, (2006) “Getting the Priorities Right: Literature vs Practice on IT Governance”  IEEE, Technology Management for the Global Future, PICMET 2006, Vol.,1, Digital Object Identifier: 10.1109/PICMET.2006.296548, pp: 18 – 26.
    124. McManus J., Wood-Harper T., (2007), "Understanding the Sources of Information Systems Project Failure", Management Services Journal, Autumn 2007, pp:38-43
    125. Mensah E. Kweku, (1997), “Critical Issues in Abandoned Information Systems Development Projects”, Communications of the ACM Vol., 40, No. 9, pp: 74-80
    126. Mohamed A. Hamada, Sherif A. Mazen , Ehab E. Hassanein, (2011), “Towards to Specific Approach for Information Systems (IS) Projects Governance” (ICICIS 2011), Fifth International Conference on Intelligent Computing and Information Systems, July 2011, Faculty of Computer &Information Science (FCIS), Ain Shams University, Egypt, pp: 213-219.
    127. Mohamed A. Hamada, Sherif A. Mazen , Ehab E. Hassanein, (2011), “The Role of the Pre-development Activities in Information Systems Projects’ Failure” The 46th Annual Conference on Statistics, Computer Science, and Operations Research, ISSR, Cairo University, Egypt, December, 26 -29, 2011. 
    128. Mohd. Sadiq, Javed Ahmad, Abdul Rahman, R. Suman, Shweta Khandelwal, (2010), “More on Adding Threat during Software Requirements Elicitation and Prioritization”, International Journal of Engineering and Technology, IACSIT, Vol.2, No.3 pp: 286-290
    129. Mojtahedi S. Mohammad , Mousavi S. Meysam , Makui Ahmad, (2010), “Project risk identification and assessment simultaneously using multi-attribute group decision making technique”, Safety Science journal, Vol.,48,  pp:499–507
    130. Muller Ralf, (2003) “Determinants for external communications of IT project managers” International Journal of Project Management, Vol. 21, pp: 345–354
    131. Muzaffar Zeeshan, Ahmed Moataz, (2010), “Software development effort prediction: A study on the factors impacting the accuracy of fuzzy logic systems” Information and Software Technology journal, Vol., 52, pp: 92–109
    132. Myrtidis A., Weerakkody V., (2008) “A Study of Information Systems Investment Evaluation in the Greek Banking Sector” Information Technology for Development, Vol. 14 (1) 11–30. 
    133. Nasution, M.F, Weistroffer, H.R., (2009), “Documentation in Systems Development: A Significant Criterion for Project Success”, IEEE, 42nd Hawaii International Conference on System Sciences, HICSS '09., pp: 1 - 9
    134. Nieto Morote A., Ruz Vila F., (2011), “A fuzzy approach to construction project risk assessment” International Journal of Project Management, Vol., 29, Issue 2, February 2011, pp: 220-231
    135. Nirup M. Menon, Byungtae Lee, (2000), “Cost control and production performance enhancement by IT investment and regulation changes: evidence from the healthcare industry”, Decision Support Systems vol.,30, pp.153–169
    136. NRC, National Research Council (2004) “A Review of the FBI’s Trilogy Information Technology Modernization Program”, Computer Science and Telecommunication Board, National Academies Press, Washington D.C., http://www.nationalacademies.org/nrc/.
    137. Nuseibeh Bashar,  Easterbrook Steve, (2000), “Requirements engineering: a roadmap”, ACM, ICSE '2000 Proceedings of the Conference on The Future of Software Engineering New York, NY, USA ISBN:1-58113-253-0, pp: 35-46
    138. Omar Anwar, (2009) “Uncertainty in Project Scheduling, Its Use in PERT/CPM Conventional Techniques” Cost Engineering Journal, Vol. 51, No. 7, pp: 30-34
    139. Pan Gary, Hackney Ray, Pan Shan (2008) “Information Systems implementation failure: Insights from prism” International Journal of Information Management, Vol., 28, pp: 259–269
    140. Parent Michael, Blaize Horner Reich, (2009) “Governing Information Technology Risk”, California Management Review Vol., 51, No., 3 spring, pp: 134-152.
    141. Park Robert E., (1995), “Checklists and Criteria for Evaluating the Cost and Schedule Estimating Capabilities of Software Organizations”, Software Engineering Institute, Carnegie Mellon University, Research Access, Inc., USA
    142. Paul L. Bowen, Cheung,  Fiona H. Rohde, (2007)  “Enhancing IT governance practices: A model and case study of an organization's efforts”, International Journal of Accounting Information Systems vol.,8 pp:191–221
    143. Peterson Ryan, (2004)  “Crafting Information Technology Governance”, information systems management, fall 2004, pp 7-22.
    144. PMI, Project Management Institute (2008) “A guide to the Project Management Body of Knowledge PMBOK Guide”, An American National Standard, Fourth Edition, PA 19073-3299.
    145. Posthumusa Shaun, Solms Rossouw (2005) “IT oversight: an important function of Corporate Governance” Computer Fraud & Security journal, Vol., June 2005, Issue 6, pp: 11-17.
    146. Radovanovic Dalibor, Radojevic Tijana, Lucic Dubravka, Sarac Marko (2010) “Analysis of methodology for IT governance and information systems audit” 6th International Scientific Conference May 13–14, 2010, Vilnius, Lithuania, Business and Management.
    147. Raghavan Sridhar, Zelesnik Gregory, Ford Gary, (1994), “Lecture Notes on Requirements Elicitation”, Software `Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, USA
    148. Raghupathi, W., (2007)   “Corporate Governance of IT: A Framework for Development”, Communications of the ACM, Vol. 50, No. 8, pp 94-99.
    149. Rajagopal, P., Lee, R., Ahlswede, T., Chia-Chu C., Karolak, D., (2005), “A New Approach for Software Requirements Elicitation”, IEEE, Sixth International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing, pp: 32 – 42
    150. Ram L. Kumar (2002), “Managing risks in IT projects: an options perspective”, Information & Management journal , Vol., 40 pp: 63–74
    151. Razali Rozilawati, Anwar Fares, (2011), “Selecting the Right Stakeholders for Requirements Elicitation: A Systematic Approach”, Journal of Theoretical and Applied Information Technology 30th November 2011. Vol. 33 No.2, pp: 250-257
    152. Ridley Gail, Young Judy and Carroll Peter,(2004) “COBIT and its Utilization: A framework from the literature” IEEE, System Sciences, Proceedings of the 37th Annual Hawaii International Conference  on Digital Object Identifier: 10.1109/HICSS.2004.1265566 
    153. Rodney A. Stewart, (2008), “A framework for the life cycle management of information technology projects: Project IT”, International Journal of Project Management, Vol., 26, Issue 2, pp: 203-212.
    154. Romero, M.; Vizcaino, A.; Piattini, M.; (2009) “Teaching Requirements Elicitation within the Context of Global Software Development” IEEE,International Conference on Computer Science (ENC), 2009 Mexican  pp: 232 – 239
    155. Ronnie Jia, Michael J., Blaize H. Reich, (2008) “IT Service Climate: An Extension to IT Service Quality Research”, Journal of the Association for Information Systems, Volume 9, Issue 5, pp. 294-320.
    156. Ropponen Janne, Lyytinen Kalle,(2000) “Components of Software Development Risk: How to Address Them? A Project Manager Survey IEEE Transactions on Software Engineering, Vol. 26, No. 2, pp: 98 – 112
    157. Rosacker, K., Olson L., (2008), “An Empirical Assessment of IT Project Selection and Evaluation Methods in State Government”, Project Management Journal, Vol. 39, No. 1, pp:49–58
    158. Sadiq Mohd, Shahid Mohd, (2009), “Elicitation and Prioritization of Software Requirements”, International Journal of Recent Trends in Engineering, Vol. 2, No. 3, pp:138-142
    159. Saunders R. G., (1990), “Project management in R&D: the art of estimating development project activities” Project Management Journal, Vol 8, No 1, pp:45-50
    160. Scasso R. Heredia, Larenas G. Santana (1991),“Project-breakdown structure: the tool for representing the project system in project management”, International Journal of Project Management, Vol., 9, Issue 3, pp:157-161
    161. Schmidt Roy, Lyytinen Kalle, Keil Mark, Cule Paul, (2001), “Identifying software project risks: an International Delphi Study”, Journal of Management Information Systems Vol., 17, No. 4, pp: 5-36. 
    162. Serafeimidis V., Smithson S., (2003), “Information systems evaluation as an organizational institution—Experience from a case study”, Information Systems Journal vol., 13 No.,(3),pp 251–274.
    163. Shang S., Seddon (2002) “Assessing And Managing The Benefits Of Enterprise Systems: The Business Manager's Perspective”, Information Systems Journal vol.,12 No., 4, pp. 271-299.
    164. Sharma Dev, Stone Merlin, Ekinci Yuksel, (2009), “IT governance and project management: A qualitative study” Database Marketing & Customer Strategy Management, Vol. 16, issue 1, pp: 29–50
    165. Sherer A. Susan (2004) “IS Project Selection: The Role of Strategic Vision and IT Governance”, IEEE, the 37th Annual Hawaii International Conference on System Sciences, Digital Object Identifier: 10.1109/HICSS.2004.1265564 
    166. Silvius A., (2006) “Does ROI Matter? Insights into the true Business Value of IT” The Electronic Journal Information Systems Evaluation Vol., 9, Issue 2, pp 93-104, www.ejise.com.
    167. Soaresa dos Santos, Vranckenb Jos, Verbraeckb Alexander, (2011), “User requirements modeling and analysis of software-intensive systems”, The Journal of Systems and Software Vol.,84 pp: 328–339
    168. Stepanek George (2005) " Software Project Secrets: Why Software Projects Fail" Apress, ISBN 1-59059-550-5,USA
    169. Stern Robert, Arias J. Carlos, (2011) “Review Of Risk Management Methods”, Business Intelligence Journal, Vol., 4, No.1, pp: 59-78 
    170. Sumner Mary, (2000), “Risk factors in enterprise-wide/ERP projects” Journal of Information Technology , Vol., 15,pp: 317-327
    171. Sun Ming, Oza Tejas (2008), “A Benefit Measurement Framework for an Online Contract Change Management System” TSINGHUA SCIENCE AND TECHNOLOGY, ISSN: 1007-0214 33/67, Vol., 13, No. S1, pp: 205-210
    172. Taimour A. Neimat, (2005) “Why IT Projects Fail”, The Project Perfect White Paper Collection, pp: 1-8, www.projectperfect.com.au
    173. Tesch Debbie, Kloppenborg Timothy, Frolick Mark (2007) “IT Project Risk Factors: The Project Management Professionals Perspective” Journal of Computer Information Systems, Summer 2007, pp: 61-69
    174. Tomi Dahlberg, Pirkko Lahdelma, (2007) “IT Governance Maturity and IT Outsourcing Degree: An Exploratory Study”, IEEE, 40th Hawaii International Conference on System Sciences.
    175. Tran T., Sherif J.S., (1995) “Quality Function Deployment (QFD): An Effective Technique for Requirements Acquisition and Reuse” Second IEEE International Software Engineering Standards Symposium, (ISESS'95) 'Experience and Practice',  pp: 191 - 200
    176. Turner J. Rodney, Muller Ralf, (2004) “Communication and Co-operation on Projects between the Project Owner as Principal and the Project Manager as Agent” European Management Journal Vol. 22, No. 3, pp: 327–336 
    177. Tuure Tuunanen, (2003), “A New Perspective on Requirements Elicitation Methods”, Journal of Information Technology Theory and Application Vol.,5 No.,3,pp: 45-62
    178. Uher E.Thomas, Toakley A. Ray, (1999), “Risk management in the conceptual phase of a project” International Journal of Project Management, Vol., 17, Issue 3, pp: 161-169.
    179. Uppal Kul B., (2008) “Project Management, Cost Engineering, Project Definition, Action Plans or What?” 2008 AACE International Transactions, PM.01.1
    180. USAID, United States Agency for International Development, (2010) “IT Project Governance Manual Version 1.1” CIO, A Mandatory Reference for ADS Chapter 577, USA
    181. Verner J., Sampson J., Cerpa N., (2008), “What factors lead to software project failure?” IEEE, Second International Conference on Research Challenges in Information Science, RCIS2008, pp: 71 – 80.
    182.  Vijayan Jaya, Raju G. (2011) “A New approach to Requirements Elicitation Using Paper Prototype”, International Journal of Advanced Science and Technology, Vol. 28, March, 2011, pp:9-16
    183. Von Wangenheim Christiane, Da Silva Djoni, Buglione Luigi, Scheidt Rafael, Prikladnicki Rafael, (2010) “Best Practice Fusion of CMMI-DEV v1.2 (PP, PMC, SAM) and PMBOK 2008” Information and Software Technology Journal, Vol., 52, Issue, 7, pp: 749-757
    184. Wallace L., Keil M., Rai A., (2004) “How software project risk affects project performance: an investigation of the dimensions of risk and an exploratory model”, Decision Sciences Vol., 35 Isu. 2, pp: 289–321.
    185. Wang T.G. Eric, Chen H.F. Jessica, (2006) “The influence of governance equilibrium on ERP project success” Decision Support Systems Vol., 41 pp: 708– 727
    186. Wang Yu-Ren, Gibson G. Edward (2010) “A study of preproject planning and project success using ANNs and regression models” Automation in Construction Journal, Vol.,19 , pp: 341–346
    187. Wanyama Tom, Far B. Homayoun (2005) “Towards Providing Decision Support for COTS Selection” IEEE, Electrical and Computer Engineering, Canadian  Conference on Digital Object Identifier; 10.1109/CCECE.2005.1557124, pp: 908-911
    188. Whitten, Jeffrey Bentley L., Lonnie D., (2007) “Systems Analysis and Design for the Global Enterprise”, MCGRAW HILL, ISBN  9780071107662.  
    189. Williams Terry , Klakegg O. Jonny, Magnussen O. Morten, Glasspool Helene (2010) “An investigation of governance frameworks for public projects in Norway and the UK” International Journal of Project Management Vol., 28 pp: 40–50
    190. Willson P., Carol P., (2008) “Exploring IT Governance in Theory and Practice in a Large Multi-National Organisation in Australia”, Information Systems Management, vol., 26, pp. 98–109.    
    191. Wood Michael,(2008), "Project Failure Statistics and Facts", PM Hut (Project Management Hut), http://www.pmhut.com/project-failure-statistics-and-facts, http://www.standishgroup.com/, September, 2008, 
    192. Xiaosong Li, Shushi Liu, Wenjun Cai, Songjiang Feng, (2009), “The Application of Risk Matrix to Software project Risk management”, IEEE, Information Technology and Applications, IFITA '09. International Forum on Vol., 2, Digital Object Identifier: 10.1109/IFITA.2009.542 , pp:480 - 483
    193. Xue yajiong, huigang liang, Boulton R. william, (2008) “Information Technology governance in information technology investment decision processes: the impact of investment characteristics, external environment, and internal context”, MIS Quarterly Vol. 32, No.1, pp: 67-96.
    194. Yan B., Benslimane Y., Yang Z., (2009), “IS Development Activities and Methodologies in Practice: A Survey of the IT Sector in China” IEEE, Issue Date: 8-11 Dec., 2009, Print ISBN: 978-1-4244-4869-2, pp: 598 - 602 
    195. Ye Tao, (2008), “A Study of Software Development Project Risk Management” IEEE, FITME '08, Future Information Technology and Management Engineering, Object Identifier: 10.1109/FITME.2008.125, pp: 309 - 312
    196. Yeo K.T., (2002), “Critical failure factors in information system projects”, International Journal of Project Management, Vol. 20, pp: 241–246
    197. Yong Hu, Jiaxing Huang, Juhua Chen, Mei Liu, Kang Xie, (2007), “Software Project Risk Management Modeling with Neural Network and Support Vector Machine Approaches”, IEEE, Conference on Natural Computation, ICNC 2007, Vol. 3, pp: 358-362
    198. Yong Hu; Xiangzhou Zhang; Xin Sun; Mei Liu; Jianfeng Du; (2009) “An Intelligent Model for Software Project Risk Prediction”, IEEE, Conference of Information Management, Innovation Management and Industrial Engineering, Vol., 1, pp: 629 - 632 
    199. Yongyi Shou; Ying Ying, (2005), “Critical Failure Factors of Information System Projects in Chinese Enterprises”, IEEE, International Conference on Services Systems and Services Management, Proceedings of ICSSSM '05. , Vol.2, pp: 823 – 827.
    200. Young Ralph R., (2002), “Recommended Requirements Gathering Practices” The Journal of Defense Software Engineering, Vol., 15, No.4, pp:9-12
    201. Young Ralph R., (2006), “Twelve Requirements Basics for Project Success” The Journal of Defense Software Engineering, Vol., 19, No.12, pp:4-8
    202. Zhang G. Peter, Keil Mark , Rai Arun, Mann Joan (2003), “Predicting information technology project escalation:A neural network approach” European Journal of Operational Research Vol.,146 pp: 115–129
    203. Zhang Jun-Guang, (2008) “Method Study of Software Project Schedule Estimation Guide” IEEE, 4th International Conference on Wireless Communications, Networking and Mobile Computing, pp: 1- 4
    204. Zheng Chan,  Feng  Jingchun, Li Ming, (2009) “Research on IT Project Contract Model” IEEE, Intelligent Computation Technology and Automation, ICICTA'09, Second International Conference on Vol., 2, pp: 172 - 175
    205. Zheng-Wei Huang, (2009) “Cost Estimation of Software Project Development by Using Case-Based Reasoning Technology with Clustering Index Mechanism” IEEE, Fourth International Conference on Innovative Computing Information and Control (ICICIC), pp: 1049 – 1052.
    206. Zia A., Rashid K., Zaman, (2011) “Software cost estimation for component based fourth-generation-language software applications”, IET Software, Vol. 5, Iss.1, pp: 103–110.

















Annexes  
Annex 1: Research Questionnaire (1)
Annex 2: Research Questionnaire (2)
Annex 3: Best practices checklists 














Annex 1: Research Questionnaire (1)
Verifying the application of the governance components 

















Research Questionnaire
This Questionnaire aims to measure the application extent for the components of the designed governance framework through developing IS projects in the Egyptian software companies. This Questionnaire contains five groups of governance components and it is introduced to the project managers of the common software companies in Egypt. The governance components are; 
    1. Defined policy’ actions and  principles (DP)
    2. Well-defined procedures (WP)
    3. Best practices (BP)
    4. Suggested practices and checklists (SBP)
    5. Expected deliverables  (ED)
No.
Governance components for the project Feasibility Study
Yes
No
The policy is: Integrated feasibility study governance based on tangible and intangible costs and benefits 
Do you adopt the following Policy’s actions and principles when executing the project feasibility study?  
DP1
Define the most favorable scenario to guarantee proper implementation of project feasibility study


DP2
Decrease IS projects’ failure which are derived from the project feasibility study


DP3
Consider the qualitative costs and benefits within project feasibility study


DP4
Improve the performance of project feasibility study


DP5
Enhance the possible deliverables of IS project 


Do you implement the following Well-Defined Procedures for the project feasibility study?  
WP1
Study the main characteristics of the present system (old system, if it manual or computerized)


WP2
Performing the “PIECES” Framework to identify the project problems, 


WP3
Study the new project idea or need and all life cycle constraints and benefits


WP4 
Investigating the objectives and other requirements for the new system (what needs to change?)


WP5
Assure the Objectives, Purpose and the Scope of the intended project, 


WP6
Explain the advantages and disadvantages of the intended IS project


WP7
Verify the objectives, purpose and the scope of the intended IS project


WP8
Estimate the traditional appraisal Techniques for the intended project (NPV, ROI, Payback period),


WP9
Test the stability of the intended project with the main Factors and variables of the organization,


WP10
Perform the five types of feasibility studies for the intended project (Economic feasibility, Technical feasibility, Legal/Cultural feasibility, Operation feasibility and Schedule feasibility)


WP11
Quantifying the qualitative benefits and costs (Intangible Costs and Benefits)


WP12
Calculate the Cost/ Benefits Analysis 


Do you consider the following Best Practices within the project feasibility study?  
BP1
Strengths, weaknesses, and improvement opportunities for the projects should be identified periodically and as needed


BP2
Appraise the projects periodically and as needed to maintain an understanding of their strengths and weaknesses


BP3
Establish and maintain guidelines to determine which issues are subject to a formal evaluation process


BP4
Assure that all intangible costs and benefits are completely estimated and considered during evaluation the economic feasibility of IS projects


BP5
Study and explain the viability of business needs completely  


BP6
Keep away from to initiate the projects according to inaccurate reasons and trivial needs


BP7
Confirm the consistency between the organization's business needs and the Information System functionalities 


BP8
Confirm that all types of feasibility studies (technical, operational, legal, economical, and schedule) are implemented completely 


BP9
Assess the gap between technology and the existing ability


BP10
Realize the ability to measure the feasibility during the project development phases


BP11
Stop to proceed the project if it isn’t viable 


BP12
Remove disagreement between the project costs and the budget.


BP13
Estimate all types of projects’ costs and benefits completely


BP14
Early determine the technical and operational needs for the projects 


BP15
Eliminate poor competencies experiences, skill shortages and improper financial management techniques


BP16
Avoid as much as possible the higher costs of capital investment 


BP17
Avert the ambiguous identification for the margin between project costs and benefits 


BP18
Don’t fear from project cancelation, if it isn’t feasible at any point 


BP19
Be aware to distinguish the "black hole" projects


BP20
Realize the ability to assess the project viability


BP21
Recognize and use the financial appraisal techniques during economic feasibility 


BP22
Taking into account the project which is feasible (now) maybe  infeasible at any later point and time


BP23
Avoid the long payback period for the cost of capital investments 


BP24
Assure that development costs don’t exceed any benefits that the system may bring throughout its useful life 


Do you adopt the following suggested practices when executing the project feasibility study?  
SBP1
Quantifying the Cost/Benefit Analysis which classify and estimate the intangible benefits and costs and weighted them to create a real Cost/Benefit Analysis. 


SBP2
“Check the Project viability” which examines three groups of critical success factors to assure if the project worth to implement or not 


SBP3
“Setting Feasibility Checkpoints” to reassess the project feasibility at many points in all project’ phases 


SBP4
“Calculate Traditional Appraisal Techniques” to analyze the financial aspects of IS project


Do you confirm to get the following Deliverables after executing the project feasibility study?  
ED1
Define the project business problem clearly 


ED2
Define the project subject and scope clearly


ED3
Define the technology that will be used in project development


ED4
State the project objectives and explain whether they will be met or not


ED5
List all the economic costs and benefits


ED6
Provide a suggested time table for the project implementation


ED7
List detailed feasibility assessment at technical, economic, schedule and operational aspects


ED8
Give a brief description for business organization


ED9
Predict any critical risk factors such as defects in economic stability


ED10
Outline the final decision and recommendations for the intended project


No.
Governance components for the project Requirements Elicitation
Yes
No
The policy is: Elicit complete project’s requirements depend on multiply sources. 
Do you adopt the following Policy’s actions and principles when executing the project Requirements Elicitation?  
DP1
Define the most favorable scenario to guarantee proper implementation of project requirement elicitation


DP2
Decrease IS projects’ failure which are derived from the project requirement elicitation


DP3
Improve the performance of project requirement elicitation


DP4
Enhance the possible deliverables for IS projects 


Do you implement the following Well-Defined Procedures for the project Requirements Elicitation?  
WP1
Collect information about user needs and expectations, 


WP2
Determine the participants in the system to be developed (project stakeholders),


WP3
Coach and analyze the Project Stakeholders


WP4 
Write descriptions of user needs,


WP5
Classify and prioritize system requirements,


WP6
Examine the elicitation techniques to choose the appropriate techniques and tools to use 


WP7
Eliciting the requirements from stakeholders and other sources, 


WP8
Understanding the application domain


WP9
Determine those functional and non-functional requirements,


WP10
Develop and Check the Prototype for the project requirements


WP11
Manage the initial requirements changes, 


WP12
Check and judge the result of requirement elicitation. 


Do you consider the following Best Practices within the project Requirements Elicitation?  
BP1
Confirm that Coordination and collaboration of the project’s elicitors  with relevant stakeholders is conducted


BP2
Elicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product life cycle


BP3
Develop an understanding with the requirements providers on the meaning of the requirements


BP4
Obtain commitment to the requirements from the project participants


BP5
Manage changes to the requirements as they evolve during the project


BP6
Maintain the requirements change history with the rationale for the changes


BP7
Maintain requirements traceability to ensure that the source of lower level (derived) requirements is documented with Generate the requirements traceability matrix


BP8
Identify inconsistencies between the project plans and the requirements


BP9
Provide adequate resources for performing the requirements elicitation 


BP10
Identify and involve the relevant stakeholders of the requirements elicitation as planned


BP11
Review the activities, status, and results of the requirements elicitation with higher level management and resolve issues


BP12
Establish and maintain quantitative objectives for the requirements elicitation that address quality and process performance based on customer needs and business objectives


BP13
Identify and correct the root causes of defects and other problems in the requirements elicitation


BP14
Stakeholder needs, expectations, constraints, and interfaces should be collected and translated into customer requirements


BP15
Eliminate misunderstanding and complexity of the problem domain (misunderstanding the domain due to the complex nature of the task; some properties of the problem space are not fully investigated; and, mistaken assumptions are made)


BP16
Select the appropriate stakeholders whose will be involved in requirements elicitation from the right subject at the right time


BP17
Communicate the allowed changes in requirements to all project’s parties


BP18
Exclude Changes in requirements without a permit of Change Control Board (CCB) 


BP19
Rectify all Communication problems, lack of communication among developers and between developers and users


BP20
Be aware to adjust project costs and timeline to the accepted requirement changes 


BP21
Avoid depending on single method to elicit the project requirements 


BP22
Elicit the project requirements from unlimited sources of stakeholders.


BP23
Set change management with understand the impact analysis of changing requirements


BP24
Avoid Inadequate/poor requirement traceability 


BP25
Depend on appropriate, complete, and accurate documentations


BP26
Confirm as possible that requirements are translating correctly to written natural language


BP27
Support adequate training and experience of the requirement engineer


BP28
Increase the awareness of all sources of requirements 


BP29
Support the communication among groups of people working together


BP30
Involve all users at all times during requirement development


BP31
Review and update knowledge, skills, or experience to perform tasks 


BP32
Establish more mechanisms to resolve the conflicting requirements and needs


BP33
Understanding the feasibility and risks associated with requirements elicitation


BP34
Complete understanding of hardware and software interface specification 


BP35
Good management of people and resources within requirements elicitation


BP36
Perceive the impact of technological, historical, organizational, and individual changes  to requirement elicitation   


BP37
User needs should be well-understood and interpreted while resolving the conflicting requirements


BP38
Users should be given adequate time available for requirements gathering


Do you adopt the following suggested practices when executing the project Requirements Elicitation?  
SBP1
“CSF for Requirement Elicitation Checklist” which contains the most critical success factors to achieve accurate requirement elicitation 


SBP2
“Customize Quality Function Deployment (QFD)” to facilitate the requirement elicitation through providing a visual connective process and translate the customer’ needs into technical characteristics for the project’ product.  


Do you confirm to get the following Deliverables after executing the project Requirements Elicitation?  
ED1
User requirements Statements in natural language, included with the diagrams of the services that the system will provide with the operational constraints 


ED2
Written for customers System requirements, a structured document with setting out detailed descriptions of the system services Written as a contract between client and contractor


ED3
High level Software specification, a software description which is written for developers to serve as a basis for a design or implementation 


ED4
System functions and no-functions requirements, an explanation of all system functions and no-functions requirements which satisfy the users’ needs


ED5
Assistant elicitation documents, JAD session results, system prototype and other reports such as the accepted requirement changes by the Change Control Board 



No.
Governance components for the project Risk Management
Yes
No
The policy is: Minimum level of project’s risks through efficient risk management governance 
Do you adopt the following Policy’s actions and principles when executing the project risk management?  
DP1
Define the most favorable scenario to guarantee proper implementation of project risk management


DP2
Decrease IS projects’ failure which are derived from the project risk management


DP3
Improve the performance of project risk management


DP4
Enhance the best possible deliverables for IS projects 


Do you implement the following Well-Defined Procedures for the project risk management?  
WP1
Risk Management Planning to decide how to approach, plan, and execute risk management activities for the intended project


WP2
Risk Identification, which is discovering, determining, defining, describing, documenting and communicating risks before they become problems and adversely affect the project


WP3
Risk Analysis, estimate the probability of occurrence and the seriousness of impact if they occur


WP4 
Risk Assessment and Prioritization, assessing and combining their probability of occurrence and impact. The purpose of risk assessment is to measure the impact of the identified risks on a project depending on the available data 


WP5
Calculate Risk Exposure,  (Risk Exposure (RE) = P × C), Where P = probability of occurrence for a risk and C is the impact of risks 


WP6
Determine Risk Response strategy, developing options and actions to enhance opportunities and to reduce threats to the project objectives


WP7
Risk Monitoring and Control, the process of implementing risk response options and actions, tracking identified risks, monitoring residual risks, identifying new risks, and evaluating the risk strategies effectiveness throughout the project life cycle 


Do you consider the following Best Practices within the project risk management?  
BP1
Monitor risks against those identified in the project plan


BP2
Collect and analyze the risk issues and determine the corrective actions necessary to address the issues


BP3
Define the parameters used to analyze and categorize risks, and the parameters used to control the risk management effort


BP4
Establish and maintain the strategy to be used for risk management


BP5
Risks should be identified and analyzed to determine their relative importance and impact


BP6
Identify and document the risks associated with cost, schedule, and performance in all appropriate product life-cycle phases


BP7
Review all elements of the work breakdown structure as part of identifying risks to help ensure that all aspects of the work effort have been considered


BP8
Review all elements of the project plan as part of identifying risks to help ensure that all aspects of the project have been considered


BP9
Evaluate and categorize each identified risk using the defined risk categories and parameters, and determine its relative priority


BP10
Risks should be handled and mitigated, where appropriate, to reduce adverse impacts on achieving objectives


BP11
Develop a risk mitigation plan for the most important risks to the project, as defined by the risk management strategy.


BP12
Identify the persons or group responsible for addressing each risk, also Determine the cost-to-benefit ratio of implementing the risk mitigation plan for each risk 


BP13
Monitor the status of each risk periodically and implement the risk mitigation plan as appropriate


BP14
Establish a schedule or period of performance for each risk handling activity that includes the start date and anticipated


BP15
Risks should be re-assessed, controlled, and managed through the project development 


BP16
Eliminate as much as possible the conflict between project’s departments and functions  


BP17
Consider the necessity of increasing the risk management efforts exponentially, according to the increase of project size and complexity.


BP18
Give equal attention to all risk factors, not to one risk factor over each others


BP19
Depend on both qualitative and quantitive risk analysis methods


BP20
Give more interest to risk identification which is the most critical phase in risk management. 


BP21
Calculate the Risk Reserve for the project and adjust the cost according it


BP22
Do best efforts with  obtaining sufficient details within the project’s risk planning 


BP23
Incorporate the Risks’ impact into the project plan 


BP24
Satisfy the required knowledge, experience and skills for the project team 


BP25
Work to achieve all end-user expectations as much as possible


BP26
 Use the appropriate development methodology and avoid Changing of technology as much as possible


BP27
Project Managers should consider the best practices and lessons learned from the previous projects


BP28
Constitute  sufficient and good risk management practices and documentations


BP29
 Set the correct assumptions regarding risk analysis 


BP30
Support good communication among customers, developers and users 


BP31
Provide adequate training for persons’ responsible of risk management process.


BP32
Establish explicit definition for the quality standards of software project 


BP33
Make redesign business processes to match the project risks as much as possible


BP34
Make good expectation as much as possible to estimate the probability of project risk factors.  


BP35
Use the mathematical models to evaluate the risk exposure 


BP36
Prepare good and consistent project risk plan 


BP37
Confirm that  the suitable risk response strategy is chosen and applied  


BP38
Continue to make risk evaluation during the project life phases 


BP39
Eliminate the conflicts between system users


Do you adopt the following suggested practices when executing the project risk management?  
SBP1
“Comprehensive List of Risk Factors” whereby the project risks are classified into thirteen main categories, these thirteen categories are branched into 170 sub-Factors 


SBP2
“Assigning the Risk Probability” to facilitate estimating the probability of project’ risk factors, 


SBP3
“Assigning Risk Reserve” is an estimation value expresses the cost of project risks in monetary form, this value must be added to the project cost estimation 


Do you confirm to get the following Deliverables after executing the project risk management?  
ED1
List of identified project risk factors


ED2
The probability of the identified risk factors 


ED3
Risk Impact (magnitude of the loss) of each identified risk factors


ED4
Risk Exposure, which is the simple calculation to give a numeric value of risk factors. it enables different risks to be compared and prioritized


ED5
Project Risk Reserve, expresses the cost of project risks in monetary form to keep the chance of IS project success if the risks are occurred. 


ED6
Contingency plan that describes what to do if certain risks are materialized. 


ED7
the suggested risk response strategies 


No.
Governance components for the project Cost Estimation
Yes
No
The policy is: Comprehensive and balanced project’s cost estimation integrating supplemental costs
Do you adopt the following Policy’s actions and principles when executing the project cost estimation?  
DP1
Define the most favorable scenario to guarantee proper implementation of project Cost Estimation


DP2
Decrease IS projects’ failure which are derived from the project Cost Estimation


DP3
Improve the performance of project Cost Estimation


DP4
Enhance the best possible deliverables for IS projects 


Do you implement the following Well-Defined Procedures for the project cost estimation?  
WP1
Review the Project Scope defection accurately


WP2
Validate the project requirements elicitation with analyzing the functional and non-functional requirements 


WP3
Develop work breakdown structure (WBS), 


WP4 
Determine the size of project’ tasks and activities, Based on WBS, 


WP5
Estimate the project size in Source Lines of Code (SLOC) or function point by using one or more cot estimation techniques 


WP6
Convert project size into efforts, Project effort =


WP7
Add Project Supplemental efforts, Project time schedule, 


WP8
Calculate the project duration based on available resources and project efforts 


WP9
Project duration = 


WP10
Estimate Project Costs 


WP11
Assess the Impact of project Risks, 


WP12
Adjust the project cost to risks, 


WP13
Validate and verify project estimation, and budget with estimate documentation. 


Do you consider the following Best Practices within the project cost estimation?  
BP1
Establish and maintain estimates of the attributes of the projects’ work product and tasks


BP2
Use appropriate methods to determine the attributes of the work products and tasks that will be used to estimate the resource requirements


BP3
Estimate, as appropriate, the labor, machinery, materials, and methods that will be required by the project


BP4
Estimate the project effort and cost for the work products and tasks based on estimation rationale


BP5
Include supporting infrastructure needs when estimating effort and cost


BP6
Collect the models or historical data that will be used to transform the attributes of the work products and tasks into estimates of the labor hours and cost


BP7
Consider the indirect costs estimation for the non-technical activities 


BP8
Adjust the project costs to risks 


BP9
Support the consistent between desired capabilities to available budgets, schedules, and skilled


BP10
Project estimation should based on more than one estimation technique   


BP11
Create a historical database to retain the estimated data 


BP12
Confirm to proper usage and analysis of the historical estimation data 


BP13
Develop the estimation competencies  for project leadership and management


BP14
Establish well-defined requirements for the project estimated activity 


BP15
Avoid to perform cost estimate based on imprecise requirements


BP16
Consider the amplification of project requirements at the late of project life-cycle 


BP17
Refuse  the frequent user change requests without change controls


BP18
Developers must be involved during the project cost estimation process 


BP19
Assess the staffing levels and skills accurately 


BP20
Avoid to force the estimation to match the resources available


BP21
Do best efforts as much as possible to meet the project costs 


BP22
Consider and expect to some extent the project’ size growth in estimates 


BP23
Establish a proper and integrated WBS


BP24
Keep the estimate current and updated  


BP25
Give sufficient time on software sizing


BP26
Use the suitable estimation methodologies 


BP27
Gather sufficient and complete project requirements  


BP28
Consider the historical estimates as basis for analogy due to differences in languages and methodologies


BP29
The schedule and effort allocations should consistent with historical experience


BP30
Avoid unrealistic estimation efforts 


BP31
Use previous knowledge to estimate software size, cost, and schedule


BP32
Always enrich  cost estimation competencies for project estimators and establish good Budget Management 


Do you adopt the following Suggested Practices when executing the project cost estimation?  
SBP1
“Comprehensive Cost Estimation Model (CCEM)” to conquer the problems of depending on one cost estimation technique by using mixture of estimation techniques and making the cost estimation process more accurate 


SBP2
“Critical Success Estimation Factors (CSEF)” to produce realistic and accurate cost estimation 


Do you confirm to get the following Deliverables after executing the project cost estimation?  
ED1
Refined project requirements and constraints


ED2
Refined software functional requirements


ED3
Project-work breakdown structure (WBS) including the attributes of work elements


ED4
List of identified Project Risks 


ED5
Methods that used to estimate software sizing


ED6
Estimation of Software sizing for all project functions and activities in SLOC


ED7
Methods that used to estimate project efforts


ED8
Complete estimation for project efforts for all work of WBS (in person-months)


ED9
Total project Effort estimation


ED10
Methods that used to estimate project costs


ED11
Costs of project procurements


ED12
Costs of additional and supplemental project activities


ED13
Cost estimates for identified project risks


ED14
Total cost estimation (in dollars)


ED15
Problems that are founded through the project cost estimation


No.
Governance components for the project Plan Development and Schedule
Yes
No
The policy is: Comprehensive and unambiguous project planning for all projects’ activities
Do you adopt the following Policy’s actions and principles when executing the project Plan Development and Schedule?  
DP1
Define the most favorable scenario to guarantee proper implementation of project Plan Development and Schedule


DP2
Decrease IS projects’ failure which are derived from the project Plan Development and Schedule


DP3
Improve the performance of project Plan Development and Schedule


DP4
Enhance the best possible deliverables for IS projects 


Do you implement the following Well-Defined Procedures for the project Plan Development and Schedule?  
WP1
Describe the project outlines


WP2
Define project roles and responsibilities


WP3
Define the project goals and objectives


WP4 
Develop the project charter


WP5
Organize a kickoff meeting,


WP6
Develop the project Scope Statement,


WP7
Develop work breakdown structure (WBS),


WP8
Establish the project repository, 


WP9
Define activity specifications and planning the Staff, 


WP10
Planning the project risks management,


WP11
Planning project cost estimation and budgeting, 


WP12
Planning the project schedule, 


WP13
Define the project communications,


WP14
Setting reviews at the end of each phase,


WP15
Determine project quality specifications


WP16
Specify Change and Configuration Management


Do you consider the following Best Practices within the project Plan Development and Schedule?  
BP1
Plan for necessary resources, knowledge and skills needed to perform the project


BP2
Plan and manage the involvement of identified stakeholders


BP3
Review all plans that affect the project to understand project commitments


BP4
Reconcile the project plan to reflect available and estimated resources


BP5
Monitor and control the project planning process against the plan for performing the process and take appropriate corrective action


BP6
Actual performance and progress of the project are monitored against the project plan


BP7
Integrate the project plan and the other plans that affect the project to describe the project’s defined process


BP8
Incorporate into the project plan the definitions of measures and measurement activities for managing the project


BP9
Define and document measurable quality and process performance objectives for the project and Establish traceability to the project’s quality


BP10
Define clear objectives and goals for the project earlier.


BP11
Rectify the imprecise and ambiguous components of the project plan 


BP12
Eliminate the Lack of Resources & inadequate staff to meet the schedule


BP13
Encourage and sustain the competencies of project planners (skill/experience) 


BP14
Prepare good plan to organize kickoff meeting 


BP15
At all times manage the project according to the project plan


BP16
Define completely the project roles and responsibilities 


BP17
Avoid Unrealistic schedules and deadlines 


BP18
Project changes should be managed efficiently  


BP19
Activate the role of configuration management and control procedures 


BP20
Establish well-define test planning 


BP21
Make reviews at the end of each phase 


BP22
Establish Contingency plan to handle problems that appear during the project development 


BP23
Set effective internal communication 


BP24
Give more interest for tasks in the critical path.


BP25
Depending on appropriate planning, communication, and technology skills.


BP26
Confirm to establish accurate estimating of project durations to create realistic schedule


BP27
Minimizing task dependencies to avoid delays caused by one task waiting for another task to complete


BP28
Review the structure of WBS according to the project scope statement


BP29
Define correct assumptions regarding resource availability 


BP30
Establish review and approval activities within the project


BP31
Consider and organize the interdependencies between tasks 


BP32
Beware that the delivery date impact the project schedule 


Do you adopt the following suggested practices when executing the project Plan Development and Schedule?  
SBP1
“Project Plan Components Checklist” to verify the most technical components of the project plan are completely incorporated. 


SBP2
“Schedule success factors Checklist” to guarantee a realistic schedule for the project activities progress against the overall project plan


Do you confirm to get the following Deliverables after executing the project Plan Development and Schedule?  
ED1
Quality Plan


ED2
Risk management plan 


ED3
Communication Plan


ED4
Logistics plan


ED5
Quality Assurance Plan 


ED6
Kick-off Meeting plan


ED7
Project schedule plan


ED8
Project resource plan


ED9
Contingency Plan


ED10
Delivery Plan


ED11
Installation Plan


ED12
Test Plan


ED13
Support Plan


ED14
Training Plan


ED15
Consultancy Plan


ED16
Configuration Management Plan














Annex 2: Research Questionnaire (2)
Examine the reliability of the governance framework 



















Research Questionnaire
This Questionnaire aims to examine the reliability of Governance on the pre-development activities as a solution to decrease IS projects’ failures and improve projects success.  Governance of IS projects are related to project’s activities. It provides a comprehensive consistent method of controlling the project and ensuring its success. It also provides the structure, through which the objectives of the project are set, and the means of monitoring performance to attain those objectives.
The suggested Governance Framework is based on five Governance components: 
    • Policies and their actions and principles
    •  Well-defined procedures to execute the pre-development activities. 
    • Best practices to reduce the failure within the pre-development activities.
    • Suggested practices and Checklists to improve the performance of the pre-development activities.
    • Define the expected deliverables for the pre-development activities.
Also, the selected pre-development activities that will be examined are; 
1) Project Feasibility Study, 
2) Project Requirements Elicitation,
3) Project Risk Management, 
4) Project Cost Estimation and 
5) Project plan development and schedule.
Part one: Examine the impact of “Governance Framework” on IS project’ failures that are related to the selected pre-development activities. 
    1. Project Feasibility Study ,Adopting the following governance components:-
1.1. Define the policy’ action and principles for the Project Feasibility Study
1.2 Executing Project Feasibility Study through the well-defined procedures; Study the main characteristics of the present system, Performing the “PIECES” Framework to identify the project problems, Assure the Objectives, Purpose and the Scope of the intended project, Estimate the traditional Evaluation Techniques for the intended project (NPV, ROI, Payback period), Test the stability of the intended project with the main Factors and variables of the organization, performing the all types of feasibility studies for the intended project and Quantifying the qualitative benefits and costs. 
1.3 Setting Best practices to reduce the failure within the project Feasibility Study. These practices are based on guidance instructions that must be considered during the project development; also comprise the most lessons learned from the previous successful projects. 
1.4 Suggested practices and checklists such as “Quantified and Qualitative Cost/Benefit Analysis” to create a real Cost/Benefit Analysis, “Check the Project viability” to assure if the project worth to implement or not, “Analyze appraisal techniques to analyze the financial aspects of IS project and “Setting Feasibility Checkpoints” to reassess the project feasibility at many points in all project’ phases.    
1.5 Defining the expected deliverables of Project Feasibility Study. 
Do you think these Governance Components can decrease the following failure reasons?
Main failure reasons related to 
Project Feasibility Study
Strongly Agree
Agree
Disagree

Strongly disagree
N/A
Underestimating the gap between technology and ability





Inability to provide investment capital  





Misusing of financial resources and weak financial management 





Long payback period for the cost of capital investments 





Development cost exceeds any benefits that the system may bring throughout its useful life 





Inconsistency between the organization's business needs and the Information System functionalities 





Usage of inappropriate technology (immature, new, …….tech) 





Losing control of the project resources





Low IS project viability and priority 





Ignoring intangible benefits and costs 





Inability  to achieve the desired benefits and critical services 





Ignoring one or more types of feasibility studies (technical, operational, legal, economical, and schedule)





    2. Project Requirements Elicitation, Adopting the following governance components:-
2.1. Define the policy’ action and principles for the Project Requirements Elicitation
2.2 Executing Project Requirements Elicitation through the well-defined procedures; Collect information about user needs and expectations, Write descriptions of user needs, Determine the participants in the system to be developed (project stakeholders, analyzing the stakeholders, Understanding the application domain), Classify and prioritize system requirements, Choose the appropriate techniques, approaches and tools to use, Eliciting the requirements from stakeholders and other sources, Determine those functional and non-functional requirements, Manage the initial requirements changes, Check and judge the result of requirement elicitation. 
2.3 Setting Best practices to reduce the failure within the project Requirements Elicitation. These practices are based on guidance instructions that must be considered during the project development; also comprise the most lessons learned from the previous successful projects.
2.4 Suggested practices and checklists such as “Requirement Elicitation Checklist” that contains the most critical success factors to achieve accurate requirement elicitation, and “Customize Quality Function Deployment (QFD)” to facilitate the difficulties of requirement elicitation and manages the requirements changes.    
2.5 Defining the expected deliverables of Project Requirements Elicitation. 
Do you think these Governance components can decrease the following failure reasons?
Main failure reasons related to
Project Requirements Elicitation
Strongly Agree
Agree
Disagree
Strongly disagree
N/A
Misunderstanding of user requirements and real customer needs 





Lack of user involvement 





Changing requirements during the project’ development phases 





Customer / Users had unrealistic expectations 





 Incomplete and Inappropriate Requirements 





Unclear/misunderstood project’ scope, goals and objectives 





Users did not give adequate time for gathering requirements





Lack of top management involvement and support 





Ambiguous business needs and unclear vision 





Conflicts of interest between different user’s groups 





No method for requirements elicitation 





    3. Project Risk Management, Adopting the following governance components:-
3.1. Define the policy’ action and principles for the Project Risk Management
3.2 Executing Project Risk Management through the well-defined procedures; Risk Management Planning, Risk Identification, Risk Analysis, Risk Assessment and Prioritization, Calculate Risk Exposure, Determine Risk Response strategy, Risk Monitoring and Control. 
3.3 Setting Best practices to reduce the failure within the project Risk Management. These practices are based on guidance instructions that must be considered during the project development; also comprise the most lessons learned from the previous successful projects.
3.4 Suggested practices such as “Comprehensive Project Risk Identification Tool” to facilitate the process of risks identification. “Assigning the Risk Probability” to Estimate the probability of the project’ risk factors, and “Assigning Risk Reserve” to keep the chance of project success if the risks have occurred.    
3.5 Defining the expected deliverables for Project Risk Management. 
Do you think these Governance components can decrease the following failure reasons?
Main failure reasons related to
Project Risk Management 
Strongly Agree
Agree
Disagree

Strongly disagree
N/A
Conflict between system’ users





Risks were not re-assessed, controlled, or managed through the project development 





Risks’ impact isn’t incorporated into the project plan 





Lack of required team knowledge, experience and skills 





Failure to achieve all end-user expectations 





Inappropriate development methodology 





Project Managers don’t consider the best practices and lessons learned 





Insufficient and poor risk management 





Incorrect assumptions regarding risk analysis 





Poor communication among customers, developers and users 





Changing of technology 





No change controls 





Applying improper risk response strategy 





Insufficient allocating the project’ Risk Reserve 





    4. Project Cost Estimation, 
Adopting the following governance components:-
4.1. Define the policy’ action and principles for the Project Cost Estimation  
4.2. Executing Project Cost Estimation  through the well-defined procedures; Define Project Scope, Specify project requirements and analyze project functional, Develop work breakdown structure (WBS), Determine the size of project’ tasks and activities, Convert project size into efforts, Add Project Supplemental efforts, Project time schedule, Estimate Project Costs, Assess the Impact of project Risks, Adjust the project cost to risks, Validate and verify project estimation, and budget with estimate documentation. 
4.3. Setting best practices to reduce the failure within the project Cost Estimation. These practices are based on guidance instructions that must be considered during the project development; also comprise the most lessons learned from the previous successful projects. 
4.4. Suggested practices and checklists such as “Comprehensive Cost Estimation Model (CCEM)” to make the cost estimation more realistic and stable, and “Critical Success Estimation Factors (CSEF)” to produce realistic and accurate cost estimation.    
4.5. Defining the expected deliverables of Project Cost Estimation. 
Do you think these Governance components can decrease the following failure reasons?
Main failure reasons related to
 Project Cost Estimation
Strongly Agree
Agree
Disagree

Strongly disagree
N/A
Overruns in costs and time 





Unrealistic estimation efforts 





Failing to meet the project costs 





Poor estimation methods 





Developers not involved in the estimation process 





Inexistence of historical database to retain the estimated data 





Ignoring the indirect costs estimation of the non-technical activities 





Weak estimation competencies and bad Budget Management 





Project estimation is based on only one estimation technique   





Ignoring to adjust the project cost to risks





    5. Project Plan Development and schedule, Adopting the following governance components:-
5.1. Define the policy’ action and principles for the Project Plan and schedule 
5.2 Developing the Project Plan and schedule through the well-defined procedures; Describe the project outlines, Define project roles and responsibilities, Define the project goals and objectives, Develop the project charter, Organize a kickoff meeting, Develop the project Scope Statement, Develop work breakdown structure (WBS), Establish the project repository, Define activity specifications and planning the Staff, planning the project risks management, Develop project cost estimation and budgeting, Develop the project schedule, Define the project communications, Setting reviews at the end of each phase, Determine project quality specifications and Specify Change and Configuration Management. 
5.3 Setting best practices to reduce the failure within Project Plan development. These practices are based on guidance instructions that must be considered during the project development; also comprise the most lessons learned from the previous successful projects.
5.4 Suggested practices and checklists such as “Project Schedule Checklist” to measure the project activities progress against the overall project plan, and “Project Plan Components Checklist” to verify the most components of the project plan are completely incorporated.    
5.5. Defining the expected deliverables of Project Plan development and schedule. 
Do you think these Governance components can decrease the following failure reasons?
Main failure reasons related to
Project Plan and schedule
Strongly Agree
Agree
Disagree

Strongly disagree
N/A
Imprecise and ambiguous project plan 





Lack of Resources & inadequate staff to meet the schedule





Poor competencies of project planners (skill/experience shortages) 





Failing in managing the project plan





Unrealistic schedules and deadlines 





Project changes are managed poorly 





Poor change and configuration management procedures 





Improper definitions of roles and responsibilities 





Poor test planning 





No reviews at the end of each phase 





Lack of Contingency plan to handle problems that arise during the project development 





Ineffective internal communication 






Part two 
1- In general, IS projects have high failure rates than other projects?

              	                                                                                             
2- Please, arrange the following Pre-development activities, according to their importance to improve IS project success?
No
Pre-development activities
1
2
3
4
5
1
Project Feasibility study





2
Project Requirements Elicitation 





3
Project Risk Management





4
Project Cost Estimation 





5
Project Plan Development





3- Please, give an average percentage represents the role of each Pre-development activity to cause projects failure?
No.,
Pre-development activity
Very likely
81-100%
Likely
61-80%
Even likely
41-60%
Unlikely
21-40%
Very unlikely
0-20%
1
Project Feasibility





2
Project Requirements Elicitation 





3
Project Risk Management 





4
Project Cost Estimation 





5
Develop Project Plan





4- Please estimate the impact strength of the following risk factors on IS projects? 
No
Main Risk Factors
 Critical Impact 
81-100%
High Impact
61-80%
Moderate Impact
41-60%
Weak Impact
21-40%
Negligible Impact
0-20%
1
Project Planning and Controls





2
New and Unproven Technologies





3
Project Requirements





4
Project Architecture





5
Project Performance





6
Project Policies and Structure





7
Customer Risks





8
Organizational and Managerial Risks





9
Project Skills





10
Project Communications





11
Cost Estimation and Schedule





12
Project Quality





13
Project Coding and Testing





5- Please, check the most common requirements elicitation techniques that are used in your company?
 No
Elicitation Techniques
Example
check
1
Traditional Techniques
Questionnaires, Surveys, Interviews, PIECES Framework

2
Group Elicitation
Brainstorming, Focus groups, RAD/JAD, Workshops

3
Prototyping
 Early versions of User interface, Higher fidelity prototypes, Low fidelity prototypes,  Iteration

4
Contextual Techniques
Ethnographic techniques such as participant and  observation

5
Cognitive Techniques
Protocol analysis, Task analysis, Knowledge acquisition techniques, card sorting, and repertory grids

6
Model-driven Techniques
Goal-based methods, Scenario based Methods, Data Flow Diagrams Use Cases

7
Documentation
Reports

8
Ontology Framework
Top level ontology, domain ontology,  task ontology, application ontology

9
Web Surveys
Web-survey tool, Social websites, forums, queries by E-mails

9-Please, select the top five of the following pre-development activities, which have the largest influence to cause the failure of information systems projects
Pre-development activities
First
Second
Third
Forth
fifth
System Service Request (SSR) Assessment   





Project Scope Definition





Project Feasibility study





Project Requirements Elicitation





Commercial Off-The-Shelf (COTS) Selection





Project Charter and Statement of Work (SOW)





Project Work Breakdown Structure (WBS)





Project Risk Management





Project Cost Estimation





Project Contract





Communication Plan development





Project Plan development and schedule





Brief description of the pre-development activities
System Service Request (SSR) Assessment, assess if there a real problem needs to develop an information system.
Project Scope Definition, where the projects’ scope and boundaries are defined and prepared for execution.  
Project Feasibility study, assess the project viability and determine their proceeding against technical, operational, economical, schedule and illegal /political criteria
Project Requirements Elicitation, where users and business requirements of an information system are identified and captured (discover, reveal, articulate, and understand users and business requirements).
Commercial Off-The-Shelf (COTS) Selection, select the appropriate and the “right” COTS components for the projects, if it is needed. 
Project Charter and Statement of Work (SOW), develop a document that formally authorized the project to fulfill a project contract.
Project Work Breakdown Structure (WBS), breakdown the project into manageable chunks that can be effectively estimated and supervised
Project Risk Management, identifying and controlling any activity or event that can negatively impact on IS project’ success.  
Project Cost Estimation, estimate the projects’ size, efforts, duration, and budget.
Project Contract, agreement between sponsors and developers to create IS projects according to a set of terms and conditions (clauses).
Communication Plan development, determine all dimensions of communication between the project participants. 
Project Plan development and schedule, a road map to explain how the project will progress through all development’ phases and guides the project implementation through the scheduling of their activities.





























Annex 3: 
Well-defined procedures and Best Practices Checklists
















A-Well-defined procedures Checklist for the main pre-development
No
Well-defined procedures of executing the project feasibility study
Yes
No 
1
Study the main characteristics of the present system (old system, if it manual or computerized)


2
Performing the “PIECES” Framework to identify the project problems, 


3
Study the new project idea or need and all life cycle constraints and benefits


4
Investigating the objectives and other requirements for the new system (what needs to change?)


5
Assure the Objectives, Purpose and the Scope of the intended project, 


6
Explain the advantages and disadvantages of the intended IS project


7
Verify the objectives, purpose and the scope of the intended IS project


8
Estimate the traditional appraisal Techniques for the intended project (NPV, ROI, Payback period),


9
Test the stability of the intended project with the main Factors and variables of the organization,


10
Perform the five types of feasibility studies for the intended project (Economic feasibility, Technical feasibility, Legal/Cultural feasibility, Operation feasibility and Schedule feasibility)


11
Quantifying the qualitative benefits and costs (Intangible Costs and Benefits)


12
Calculate the Cost/ Benefits Analysis 



No
Well-defined procedures of executing project Requirement Elicitation 
Yes
No 
1
Collect information about user needs and expectations, 


2
Determine the participants in the system to be developed (project stakeholders),


3
Coach and analyze the Project Stakeholders


4
Write descriptions of user needs,


5
Classify and prioritize system requirements,


6
Examine the elicitation techniques to choose the appropriate techniques and tools to use 


7
Eliciting the requirements from stakeholders and other sources, 


8
Understanding the application domain


9
Determine those functional and non-functional requirements,


10
Develop and Check the Prototype for the project requirements


11
Manage the initial requirements changes, 


12
Check and judge the result of requirement elicitation. 



No
Well-defined procedures of executing the project Risk Management
Yes
No 
1
Risk Management Planning to decide how to approach, plan, and execute risk management activities for the intended project


2
Risk Identification, which is discovering, determining, defining, describing, documenting and communicating risks before they become problems and adversely affect the project


3
Risk Analysis, estimate the probability of occurrence and the seriousness of impact if they occur


4
Risk Assessment and Prioritization, assessing and combining their probability of occurrence and impact. The purpose of risk assessment is to measure the impact of the identified risks on a project depending on the available data 


5
Calculate Risk Exposure,  (Risk Exposure (RE) = P × C), Where P = probability of occurrence for a risk and C is the impact of risks 


6
Determine Risk Response strategy, developing options and actions to enhance opportunities and to reduce threats to the project objectives


7
Risk Monitoring and Control, the process of implementing risk response options and actions, tracking identified risks, monitoring residual risks, identifying new risks, and evaluating the risk strategies effectiveness throughout the project life cycle 



No
Well-defined procedures of executing the project Cost Estimation 
Yes
No 
1
Review the Project Scope defection accurately


2
Validate the project requirements elicitation with analyzing the functional and non-functional requirements 


3
Develop work breakdown structure (WBS), 


4
Determine the size of project’ tasks and activities, Based on WBS, 


5
Estimate the project size in Source Lines of Code (SLOC) or function point by using one or more cot estimation techniques 


6
Convert project size into efforts, Project effort =


7
Add Project Supplemental efforts, Project time schedule, 


8
Calculate the project duration based on available resources and project efforts 


9
Project duration = 


10
Estimate Project Costs 


11
Assess the Impact of project Risks, 


12
Adjust the project cost to risks, 


13
Validate and verify project estimation, and budget with estimate documentation. 



No
Well-defined procedures of executing the project plan development and schedule
Yes
No 
1
Describe the project outlines


2
Define project roles and responsibilities


3
Define the project goals and objectives


4
Develop the project charter


5
Organize a kickoff meeting,


6
Develop the project Scope Statement,


7
Develop work breakdown structure (WBS),


8
Establish the project repository, 


9
Define activity specifications and planning the Staff, 


10
Planning the project risks management,


11
Planning project cost estimation and budgeting, 


12
Planning the project schedule, 


13
Define the project communications,


14
Setting reviews at the end of each phase,


15
Determine project quality specifications


16
Specify Change and Configuration Management 






No
Well-defined procedures of executing the project scope definition
Yes
No 
1
Define the business needs to initiate and justify the project


2
Define the main project objectives


3
Define the Scope


4
Determine project product and deliverables


5
Planning the Scope


6
Scope Verification


7
Scope Approval


8
Perceive Scope Change Control


9
Develop the project scope statement 



B-Best practices checklists for the main pre-development activities
No
Best practices of project feasibility study
Yes
No
1
Strengths, weaknesses, and improvement opportunities for the projects should be identified periodically and as needed


2
Appraise the projects periodically and as needed to maintain an understanding of their strengths and weaknesses


3
Establish and maintain guidelines to determine which issues are subject to a formal evaluation process


4
Assure that all intangible costs and benefits are completely estimated and considered during evaluation the economic feasibility of IS projects


5
Study and explain the viability of business needs completely  


6
Keep away from to initiate the projects according to inaccurate reasons and trivial needs


7
Confirm the consistency between the organization's business needs and the Information System functionalities 


8
Confirm that all types of feasibility studies (technical, operational, legal, economical, and schedule) are implemented completely 


9
Assess the gap between technology and the existing ability


10
Realize the ability to measure the feasibility during the project development phases


11
Stop to proceed the project if it isn’t viable 


12
Remove disagreement between the project costs and the budget.


13
Estimate all types of projects’ costs and benefits completely


14
Early determine the technical and operational needs for the projects 


15
Eliminate poor competencies experiences, skill shortages and improper financial management techniques


16
Avoid as much as possible the higher costs of capital investment 


17
Avert the ambiguous identification for the margin between project costs and benefits 


18
Don’t fear from project cancelation, if it isn’t feasible at any point 


19
Be aware to distinguish the "black hole" projects


20
Realize the ability to assess the project viability


21
Recognize and use the financial appraisal techniques during economic feasibility 


22
Taking into account the project which is feasible (now) maybe  infeasible at any later point and time


23
Avoid the long payback period for the cost of capital investments 


24
Assure that development costs don’t exceed any benefits that the system may bring throughout its useful life 


No
Best practices of project Requirement Elicitation
Yes
No
1
Confirm that Coordination and collaboration of the project’s elicitors  with relevant stakeholders is conducted


2
Elicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product life cycle


3
Develop an understanding with the requirements providers on the meaning of the requirements


4
Obtain commitment to the requirements from the project participants


5
Manage changes to the requirements as they evolve during the project


6
Maintain the requirements change history with the rationale for the changes


7
Maintain requirements traceability to ensure that the source of lower level (derived) requirements is documented with Generate the requirements traceability matrix


8
Identify inconsistencies between the project plans and the requirements


9
Provide adequate resources for performing the requirements elicitation 


10
Identify and involve the relevant stakeholders of the requirements elicitation as planned


11
Review the activities, status, and results of the requirements elicitation with higher level management and resolve issues


12
Establish and maintain quantitative objectives for the requirements elicitation that address quality and process performance based on customer needs and business objectives


13
Identify and correct the root causes of defects and other problems in the requirements elicitation


14
Stakeholder needs, expectations, constraints, and interfaces should be collected and translated into customer requirements


15
Eliminate misunderstanding and complexity of the problem domain (misunderstanding the domain due to the complex nature of the task; some properties of the problem space are not fully investigated; and, mistaken assumptions are made)


16
Select the appropriate stakeholders whose will be involved in requirements elicitation from the right subject at the right time


17
Communicate the allowed changes in requirements to all project’s parties


18
Exclude Changes in requirements without a permit of Change Control Board (CCB) 


19
Rectify all Communication problems, lack of communication among developers and between developers and users


20
Be aware to adjust project costs and timeline to the accepted requirement changes 


21
Avoid depending on single method to elicit the project requirements 


22
Elicit the project requirements from unlimited sources of stakeholders.


23
Set change management with understand the impact analysis of changing requirements


24
Avoid Inadequate/poor requirement traceability 


25
Depend on appropriate, complete, and accurate documentations


26
Confirm as possible that requirements are translating correctly to written natural language


27
Support adequate training and experience of the requirement engineer


28
Increase the awareness of all sources of requirements 


29
Support the communication among groups of people working together


30
Involve all users at all times during requirement development


31
Review and update knowledge, skills, or experience to perform tasks 


32
Establish more mechanisms to resolve the conflicting requirements and needs


33
Understanding the feasibility and risks associated with requirements elicitation


34
Complete understanding of hardware and software interface specification 


35
Good management of people and resources within requirements elicitation


36
Perceive the impact of technological, historical, organizational, and individual changes  to requirement elicitation   


37
User needs should be well-understood and interpreted while resolving the conflicting requirements


38
Users should be given adequate time available for requirements gathering



No
Best practices of project Risk Management
Yes
No
1
Monitor risks against those identified in the project plan


2
Collect and analyze the risk issues and determine the corrective actions necessary to address the issues


3
Define the parameters used to analyze and categorize risks, and the parameters used to control the risk management effort


4
Establish and maintain the strategy to be used for risk management


5
Risks should be identified and analyzed to determine their relative importance and impact


6
Identify and document the risks associated with cost, schedule, and performance in all appropriate product life-cycle phases


7
Review all elements of the work breakdown structure as part of identifying risks to help ensure that all aspects of the work effort have been considered


8
Review all elements of the project plan as part of identifying risks to help ensure that all aspects of the project have been considered


9
Evaluate and categorize each identified risk using the defined risk categories and parameters, and determine its relative priority


10
Risks should be handled and mitigated, where appropriate, to reduce adverse impacts on achieving objectives


11
Develop a risk mitigation plan for the most important risks to the project, as defined by the risk management strategy.


12
Identify the persons or group responsible for addressing each risk, also Determine the cost-to-benefit ratio of implementing the risk mitigation plan for each risk 


13
Monitor the status of each risk periodically and implement the risk mitigation plan as appropriate


14
Establish a schedule or period of performance for each risk handling activity that includes the start date and anticipated


15
Risks should be re-assessed, controlled, and managed through the project development 


16
Eliminate as much as possible the conflict between project’s departments and functions  


17
Consider the necessity of increasing the risk management efforts exponentially, according to the increase of project size and complexity.


18
Give equal attention to all risk factors, not to one risk factor over each others


19
Depend on both qualitative and quantitive risk analysis methods


20
Give more interest to risk identification which is the most critical phase in risk management. 


21
Calculate the Risk Reserve for the project and adjust the cost according it


22
Do best efforts with  obtaining sufficient details within the project’s risk planning 


23
Incorporate the Risks’ impact into the project plan 


24
Satisfy the required knowledge, experience and skills for the project team 


25
Work to achieve all end-user expectations as much as possible


26
 Use the appropriate development methodology and avoid Changing of technology as much as possible


27
Project Managers should consider the best practices and lessons learned from the previous projects


28
Constitute  sufficient and good risk management practices and documentations


29
 Set the correct assumptions regarding risk analysis 


30
Support good communication among customers, developers and users 


31
Provide adequate training for persons’ responsible of risk management process.


32
Establish explicit definition for the quality standards of software project 


33
Make redesign business processes to match the project risks as much as possible


34
Make good expectation as much as possible to estimate the probability of project risk factors.  


35
Use the mathematical models to evaluate the risk exposure 


36
Prepare good and consistent project risk plan 


37
Confirm that  the suitable risk response strategy is chosen and applied  


38
Continue to make risk evaluation during the project life phases 


39
Eliminate the conflicts between system users



No
Best practices of project Cost Estimation 
Yes
No
1
Establish and maintain estimates of the attributes of the projects’ work product and tasks


2
Use appropriate methods to determine the attributes of the work products and tasks that will be used to estimate the resource requirements


3
Estimate, as appropriate, the labor, machinery, materials, and methods that will be required by the project


4
Estimate the project effort and cost for the work products and tasks based on estimation rationale


5
Include supporting infrastructure needs when estimating effort and cost


6
Collect the models or historical data that will be used to transform the attributes of the work products and tasks into estimates of the labor hours and cost


7
Consider the indirect costs estimation for the non-technical activities 


8
Adjust the project costs to risks 


9
Support the consistent between desired capabilities to available budgets, schedules, and skilled


10
Project estimation should based on more than one estimation technique   


11
Create a historical database to retain the estimated data 


12
Confirm to proper usage and analysis of the historical estimation data 


13
Develop the estimation competencies  for project leadership and management


14
Establish well-defined requirements for the project estimated activity 


15
Avoid to perform cost estimate based on imprecise requirements


16
Consider the amplification of project requirements at the late of project life-cycle 


17
Exclude  the frequent user change requests without change controls


18
Developers should be involved during the project cost estimation process 


19
Assess the staffing levels and skills accurately 


20
Avoid to force the estimation to match the resources available


21
Do best efforts as much as possible to meet the project costs 


22
Consider and expect to some extent the project’ size growth in estimates 


23
Establish a proper and integrated WBS


24
Keep the estimate current and updated  


25
Give sufficient time on software sizing


26
Use the suitable estimation methodologies 


27
Gather sufficient and complete project requirements  


28
Consider the historical estimates as basis for analogy due to differences in languages and methodologies


29
The schedule and effort allocations should consistent with historical experience


30
Avoid unrealistic estimation efforts 


31
Use previous knowledge to estimate software size, cost, and schedule


32
Always enrich  cost estimation competencies for project estimators and establish good Budget Management 



No
Best practices of project plan development and schedule
Yes 
No 
1
Plan for necessary resources, knowledge and skills needed to perform the project


2
Plan and manage the involvement of identified stakeholders


3
Review all plans that affect the project to understand project commitments


4
Reconcile the project plan to reflect available and estimated resources


5
Monitor and control the project planning process against the plan for performing the process and take appropriate corrective action


6
Actual performance and progress of the project are monitored against the project plan


7
Integrate the project plan and the other plans that affect the project to describe the project’s defined process


8
Incorporate into the project plan the definitions of measures and measurement activities for managing the project


9
Define and document measurable quality and process performance objectives for the project and Establish traceability to the project’s quality


10
Define clear objectives and goals for the project earlier.


11
Rectify the imprecise and ambiguous components of the project plan 


12
Eliminate the Lack of Resources & inadequate staff to meet the schedule


13
Encourage and sustain the competencies of project planners (skill/experience) 


14
Prepare good plan to organize kickoff meeting 


15
At all times manage the project according to the project plan


16
Define completely the project roles and responsibilities 


17
Avoid Unrealistic schedules and deadlines 


18
Project changes should be managed efficiently  


19
Activate the role of configuration management and control procedures 


20
Establish well-define test planning 


21
Make reviews at the end of each phase 


22
Establish Contingency plan to handle problems that appear during the project development 


23
Set effective internal communication 


24
Give more interest for tasks in the critical path.


25
Depending on appropriate planning, communication, and technology skills.


26
Confirm to establish accurate estimating of project durations to create realistic schedule


27
Minimizing task dependencies to avoid delays caused by one task waiting for another task to complete


28
Review the structure of WBS according to the project scope statement


29
Define correct assumptions regarding resource availability 


30
Establish review and approval activities within the project


31
Consider and organize the interdependencies between tasks 


32
Beware that the delivery date impact the project schedule 




No
Best practices of project scope definition
Yes
No
1
Establish a top-level work breakdown structure (WBS) to estimate the scope of the project


2
Define the project life-cycle phases upon which to scope the planning effort


3
Define clear project objectives and assumptions  


4
Avoid Imprecise identification  for business needs 


5
Set a proper procedures to manage the scope changes accurately 


6
Exclude the unauthorized scope changes (Scope creep)


7
Avoid Changing scope and objectives during the project as much as possible 


8
Define clear project boundaries and what is out of the scope  


9
Tack care of Customer/Users unrealistic expectations


10
Defining the initial project scope and justification completely 


11
Assure that  initial project scope is completely understanding 


12
Consider that product which users want is more complicated than the delivered original ones


13
Key stakeholders should be informed of scope changes that have effect on project schedule, cost, and quality. 


14
Avoid words and statements that require judgment or invite interpretation, such as ‘improve,” "enhance," "better," "more efficient" and "effective." Use numbers, facts, and concrete results. Use quantifiable terms, and provide target values or ranges. 


15
Consider the overlooked elements of the scope


16
Avoid rework because the scope is poorly defined as much as possible


17
Communicate  scope changes to all project parties