An Approach to Sharing Solutions to Software Project Management Problems

Khairuddin Hashim
Software Engineering Department
Tenaga Nasional University
43009 Kajang, Malaysia
khairuddin@uniten.edu.my
Ayad Ali Keshlaf
Industrial Research Center
Tripoli, Libya


AbstractSoftware project management becomes more
challenging due to increase in budget investment and stiff
business competition requiring urgent deliveries. The paper
presents an approach to sharing solutions to software project
management problems. It includes risk identification, risk
analysis and planning, risk prioritization, risk monitoring and
risk control. The model incorporates problem analysis of
historical data of projects which gives a good basis for risk
projection. Organizations get to share project management
problems and solutions in anonymity.
Keywords- Software Project Management,, Problem
Analysis, Risk Monitoring, Risk Control
I. INTRODUCTION
The success of any project is usually dependent much
upon its project management. As in any project
management endeavor, proper planning and execution is
critical. A lot of problems and difficulties have caused
delays and incompleteness in software projects. Many
reports and statistics attributed the failure of software
projects to poor project management.
Project management includes two important phases
which are monitoring and control. Through monitoring we
can check if a project is conforming to planned schedule.
Through control, the project manager is required to resolve
any deviation from scheduled activities.
In software engineering, risk is defined as the probability
of incurring a loss or enduring a negative impact [1]. In a
multi-faceted project, there are many potential factors that
can affect the success of a project. Risk management is a
critical component of modern day software project
management. Through risk management, every critical
factor that can affect the success of a project is identified
and analyzed, and mitigation steps are laid in place and
executed, if the risk becomes reality.
This paper introduces a model that facilitates the sharing
of problems and solutions in a risk management model that
can be useful to any software project management. The
model covers the following phases: risk identification, risk
analysis and planning, risk prioritization, risk monitoring and
risk control. Under the phase of risk analysis and planning,
the model incorporates a problem analysis approach based
on historical data.
II. BACKGROUND
Bannerman suggests that current risk management may
not be good enough, with both opportunity and need to
improve the contribution of research and practice to project
outcomes [2]. Project management covers the scope of early
identification of problems so that corrective action may
follow [3]. An improvement to project management can be
done through learning from history i.e. learning from
successes and failures and how to make the right decisions
in the future [4]. The model that has been developed
incorporates a module to identify potential problems based
on past projects. With an ever increasing dependence on
information technology to enable our businesses,
governments and society in general, the time has come for
radical improvement [5].
Work done in [6] describes a 7 step risk
baselining which starts with identification, approval and
documentation of a risk by the lead member of a project. The
risk details are then sent to a project management risk review
board for approval. Upon approval, a risk owner is assigned.
The risk owner who is a member of the team works with the
team to analyse situation, identify root causes, evaluates
consequences, categorise risk level, and develop risk handing
strategy and plan. The handling plan is then submitted to the
review board for approval. Upon approval, the risk is
baselined and executed according to the risk handling plan,
when necessary.
III. THE MODEL
The model represents phases and support entities that
ensure proper risk management are done. The model
comprises of the following phases:
Risk Identification
Risk Analysis & Planning
Risk Prioritization
Risk Monitoring
Risk Control
Apart from these, the model is supported by risk matrix
and database. A risk matrix defines the risk attributes of a
risk item. A Risk Database stores current and past projects
risk information. A graphical representation of the model is
given in Fig. 1.
2009 International Conference on Information Management and Engineering
978-0-7695-3595-1/09 $25.00 2009 IEEE
DOI 10.1109/ICIME.2009.141
694
2009 International Conference on Information Management and Engineering
978-0-7695-3595-1/09 $25.00 2009 IEEE
DOI 10.1109/ICIME.2009.141
694

Figure 1. The risk management model.
A. Risk Identification
In a typical project initiation phase, potential risk items
are identified. Usually, relevancy of risk items against
project attributes is evaluated. This approach makes use of
the ten risk items [7] by Boehm and includes an additional 7
risk items which were proposed through a survey. The list
of risk items is given in Table 1.
At the end of this phase, only relevant risks items are
listed for future assessment. The model is supported by a
Risk Matrix definition for each risk Item. An example of a
Risk Matrix is given in Table 1.Newly identified risk items
not in the current list will be added to the Risk Database.
TABLE I. LIST OF RISK ITEMS
No. Risk Item Risk Management
Techniques
1 Personnel Shortfalls Staffing with top talent,
job matching, pre-
scheduling key people
2 Unrealistic Schedule
& Budget
Detailed cost and
schedule estimation,
design to cost,
incremental development,
software reuse
3 Developing the User surveys, prototyping
wrong software
functions
4 Developing wrong
user interface
Prototyping, task analysis,
5 Gold Plating Requirements scrubbing,
prototyping, cost benefit
analysis, design to cost
6 Continuing stream of
requirements change
Incremental development
7 Shortfalls in
externally furnished
components
Benchmarking,
inspection, reference
checking,
8 Shortfalls in
externally performed
tasks
Reference checking, pre-
award audits,
9 Real-time
Performance
Shortfalls
Simulation, modeling,
tuning
10 Straining Computer
Science capabilities
Technical analysis,
reference checking
11 Stability of personnel
high staff turnover
Strong management,
organizational review,
good working
environment
12 Bad traceability Good documentation &
cross referencing
13 Insufficient
verification &
Validation
Check-listing & check-
pointing
14 System complexity Documentation,
decomposition, metric
measurement
15 Customer unsatisfied
at project delivery
Prototyping, customer
review, incremental
development
16 Risk reducing
technique producing
new risk
Thorough study of risk
reduction techniques,
special risk management
17 Catastrophe/Disaster Disaster recovery
measures

TABLE II. RISK MATRIX
Risk Item: System Complexity
Risk Type: Technical Risk
Risk Phase: Design and Coding Phases
Risk Cause: Lack of Expertise
Probability of Occurring: Low
Risk Magnitude: High
Risk Responsibility: Developer X
Contingency Plan if RE is Moderate
Execute Decomposition
Contingency Plan if RE is Critical
Hire Expert
Acceptable Risk Level: If RE is Marginal
695 695

B. Risk Analysis And Planning
Risk analysis is usually done through the evaluation of
risk exposure (RE) which is defined as the probability of a
risk happening multiplied by the impact or magnitude. A
high probability risk with high impact is give a Critical RE
value. This represents a risk that needs to be managed to
reduce the possibility of it happening and giving a big
negative impact to a project. The rating of RE based on risk
probability against risk impact is given in Table 2.
TABLE III. RATING OF RE
Probability
High Medium Low
I
m
p
a
c
t

High Critical Critical Moderate
Medium Critical Moderate Marginal
Low Moderate Marginal Marginal

Analysis is done on a weekly basis through the use of a
questionnaire which will give the RE rating for each
identified risk item.
Risk mitigation steps are planned for each risk item.
This is to ensure that when a risk happens, steps to mitigate
it can be taken immediately.

Problem Analysis
Through this approach, past projects details are mined
from Risk Database to help highlight potential problems in
current projects. Apart from providing a list of potential
problems, the model also provides a feature for comparison
between two or more projects to identify similarities in
problems faced or personnel resource involvement.

Analysis of Old Projects
Pressman reported that those who cannot remember the
past are condemned to repeat it [8]. One of the most
important steps is to avoid areas where problems arise.
Statistical quality assurance based on past projects can help
enormously in identifying problem areas and resources. The
model implements the following:
(a) Provision of information on problems in both current
and past projects.
(b) Provision of information on critical problems, and
frequency of occurrence.
The model records all information about each problem
such as the factors responsible for causing the problem and
projects which have been affected by this problem. Data
collected helps in identifying potential problems in new
projects.

Analysis and Comparison Based on Selected Projects
The model helps the project manager to analyze
projects, which might be related to each other or in the same
application domain. The model allows for comparison
between 2 or more projects. This is done by providing
information on the following:
a- All problems and the responsible personnel affecting
the selected projects and highlighting the problems for
each selected project. This helps identify incompetency.
b- Similar problems and similar personnel responsible for
causing the problems.
c- Problems and the corresponding personnel responsible
for the selected projects in specific phase.
d- Identification of similar problems in specific area.

C. Risk Prioritization
Based on the evaluation of RE and taking into account
other aspects impinging on each risk item, a prioritized list
is created. This list has the list items sorted in descending
order of criticalness.

D. Risk Monitoring
Risk monitoring is the process of checking the risk
levels of identified risk items so that they are within
acceptable levels. A tool can help visualize the current level
of a set of risk items through a bar chart. A week by week
representation for each risk item can be done through the
use of a line chart. Identification of levels exceeding the
threshold levels can be highlighted using color.

E. Risk Control
Based on the RE ratings monitored during the risk
monitoring phase, if the risks levels go beyond acceptable
levels, recommended mitigation steps are executed.
The development of a web-based system to support the
model on an ASP (Application Service Provider) mode will
help organizations subscribe; and share problems and
solutions in anonymity whilst project and personnel details
can be hidden or be secured at local servers.
IV. CONCLUSION
In this paper we described our approach to sharing
software project management problems and solutions. This
approach helps identify potential problems early and
facilitates access to possible solutions when problems arise.
The model covers important phases and emphasizes on risk
projection for current projects based on historical data.
REFERENCES
[1] R. Fairly, Software risk management [Glossary], IEEE Software,
22(3), 2005, 101.
[2] P. Bannerman, Towards An Integrated Framework of Software
Project Threats, Proceedings of Australian Software Engineering
Conference, 2008.
[3] L.A. Patah, M.M. Cavalho, Measuring the Value of Project
Management, PICMET 2007 Proceedings, 5-9 August, Portland,
Oregon.
[4] Zimmermann, N. Ngappan, A. Zeller, Predicting Bugs from
History, Thomas, T. Mens, S. Demeyer (Ed.), Software Evolution,
Chapter 4, Springer, 2008, pp. 69-88.
696 696
[5] C. B. Daniels, W. J. LaMarsh, Complexity as a Cause of Failure in
Information Technology Project Management, SoSE07, IEEE
International Conference on System of Systems Engineering, 2007.
[6] C. W. Benjamin, Hon-Yue Chou, M. B. C. Wu, D. H. C. Chang,
The Risks of Risk Management, IEEE International Conference
on Management of Innovation and Technology, 2006.

697 697