See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/221610941

A Survey on Challenges of Software Project Management.

Conference Paper · January 2009

Source: DBLP

CITATIONS READS
15 1,537

1 author:

Kadir Alpaslan Demir

Naval Research Center
54 PUBLICATIONS   241 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Industry 5.0 View project

Development of a systems development life cycle model for large-scale defense systems View project

All content following this page was uploaded by Kadir Alpaslan Demir on 13 October 2014.

The user has requested enhancement of the downloaded file.

 A Survey on Challenges of Software Project Management
Kadir Alpaslan Demir
Department of Computer Science, Naval Postgraduate School, Monterey, CA, 93943, USA

that it has a broader view and focuses on management areas

Abstract - Recent surveys indicate that software projects have
rather than specific reasons for software project challenges.
still high failure rates. In order to increase the odds of
This is important since it provides guidance for research
success, we have to identify the challenges and determine the
studies focused on improvements in specific management
causes. Management issues, rather than technological issues,
areas. Most previous surveys were conducted on a specific
are mostly the causes of these failures. We identified 17
geographical region while ours has representatives from
possible areas in which the projects may have been
different regions in the world. This study also includes areas
challenged. In this study, we present our findings based on a
not specifically covered in other studies; for example
survey on challenges of management of software projects. We
teamwork, staffing and hiring, configuration management, and
conducted the survey in 2007 among 78 software practitioners
support activities. In addition, we did not differentiate between
regarding their last projects. The participants are from
successful and failed projects; therefore, the survey results
different geographical regions of the world.
also include the challenges faced in successful projects.
Keywords: Software Project Management, Software Project
Management Challenges, Software Projects Survey, 2 Survey Methodology
Empirical Study of Software Projects, Empirical Software We have identified possible 17 areas in which the
Engineering software projects may have been challenged. These areas are
identified through extensive literature search and provided in
Figure 4.
The survey instrument was a self-administered
1 Introduction questionnaire. The timeframe of the survey study was the
There are two well-known studies regarding the failure and beginning of 2007 and the study took around 4 months. The
successes of software projects [1,2]. These studies also report survey participants were invited via e-mails to take a web-
failure factors and challenging issues in software projects. based questionnaire prepared with a commercial tool. The
According to the GAO report (1979) and Standish CHAOS random sampling method was applied. Around 400 software
report (1994), which were conducted 15 years apart, software development practitioners were invited from all over the
projects are failing significantly. These studies are referenced world. We did not use any commercial or readily available
in software engineering related publications numerous times population sample. The invitations were sent to practitioners
[13]. However, especially the numbers in Standish Chaos from different organizations. The participants included
report are being questioned by various researches [3,4,13]. managers at different levels and software developers.
Other studies were conducted (such as [5,6]) and inconsistent Developers were also included since the management
results are reported. We believe there are two main reasons for decisions closely affect them. Therefore, developers have a
such discrepancies. First, defining success and failure is not an sense of what the important issues are in management.
easy task and different stakeholders may have different views There were 78 responses and the response rate is about
[14]. Second, we still lack adequate number of empirical 19.5%. We had responses from North America, Europe, Asia,
studies. and South America. However, most of the responses are from
Due to the inconsistent results and various challenges North America, which produces a significant portion of the
reported in previous studies, the author conducted a study to software in the world. The survey was conducted with the
investigate the management challenges of software projects. promise that the identities of the participants would be kept
This survey study was conducted as a part of a doctoral confidential.
research. Most publications on the topic of software project We provided a glossary of the terms used in the study to
management are based on the experiences of researchers and ensure that the survey participants understood the same
practitioners (such as [7,8,9,10,15]) rather than empirical concepts.
studies (such as [11,12,14]). Different studies and researchers In the first part of the questionnaire, we gathered data on the
identified various issues, for example in [10,11,12,15]. participant’s background. We first asked the participant’s past
Our primary goal in the study is to find out the challenges experiences in terms of years in various software development
faced in the management of software development projects. roles, including management. Second, we inquired about the
This study is different from the previous surveys in the sense number of projects in which they have participated. We
believe that the results are derived from a good mix of roles 3 Survey Study Results
and experiences from participating in a different number of
projects. Since having a certain role or participation in a The responses to the questions are summarized in the
certain number of projects may bias the perspective of the following figures.
participant. 42 respondents out of 78 have participated in less
than 15 projects. 36 out of 78 respondents have participated in
15 or more projects. Table 1 provides the participants’
experiences in terms of roles. The table includes all of the Question #1 Project Size in Terms of Number
roles each participant has played during his/her career in of Staff
50
software development. 41

Response Count
40
32
Table 1. Participants’ Experiences in Terms of Roles 30
Roles Response Count 20
Project Manager 56
Project Team Leader 49 10 5
Requirements Engineer 23 0
Software Architect 27 1-1O 11-100 101-or more
Software Designer 24
Software Tester 15
Software Maintenance 18 Figure 1. Responses to Question #1
Software Code Developer 43
Researcher/Scientist 28 Question #2 - Project Size in Terms of
Software System Engineer 24 SLOC
70 62
Other 26 Response Count 60
Total number of responses 78 50
40
30
In the second part of the questionnaire, we gathered data on 20 13
10 3
the last project in which the survey respondents participated. 0
We asked the following questions: (small) (medium) (large) >2
1. How many people were working in your last software <20,000 SLOC 20,000 SLOC - Millions SLOC
project? 2 Millions
o 1-10 SLOC
o 11-100
o 101 or more
Figure 2. Responses to Question #2
2. What was the size of your last software project in terms of
SLOC (SLOC: Source Lines of Code)?
o (small)<20,000 SLOC Question #3 - Organization Type
o (medium) 20,000 SLOC – 2 Millions SLOC
o (large) > 2 Millions SLOC 40 36
Response Count

3. What was the type of your organization in your LAST 35

software project? 30 24
25 18
o Government 20
o Commercial 15
o Government-Contract 10
5
4. What kind of an application was developed in your last 0
project? (real-time system, web-based, office-type application, Government Commercial Government-
operating system etc.) Contract
5. In your last project, in which of the areas did you face
challenges?
The participant was asked to select one or more from the areas Figure 3. Responses to Question #3
presented in Figure 4.
Question #4 was open-ended and all other questions are
provided with choices. In question #5, two more choices
added to the list: “Others” and “The project was smooth in
every way.”
 Question #5
45 41 40
40
Response Count

35 32 30
30 26
25 22 21 21 20 20 20
19 18 17
20 15
15 11
8 7
10
5 2
0

.
t M en t

)
ty

)
ng
t

er
om rol

k
t

t
on

ay
fy

c.
ro
en

en
en

en

en

or
hi
rin
io

xi

ag

t
ci
i
i

w
nt

,e
er
rs
em

m
at

at
em

em

w
on

le
Hi

pe
an
Co

am

y
ve
t im

ic

ne
t
e
p

ls
i
C

s
g/

er
ag
ag

ag
ad

s
un

oo
se
ol
g/

gi

Te
fin

sk

ev
Es

om

e
an
an

an
Le
nv
rin

En
m

As

as
lC

,T
ec
Ri
af
g/

in
M
M

M
m

lC
rI

le
ito

ng
oj
ca
St
in

sk
Co
e

ts

th
P
de

lit
na

r
nn
op

on

ni

ni
io

(
Ri
en

oo
ua
ol

er
io
ch

ai
at
la
Sc

tM
m

eh

sm
Q

th

r
at
ur
tP

Te

(T
ire

iz
ec

O
ak

ig
ec

as
s
an
qu

nf
oj

St

e
oj

tw
it i
rg
Co
Pr
Re

Pr

tiv
O

ec
c

oj
tA

pr
or

st
pp

la
Su

e
Th
Figure 4. Responses to Question #5

4 Detailed Discussion of Results 41.7%. In short, almost one out of two software projects were
challenged in managing the scope.
Identifying objective criteria for determining whether a
project management area is challenged or not, is not an easy Table 2. Challenging areas in software projects
task. To capture the challenged project management areas in Project Management Response Response
the broadest sense, a definition of a challenge was not Areas Percentage Count
provided to the study participants. Since an inaccurate or Scope Management 52.6 % 41
insufficient definition of a challenge may lead to losses in the Requirements Management 51.3 % 40
data. Project Planning & Estimation 41.0 % 32
We categorized the projects based on various projects Communication 38.5 % 30
characteristics provided in the choices with questions 1,2 and Staffing & Hiring 33.3 % 26
3. Therefore, there are nine categories. Project Monitoring & Control 28.2 % 22
The discussions for each challenged areas are presented Risk Control 26.9 % 21
below in the order in which they are listed in Table 2. We
Technical Complexity 26.9 % 21
discuss two categories of projects separately: Projects
Stakeholder Involvement 25.6 % 20
involving 101 or more people and projects having more than 2
Leadership 25.6 % 20
million lines of code. We had very limited data on these
Configuration Management 25.6 % 20
projects; therefore, comparisons based on this data would not
produce meaningful results. The discussions provided below Organizational Commitment 24.4 % 19
do not include these two categories of projects. Thus, it Quality Engineering 23.1 % 18
includes results from the rest of the 7 categories. We Teamwork 21.8 % 17
compared the categories with each other, for example projects Risk Assessment 19.2 % 15
developed by different type of organizations. Project Manager 14.1 % 11
Scope Management: In all categories of projects, scope Other 10.3 % 8
management is observed in the top three as a challenging area. Support Activities 9.0 % 7
The ratios of number of projects challenged in scope The last project was smooth in 2.6 % 2
management to total number of projects varies from 61.5% to every way.
 Requirements Management: In all categories of projects, 10 people and 11-100 are very close. The ratio in the former is
requirements management is observed in one of the top two 28.1% and the ratio in the latter is 29.3%. Also, the numbers
challenging areas. The ratios vary from 61.1% to 45.8%. in small-sized and medium-sized application projects are
Again, almost half of the projects had troubles in managing close; the former being 30.8% and the latter being 27.4%.
the requirements. Risk Control: Controlling the project risks is another
Project Planning and Estimation: This project challenging aspect of software projects. Almost one out of
management area was also among the top challenges in the every four projects had difficulty in risk control area. The ratio
list. It is the top item in government projects and half of the differs from 38.5% to 24.2%. In only small-sized application
projects were challenged in this area. The ratios vary from projects, it was higher than the others were. In the rest of the
50.0% to 30.8%. The ratio in projects having less than 20 categories, the ratios were almost identical (between 24.2%
KSLOC is 30.8% and it is slightly lower than what is observed and 27.8%).
in other categories. This is not surprising considering the small Technical Complexity: We would have expected that the
size of the application developed. ratio regarding technical complexity would be higher in
Communication: Communication, which is not generally medium-sized application projects. However, the numbers are
covered in other surveys, is also among the top items. We close in small and medium-sized application projects (23.1%
would have expected to see that communication wouldn’t be a and 25.8%). This may also be due to the limited data we had
challenge in smaller project organizations. However, the in small-sized projects. The ratios vary from 34.1% to 12.5%.
survey results indicate that there is almost no difference in the It is lower in government projects than other categories. We
ratios observed in projects organizations between those having believe further study is needed in order to find the validity of
1-10 people and those having 11-100 people. In addition, the such results and the causes. Various researchers point out very
results show that communication is challenging regardless of few projects fail due to technical reasons. The survey results
the organization type. It is slightly higher in government- are also consistent to some extend with the opinions of these
contract organizations when compared to other types of researches.
organizations. In these organizations, in half of the projects, Stakeholder Involvement: The ratios vary from 38.9% to
communication was challenging. In small-sized application 15.4%. It is the highest in projects developed by government-
projects, it was somewhat lower than the other categories. The contract organizations. The ratio is 25% in the category of
ratios vary from 50.0% to 21.3%. government organizations and 19.4 in the category of
Staffing and Hiring: Staffing and hiring is also one of the commercial organizations. The government-contract
areas not generally mentioned in other surveys. In all organizations develop products for government while being a
categories of the projects, staffing and hiring is among the first part of commercial world. The high ratio may be interpreted as
seven, mostly close to the top. The ratios of number of that this unique situation of government-contract organizations
software projects challenged in staffing and hiring to total may lead to interface problems between these two worlds.
number of projects vary from 50.0% to 25.00. In projects Further research to the causes of such numbers will reveal the
developed by government-contract organizations, the ratio is possible solution alternatives for the challenges in this area. In
50% compared to 25% in projects developed by commercial most other categories, the numbers are close except in small-
organizations. In order to interpret such results, we believe sized applications projects category. The ratio is the lowest in
further study is needed. Studies with higher amount of data this category. We believe, this may be the outcome of having
and questions related to the causes will provide insights to the limited data on this category.
subject. Staffing and hiring is related to the number of Leadership: The ratios vary from 38.9% to 7.7% in the
available practitioners with the necessary skills in the field. categories of projects. It is the highest in government-contract
We believe that project organizations and managers are projects while it is the lowest in small-sized application
limited in providing resolutions to the challenges in this area projects. In other categories, the ratios are close to some
and this issue extends to education and training in software extent (28.9% to 19.4%). There is a significant difference
engineering. between small-sized applications projects and medium-sized
Project Monitoring and Control: Project monitoring and application projects. In the former category, it is 7.7% and in
control is another item close to the top of the list. The ratios the latter, it is 28.9%. We were surprised by such difference
vary from 33.3% to 22.2%. In all categories of projects, and this may be just due to the data set.
project monitoring and control area is challenging without Configuration Management: The ratios vary from 33.3% to
much difference between project types. While the ratio, 15.4%. We did not observe a significant difference in
33.3%, is the same in projects developed by government and comparing various categories with each other. It is slightly
government-contract, it is the lowest in projects developed by higher in medium-size application projects than small-size
commercial organizations, 22.2%. It is possible to argue such application projects (25.8% and 15.4%).
results come from the fact that the first two types of Organizational Commitment: The ratios vary from 44.4%
organizations are bounded with many governmental policies to 13.9%. It was the highest in projects developed by
and regulations. Therefore, the management team of these government-contract organizations, while it is the lowest in
projects may have lower autonomy and control over the projects developed by commercial organizations. The
project. We observed that the ratios in projects those having 1- difference is quite high and may be significant. We believe
further research will reveal the causes of such difference. It is can be categorized as staff turnover. Having only a few items
slightly higher in projects developed with 11-100 people than (a total of 8) in the list indicates that we were able to cover
in the projects developed with 1-10 people (24.4% and most of the challenging areas.
18.6%). The last project was smooth in every way: There are only
Quality Engineering: The term quality engineering is used two projects not challenged in any of the areas. Both of them
instead of quality assurance, because quality assurance is are projects developed with 1-10 people. One of them is a
defined as a specific process in most organizations. Quality small-sized application while the other is a medium-sized. One
engineering is a broader term. of them is developed in a commercial organization and the
We wanted to capture quality related challenges in a broader other is in government. Having only two projects in this
sense. The ratios vary from 33.3% to 12.5%. It is the highest category limits our ability to interpret. However, such a low
in projects developed by government-contract organizations number may indicate that development of software projects
and it is the lowest in projects developed by government are quite challenging.
organizations. Most government organizations have to follow Projects with 101 or more people involved: There are five
specific standards and policies. This may have a positive projects in this category. Three of them are middle-sized and 2
effect on the projects and is likely to reduce the problematic of them are large-sized application projects. All of them were
issues related to quality. However, government-contract challenged in some area. One of them was challenged in all
organizations are generally encouraged to use such standards areas, and this project was a large scale distributed simulation
and policies. The unique aspect of these organizations, project developed by a government-contract organization with
residing in commercial environment and contracted for 101 or more people. One of the projects with l01 or more
government projects that have to comply with certain people involved was challenged only in the stakeholder
standards, may have made quality related issues more involvement area. This was a commercial web-based real-time
challenging. In other categories, the ratios are close. project having more than 2 millions lines of code.
Teamwork: The ratios vary from 15.6% to 30.8%. It was Projects with products of more than 2 millions lines of
the highest in small-sized application projects and there is code: There are three projects in this category. Deriving
quite a difference between medium-sized application projects conclusions from such a limited data set will be meaningless.
(19.4%). This may be the result of having a limited data set in Note that authors are advised not to include their email
small-sized application projects. In projects developed by addresses.
different types of organizations, the ratios are close (16.7%-
25.0%). In projects developed with 1-10 people, the ratio is 5 Multivariate Analysis
15.6% while it is being 22.0% in projects developed with 11-
100 people. Almost all the projects had challenges in multiple areas.
Risk Assessment: This area is one of the items that are close We conducted analysis to identify the challenged areas that
to the bottom of the list. Controlling the project risks is more accompany a particular challenged area. For example, more
difficult than acknowledging and assessing them. The ratios than half of the projects that are challenged in scope
vary from 30.8% to 12.5%, mostly close to low numbers. management are also challenged in requirements management.
There is a significant difference between small-size Since the goal of the survey study was not to investigate cause
application projects and medium-size application projects and effect relationship, the results should not be interpreted as
(30.4% and 16.1%). It is the highest in small-sized application such. We do not report the areas that are challenged in less
projects. This may be due to the issue that in smaller than 20 projects out of 78. Because the dataset is limited for
applications assessing project risks may have been these areas, the results may be misleading. These areas are
overlooked. organizational commitment, quality engineering, teamwork,
Project Manager: Project manager’s ability and risk assessment, project manager, and support activities.
skillfulness is an important factor in software projects and 41 projects out of 78 projects are challenged in scope
replacement of the project manager during the project management. 24 of the projects that are challenged in scope
seriously affects the project’s overall performance [11]. management are also challenged in requirements management.
However, in most studies this item is not analyzed. The ratios Following tables provides project management areas that are
differ from 22.2% to 0%, mostly close to low numbers. In challenged concurrently when a specific area is challenged.
small-sized application projects, none of the projects was We only report the areas when the ratio is over 40%.
challenged in the project manager area. In projects developed
with 1-10 people, the ratio is 6.3%. These are smaller projects Scope Management 100% 41
and generally, project manager’s interaction with the team is Requirements Management 58.5% 24
higher. Project Planning/Estimation 43.9% 18
Other: Other challenges mentioned by the participants Communication 41.5% 17
consist of high turnover rate at prime contractor facility, team
turnover, prioritization, micromanagement, distributed funding
control, hardware configurations, loss of key personnel, and
under funded software safety engineering. Three of the items
Requirements Management 100% 40 Leadership 100% 20
Scope Management 60.0% 24 Requirements Management 75.0% 15
Project Planning/Estimation 52.5% 21 Communication 75.0% 15
Communication 47.5% 19 Scope Management 65.0% 13
Project Monitoring/Control 42.5% 17 Project Planning/Estimation 60.0% 12
Risk Control 45.0% 9
Project Planning/Estimation 100% 32 Configuration Management 45.0% 9
Requirements Management 65.6% 21 Project Monitoring/Control 40.0% 8
Scope Management 56.3% 18 Teamwork 40.0% 8
Project Monitoring/Control 53.1% 17
Communication 43.8% 14 Configuration Management 100% 20
Risk Control 40.6% 13 Scope Management 65.0% 13
Requirements Management 50.0% 10
Communication 100% 30 Project Planning/Estimation 50.0% 10
Requirements Management 63.3% 19 Leadership 45.0% 9
Scope Management 56.7% 17 Communication 40.0% 8
Leadership 50.0% 15 Quality Engineering 40.0% 8
Project Planning/Estimation 46.7% 14
Project Monitoring/Control 40.0% 12 Challenges in scope management, requirements
Teamwork 40.0% 12 management, and project planning and estimation area
accompany challenges at higher rates in all other areas listed
Staffing/Hiring 100% 30 above. There are also other noteworthy findings. A significant
Requirements Management 46.2% 12 number of projects that are challenged in project monitoring
Scope Management 46.2% 12 and control area are also challenged in requirements
management and project planning and estimation area. When
Project Monitoring/Control 100% 22 there are challenges in leadership, requirements management
Requirements Management 77.3% 17 and communication areas are also challenged.
Project Planning/Estimation 77.3% 17
Scope Management 54.5% 12 6 Conclusions
Communication 54.5% 12
Risk Control 40.9% 9 The motivation for this study was to obtain an up-to-date
survey of software project management challenges. Because
Risk Control 100% 21 there are rapid advances in software development technology,
Requirements Management 66.7% 14 the challenges may change. The results of this survey study
Scope Management 66.7% 14 were used in guiding a doctoral research. Stating research
Project Planning/Estimation 61.9% 13 hypotheses based on outdated survey results and possible
Communication 52.4% 11 invalid assumptions may threaten the validity of studies. It is
Risk Assessment 47.6% 10
Project Monitoring/Control important to conduct regular surveys of software projects to
42.9% 9
Staffing/Hiring 42.9% 9 help researchers state research hypotheses. Furthermore, these
Leadership 42.9% 9 survey studies help analyze trends.
The findings of this study are similar to the findings in
Technical Complexity 100% 21 earlier studies; for example to the findings of [7][11][12]. This
Scope Management 66.7% 14 finding, itself, is a significant finding. Because it seems like
Staffing/Hiring 47.6% 10 the advances in software development technology are not very
Project Planning/Estimation 47.6% 10 effective in solving software project management challenges.
Requirements Management 42.9% 9 This study covers some areas that are not generally covered
Quality Engineering 42.9% 9 in other studies. Teamwork, configuration management,
organizational commitment and support activities are among
Stakeholder Involvement 100% 20 these areas. This study also provides multivariate analyses that
Scope Management 70.0% 14 will guide other researchers in stating hypotheses for further
Requirements Management 60.0% 12 research with a focus in a specific project management area.
Organizational Commitment 45.0% 9
Communication
We did not gather data on whether the projects were
45.0% 9
Project Planning/Estimation 40.0% 8 considered successful or not. We simply gather the
experiences of the participants on software projects. There are
two reasons. First, defining success is not an easy task.
Therefore, in some studies the researchers prefer to ask the
participant’s perception on project success/failure and conduct
analyses based on that (such as [11,14]). If a survey
participant miscategorizes a project as a success instead of a [10] E. Yourdon, Death March, 2nd Edition, Yourdon Press,
failure, it will affect both results. Second, our research focus Pearson Education Inc., Publishing as Prentice Hall
was the challenges regardless of the project’s outcome. All Professional Technical Reference, NJ, 2004.
survey study details can be found in [16].
We do not have a dependent variable in this study. Thus, it [11] Verner, J.M. and Evanco, W.M., “In-house software
is not possible to conduct advanced statistical analyses. This development: what project management practices lead to
study is important in the sense that it covers most challenging success?” IEEE Software, Vol. 22, Jan.-Feb. 2005 pp.86 – 93.
areas in software projects regardless of resulting in a success
or a failure. Generally, studies only focus on failure factors or [12] C. Jones, “Software Project Management Practices:
areas challenged when the project is considered a failure. We Failure versus Success”, Crosstalk, Vol. 17, No.10, Oct.,
believe the path to completing projects with higher rates of 2004.
success starts with correctly identifying challenging areas and
providing resolutions. More empirical studies are needed that [13] R. Glass, “The Standish Report: Does it really describe a
focus on software project success/failure factors and software crisis?”, Communications of the ACM, Vol. 49, No.
challenges of managing software projects under similar and 8, August 2006.
different contexts.
[14] J. D. Procaccino, J. M. Verner, M. E. Darter, W. J.
7 Disclaimer and Acknowledgements Amadio, “Toward predicting software development success
from the perspective of practitioners: An explanatory
The views and conclusions contained herein are those of Bayesian model”, Journal of Information Technology,
the authors and should not be interpreted as necessarily Vol.20, 2005, pp. 187-200.
representing the official policies or endorsements, either
expressed or implied, of any affiliated organization or [15] M.W. Evans, A.M. Abela, and T. Beltz, “Seven
government. We also would like to thank all anonymous Characteristics of Dysfunctional Software Projects”,
participants for their participation. Crosstalk, Vol. 15, No. 4, April 2002.

8 References [16] K. A. Demir, Measurement of Software Project

Management Effectiveness, PhD Dissertation in Software
[1] Contracting for computer software development, Engineering, Naval Postgraduate School, Monterey, CA,
FGMSD-80.4, US GAO, Washington, DC, 1979. December, 2008.

[2] Standish Group, “The CHAOS Report (1994), 1994.

[3] R. Glass, “Failure is looking more like success these

days”, IEEE Software, Jan/Feb 2002.

[4] M. Jorgensen, and K. Molokken-Ostvold, “How large

software cost overruns? A review of the 1994 CHAOS
report,” Information and Software Technology, vol. 48, 2006,
pp. 297-301.

[5] K. E. Emam, and G. Koru, “A Replicated Survey of IT

Software Project Failure Rates”, IEEE Software, Vol. 25, No.
5, pp. 84-90, 2008.

[6] C. Sauer, C. and Cuthbertson, "The State of IT project

Management in the UK 2002-2003,"Computer Weekly, 2003.

[7] T. DeMarco, and T. Lister, Peopleware: Productive

Projects and Teams, 2nd Edition, Dorset House Publishing
Company, New York, NY, 1999.

[8] S. Robertson, and J. Robertson, Requirements-Led

Project Management, Pearson Edu. Inc., Boston, MA, 2005.

[9] G. Weinberg, Quality Software Management: Volume 3

Congruent Action, Dorset House, New York, 1994.

View publication stats