RHouraniDSFinalPaper

Controlling IT Projects Risks
Caused By People
The Case:
Implemented “Open Source” E-Learning Systems
In Small Educational Institutes
By
Rasheed Hourani
A DISSERTATION
Submitted to
The University of Liverpool
in partial fulfillment of the requirements
for the degree of
Information System Masters
1/October/ 2009

ABSTRACT
Controlling IT Projects Risks
Caused By People
The Case:
Implemented “Open Source” E-Learning Systems
In Small Educational Institutes
By
Rasheed Hourani
IT projects have its unique characteristics as well as its related risks. An enormous amount of
those risks are caused by people whom are involved in the projects. The business can be fatal-
ly affected by those human-related risks which we are going to address it in this research as
human risk factors. The types of people involved might be: the business owner, the stakehold-
ers, the project manager/leader, the project team, the IT developer, the IT professionals, and
some time the end users or the audience.
From my real work environment, I noticed the huge gap in both understanding and awareness
of such risks between IT oriented staff and other business department‟s staff.
In addition, such risks increase when implementing an open-source environment which, despite
its great advantages, has its disadvantages and might generate high level of risks during im-
plementation process.
The educational sector and institutes are considered as intensive user of “open source” solu-
tions that is because of its academic and non-profit nature. Academic institutes attempt to pro-
vide low cost E-Learning solutions to its customers (students) and users (teachers). In order to
do so, they consider “Open Source” solution as a valid option. However, approaching such
technology should be conducted with a lot of cautions. Consequently, those involved should
have a great amount of experience and awareness of the generated risks.
Decision makers should be prepared and ready to handle its risks probability, likelihood and
consequences. This is our aim in this research.

DECLARATION
I hereby certify that this dissertation constitutes my own product, that where the
language of others is set forth, quotation marks so indicate, and that appropri-
ate credit is given where I have used the language, ideas, expressions, or writ-
ings of another.
I declare that the dissertation describes original work that has not previously
been presented for the award of any other degree of any institution.
Signed,
Rasheed Hourani
1 April 2009

ACKNOWLEDGEMENTS
I would like to thank my dissertation Supervisor, advisor, and sponsor, Dr. Kathleen Kelm
(KMK). Her style, feedback and expertise would prove beneficial for me in my chase of this top-
ic. I appreciate her quick acceptance of my project, the guidance, and resources provided to
me during the progress of the project.
I also like to thank all University of Liverpool Professors for furthering my knowledge and pro-
viding me with insight vision of handling IT projects as well as managing an IT environment in a
prober way. Our weekly interactive was a real added value for my career. I will never forget the
three great, friendly, and kind program mangers: Agi Sieradzkea, Stephanie Blanchard, and
Olga Moroz for their prompt support and kind motivation. They surly make it easy for me all the
way.
A big “thank you” to Dr. Sayed Saatchi the ICU head of Arabic Open University, Kuwait and Mr.
Khaled Eskaf from Arab Academy for Science & Technology, Syria for their academic and
technical information provided to me. The rich resources they provided improved my case stu-
dies, interviews, and survey‟s. They played a sharp role in the survey distribution, collecting,
and analyzing. Many thanks for all those IT professional, teachers, and students whom I rarely
and sometimes never know for filling the survey‟s despite of their busy schedules.
This dissertation is the conclusion of many years of life, education and experience. Before
2007, holding a Master degree was a kind of a dream and an impossible thing that I can never
think of. Now, with the support of my Family and the contributions and encouragement of some
great friends, I am here on the graduation ceremony and on the stage shaking hands while
holding my certificate close to my heart.
I want to thank my mother “Hind” for her prayers, support and encouragement.
I reserve my greatest thanks to my wife for her uncountable efforts and help. I am sure we are
both happy that this is done! My love, respect, and appreciation for you Nada!
Finally, nothing would happen without the assist of Allah. So thank you God.

v
TABLE OF CONTENTS
Page
LIST OF TABLES viii
LIST OF FIGURES ix
Chapter 1. Introduction 1
1.1 Scope 1
1.2 Problem Statement 2
1.3 Approach 3
1.4 Outcome 5
Chapter 2. Background and review of literature 6
2.1 Related Work 6
2.2 Literature 9
2.2.1 Project Risk Management Process....................................................................9
2.2.2 Some important definitions (CECC):..............................................................10
2.2.3 Severity of Human-Risk-Factor (ILPP) ..........................................................11
2.3 What is MOODLE? 12
Chapter 3. Theory 14
3.1 Assumptions 14
3.1.1 Why it is important to manage RISKS?..........................................................14
3.1.2 Common Risks in IT Projects: .......................................................................15
3.2 Open Source Projects Risks: 16
3.2.1 From the real life ...........................................................................................16
3.2.2 List of those possible risks:............................................................................18
Chapter 4. Analysis and Design 20
4.1 The Case study: 20
4.2 An interview: 20
4.3 The Survey: 20
4.4 The findings 20
4.5 The Booklet (Framework): 21
4.6 Testing the Framework: I will evaluate the framework: 22
4.7 The result of testing the Booklet framework 22
Chapter 5. Methods and Realization 23
5.1 Results of Case Studies 23
5.1.1 Interview Result: ...........................................................................................23

vi
5.1.2 MOODLE Survey Input.................................................................................24
5.1.3 IT Professional Survey...................................................................................27
5.1.4 Educators/Teachers Survey............................................................................29
5.1.5 Students Survey.............................................................................................31
5.2 List of most common human-risk-factors in IT projects related to
implemented Open Source E-Learning Solutions: 33
5.3 Test Plan 34
5.4 The Results: 35
Chapter 6. Results and Evaluation 36
6.1 Policies and Procedures 36
6.1.1 Policies..........................................................................................................36
6.1.2 Procedures:....................................................................................................37
6.2 List of Tools and Techniques 38
6.2.1 Choose the right person to do the right task: ...................................................38
6.2.2 Have a Projects Risks Breakdown Structure ...................................................38
6.2.3 Use Risk Register Form:................................................................................39
6.2.4 Have in-hand a Probability/Impact Matrix:.....................................................41
6.2.5 Track the risk using the Top Ten Risk Item Tracking: ....................................42
6.2.6 Keep a watch list: ..........................................................................................43
6.2.7 SWOT...........................................................................................................44
6.2.8 Thaman and Wilemin’s Way:.........................................................................44
6.2.9 Use HOCKEY Stick Effect:...........................................................................45
6.2.10 RAM responsibility assignment matrices:.......................................................46
6.2.11 Security Risk Management Team SRMT .......................................................46
6.2.12 What can go wrong?......................................................................................47
6.3 To-Do Task List 48
6.3.2 Always perform Continues Analyzing:...........................................................48
6.3.3 Keep on monitoring the risks: ........................................................................49
6.3.4 List of people and risks..................................................................................50
6.3.5 Risk Identification method:............................................................................51
6.3.6 Perform several Stress Testing:......................................................................52
6.4 List of advises, recommendations and best practices: 52
6.4.1 Make Sure:....................................................................................................52
6.4.2 Advice to avoid Day-To-Day Risks:...............................................................53
6.5 Lessons Learned: 57
6.5.1 The art of leadership, influencing, and motivating Project Team Member: ......57
6.5.2 Improve Leadership Skills: ............................................................................58
6.5.3 Develop Strong Communications Skills: ........................................................59
6.5.4 Document of Roles and Responsibilities.........................................................60
6.5.5 Brainstorming sessions and interviewing techniques.......................................61
6.5.6 Effective hiring process: ................................................................................61
6.5.7 Follow the PMI PMBOOK hints:...................................................................63
6.5.8 Stakeholders Risk Tolerances.........................................................................64
Chapter 7. Conclusion 66
7.1 Lessons Learned: The research emphasized on: 66
7.2 Further Activities: 68
7.3 Prospects for further work to be conducted: 69

vii
REFRENCES CITED 70
Appendix A. Case Study (1) 72
Appendix B. Case Study (2) 76
Appendix C. Risk Management Plan 82
Appendix D. The interview with the IT Manager 84
Appendix E. IT Professionals Survey and Results: 85
Appendix F. Educators survey and Results: 90
Appendix G. Students Survey and Results: 97

viii
LIST OF TABLES
Page
Table 1: PM Maturity by Industry Group and Knowledge Area - William and Ibbs ... 8
Table 2: IT Success Potential Scoring Sheet .................................................... 15
Table 3 : Risk Register - Example ........................................................................... 40
Table 4: Probability/Impact Matrix.......................................................................... 41
Table 5: Top Ten Risk Tracking .............................................................................. 42
Table 6: Watch List ................................................................................................. 43
Table 7: SWOT Strengths, Weaknesses, Opportunities, Threats. ............................. 44
Table 8 Categorize Project Risks ............................................................................. 48
Table 9: Risks Severity/Impact................................................................................ 49
Table 10: List of People and Related Risks.............................................................. 50
Table 11: Risks By Implementation Phases ............................................................. 50
Table 12: Risk Identification ................................................................................... 51

ix
LIST OF FIGURES
Page
Figure 1: Risk Management Process........................................................................ 10
Figure 2: Moodle Implementations Map............................................................. 12
Figure 3: Total Know............................................................................................. 13
Figure 4: Total Downloads ...................................................................................... 13
Figure 5: Population................................................................................................ 13
Figure 6: IT Professionals Survey - Results ............................................................. 28
Figure 7: Risk Breakdown Structure........................................................................ 39
Figure 8: HOCKEY STICK EFFECT...................................................................... 45
Figure 9: Human Resource Planning........................................................................ 62

1
Chapter 1. INTRODUCTION
1.1 Scope
The research will focus on controlling, handling and resolving risks caused by
human/people who are involved in a way or another in IT projects related to the
implemented Open-Source E-Learning System for small Educational Institutes.
As a prove successful tool for implementing an open source E-Learning solu-
tions, MOODLE (http://moodle.org) will be the technology example used to inves-
tigate the problem and the case study will be conducted on the Arabic Open Uni-
versity in Kuwait (http://www.aou.edu.kw) and the Arab Academy for Science &
Technology – Syria Branch (www.aou.edu.kw).
In deciding to review and research, an open-source technology was for several
reasons:
 It is availability for download
 It is willing to being inspected of its development process from end to end
 It is successful and stable implementations in many educational institutes.
 It is a rich environment for human risks to be generated.
I will refer to those risks from now on as: Human-Risk-Factor.
The aim is to advice small educational institutions to approach such a solution
with an open eye to all possible human-risk-factors that might be raised within
and after the implementation phases.

2
1.2 Problem Statement
Open source systems are like a coin with two faces! One side is bright (positive)
because of its several great advantages such as low cost, flexibility and expe-
riences sharing, while the other side is the dark side (negative) one because of its
disadvantages and risks that may be expected from it.
Basically, organizations face risks when:
 Risks are not well considered before they occur and/or;
 Risks are not well judged and dealt with once they occur and/or;
 No solid plan is available to protect against risks in future events.
Additionally, human/people factor is a crucial „risk generator‟ in any IT project,
and it becomes more and more severe with projects that implement open-source
solutions! Here, risk probabilities are very high because human/people from dif-
ferent job levels might assume that open source projects can be easily handled or
they might consider it as a “not a big deal” issue comparing to –what they think-
the “almost zero” cost of it! What they do not know is that there are many hidden
costs distributed between the implementation phases which may turn to be a
painful, indirect high cost affecting areas such as manpower, maintenance, and
bug fixing.
I believe that ignoring or underestimating those risks will lead any “Open-source”
implemented project to a „fail‟ situation with sad end. Therefore, it is „a must‟ to
have a vision as well as a plan to manage all different kind of risks caused by
human/people whom are involved in such projects. I also believe that planning to
control and manage those risks will help to minimize project delays, put the
project cost on track, and minimize the possible project lost. Adding to that, hav-
ing in hand a well written „lessons learned document‟ will maximize the ROI and
avoid such risks in future circumstances.

3
Academic institutes attempt to provide low cost E-Learning solutions to its cus-
tomers (students), and users (teachers). In order to do so, they consider “Open
Source” solution as a valid option such as MOODLE.
Usually, the educational sector is considered as an intensive user of “open
source” solutions that is because of it is academic and non-profit nature. They
see it as a low-cost yet stable and flexible technology to count and depend on.
While doing so, they might face several kinds of risks including those that are
generated and related to human/people from different work levels, positions, and
authorizations.
Because of the sensitivity of the educational process and the need to have it up
and running 24/7 with both available and accurate information, Open-Source ap-
proach might be considered a „business killer‟ application.
Being unprepared to face and handle such risks in a comprehensive and profes-
sional manner can lead to several project failure situations and a significant num-
ber of problems will be generated to the end user/clients for whom this service is
offered.
1.3 Approach
1. Investigate MOODLE as a successful tool usually used to implement
open-Source E-Learning solutions.
2. Investigate all possible Human-Risk-Factors generated by an
implemented solution.
3. Prepare a Case Study on the E-Learning Management System in Arabic
Open University in Kuwait and the Arabic Academy for Science and
Technology – Syria Branch.
4. Interview and seek professional and administrative feedback to determine

4
their understanding of the risks in their IT open source environments and
related projects:
a. Interview with the ICU manager Arabic Open University in Kuwait.
b. Interview with a stakeholder in the Arabic Academy for Science
and Technology – Syria Branch
5. Distribute three kinds of survey‟s to three categories of people:
a. IT Staff – 5 persons in different levels of job titles related to LMS
(LEARNING MANAGEMENT SYSTEM)
b. Educators/Instructor – 20 persons actually using the LMS
(LEARNING MANAGEMENT System)
c. Students – 50 students with an account to access the LMS
(LEARNING MANAGEMENT SYSTEM) from different university
studying years.
6. Create a comprehensive picture on the environment of this institution. I
will be able to find the risks caused by people and how did they dealt with
it.
7. Use my contacts from attending a conference in Kuwait University related
to E-Learning system. It provided rich information about the LMS
(LEARNING MANAGEMENT SYSTEM) but was so general. Luckily,
another conference will be held in Nov 2009. I was able to meet one of the
conference organizers and he promised to provide me with valid and val-
uable documents.
8. Analyze the 10 most common risks caused by people (Human-Risk-
Factors) in implemented “open source” E-Learning solution project, includ-
ing their causes, severity levels and impacts.
9. Build the booklet of recommendations, best practices and directions.
10. Present the Booklet to the stakeholders for their review
11. Test the Booklet on one of the possible risks in order to validate its

5
usefulness.
1.4 Outcome
1. Highlight all possible disadvantages of open-source solutions and will explain
the necessity of understanding, well judging, and proper handling of such
risks.
2. Catch the attention of stakeholders to consider those risks and deal with it
with a lot of caution and seriousness in order to avoid a project fail situation.
3. Provide decision makers a plan to deal with such risks will help to minimize
delays, put the cost on track, and minimize the possible project lost.
4. As a consequence, the plan will reinforce the need for decision to not unde-
restimate the risks, nor allow risks to be repeated, and to learn from previous
mistakes.
5. Provide an explanation on how what we might think a “No-Cost” project could
turn indirectly to be a painful high cost project through several hidden costs,
manpower, maintenance and bugs fixing after the go live stage.
6. Clarify that documenting what went wrong and having a “what if” scenarios in
hand along with the list of lessons learned from previous experiences is a
must.
7. Develop a framework in a format of a booklet which will address the common
risks. The booklet will be investigated and presented in a way that makes it
easy to use and of great help for educational institutes who are thinking of
implementing an open source E-learning system. The booklet will provide the
following: List of recommendations, List of best practices, and List of direc-
tions and lessons learned.

6
Chapter 2. BACKGROUND
AND REVIEW OF LITERATURE
2.1 Related Work
As mentioned in the introduction, risks are like a coin with two faces one is beau-
tiful and the other one is ugly. In both cases and before we throw the coin we
must be prepared to deal with any face that will be on the top side. According to
Project Management Journal (March 2000), risks can be negatives Threats or
Positive opportunities. Our role is to “minimize potential negative risks while max-
imizing potential positive risks” (PM Journal, 2000).
A Statistic by Bryan Barrow MBCS CITP (2007) showed that “Price Water house
Coopers found that just 2.5 percent of companies had 100 percent of their
projects delivered on time, within budget, to scope and delivering the right busi-
ness benefits”.
Such low percentage is so much related to human factor risks along with other
risk factors such as time, cost, and plan. IT projects is not in a better situation as
a survey furnished by the IT-cortex, performed by Spikes Cavell research inde-
pendent company to the benefit of the French computer manufacture and sys-
tems integrator „Bull‟ in (1998), concluded that the major causes of IT projects
failure in the French sector are: “Missed deadlines (75%), Exceeded budget
(55%), Poor communications (40%), and Inability to meet project requirements
(37%)” (IT-cortex, n.d.).
As we can see from this horrific sky high statistic, human factor is related to all its
findings. The reasons are more clarified in the findings of other statistic furnished
by KPMG study which was published in 1995 in which it stated that: “55 percent
of runaway projects … did no risk Management at all; 38 percent did some (but
half did not use their risk findings after the project was underway); and 7 percent

7
did not know whether they did risk Management or not” (K Schwalbe, 2007, p.
457). Scary figures, aren‟t they?
Schwalbe (2007) furnished a crucial survey conducted by William Ibbs and Young
H. Kwak. In this survey, Ibbs and Kwak tried to measure the maturity of risks
Management while running a project. The Survey results showed that out of
score 5, comparing to other business industries, information system software de-
velopment sectors were the lowest grade with regards to risk Management! As a
result, they pointed out that: “all organizations should put more efforts into project
risk Management, especially the information system/software development indus-
try which had the lowest rating of 2.75” (K Schwalbe, 2007, p. 447).
From all of the above mentioned statistics, we can clearly state that project Man-
agement is the “art and science of identifying, analyzing, and responding to risks
through the life of the project and in the best interest of its objectives” (K
Schwalbe, 2007, p. 447). As we can see from the definition, human involvement
is everywhere! It is in the identifying and analyzing and responding to the risks
and those activities are throughout the project life.
Sadly and despite the fact that risk Management is the main reasons for the
smooth running of a project to its final distention, risk Management efforts are not
noticed in many cases!
The efforts by William and Ibbs following a logical method to assess the maturity
of the project Management in each business industry and according to the know-
ledge area reached the following results:

8
Table 1: PM Maturity by Industry Group and Knowledge Area - William and Ibbs
Knowledge Area Engineering/
Construction
Telecommunications Information
Systems
Hi-Tech Manu-
facturing
Scope 3.52 3.45 3.25 3.37
Time 3.55 3.41 3.03 3.50
Cost 3.74 3.22 3.20 3.97
Quality 2.91 3.22 2.88 3.26
Human Resources 3.18 3.20 2.93 3.18
Communications 3.53 3.53 3.21 3.48
Risk 2.93 2.87 2.75 2.76
Procurement 3.33 3.01 2.91 3.33
*Table 11-2: Project Management Maturity by Industry Group and Knowledge Area (K Schwalbe,
2007, p.448).
As a result, IT professionals must have in hand a solid document as a reference
to know what to do in each and every human related risk situation. It is a type of a
booklet with recommendations, directions, and best practices that are easy to use
and understood. This booklet “needs to be consistent, repeatable, cost-effective
and “reduce risks to a reasonable level” (K Rabah, 2008, p. 2).

9
2.2 Literature
We cannot talk about risk handling without introducing the PMI PMBOK
(2008) four steps of Risk Process and adapt it to fit in the research subject.
2.2.1 Project Risk Management Process
1. Risk Management planning: this is where we plan to approach and deal
with the expected human-risk-factors.
2. Risk Identification: this is where we document the characteristics of the
human-risk-factor and determine which might affect the project.
a. Qualitative Risk Analysis: this is where we performing a qualit-
ative analysis of human-risk-factors and conditions in order to
prioritize their effects on project objectives.
b. Quantitative Risk Analysis: this is where we measure the prob-
ability and consequences of human-risk-factors and estimating
their implications on the project objectives.
3. Risk Response Planning: this is where we response to the human-risk-
factors with a tight procedures and techniques in order to reduce its
threats to the project‟s objectives.
4. Risk monitoring and controlling: this is where we keep an open eye on the
human-risk-factors and evaluate the effectiveness of our response plan
against it throughout the life of the project. This is also where we identify
any new human-risk-factors.

10
Figure 1: Risk Management Process
(Deltek, 2007 p.4)
2.2.2 Some important definitions (CECC):
1. Human-Risk-Factor Cause is when someone intentionally or
non-intentionally causes a human-risk-factor to occur at any cer-
tain stage of the project such as limitation of human resources
assigned.
2. Human-Risk-Factor Event is when some events occurred during
the project stages and support the human-risk-factor cause, such
as when the human resource is not committed for his task.
3. Human-Risk-Factor Consequences is when any uncertain
events occur. The consequence on the project might be on cost,
schedule, or quality.
4. Human-Risk-Factor Condition is when some other aspects of
the project environment contribute to project risk such as poor
project team spirit or unprofessional team member practices.

11
2.2.3 Severity of Human-Risk-Factor (ILPP)
1. Impact (Consequences) the effect that a human risk will have on the
project if it occurs. Numerical rating of the effect 12345: very low, low,
medium, high, very high.
2. Likelihood (probability) the extent to which the human risks effects are
likely to occur. Numerical rating of the extent: 12345 very unlikely, low li-
kelihood, likely, high likely, near certain.
3. Probability of occurrence that the human risk event will occur if we take
no action to solve the risk. Numerical rating: 12345 very low 0-20%, low
20-40%-possible 40-60%-High 60-80%- Almost certain 80-100%.
4. Precision the degree to which the human risk is currently known and un-
derstood:
a. The extent of our current knowledge about the project
b. Tell us how much we can trust that assessment
c. Rating
i. Low estimate of risk effect and or likelihood are merely
guesses
ii. Medium enough info is available to provide provisional es-
timates of risk effects and likelihood
iii. High knowledge of risk effects and likelihood is adequate
for all practical purposes.

12
2.3 What is MOODLE?
1. Moodle is an open-source code dedicated to provide solution for learning
Management systems available all over the world.
2. Moodle proofs itself for that educational institute can depend on it be-
cause of its stability usability and availability.
3. The following charts collected from Moodle site (http://www.moodel.org) il-
lustrates it:
4. Implementation locations
5. Total registered sites.
6. Total downloads per month
7. Total population all over the world
Figure 2: Moodle Implementations Map

13
Figure 3: Total Know
sites
Figure 4: Total Downloads
Figure 5: Population

14
Chapter 3. THEORY
3.1 Assumptions
3.1.1 Why it is important to manage RISKS?
1- Risk Management is now a subject that is on the agenda of every IT pro-
fessional, specifically those whom are involved in implemented open
source E-learning solution is in order to protect institutes critical missions.
2- It is strange to know that “While risk Management has been practiced by
other industries for hundreds of years, little historical data exists to sup-
port qualitative analysis in the IT environment” (K Rabah, 2008, p. 2).
3- Open source attracted organizations by its low cost, but is entitled to sev-
eral high human-risk-factors. It would be a catastrophe to the educational
institutes to be one of those who buy with no vision of possible risks “in-
dustry approach to-date has been to buy technology without really under-
standing the potential underlying risks” (K Rabah, 2008, p. 2).
4- Such educational institutes can‟t compromise to handle the risks of losing
sensitive data related to education process. Therefore, they should identi-
fy and evaluate the source and level of each human-risk-factor.
5- Open source implementation for educational institutes is provided to sup-
port the educational process. But several uncertainties will rise during the
life running of the application, some of which are related to human factor
and might be a severe risk to the whole process.
6- In order to support the institute, IT team must be able to help to manage
and understand these human factor uncertainties.
7- “Managing uncertainties is not an easy task” (K Rabah, 2008, p. 2). Ex-
ample is limitation of resources, alone; it is a huge risk.

15
8- “The fact is that all organizations have limited resources and risk can nev-
er be reduced to zero. So, understanding risk, especially the magnitude of
the risk, allows organizations to prioritize scarce resources” (K Rabah,
2008, p. 25).
3.1.2 Common Risks in IT Projects:
Based on the PMI PMBOK (2008), it is noticed that in each step of the risk
Management process we will face a Human-Risk-Factor! Either in input,
tools and techniques, or outputs step. In general, some common risks in
IT projects are listed by the Standish group to CHAOS research in which
they stated that those risks have been graded in a way that those grades
become a sign of the level of successfulness of a project. If the project
does not get the minimum score that means there is a high risks factors in
this project. Again, we noticed that in this grading system, Human-Risk-
Factors are having a good portion of it.
Table 2: IT Success Potential Scoring Sheet
Success Criterion Relative Importance
User Involvement 19
Executive Management support 16
Clear Statement of Requirements 15
Proper Planning 11
Realistic Expectations 10
Smaller Project Milestones 9
Competent Staff 8
Ownership 6
Clear Visions and Objectives 3
Hard-Working, Focused Staff 3
Total 100
“Table 11-3: Information Technology Success Potential Scoring Sheet” (K Schwalbe, 2007, p. 455).

16
As we can see from the above mentioned table, user involvement as a “human-
risk factor” have the highest relative importance grade following it is the executive
Management support which if not provided a risk of grade 16 might occur and as
a result, disturb the IT project process.
Still the competent staff is a valid risk and can cause a lot of project confusing
and finally the staff should be fully focused on the project, if not, a risk of grade 3
will rise. Those factors are related to our research as they relates to people in-
volved in a project.
What is interesting here is that the highest score is for the end user involvement
so if they reach this score that means the risks are low from the end user pros-
pective side else the risks are high.
3.2 Open Source Projects Risks:
3.2.1 From the real life
In his article: „Joint information Systems committee‟, Norman Wiseman
(2009) clarified that: “Many institutions are currently faced with making
decisions on whether to purchase proprietary or open-source software to
meet their teaching, financial and administrative requirements, or develop
applications and services in-house. Increasingly, the market is offering in-
stitutions complete service solutions, rather than software packages”.
According to his findings, it is not any easy decision to make. Still which
way to go is a confusing maze, but the extra balance is on the side of
complete service solution wither it is an open-source or a special custo-
mized solution more than to the side of the software on-shelf packages

17
that is because of the last one limitations and closed environment in which
we do not have the flexibility of modifying, changing, and customizing it in
order to fit to our business, changes and needs.
So open sources as a “software development model” (G Hein, 2004, p.7), is
going nowhere, it is a reality, and it proofs itself so far and it provides a wide
range of choices to the stakeholders as
1. it reduces the cost of implementation
2. it is has “no usage restrictions” (G Hein, 2004, p.7)
3. it provides the “freedom to inspect and verify” (G Hein, 2004, p.7)
4. it provides the “Freedom to modify, customize, enhance, or repair” (G
Hein, 2004, p.7)
5. it also, “allow anyone to influence, drive or lead” (G Hein, 2004, p.7)
On the other hand, Norman Wiseman (2009) stated that: “the use of open-
source software also introduces some new issues that Management may
not fully appreciate. For example, an open source solution is typically
based on a number of separate components; the tender process may not
have the flexibility to analyze the best mix of offers” (N Wiseman, 2009,
p.1).
As a consequence, open source solutions hold many risks. Human-Risk-
Factor in Norman‟s example is the possibility of not having the proper ex-
perienced persons to handle those separate components and make it all
work together smoothly.
Another risk that can be sensed from the definition of the Open source is
describe by Hein (2004, p. 6) “Freedom to anyone to acquire source code,

18
inspect, modify, use, and create derived works” From the risk observer
point of view, freedom maybe misused if provided to unqualified persons.
In this case, human-risk-factors might be: acquiring a poorly written code
by a non experienced developer, lack of knowledge in inspecting the
code, or a poorly developed capability which enables the system analysis
to modify the code to meet the business requirements.
3.2.2 List of those possible risks:
Gary Hein (2004) in his article listed several risks related to the approach of
open-source implementation; For the sake of the research, we will only list
what is related to Human-Risk-Factor:
1. Even it is less in total cost of ownership but it require training, service, im-
plementation, and support cost and sometimes this could be “more than
the commercial products it‟s replacing” (G Hein, 2004, p.12)
2. Frequent updates: “as often as every day” as well as implementation up-
dates “interoperability and support challenges” (G Hein, 2004, p.12). All
this requires daily human involvement which will generate several risks as
well.
3. “Impose additional in-house development and support requirements” (G
Hein, 2004, p.13). That also requires a lot of human involvements and ge-
nerates several human-risk-factors.
4. It is a fact that: “Open source is great at point technologies, but weak at in-
tegration, especially across multiple technologies and packages” (G Hein,
2004, p.20). We will need to have a lot of qualified staff to integrate all
coded parts and make a final working solution out of it.

19
5. Support is “the biggest issue with open-source software deployments” (G
Hein, 2004, p.13). This research survey‟s proofs that support has been a
critical issue and a challenging risk if the IT departments doesn‟t have
enough related staff.
6. “Requires greater involvement and different skill set from operations staff‟
(G Hein, 2004, p.13). A huge human-risk-factor is when the IT department
doesn‟t have enough, proper, and qualified staff to handle the open-
source implementation and maintenance as well.
7. I see this as the most critical human-risk-factor in any open-source solution
implementation. It is the “Developer contamination” (G Hein, 2004, p.15).
That is when developers copy code from existing implemented solution
and just insert it “AS IS” in their code related to different environment and
situations. The code might work, but the final solution will suffer later on.
G Hein (2004) stated that “developer reviews an existing open source
project, sees an elegant solution, then implement a similar function in
closed source project” (G Hein, 2004, p.15).

20
Chapter 4. ANALYSIS AND
DESIGN
The Framework Analysis and Design consists of:
4.1 The Case study:
1) Arabic Open University in Kuwait
2) Arab Academy for Science & Technology – Syria Branch
The aim is to collect the perceptions of the risk and to determine their un-
derstanding of the connection between risk, project planning and project
failure.
4.2 An interview:
1) IT Professional
2) Educational Institute stakeholder
4.3 The Survey:
1) The IT Professionals Survey
2) The Educator Survey
3) The Students Survey
4.4 The findings
1) List of findings with explanations
2) Categories them as per their relation to which part of the project
3) Prioritize them as level of risk from high medium to low
4) Identify the kind and position level of person casing the risk and related
source to it

21
4.5 The Booklet (Framework):
Framework that identifies and resolve the most common human-risk-
factors in IT projects and their relevance to open source projects imple-
mented in a small educational environment. The booklet will also help to
identify its causes, severity level and impact. It will provide some signs of
people with appropriate skills: List of ways to know if these people are
having the necessary managerial and technical skills and ways to esti-
mate their experience and evaluate it. It will be simple and easy to under-
stand. It will include the following methods:
1. A set of Policies and procedures
2. A group of techniques and tools
3. A list of To-Do-Tasks
4. A list of advises, recommendations, and best practices to resolve
occurred human-risk-factors, and avoid human-risk-factors in fu-
ture occasions and similar circumstances.
5. A list of lessons learned in dealing with human-risk-factors

22
4.6 Testing the Framework: I will evaluate the framework:
1) Present the „cure‟ to the stakeholders for review and application against
the actual project results to validate the usefulness of the „cure‟
2) Assess the project plan‟s ability to acknowledge and address the risk
3) Assess the surveys, interviews and case study for data integrity and va-
lidity and the case study and resulting assessment will evaluate the appli-
cability of the framework and resulting recommendation on how to man-
age an open source project and reduce the level of risk to its minimum.
4) Have the sponsor regularly review the progress. The results of the case
studies will provide an evaluation of the success of the framework as a
way to avoid and overcome some people risks in IT projects being ma-
naged within a small organization
4.7 The result of testing the Booklet framework
1) The results of surveys of stakeholders will describe the level of awareness of
people related risk and impact on project success

23
Chapter 5. METHODS AND
REALIZATION
5.1 Results of Case Studies
5.1.1 Interview Result:
The interviews with the ICU manager of the Arabic Open University and
the Educator in the Arabic Academy of Science and Technology showed
that they are satisfied with the implemented open-source solution. They
believe that this approach provided them with flexibility of modifications
and enhancements and the low cost of ownership. Yet, they are still facing
some critical issues related to shortage of man power as well as educa-
tors ability to digest the E-Learning concept. They also mentioned the
heavy human involvements when new requirements is needed and a long
process of person to person communication is needed and established in
order to collect all requirements and come to common understanding.
Another serious of human interaction occurs between the IT team to ana-
lyze the requirements and develop the right code to produce the final ap-
plication and post it to the main LMS (LEARNING MANAGEMENT
SYSTEM) interface. Those heavy human activities create a rich environ-
ment for risks and conflicts that could lead the project to a fail status.
Such risks want occur in the situation when on-shelf package is imple-
mented.
Please refer to the case studies appendix C

24
5.1.2 MOODLE Survey Input
The survey was conducted with students who completed a prototype using
Moodle on behalf of Edgewood College, in Madison Wisconsin. They pro-
vided the following feedback:
1) Input (1) No human-risk-factor founded during the installing and configura-
tion phases: the feedback was “someone with little or no programming
expertise could install and configure a simple Moodle site in a relatively
short period of time” (DS Survey 2009).
2) Input (2) When it comes to more-in-depth environment, some human-risk-
factors are considered issues such as the need for a IT professional with
high skills to understand the detailed setting: “however if you want to get a
more in-depth Moodle installation then someone would need to read-up
on the various options and get a little deeper into the settings” (DS Survey
2009).
3) Input (3) Human-risk-factor: rare of programmers continues support to
their code is a high risk especially in complicated implementation scena-
rios and still a big issue after the go-live situations: “exceeding plethora of
options with no good way to find the wheat among the chafe - and some
of the features you would like to see are in plug-in, modules, etc. that are
no longer supported by their authors - which is fine if you have someone
that knows PHP and can support modifying and fixing it for each release”.
(DS Survey 2009).
4) Input (4): The need for qualified programmers and developers is s must:
“going to need someone that really understands php, mySql (or chosen
db), Linux(or chosen OS) and has plenty of time to learn and understand
the source code and how Moodle 'works'” (DS Survey 2009).

25
5) Moodle - as an open source solution - gained a high trust grade.
6) Human-risk-factors are present in all design and implementation phases.

26
7) Moodle gained developers confidante to adopt it as a solution for academ-
ic institutes. Obviously because they are familiar with it.
8) Developers found that time required for configuration is crucial risk along
with the functional options. Those are related indirectly to the human ca-
pabilities to use the solution.

27
5.1.3 IT Professional Survey
The Survey conducted with IT professions in both the Arab Open universi-
ty in Kuwait and the Arab Academy for Science & Technology in Syria.
Both universities use the open-source solution: Moodle as the main learn-
ing Management system LMS (LEARNING MANAGEMENT SYSTEM).
The IT professional‟s responses showed more concerns towards the mon-
itoring and controlling the human-risk-factors and that they are not sure
wither the end users are aware of the risks caused by people. They be-
lieved that IT projects are unique and that they will face risks in each
project will have its own risks in each stage. The following input is a sum-
mary of the survey:
1- 66.67% agreed that each risk should be recognized and observed
2- 83.33% of them agreed that risks can cause a big lose to the project
3- 50% agreed that most risks are caused by people
4- 66.67 strongly agreed that people risks should be identified
5- 50% agreed that people risk should be categorized in order to deal with it.
6- 50% agreed that risks should be controlled and monitored.
7- 83% assumed that some risks can be solved
8- 16.7% said that all risks can be solved
9- 50% considered some risk can be avoided.
10- 66.7% agreed that a booklet can be a good help and minimize the risk
11- 50% thought that companies will adopt the booklet and add it to the ma-
nual and procedures.

28
Figure 6: IT Professionals Survey - Results
0
10
20
30
40
50
60
70
80
90
100 recognize each risk
risk cause a big lose
people are the cause of most risks
people risks should be identified
people risks should be categorized
people risks to be monitored and
controlled
some risks can be solved
all risks can be solved
some risks can be avoided
booklet will help to mimize risks
booklet will be used by companies
12. In their comments, the IT staff clarified that the most common risks they
faced with the open-source E-Learning solution is the possibility of misun-
derstanding of the end user requirements.
13. On the other hand, the IT professionals also commented that the fear the
risk of poor coding quality which might affect the network infrastructure
performance and as a result face the expected end users complains.
14. IT professional also raised their concerns of a real human-risk-factor
which is “developer‟s unavailability” for any reason such as: vacation, sick
leave, left the institute, death, or even take two hours leave permission.
For them it is a risk.
Please refer to the IT professional Survey Results – Appendix D

29
5.1.4 Educators/Teachers Survey
The survey was conducted with academic staff of both the Arab Open
university in Kuwait and the Arab Academy for Science & Technology in
Syria. Both universities use the open-source solution: Moodle as the main
learning Management system LMS (LEARNING MANAGEMENT
SYSTEM).
1. The results showed some resistant from the instructors to the concept
of E-Learning as 55% of them answered “no I do not support the E-
Learning Concept”.
2. A great deal of them found it tough, confusing, and time wasted. They
referred any downtime in the system 30% to the student heavy access
of the system and 25% to the development bugs conducted by pro-
grammers.
3. They sense the human-risk-factor and refers it to students and IT staff,
and kept themselves away from the blame! As a result 60% answered
“somehow” to the question: Do you think you can count on the LMS
(LEARNING MANAGEMENT System) in your day to day work” (In-
structor Survey, Question 8). The reasons they furnished for their sus-
picious position are again putting the responsibility on someone else
as they vote 30% to the weak support from IT staff and 20% for both
developers coding bugs and system is not meeting our requirements.
Still, 50% of them believes that students are doing fine using the sys-
tem and accepting it. Several kinds of problems reported to the in-

30
structors by the students. 30% is related to the weak support from IT
staff.
4. As we can see, the human-risk-factor “Weak support from IT staff” is a
real worrying issue to the instructors.
5. In their comments, educator‟s clarified that the most common risk they
are facing is miscommunication with IT staff. In many cases educates
are unable to understand the IT staff jargon. On the other hand, the
educators are afraid not to be able to explain their requirements to IT
staff.
Please refer to the Instructor survey results – Appendix E

31
5.1.5 Students Survey
The survey was conducted with more than 50 students from both the Arab
Open university in Kuwait and the Arab Academy for Science & Technol-
ogy in Syria. Both universities use the open-source solution: Moodle as
the main learning Management system LMS (LEARNING MANAGEMENT
SYSTEM).
1. 58.33% of the students use the E-Learning system on daily bases,
nevertheless, students didn‟t show full support to the E-Learning con-
cept as only 33.33% of them said that we support the LMS
(LEARNING MANAGEMENT System).
2. Students didn‟t find it a tough system to use but 45% of them found it
confusing and 41.67 % of them found it a time wasting system and in
contradiction the same percentage of student found it as a time saver
system.
3. 35% of the students found it a helpful tool to post their assignments and
30% depends on it for all kind of registration. But 60% of them faced a
system down situation and 38.33% of them put the blame on the
Weak support from the IT team. The weak support is the most com-
mon human-risk-factor in this survey.
4. 61.67% of the students said that they can‟t count on the E-Learning
system on their day-to-day work. The student explained their position
as following:
a. 25% because of weak support from IT staff

32
b. 21.67% because of teachers are not counting on it
c. 16.67% because of several development bugs
5. As we can see, students blamed others and free themselves from any
responsibilities.
6. Students followed a risk approach to solve any technical issue they
came through while using the system as 48.33% of them said that we
talk to colleagues to get support and only 23.33% of them tried to get
support from IT staff. This is a sign of not trusting the people in charge
of the system which I consider a huge human-risk-factor. Despite of
that 58.33% of them consider themselves doing fine while using the
system and that they accept it.
7. Student‟s survey showed that the human-risk-factor from their point of
view is so much related to:
a. IT helpdesk weak and late response
b. Wrong feedback from both IT and educators
c. Resistant from educators
d. System downtime
Please refer to the students survey results – Appendix F

33
5.2 List of most common human-risk-factors in IT projects related to
implemented Open Source E-Learning Solutions:
1. Low Experience and Qualifications:
a) Rare of persons with appropriate skills and experience.
b) Poor system developing skills.
c) An inexperienced developer might generate huge coding lines that
might be either full of bugs or not well designed which will consume
a huge amount of resources and as a result cause a lot of system
failures.
d) A confused Database Admin might not perform a solid DB tuning
and maintenance procedures such as backup and preventive re-
store plan in regular bases which might cause the whole application
to go down.
e) A low profile Network Admin might not have the proper know-how to
monitor and control the network related hardware and software as
well as not having a DRS or a BCP to keep the system up and run-
ning when needed. This situation might put us face to face with a
sudden system crash and retrieving it become impossible.
2. Resistance:
a. An end user might resist against using the system either because
of:
i. his technical limitation or
ii. because he is not familiar with such system or
iii. it might also be because of the difficult-to-use interface.
b. Such resistant will cause a situation where the system is not
adopted by decision makers.
3. Support:
a) A senior manager might not support the implementation or refuse to
provide the needed fund either because he doesn‟t believe in tech-
nology or because he prefers the old fashion way, or he like to keep
his budget as low as possible.
b) Rare Support from stakeholders and decision makers
c) Delay because of Vertical Management decisions

34
d) Not enough manpower involved in the project
4. Training:
a. Poor Not enough orientation and training for related persons
5. Communications:
a. Poor communication skills
b. Incomplete or inaccurate feedback
6. Managerial Skills:
a. Poor teamwork attitude
b. Poor Management of conflicts
c. Poor definition of responsibilities
d. Absence of leadership skills
5.3 Test Plan
I introduced the booklet to both the Arabic Open University in Kuwait and
the Arabic Academy for Science & Technology in Syria.
The persons in charge used the booklet as a reference while facing a sud-
den risk.
We agreed to test the booklet on one IT Professional, two faculty staff, and
5 students.
We agreed to test the following:
1. Ability to categorize the risk as a human-risk-factor or other factor
2. Ability to define the risk in detail
3. Ability to judge the severity, probability, and priority of the risk
4. Ability to minimize the risk
5. Ability to use the provided tables as a usable tools

35
5.4 The Results:
As expected the booklet helped all parties to better understanding of the E-
Learning system and as a result avoid many previous risks caused by
people. In some cases people were unable to interact with the booklet for
language or technology barriers.
In general, the issues pointed upwards to be tested were completed with
few uncertainties. It brought the attention of the persons involved to cate-
gorize the risk, identify it, and judge it severity. It also allowed them to pen-
point the risk and minimizes its consequences. The booklet successfully
presented itself as a useful and usable reference to monitor and control
human-risk-factors in IT projects related to implemented open-source solu-
tions in educational institutes.

36
Chapter 6. RESULTS AND
EVALUATION
The “Cure” Booklet
The booklet is a set of techniques and tools gathered in one document to
form a useful list that can sense in advance and investigate any suspected
human-risk-factor. It will include the following:
1. A set of Policies and procedures
2. A group of techniques and tools
3. A list of To-Do-Tasks
4. A list of advises, recommendations, and best practices to resolve
occurred human-risk-factors, and avoid human-risk-factors in fu-
ture occasions and similar circumstances.
5. A list of lessons learned in dealing with human-risk-factors
6.1 Policies and Procedures
6.1.1 Policies
This is a whole research by itself, but the main policy right here is that if
we encounter any human-risk-factor, we can count on the provided tech-
niques and tools, list of to-do-tasks, list of advices, recommendations, and
best practices, and the list of lessons learned to help you while putting to-
gether your set of policies and procedures.
One of the most important polices in risk Management is to have a tem-
plate for risk Management plan approved and distributed to related de-
partments to be used and unified. An example is in appendix C

37
6.1.2 Procedures:
1. Identify the risk and its characteristics
2. Recording the risk and its impact and
3. Investigating and research the risk for further analysis
4. Auditing the risk date and time, severity, effects, impacts, probability, and
possibilities.
5. Assign the risk for a appropriate staff member for further analysis and actions.
6. Assign persons to do the following:
a. Response to the risk
b. In charge of resolving the risk
c. Execute the response plan
d. Monitor the risk status and the progress of the risk Management activ-
ities
7. Prepare an risk Management execution plan
8. Measure and evaluate your plan activities, check your timing, your schedules,
your progress, and your communications.
9. Right a closing report in which you state the status of the risk, date and time
of the status, the result of your plan, the possibilities of further occasions for
the same risk, and finally the lessons learned.
10. Techniques and tools
11. Have a Risk assessment form in hand

38
6.2 List of Tools and Techniques
6.2.1 Choose the right person to do the right task:
In software development projects “Team members‟ under performance is
the source of most software project failures” (W E. Lewis 2005, p. 241).
Therefore, we must choose the right person to perform the right task. A
big mistake that many project managers do is to “simply dumping an
available resource into the project may cause havoc” (W E. Lewis 2005, p.
242). The right person should follow the following concepts:
 Do it right from the first time.
 Perform the task correctly with minimum errors. “Doing what we know in
a way we understand, for a predictable outcome” (Joanne Ceserani,
2003, p. 15).
6.2.2 Have a Projects Risks Breakdown Structure
It helps to identify and categorize risks. Project Managers needs to deal
with the following human-risk-factors: executive support, team experience,
and resources availability.
In the following figure we can see that human-factor-risks are presented in
different sections of the project risk Management stages.
 In business section, we might face human-risk-factor such as com-
petitor‟s attempts to blocking us from completing the implementa-
tion, or the suppliers who might not provide the needed resources.

39
 In the organizational section, we might face several human-risk-
factors such as missing the support from executives, providing
weak support for the end user, and also the team is not provided
with necessary tools to accomplish the implementation.
 In the project Management section of the risk breakdown structure
we can sense the human-risk-factor such as not enough human
resources available to complete the implementation. So the Risk
breakdown structure is a great tool to use.
Figure 7: Risk Breakdown Structure
“Figure 11-4: Sample Risk Breakdown Structure” (K Schwalbe, 2007, p. 458).
6.2.3 Use Risk Register Form:
Using “Risk Register” will register all possible human-risk-factors in order
to put it in one document/spreadsheet which contains the results of a
range of risk Management processes and then we can use its output as a
list of identified risks and other information needed to resolve the risk.
In the risk events section we can list all the human-risk-factors with it un-
certainties and the triggers or symptoms of actual risk event that might

40
occur in any stage of the implementation. As a result, we can pen-point
the solution on the spot. Kathy Schwalbe (2007) provided a sample Risk
Register table which I redesigned it to so that it can fit the purpose of the
research as following:
Table 3 : Risk Register - Example
Risk ID Details
Human-Risk-Factor Event Poor Development Skills by a Programmer
Description Poor Programming skills can generate a code full of bugs which
will reflect the overall performance of the application
Rank High Risk
Category (IT staff, Educa-
tor, Student, …etc
IT Staff
Root cause 1. Not enough inspection before hiring
2. Hired because of project immediate need
3. Project manager does not have a solid technical background
Triggers Pilot (Testing) setup environment generates a log full with bugs and
system instability
Potential responses Resistance of using the system by all end users
Responsibility
Risk owner
1. Project Manager
2. Staff Supervisor
3. HR recruiter
Probability Such risk can be repeated and will always have a negative impact
Impact Negative, stress environment, resist by end users
Status Building a complete manual of hiring polices and procedures for IT
staff related to open source E-Learning solutions suitable for educa-
tional institutes.

41
6.2.4 Have in-hand a Probability/Impact Matrix:
In the Qualitative & Quantitative risk analysis steps where we decide the
probability and impact of occurrence and we estimate the effects of risks on
project objectives. Some human-risk-factor occur when expert persons
miss-judge the risk and do not possess a strong knowledge of using the
proper tools and techniques. In order to avoid such situations we should
train all related persons use and actually master the Probability/impact ma-
trix techniques
Using probability/impact matrixes well help us to estimate the level of hu-
man-risk-factor and its impact on each step of the implementation process.
According Kathy Schwalbe (Figure 11-5, 2007, p.465), we can categories
the probability as high medium and low, and give each human-risk-factor a
level of impact again from high, medium, and low. The following table is an
example:
Table 4: Probability/Impact Matrix
Human-risk-factorProbability
High developers is new to
Open-Source environ-
ment
developers in sudden
leave with mo replace-
ment
developers‟ bad coding
developers not qualifies
Medium developer not enough
Low Technician is not quali-
fied
Low Medium High
Human-risk-factor Impact

42
6.2.5 Track the risk using the Top Ten Risk Item Tracking:
Using the top ten risk item tracking techniques periodically as a qualitative
risk analysis tool, we can identify all human-risk-factors and as a result
maintain a strong alertness of those risks throughout the life of a project.
As a result, we can command all the circumstances surrounding these
human-risk-factors.
For example we list all the current human-risk-factors along with its cur-
rent rank and the previous rank – if exist -. We also register the number of
times in which the human-risk-factor showed-up over a period of time,
then, we document the risk resolving steps and actions along with its sta-
tus. The following table is just an example:
Table 5: Top Ten Risk Tracking
Risk event Current Rank Previous Rank Resolving Actions Status
Developer absence 2 1 Job Matrix In progress
End User Resis-
tance
3 1 Orientation Ses-
sions
Done
Poor Leadership
from project man-
ager during the
implementation
1 4 Replacing the
Project Manager
Under Observa-
tion

43
6.2.6 Keep a watch list:
It is good also to watch and monitor all kind of risks even if they are cate-
gorized as low priority human-risk-factors as we do not want to leave a
chance for any sudden circumstances where we find ourselves face to
face with a potential human related risk. One way to perform this monitor-
ing is to use the watch list technique in which we list all the low priority
human related risks and keep it on-site for regular reviews such as using
the following table:
Table 6: Watch List
No Risk Event Explanation Why it is low priority Date of
review
Reviewer
1 End user difficul-
ties
Several end users faced a
difficulty in using the interface
We already oriented them along
with the instructors and pro-
vided them with hard=copy
material and provided on site
tutorial
1 Sep 2009 Rasheed
2 Leave Permis-
sions
Might lead to lose of resources
when needed and as a result
project delay
We have a job Matrix and a
knowledge transfer strategy by
which we keep all staff updated
and alternatives are always
available
15 Oct
2009
Kathy

44
6.2.7 SWOT
SWOT analysis for resources
Table 7: SWOT Strengths, Weaknesses, Opportunities, Threats.
Internal
External S W
O SO WO
T ST WT
6.2.8 Thaman and Wilemin’s Way:
K Schwalbe (2007) presented Thaman and Wilemin‟s way designed to avoid hu-
man-risk-factors though influencing all team members by the project manager.
What is interesting is that present of the work challenges and the expertise are
the reason of the success of most of the projects while giving authorities, money
and penalties are the reason for most projects fails. Here are the way‟s headlines:
1. Give team members the (A)authority to take decisions and give orders
2. Release prober (A)assignments to the team members by the project
manager
3. Have a reserved enough (B) budget to improve the quality and expe-
rience of team members as well as to run the project.
4. Have a plan of (P) promotion by which the project manager improves
workers positions and give them the chance to upgrade their job posi-
tions, titles, and responsibilities.
5. Spend (M) money by which the project manager can increase team
members salaries and related benefits.

45
6. From time to time raise the steak of (P) penalties in order to let the
team members know that as they are rewarded for good efforts they
also can be punished for critical mistakes.
7. Introduce some (W)work Challenge which will enhance the teams de-
sire to perform better and meet the expectations of the manager as
well as show their best skills. This is how they will be up to the chal-
lenge.
8. Introduce and emphasize the (E) expertise of everybody knowledge of
the project Management techniques and methods.
9. Improve the (F) friendship relation between the project manager and
others team members.
6.2.9 Use HOCKEY Stick Effect:
Manage the need of more resource by use the HOCKEY Stick Effect con-
cept (K Posner & M Applegarth, 1998, p.532).
Figure 8: HOCKEY STICK EFFECT

46
6.2.10 RAM responsibility assignment matrices:
To avoid human-factor-risks create a Project responsibility assignment
matrices in which we define who is responsible for which task in the
project and this is how we avoid critical risks of conflicts and every person
knows what is his responsibility and in which stage of the project. One im-
portant step that should be followed by the project manager is to track and
assess the performance of the team members. At this stage he must be
able to decide:
 If changes should be requested to the project
 If corrective or preventive actions should be recommended
 If updates are needed to the project Management plan or organi-
zational process assets
6.2.11 Security Risk Management Team SRMT
Because: “you cannot eliminate risk – you can only reduce it!” (K Ra-
bah,2008, p.3), all resources should be allocated in the most effective way to
support the business objectives such as:
 The project team should have the right skill to avoid the most crucial risks
 Team members available when needed
 Team member aware and fully understanding the project purpose, scope
of work, and in-depth read of the project charter.
 Team members should be prepared to work together as a team.
 The project team should share risk possibilities and causes

47
 Team members should be asked to participate in the process of identify-
ing the risks sources and act as a resource to avoid these risks
 Team members should be invited to be part of the project risk planning
 The project team should hold de-briefing sessions in which the project
manager reviews the risk breakdown structure and seeks feedback from
members.
6.2.12 What can go wrong?
According to Marc Weinberg (2006) in Passion Consulting, some people re-
lated issues can go wrong in an IT project and there is always a way to deal
with it. For example:
1. What if the process owner is out on vacation? The project manager
should try to delay their vacation time until after project completion. When
facing difficulties he should involve higher managers in the situation as:
“project czar whose role is to communicate the project importance through
the company” (M Weinberg, 2006, p. 2). Other types of questions to an-
swer are:
2. What if people are unavailable for hiring interviews?
3. What if there is a lack of senior Management support?
4. What is the probability that it would go wrong?
5. What are the consequences in the event the risk becomes a reality?

48
6.3 To-Do Task List
6.3.1.1 Categorize Project Risks
Project manager should know how to categorize the risks and updates the
following list and keep it in hand:
Table 8 Categorize Project Risks
Risk Kind
Macro Project Managerial
1 social issues Availability of re-
sources
Providing team
needed
2 Leave Issues Resource Man-
agement
Conflict Manage-
ment
3 Resources spirit
towards the project
Team work atmos-
phere
Stakeholders nego-
tiations
4
5
6.3.2 Always perform Continues Analyzing:
The role of Project Manager does not end “after preparing a detailed
project plan that includes the risks and assumptions” (W E. Lewis 2005, p.
243), but it is also a primary responsibility to the project manager to con-
tinue analyzing these risks while the project is in progress” (W E. Lewis
2005, p. 243).

49
6.3.3 Keep on monitoring the risks:
The Project Manager should keep-on monitoring the risks. Remote Man-
agement and improper delegation might turn to a catastrophe situation
“Several projects that have been managed by technical gurus have failed
simply for the reason that they have been micromanaged” (W E. Lewis
2005, p. 243). So the aim of monitoring is to be able to identify the prob-
lem in early stages and have the chance to resolve them before they turn
to cause a great damage. According to W E. Lewis (2005, p. 243) a Risk
and assumption analysis report is an effective monitoring tool that helps
the PM.
Use the following table as a help tool:
Table 9: Risks Severity/Impact
Risk
NO
Risk
Impact
Internal/External
Severity Very
High
High Medium Low Very Low
The Cause
The Effect
The Solution
Source of proba-
bility and magni-
tude of loss

50
6.3.4 List of people and risks
Always have in hand the list of people and related risks as furnished in ta-
ble 10 and as suggested in table 11
Table 10: List of People and Related Risks
No People Project
phase
Risk Cause Solution QA
Biz owners
Biz end users
Vendors
Project members
Project manag-
er/leader
Table 11: Risks By Implementation Phases
NO Risk Caused by Before Implemen-
tation
During After Later
IT Staff
Professional
Project Leader
Project team member
End user Educator
Students
Audience/Public
Decision Mak-
ers
Stakeholders
Mangers
Vendor/Solution pro-
vider

51
6.3.5 Risk Identification method:
 Planning Assumptions: There is some weakness in the planning assump-
tions method which we should open the eye on it as human resources are
not always available for such method and some personal interest will
cause conflict and a lot of misunderstanding.
 Diagramming techniques are more close to reality such as cause and ef-
fect diagram (ISHIKAWA, Fishbone diagram) will help us to identify the
human risk in precise
 In Software implementation projects it is good to use the System &
process flowcharts to identify risks in and their causes in processes ot
systems
Triggers and risk symptoms are warning signs that will alert us if human risk is
occurred or about to occur. An example of risk identification is shown in Table 9
(below)
Table 12: Risk Identification
Risk id Notes
Person (Risk Source) Rasheed
Position Project Member – Programmer
Risk Disc Absence with no excuse while he was supposed to per-
form a daily backup
Trigger of the risk End user trying to upload huge files caused the system
to halt
Consequences Today‟s data is not achieved
Category Of risk High risk
When Date & Time 1/11/2008 & 03:35 PM
Where
Effect
Cause
Cause

52
6.3.6 Perform several Stress Testing:
Testing the software is the key recommendation before we go live we
should stress test all the possible risks and analysis it. Perform risk analy-
sis task is to “measure the degree of business risk in an application sys-
tem to improve testing” (W E. Lewis 2005, p. 124). I believe that the best
approach in our research subject is to test the components of the applica-
tion “so that the testing can be directed at those components” (W E. Lewis
2005, p. 124).
6.4 List of advises, recommendations and best practices:
6.4.1 Make Sure:
In order to be able to a have a successful learning Management solution both
implemented and operated educational institutes should make sure to monitor
the capacity of the available staff both in quantity wise and quality wise. Also
educational institutes should monitor the right capabilities! The type and level
of needed skills of provided staff.
On the other hand, educational institutes should focus not only on the availa-
bility of project related staff, but also the continuity of the availability of those
needed staff during the time frame of the project whether they are internal or
external staff.
Another advice: It is not smart to build project team without project related ex-
perience! Team members should be armed with the right qualifications, the
right “needed” quality of work, and the professional sufficient training.

53
Projects uncertainties are unwelcomed visitors, and there is no escape from
them, but with a solid systematic monitoring and observing procedures, some
uncertainties such as: lose of key staff to competitors, death, or leave country,
and such as failure to deploy skilled staff, can be avoided. Have a task list to
be approved by all related members to before leaving for vacation
In order to have a good IT team educational institutes should hire ONLY the
proper and certified staff and Exam their qualifications before hiring them. For
example prepare a test scenario and ask them to solve a code bug. Later, ask
a quality assurance team and a CISA (Certified Information System Auditors)
to review the code, test it thoroughly, and provide their fair feedback before
hiring and before taking any code to a real live environment.
6.4.2 Advice to avoid Day-To-Day Risks:
According to Keith Posner & Mike Applegarth (1998, p. 96-99) in their great
PM Pocketbook, project managers should do the following:
1. Consider the RISK concept (Relationship-Information-Support-Kindness)
from the organizational point of view. For example, they suggest that in-
formation should be shared between members of the team, listen with
kindness and have a supportive leader (K Posner & M Applegarth, 1998,
p.72). The RISK concept have been introduced to the ICU at AOU, he
successfully used it to convince the educators to use the LMS
(LEARNING MANAGEMENT SYSTEM). He noticed that a huge differ-
ence occurred when he showed extra kindness and supportive activities
to the educators. This „RISK‟ concept emphasis information sharing and
exchanging habits.

54
2. Provide project members with required tools. In AAST Syria branch, the
stakeholder realized that providing training, orientation sessions, original
software, and professional textbooks improved his IT team performance
and minimized the founded bugs in the development phases. One of the
important tools I wanted every IT manager to implement is to let every
team member prepare an „Action Plan‟! in order to “„buy in‟” (K Posner &
M Applegarth, 1998, p.105) their attention and to always have a project
review In hand. Another tool that I stress on is it that every staff should
build his own plan including mission, goals, and Objective in the light of
the department plan.
3. Have a „Knowledge Transfer Matrix‟ in hand, and update it regularly to en-
sure dependency on one person. In other words, have a “buddy” for each
project team member as the “show must go on” (K Posner & M Apple-
garth, 1998, p.96). ICU manager at AOU told me that after reading this
advice, he used the phrase: “the show must go on” to spread the culture
of knowledge transfer among his IT staff. This was the first step for him to
prepare the job MATRIX later on. Along with Knowledge Transfer Matrix,
communication tactics should be performed such as departmental
monthly meetings, team weekly meeting, and one-to-one meetings on dai-
ly bases “a series of five minutes for each of my team” (K Posner & M Ap-
plegarth, 1998, p.100). ICU manager at ICU performed one of those meet-
ings in front of me. The staff was so comfort and relaxed knowing that I
am at the same time suggesting and witnessing this activity.
4. Emphasis the spirit of teamwork, and get “the right mix of traits, not just
skills” (K Posner & M Applegarth, 1998, p.42). During the interview, AAST
stakeholder told me that they were never satisfied with the quality of the IT
staff they have, but when the followed this advice and start filling the gaps

55
and hire a new mix of needed experience, not only he improved the
project performance but also he kept the staff and did not lose any of
them. The mixing idea indirectly helped him to monitor and control situa-
tions when one member believes that he is carrying the rest member. No
more, one man show, and no more superman thoughts.
5. Follow all what TEAM Concept need: “Together Everyone Achieves More”
this simple advice was already adopted by the ICU in AOU, but after re-
viewing the research advice related to teamwork such as: „Keep all mem-
bers informed‟, „Organize resources and clearly define their rules‟, and
„Trust their skills‟, he noticed the improved positive atmosphere among his
staff, and the amount of shared idea on his table waiting to be approved.
All staff is now project owners.
6. Using MORALE Concept (K Posner & M Applegarth, 1998, p.102) in order
to build positive self-estimated team members. They suggest that project
leaders must respect and listen to his staff when they need to talk as well
as to provide each team member with enough attention and concentration
including open communication such as greeting, congratulations, recom-
mendations to someone else, as well as remembering their activities such
as saying welcome back from vacation and appreciate meeting miles-
tones with one tough customer. They also suggest to the leaders to show
more attention to their staff by a greetings cards, a smile with caring eye
contact, and similar unexpected attentions. AAST told me that this is so
difficult in real work life and the day-to-day pressure denies him from be-
ing that kind with his staff. But he admitted that in the few occasions in
which he used MORALE concept it works like a magic.

56
7. Attracting principle: most of end users do not just resist IT solution for the
sake of resistant, they have some good reason such as fear of technolo-
gy, never did it before, language barriers, etc. In order to cut this out and
IT project managers should move one positive step towards his
clients/customers and he will notices that they will move two positive steps
as well. There are so many technology related attractions such as provide
each one of them with a person email account, provide access to interac-
tive services such as chatting, Blogs, Voting Pools. Free, rich and easy to
use E-Libraries works like a magic as it provides security and safety that
whatever information we need is available. ICU Manager in AOU told me
that his running E-Library in the LMS (LEARNING MANAGEMENT
SYSTEM) is the most used application right now. If the end user is an
educator/instructor, let them be part of the game! Ask for their input while
collecting business requirements and let them approve it and sign it be-
fore starting the implementation. Another attracting techniques is to pro-
vide them with a test environment in order to test the two side of the coin:
the application bugs, and the ability to use it by the educators.
8. Have a Solid IT infrastructure in order to avoid end user resistant. When
you have a solid and stable high availability fault tolerance systems no
one can blame you. ICU Manager at AOU told me during the interview
that he did not get the positive level of end user satisfaction until he re-
builds the whole IT infrastructure. I also believe that inviting end users to
short orientation sessions to explain what unnecessary activities could
cause and what risk might be generated is a helpful technique. Part of the
orientation sessions should be a kind of warning them from any destruc-
tive behavior such as performing unnecessary operations or any hacking
activities. Have a solid policy with punishment statements

57
6.5 Lessons Learned:
Based on the case studies furnished in appendix 1 and 2, along with other
investigations, the research collected and combined a list of lessons
learned from real life and real educational environment.
The research considered those lessons as practical and touches the psy-
chological part of the working environment.
Both AOU and AAST performed such activities but either randomly or se-
lectively, but when the research introduced this „combined‟ list of practical
lessons learned along with the other tools and techniques provided in sec-
tion 6.1, 6.2, 6.3 and 6.4, it makes a difference and get them interested to
test it profoundly.
Universities tried to put into practice some of these lessons, both from the
technical point of view (IT manger in AOU) and stakeholder point of view
(AAST), they notice the difference, and here are some example:
6.5.1 The art of leadership, influencing, and motivating Project Team
Member:
AAST stakeholder gathered the IT staff and used his skills of public
speaking to motivate them to keep their performance level going towards
the positive side of the chart. He noticed that almost 50% (5 staff in this
case) was really inspired and their performance was improved while the
other 50% improved their relations with the rest of the team. As a result,
an important lesson to be learned right here is:
Each and every project manager should master the science of motivating,
inspiring, and influencing his team members.

58
Influencing and motivating others is a great leadership skill that each and
every project manager should master in order to get the best of his team.
He must be able to let them talk, let them care, and let them, share. Re-
porting to him should be fun and something everyone like to do.
Discussion sessions should be a cheerful and enjoyable thing to do during
the project phases. The ability to solve any conflict between the team
members is so vital to the success of the project. Open door policies, en-
couraging team members to suggest and anticipate in the decision mak-
ing process is crucial help to enhance the project performance. On the
other hand the project manager should have his own approaches to man-
age his staff and he should be able to incorporate some of the following
tools and techniques:
 Observation and conversation
 Project performance appraisals
 Conflict Management
 Issue logs
6.5.2 Improve Leadership Skills:
Dr. Saatchi, the IT manager in AOU is armed with some strong leadership
personality, I noticed that during my site visit, while waiting in his office I
observed his staff working hard and focusing on what in their hands.
When Dr. Saatchi came all of them give him a respect look and nice smile
and kept doing their task. He shakes hands with all of the 3 persons in the
room and introduced me to all of them one by one. When he turned
around he just said: “Mr. X, I believe you completed the code related to
the new voting web part in our student‟s portal” and the answer was “yes

59
sir, indeed. It is in your email box”. It was clear that his wishes are their
commands. I believe with this kind of follow up and commanding capabili-
ties, no chance for any „delivery delay‟ human-risk-factor can occur.
As a result, a huge lesson learned right here is that: A strong leadership
personality is a must for any projects manager/leader or owner.
According to Stephen Covey: “the manager who do things right but the
leader is who do the right things” (CHOPARD, 2009). If we command the
leadership skills, we can control and avoid any possible risks in IT projects
“a leader alone will take the organization to greater heights” (W E. Lewis
2005, p. 242).
6.5.3 Develop Strong Communications Skills:
From the same example and witnessed case mentioned in 6.5.2, we can
notice the strong communication skills from two sides, the IT manager,
and the staff. The eye contact, the hand shaking, the smile, the clear and
short question, the immediate and right answer, and finally the communi-
cation media (email). All are indications of well established communica-
tions skills among the whole ICU. The important lesson to be learned here
is that:
A good, clear, and practical communication skill is an essential tool to
handle risks caused by people.
The well managed dialog and professional discussion skills will help the
project manager to find-out the real risk and handle it. All kind of commu-
nication skills such as verbal, written, listening, or speaking wither it is in-
ternal or external to the project all should be mastered. In summary, we
must make sure that data is accurately exchanged.

60
6.5.4 Document of Roles and Responsibilities
During my interviews with both ICU manager in AOU and stakeholder in
AAST, they both explained in so much detail their IT environment and the
technology they used, but when I asked about the role of the staff related
to E-Learning solution, they both summarized the role description and un-
intentionally switched the subject to what they are suffering because of
the lack of manpower and the risks that are generated. I told them that
from my work experience, I know what it takes to have a complete and
updated documented manual of roles and responsibilities. It is a real
tough work to do, but once done, it is with great help and really let every-
one understand what he is supposed to do and what he is not supposed
to do. It unifies the expectations and protects every individual in the
project.
It was not an easy subject to raise, but both agreed with me: It worth a try.
According to the PMBOK, in the risk Management planning step, a com-
mon human-risk-factor at this stage occurs when project team members
do not take enough time to review and understand the project scope of
work document as well as do not get a complete clarification of the needs
of project sponsors. Such risk at this early stage will clone several
chances for risks. A good solution to avoid such situation is to emphasize
the use of a well written roles and responsibilities document which will
provide a clear explanation of: who should do what and why and when
and where. It is preferable to have as an appendix to this document a list
of all possible human-risk-factors at this stage with a predefined actions
and directions to the project team members as a “must follow” if an identi-
fied risk event occurred.

61
6.5.5 Brainstorming sessions and interviewing techniques
Mr. Khalid from AAST told me that he supervised several brainstorming
sessions with his staff to draw a clear picture of how the LMS (LEARNING
MANAGEMENT SYSTEM) solution will be. At first, nothing was deserved
to be recorded and discussion was poor and unpromising. “Maybe be be-
cause we are not used to such techniques” He added. But after 3-4 ses-
sions things changed and some creative ideas was presented and
adopted as well.
The lesson learned here is: brainstorming and interviewing techniques are
useful despite of their time consuming nature. If the project manager is out
of ideas, go for it, and record all ideas. You might need it later on.
On the other hand, and according to the PMBOK, in the risk identification
step, a possible human-risk-factor might occur such as not having a
common understanding and agreement on the project identification be-
cause of counting just on documents without collecting feedback from
business related persons. Therefore brainstorming sessions is very useful
activity at this stage. The input of the brainstorming sessions and inter-
viewing should be documented and reported to all related stakeholders
footed by the signature of all sessions and interview attended. These
signed documents should be attached to the project main plan.
6.5.6 Effective hiring process:
Both Mr. Khalid and Dr. Saatchi explained the methods the followed to hire
their staff and that they are happy with their choices. Dr. Saatchi stated that
he preferred to hire staff rather than outsource them. After testing their qua-
lifications, he hired them and built their experience related to the LMS

62
(LEARNING MANAGEMENT SYSTEM) solution. He considers them the
most important asset in his department.
As we can see from this example, in IT projects, staff is the most important
assets. If they are qualified the success rate of the project will improve. It‟s
important to assign the appropriate type and number of productive people
to work on projects at the appropriate time with needed skills. This is a criti-
cal component to consider when hiring people who will be involved in a
project.
According to the PMBOK, we must plan first for the needed resources and
to identify their roles and responsibilities in the project. Once the team is
formed, a lot of efforts should be established to properly manage, monitor,
and control their performance.
The lesson learned here is that: It is an art and a great skill to be able to
acquire the project team members out of all nominated persons to the posi-
tion and get the needed person and suitable for it.
Kathy Schwalbe (2007) summarized this in the following figure:
Figure 9: Human Resource Planning
“Figure 11-3 Project Risk Management Summery” (K Schwalbe, 2007, p. 353)

63
6.5.7 Follow the PMI PMBOOK hints:
I enjoyed talking to Mr. Khalid from AAST because of his skills and knowledge in
project Management. He commanded the PMP (professional Project Manage-
ment) curriculum. Our interview summarized the PMP process and linked it to the
risk Management planning. We concluded that: In order to avoid those human
risks we must do the following:
 In the planning step we must define:
o the Roles& & Responsibilities
o the Authority levels
o the decision making responsibilities
 In the risk identification step we must avoid the following:
o poor allocation of resources
o poor use of PM disciplines
o Resource conflict with other projects in the educational institutes.
 We also should do the following:
o document the project plan and assumptions
o document the roles and responsibilities
o have a good information gathering techniques which involves hu-
man such as brain-storming and interviewing
6. In the qualitative risk analysis we must:
o Assess the impact and likelihood of all identified human risk
o Prioritize it according to its positional effect on the project objec-
tives.
 In the quantitative risk analysis we must
o Assess the cost and possible lost of all identified human risk
o Prioritize it according to its positional effect on the project objec-
tives.

64
 In the risk response planning we must
o Risk Response plan should be owned by a responsive person, ap-
proved by the decision makers, suitable for the severity of the hu-
man-risk-factor, consider the quality, quantity, and qualifications of
the hired persons, and finally, It should be controlled and moni-
tored
o Provide resources to solve the human-risk-factor
o Manage resources to perform task in the best possible time and
performance to get the best possible result
o Minimize the risk possibilities in future occasions
o Record the risk, the actions, and the result
 In the risk monitoring and control we must
o Keep records for risk status
o Keep a professional person to handle those records
 The benefits of Risk Analysis is to improve communication between
members of the project team and other stakeholders that will create com-
mon views and better focus on project
6.5.8 Stakeholders Risk Tolerances
Dr. Saatchi explained his efforts in explaining the importance of the sys-
tem to the educators as stakeholders and to the university top Manage-
ment. He faced resistance, unfamiliarity with the concept, and inability to
define the role of each one of them.
According to the interview, he did not successes until a new CEO has
been hired and adopted the concept of LMS (Learning Management Sys-
tem). Only then, Dr. Saatchi was able to improve his IT infrastructure,

65
build the LMS (LEARNING MANAGEMENT SYSTEM) solution based on
Moodle technology.
As human, stakeholders might cause some risks, such as not knowing
their roles in the projects implementation plan. What they should and
should not do.
We should also understand their mentality towards risks! Are they risk
averters or neutral or seeker and based on that we can build a response
plan to the risks.
According to the PMBOK:
 Risk Avoidance are those who act in a preventive way towards
risks once they occur
 Risk Transformers are those who always shift responsibilities to
others once the risk occurs.
 Risk Acceptance are those who accept consequences of any risk if
it occur.
 Risk Mitigations are those who always take corrective actions to-
wards a risk once it occur.
The lesson learned here is that: it is a must to define the stakeholder’s
role and to appoint them based on their background related to the project
as well as their experience.

66
Chapter 7. CONCLUSION
7.1 Lessons Learned: The research emphasized on:
At the end of the research, we came to know several ways to con-
trol and handle risks caused by people using open source technol-
ogy to implement E-Learning solutions. The research emphasized
that IT projects risks are not something to live with any more. It
should be pen-pointed and resolved even before they can occur.
The research proofed that those human-risk-factors increases when
working with open-source solutions environment and explained that
educational institutes should approach the open-source solutions
with caution and that they should be prepared to face the human-
risk-factor with a solid plan.
The research clarified the hidden costs in any IT project and con-
cluded that “Nothing is for free”. The theory of the “free-of charge”
open-source solutions should be clarified and explained in transpa-
rency for all who plan to use it. Another delivered message was:
when it comes to implementing a learning Management system
LMS (LEARNING MANAGEMENT SYSTEM) for educational insti-
tute, it is quality, stability, and availability is what counts and not on-
ly cost.

67
The research provided a handy booklet to keep in hand and review
when needed. This booklet provided a list of recommendations, ad-
vises, and best practice direction to avoid the human-risk-factors in
those kinds of projects. The booklet has been reviewed by IT direc-
tor and a university stakeholder and both confirmed that it helped
them to minimize risks and have a clear idea on how to deal with
risks if occurs.
Together, the above mentioned: (6.1) the policies and procedures
manual (6.2) list of tools and techniques (6.3) list of to-do-tasks
(6.4) list advices, recommendations and best practices (6.5) Les-
sons learned, forms a perfect framework for any educational insti-
tute to anticipate and foresees human-risk-factors in related IT
projects.
Finally, and as a result of the research, a lessoned learned state-
ment has been designed, a booklet of best practice has been pro-
vided, a list of recommendations has been accomplished, and all
are tested in the AOU and considered as useful and valid.

68
7.2 Further Activities:
I believe that more stress testing activities should be performed by
several educational institutes in order to find and perform the re-
quired improvements and enhancements to the provided booklet. I
also suggest that this booklet should be converted from just a ma-
nual of recommendations, advices, and directions into a complete
software solution to analyze the human-risk-factors and provide a
cure to it on the spot.
Finally, I have a vision by which I am going to study the physiologi-
cal effect on human while facing or causing a risk during IT project
related to implementing an open source E-Learning system.

69
7.3 Prospects for further work to be conducted:
From my point of view, I visualize the following optimistic scenarios
for this booklet: It is going to be improved by several modifications
and critical enhancements. Depending on the findings of the two
case studies I performed, some efforts will be generated to reformat
the booklet, and introduce it in a form of IT Projects RISK Policies
and Procedures Manual.
The next step would be a deep technical efforts to covert the book-
let into software analyzing package by which educational institutes
can measure risk situations, categorize it, and provide information
about the level, the impact, and the probability of the risk being ob-
served. The software will generate alerts, notifications, and reports
directed to related persons.
I also prospect that with some extra academic efforts, the research
is going to be improved and introduced in a reference/textbook for-
mat that can be founded on the book library‟s shelves in the busi-
ness Management section.

70
REFRENCES CITED
Bedrock City University (BCU) Secure Network Infrastructure Project Developing
IT Security Risk Management Plan. The Way Forward: A Global Open Varsity
Reading Room Academic Technical Publication. Permissions: A GOV Open
Knowledge Academic Access License
Bryan Barrow MBCS CITP (2007) „Four reasons to use project risk Management‟
[Online] Available from: http://www.bcs.org/server.php?show=ConWebDoc.16427
(Accessed: 7 July 2009).
CHOPARD (2009) Managers do things right, leaders do the right thing.
[ONLINE] Available from: http://chopard.watchprosite.com/show-forumpost/fi-5/pi-
3184601/ti-524426/s-0/ (Accessed on: Oct 10
th
, 2009).
Deltek (2007) White Paper: Improving Project Decision Making and Reducing
Exposure through Risk Management
Gary Hein (2004) Open Source Software: Risks and Rewards.
ECAR Symposium Application Platform Strategies VP and Service Director
W E. Lewis (2005) Software Testing and Continuous Quality Improvement Second Edition
By CRC Press LLC Published by: Auerbach Publications. ISBN 0-8493-2524-2
IT-Cortex (n.d.) „Failure Causes Statistics‟ [online] Available from:
http://www.it-cortex.com/state_Failure.htm (Accessed: 1 Aug 2009).
Joanne Ceserani (2003) Problem Solving Pocketbook Published by Management
Pocketbook Ltd www.pocketbook.co.uk ISBN: 1-903776-04-X.
Kathy Schwalbe (2007) Information Technology Project Management Fifth Edition
Thomson Course Technology a division of Thomson Learning, Inc. ISBN: 13:
978-1-4239-0145-7
Keith Posner & Mike Applegarth (1998) Project Management Pocketbook Management
Pocketbooks Ltd ISBN 1 870471 63 6 Printed in U.K.

71
Kifa Rabah (2008) IT Risk Management Plan – The Way Forward Module I Risk
Management Plan A case Study.
Marc Weinberg (2006) Project Risk Management Are you Asking, “What Can
Go Wrong?” Parson Consulting Sarbanes-Oxley
Moodle (n.d.) Moodle Statistics [Online] Available from: http://moodle.org/stats/
(Accessed: 4 Aug 2009).
Norman Wiseman (2009) „JOINT INFORMATION SYSTEMS COMMITTEE INVITATION
TO TENDER - A Guide to Investing in Proprietary, In-House or Open-source
Software and Services‟
Project Management Journal (2000) Risk Management: The undiscovered dimension
of project Management. Project Management Journal | March 1, 2000| Royer,
Paul S | Copyright.
PMI PMBOOK (2008) „Project Management Book‟

RHouraniDSFinalPaper

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (17)

Similaire à RHouraniDSFinalPaper

Similaire à RHouraniDSFinalPaper (20)

RHouraniDSFinalPaper