Key Success Factors in Software Development Projects

Santosh J. Dubey (MBA) (Inf. Sys.), (MPM)

Mediasoft Integration Pte Ltd, 37A Hong Kong Street Singapore 059676
Correspondence: Email: santosh@mediasoft.com.sg

Abstract
Software development projects are complex. Coupled with technical factors, anomalies that are environmentcontingent often influence such projects. Human capital, being a vital resource for project delivery, undoubtedly plays
a critical role in software development projects but studies that ascertain the extent to which technicalities and
conventional factors, like human resource, influence development are limited. This is in light of the recent emergence
of development methodological frameworks that act as nomenclatures, which aim to eliminate development
ambiguities. After the emergence of such a centralized approach to software development management, process
iteration practices, such as Agile, which downplay the formality of central methods approach have complicated the
processes and this has resulted in an ideological stand-off between the management and the development classes
of a standard software development project. While a standard model helps benchmark and standardize process tasks
for predictable outcomes, it may equally be lengthy and slow in a development environment that is often highly
dynamic and rapid. Likewise, without rapidity, software projects risk potential project losses. To understand this
process, a study involving 56 professional software development professionals was conducted in August 2011. It was
ascertained that complexities and the primary indicators of project success forms can differ based on the
respondents project role; likewise, the study also confirmed the factors that influence software project success.

1.

Introduction:

As Information Technology permeates across businesses, sectors and industries, software development projects
have begun to influence modern businesses. It is not uncommon to find software-oriented projects, however the
scale, in a registered business entity, whatever the size. With emerging markets such as India and China and the
outsourcing culture as a result, software development processes, in practice, have been needed to respond to the
st
general paradigm shifts to reflect business and operational realities of the 21 century (Safon, 2008). Projects are no
longer isolated corporate practices, they are much more dynamic, global and strategically aligned to business
strategies and the organizations long term goals (Walker, 2009). Due to the business aspect of project investment
decisions, software projects often need to satisfy a range of variables such as ownership cycles and long term cost
savings to justify expenditure (Blanchard and Fabrycky, 2006).
The evolution of information and communication technology infrastructure has accelerated with the emergence of the
Internet as end-users are inundated with accessibility that enables swift communication with computer hardware that
st
process more information (Parikh, 2002). Such evolution is also visible in software projects of the 21 century. If
comparison is made between software deliverables of the early 2000s and the year 2010, the differences are very
noticeable, not just aesthetically in the graphical user interface (GUI) or in interactivity but also on the basis of
functionality and utility. Major software development initiatives have been expected to fulfill and respond to this
development as new technologies have enabled better process automation and intermediation through innovation
(Kristoffersen and Ljungberg, 1999). Innovation, in both utility and functionality as a requisite to project success, has
increased the complexity in development of a software project. This complexity has often been sought to be
addressed with methodologies.
Methodologies such as the PMBOK framework of the Project Management Institute and CMM or the Capability
Maturity Model, which adopts a benchmark for organizational project goals, have been projected as key
nomenclatures in response to increased project complexity. In contrast to standardization, Agile methodologies have
also emerged as key guidelines that promote an adaptive method to accelerate software development through close
co-ordination with end-users, albeit ones that oppose documentation-heavy practices (Hass, 2007). The 5 most
common Agile methods are; Adaptive Software Development, Crystal Methods, Dynamic Systems Development
Method, Extreme Programming and Scrum (Szalvay, 2004). For methodologies, there has been a tendency of
emergence of a particular method to address its predecessors shortcomings. This can be traced with the emergence
of Spiral from Waterfall by different authors. There is a trend underlined because evolution is only possible after
extensive utility (Mills, 2000) and utility of methods with careful comparative application can confirm process
improvements and thus the retention of resulting productivity. Likewise, constant practice improvement in project
environments is a factor that fits both technical and non-technical project team success requisites.

As methodology seeks to address process production complexities, human factors weigh in on process outcomes
within project endeavours. Software project implementation has become more strategic and requires extensive
alignment to an organizations goals. Success of a software project is said to depend greatly on successful
implementation. Implementation, in turn, depends on non-technical variables such as an organizations culture, its
structure and the change management strategies in place as response contingencies (Hiatt and Creasey, 2003).
Contingencies require meticulous planning and effective drafting of resources with good management of risks and
issues concerning a project. The end collective view of key success factors for software projects thus encompasses
both technical and non-technical variables. The evidence for IT project performance has been a widely pursued area
of research, the Standish Groups Chaos Report is one such infamous outcome.
Complexities in such projects do make assiduity difficult in large software projects, particularly given the demands of
modern organizations that need to incorporate rapid progress of IT applications and tools within internal development
cycles for enhanced deliverable life-cycle outcomes. With an increase in the number of potential standardized models
of software development, it is possible that project managers and teams may experience an information overload
where terminology and technical jargon affect communication and decision-making in projects (Davenport and
Prusak, 1998). Particularly, given the availability of methodology and claims of development-wide applicability by
each of the method developers, project managers may misapply approaches and thus diminish returns from
investment for the projects investors.
2.

Research background and model:

Projects are complex undertakings and are key processes within modern organizational development cycles
(Blanchard and Fabrycky, 2006). Given their temporary form, resource allocation, resource management, method
election, utility and implementation are notable areas where a project manager managing software development may
seek to address potential issues. As each of these areas of management has the potential to increase individual
process complexity, the collective control of the project requires a balance between technical and non-technical
parameters within a development process. According to the Royal Academy of Engineering and the British Computer
Society (2004), methodology and the successful adoption of the methodology in a synergistic manner by the
development team contributes to the success of software projects. This clearly suggests that methodology is a critical
project success factor, however, what is also highlighted by literature is the need for adoption and the ability of the
team to evolve that method and apply it in practice effectively (Kappelman et al., 2006). It needs to be investigated
how both elements play a role in successful project endeavours. While a development methodology undertaken by
project managers can influence the overall risk faced by a project (Tiwana and Keil, 2004), such methods are heavy
on documentation and require extensive knowledge management practices which leads to the erection of
nomenclatures for reference.
This is a complex process since Davenport et al. (1996) confirm that knowledgeoriented workers tend to resist standardization and structuration. This study
attempts to first evaluate these areas of interest, confirm practices in industry
and attempt to offer counter-suggestions through review. Quantitative
assessment of issues will be undertaken to provide academic assiduity to the
factors that affect software projects (Fig. 2.0). A diverse array of participants has
contributed to the research process and tools have been attached for general
perusal.
The studys aim is to ascertain:
(1) If only methodology has as much impact on project success (H1)
(2) If only non-methodology has impact on project success (H2)
(3) If a balance between the two impact project success (H3)
This has been modelled within the response sheets where success definitions and their correlation with definitions of
project success are sought.

The primary research tool used by this study has been web-surveys issued to various respondents who are project
management professionals. The project was primarily funded by Mediasoft Integration Pte Ltd, a private enterprise
located in the country of Singapore, Sydney and Kuala Lumpur. A web-based survey was undertaken since most
project managers have access to a computer and an Internet connection. All respondents also enjoyed anonymity
when responding and did not provide information such as individual emails. 56 respondents (56% response rate)
have participated in the survey though 100 invitations were sent. The respondents have the following traits:
(i)
(ii)
(iii)
(iv)

Extensive Project Management Experience

PMI/P3M3 certification, according to intermediary channels
Holders of baccalaureate degrees or above
Have participated in or have been stakeholders in past or current Mediasoft Integration projects

The respondents were contacted by email only once. As the survey was anonymous, it was impossible to know who
had responded and who had not. The survey remained online between the 01/07/2011 here to 30/08/2011. The
thesis requires each respondent to fill in the survey for the latest project he/she has worked on. The webform that
contained the survey was programmed in a way that prevented multiple entries from individual IPs and skipped
questions. Before the survey was made available, a test of the webform was conducted by 3 individuals, including the
author and it was found to meet anticipated standards. The testing processes on the web form allowed for bettering
the form with improved utility and arrangement of questions. Every effort was undertaken to ascertain that ambiguities
and vague assertions were avoided and each question reflected realism for increased accuracy.
3.

Research Methodology:

The research model entails various variables (for mean analysis) that are clustered in 3 variable categories,
methodology-related, other project factors and general project success outcomes. While methodology-related factors
have been simplified to fit in general preferences of the respondents, other project factors project the following areas
to better exemplify assertions. The identified important variables for project success have been developed in line with
the conducted literature review. They are (measured on a 5-point Likert scale):
(i)
(ii)
(iii)
(iv)
(v)

Project culture
Project governance
Project criticality
Project general resource
Project human resource

This thesis lies primarily on the empiricist principle followed by strains of positivism, both of which purport that any
form of hypothesis requires factual study of consistent empirical co-relation between the respective variables
(Easterby-Smith et al., 2008). This study attempts to co-relate the relationship between a software projects methods,
the non-methodology related factors and project outcomes, whether successful or otherwise. The primary objective of
the thesis is to confirm key variables that influence a projects success. The analysis process also utilizes the corelative relationships between independent variables in the prediction of dependent variables that may be modelled to
demonstrate project success and relation. Furthermore, the correlation coefficient R2 provides a general measure of
how well a regression model fits, and is used as an underling factor that allows for the balance in analysis between
estimated and actual values. For the project, for H1 to H3, non-methodology related factors and methods were the
independent factors while project success was the dependent variable. The role of these variables was assessed
based on correlation and multiple regression analysis. This should also help in developing a causal link between
project success with the other variables and to the links between the non-methodological factors, methodology and
project success. Project success is an extensively vague term, as such, reliability was important given that it was
measured over several questions. As such, apart from consistency, Cronbachs method was used where item
consistency was checked on a scale of items derived from the hypothesis constructs. A coefficient of 0.6 was
considered to be an acceptable benchmark in this project.

4.

Study findings:

Out of the 56 responded, the majority of the respondents had 4 to 5 years of project experience at 37.5%. The
second highest number of respondents stood at 32.14% of the respondents with 3-4 years of project management
rd
th
th
experience while the 3 , 4 and 5 largest cluster of respondents rested at 21.43% with 2-3 years of project
management experience, 5.36% with 1-2 years of project experience and 3.57% with 0-1 years of experience. The
largest cluster of respondents had 4-5 years (or more) experience in project management and are expected to thus
be privy to conventions and industrial norms.
The participants were also asked about their previous position in a project. 55.36% of the respondents, the majority,
were project managers. 37.5% were project team members in their previous project positions while 3.57% were in
supervisory roles, 1.79% Sponsors and 1.79% were categorized as Others. In the survey, Others may be classified
as vendors or customers. The study took into consideration that it was vital to distinguish differing perceptions of
project management practices and the general division of work experience and project positions will help in better
distinguishing the different levels of interests in a project.
The participants who participated in the survey were from an
extensively diverse background in project management. They
ranged from project personnel whose previous project size,
based on project manpower, ranged from 1-10 to 1000+ people.
48.21% or 27 of the respondents had worked on projects that
had between 50-100 project staff. 30.36% or 17 of the
respondents had worked on projects between 10-50 project staff
while 10.71% or 6 participants worked on projects between 1001000 staff while 5.36% or 3 of the participants worked in
projects with 0-10 or 1000+ respectively. In total, the 56
respondents confirmed their project work experience, the sizes
of the projects they have been working on and, most
importantly, their positions in a project. Based on analysis, the
most dominant cluster in this data comprises of the following
description:
(i)
(ii)
(iii)

Dominant cluster group has 4-5 years of work experience

Dominant cluster group is the Project Manager group
Dominant cluster group has most experience in projects
that have 50-100 people

The participation statistics may be summarized as (N=56) (Table 4.0a1):

Project experience:
0-1 Years
1-2 Years
2-3 Years
3-4 Years
4-5 Years
Role of participants in the last project:
Project-Manager
Team-member
Supervisor
Sponsor
Other
Size of previous project:
1-10 Personnel
10-50 Personnel
50-100 Personnel
100-1000 Personnel
1000+ Personnel
Total:

Percentage:
3.57%
5.36%
21.43%
32.14%
37.50%
Percentage:
55.36%
37.50%
3.57%
1.79%
1.79%
Percentage:
5.36%
30.36%
48.21%
10.71%
5.36%
100%

Number:
2 Participants
3 Participants
12 Participants
18 Participants
21 Participants
Number:
31 Participants
21 Participants
2 Participants
1 Participant
1 Participant
Number:
3 Participants
17 Participants
27 Participants
6 Participants
3 Participants
56 Participants

4.1 Survey results (Table 4.0a2):

Connotation:
IND-A

Question:
How long have you worked in the software development
industry?

Dominant
variable:
4-5

Results:
0-1 = 2 (3.57%)
1-2 = 3 (5.36%)
2-3 =12 (21.43%)
3-4 = 18 (32.14%)
IND-B
What was your position in the project you worked in?
PM
Results:
PM = 31 (55.36%)
TM = 21 (37.5%)
Super. = 2 (3.57%)
Sponsor = 1 (1.79%)
IND-C
The size of your last project?
50-100
Results:
1-10 = 3 (5.36%)
10-50 = 17 (30.36%)
50-100 =27
100-1000 = 6
(48.21%)
(10.71%)
Methodology-related
MET-A
Projects plans were more important than management
5
directives for project success
Results:
1 = 2 (3.57%)
2 = 8 (14.29%)
3 = 8 (14.29%)
4 = 16 (28.57%)
MET-B
Changes identified and needed to be addressed by end2
users were considered more important than a planned
initiative for project success
Results:
1 = 11 (19.64%)
2 = 19 (33.93%)
3 = 2 (3.57%)
4 = 9 (16.07%)
MET-C
End-user participation was deemed critical to the
4
development process for project success
Results:
1 = 1 (1.79%)
2 = 5 (8.93%)
3 = 9 (16.07%)
4 = 31 (55.36%)
MET-D
Autonomy was preferred over control structures for
5
individual developers for project success
Results:
1 = 16 (28.57%)
2 = 14 (25%)
3 = 1 (1.79%)
4 = 7 (12.5%)
MET-E
Intuitive considerations were considered over external
4
benchmarks for project success
Results:
1 = 5 (8.93%)
2 = 17 (30.36%)
3 = 6 (10.71%)
4 = 18 (32.14%)

Percentage
attained:
37.5%

4-5 = 21 (37.5%)
55.36%
Other = 1 (1.79%)
48.21%
1000+ = 3 (5.36%)

39.29%

5 = 22 (39.29%)
33.93%

5 = 15 (26.79%)
55.36%

5 = 10 (17.86%)
32.14%

5 = 18 (32.14%)
32.14%

5 = 10 (17.86%)

OTH-A-C1
Results:
0 = 0 (0%)
OTH-B-C2
Results:
1 = 6 (10.71%)
OTH-C-D1

Other Project factors

Project communication networks were one of the main
factors for project success

62.5%

0 = 0 (0%)
3 = 3 (5.36%)
4 = 35 (62.5%)
Team members working on the project were committed
4
formally for project success

5 = 18 (32.14%)
33.93%

2 = 10 (17.86%)
3 = 13 (23.21%)
4 = 19 (33.93%)
Control Structures required extensive rigidity for control for
5
project success

5= 8 (14.29%)
37.5%

Results:
1 = 13 (23.21%)
2 = 8 (14.29%)
3 = 3 (5.36%)
4 = 11 (19.64%)
OTH-D-D2
Processes required to be benchmarked for efficiency for
2
project success
Results:
1 = 4 (7.14%)
2 = 21 (37.5%)
3 = 9 (16.07%)
4 = 18 (32.14%)
OTH-E-E1
Projects with higher possibility of failure required extensive
4
attention
Results:
1 = 1 (1.79%)
2 = 18 (32.14%)
3 = 9 (16.07%)
4 = 22 (39.29%)
OTH-E-E2
Projects with higher demonstrable need by the end-users
4
tend to get better management attention
Results:
1 = 1 (1.79%)
2 = 19 (33.93%)
3 = 7 (12.5%)
4 = 21 (37.5%)
rd
OTH-F-F1
3 party intermediary tools were critical for software project
2
success
Results:
1 = 2 (3.57%)
2 = 19 (33.93%)
3 = 14 (25%)
4 = 13 (23.21%)
rd
OTH-F-F2
Impact of 3 party technology and tools had great impact
3
on project success
Results:
1 = 0 (0%)
2 = 9 (16.07%)
3 = 23 (41.07%)
4 = 16 (28.57%)
OTH-G-G1
Experience of project staff was critical to project success
5
Results:
1 = 0 (0%)
2 = 1 (1.79%)
3 = 3 (5.36%)
4 = 25 (44.64%)
OTH-G-G2
Leadership was deemed to be critical for project success
5
Results:
1 = 1 (1.79%)
2 = 9 (16.07%)
3 = 8 (14.29%)
4 = 14 (25%)
Project success
PJT-A
Project schedule more than other factors adherence after
2
completion was considered project success
Results:
1 = 6 (10.71%)
2 = 21 (37.5%)
3 = 14 (25%)
4 = 12 (21.43%)
PJT-B
Project scope adherence more than other factors after
4
completion was considered project success
Results:
1 = 2 (3.57%)
2 = 5 (8.93%)
3 = 9 (16.07%)
4 = 24 (42.86%)
PJT-C
End-consumer satisfaction is considered critical for project
4
success
Results:
1 = 0 (0%)
2 = 10 (17.86%)
3 = 13 (23.21%)
4 = 25 (44.64%)
PJT-D
Project needed all scope, time and cost to be defined as a
5
success
Results:
1 = 0 (0%)
2 = 3 (5.36%)
3 = 10 (17.86%)
4 = 13 (23.21%)
PJT-E
End-consumer consensus for project success is critical for
3
IT projects
Results:
1 = 1 (1.79%)
2 = 11 (20%)
3 = 18 (32.73%)
4 = 16 (29.09%)

5 = 21 (37.5%)
37.5%

5 = 4 (7.14%)
39.29%

5 = 6 (10.71%)
37.5%

5 = 8 (14.29%)
33.93%

5 = 8 (14.29%)
41.07%

5 = 8 (14.29%)
48.21%
5 = 27 (48.21%)
42.86%
5 = 24 (42.86%)
37.5%

5 = 3 (5.36%)
42.86%

5 = 16 (28.57%)
44.64%

5 = 8 (14.29%)
53.57%

5 = 30 (53.57%)
32.73%

5 = 9 (16.36%)

GNL-A
Results:
1 = 9 (16.36%)
GNL-B

Methodology is the more important than any other factor for

project success

32.73%

2 = 18 (32.73%)
3 = 5 (9.09%)
4 = 8 (14.55%)
Other factors (such as project plan, people and similar
2
variables) are more important for project success

5 = 15 (27.27%)
42.86%

Results:
1 = 10 (17.86%)
2 = 24 (42.86%)
3 = 12 (21.43%)
4 = 8 (14.29%)
GNL-C
Both methodology and other factors need to address for
5
project success
Results:
1 = 0 (0%)
2 = 1 (1.79%)
3 = 10 (17.86%)
4 = 6 (10.71%)

5 = 2 (3.57%)
69.64%

5 = 39 (69.64%)

SEM analysis with the Amos package attained the following result (p value = 0.05):
Model Fit Summary:
CMIN (Table 4.4a)
Model
Default model
Saturated model
Independence model

NPAR
41
44
16

CMIN
3.513
.000
788.732

DF
3
0
28

P
.319

CMIN/DF
1.171

.000

28.169

NPAR represents the number of parameters in the proposed model. In the saturated, or as it is known, the justidentified model, 44 parameters are represented with 16 variances and 28 path coefficients. For the proposed project
success factor model, there are 41 paths where two have been dropped for testing. For our independence model
where general paths are deleted, there are 16 parameters. With the CMIN, where Chi-square statistic is compared
between the tested, independent and saturated models, it was found that the model reflect the complexity between
the varying factors that underline general project performance between the different cluster groups as such, given
such a consideration, the DF was retained even as it reached 3.0.
Baseline Comparisons (Table 4.4b)

Model
Default model
Saturated model
Independence model

NFI
Delta1
.996
1.000
.000

RFI
rho1
.958
.000

IFI
Delta2
.999
1.000
.000

TLI
rho2
.994
.000

CFI
.999
1.000
.000

Both NFI and RFI values indicated a fit exceeding .95, indicating superior fit. Both IFI and CFI values also indicate
good fit of the proposed model given the general values indicating numerical conformity between the references.
RMR, GFI (Table 4.4c)
Model
Default model
Saturated model
Independence model

RMR

GFI

AGFI

PGFI

.046

.957

.260

.691

.944
.000
.569

.380
1.000
.499

The proposed models the root mean square residual stood at 0.46, suggesting that the variances and co-variances
differ as intended from observed variances and co-variances. Likewise, the goodness of fit index has confirmed the
proportion of variance and co-variance in the matrix within the proposed model. The GFI remained at 0.957,
indicating a good fit and given how close the GFI is to the AGFI, it is confirmed that the number of entered

parameters in the model is relative to the variances and co-variances in the models sample variance and co-variance
matrix.
RMSEA (Table 4.4d)
Model
Default model
Independence model

RMSEA
.056
.703

LO 90
.000
.661

HI 90
.241
.746

PCLOSE
.379
.000

The models root mean square error of approximation estimates has resulted in 0.56, thereby indicating the general
good fit of the model while the independence model stands at .703. The LO90 and HI90, which indicated the lower
and upper ends of in a 90% confidence level were reflected as anticipated. The relative relationship between the
factors may be confirmed and as such, H1 (0.127), H2 (-0.413) and H3 (0.493) are supported.
4.5 Resulting output:

While a balanced approach seems like the best alternative to project success, the following findings also influence
the study of the success factors affecting the project. It is to be noted that based on the loadings (where an indication
of exceeds 0.5 is acceptable) the following findings have been made:
(i)
(ii)
(iii)

A projects schedule may influence its methodology election ( = 0.79)

A project which focuses on scope will focus on both methodology and other related factors ( = 0.5)
A project which focuses on end-user consensus will focus on both methodology ( = 0.5) and other
qualitative factors ( = 0.62) respectively.

5.

Discussion:

The most complicated part of a research practice lies in understanding of repeated trends and hoping that such
trends and co-relations will appear consistently enough to enable potential academic study and thus help in the
formation of a hypothesis. Implications occur in inferences that need to maintain some form of consistency in how
different people will respond in the ever-evolving system of management of projects, no two situations are expected
to yield the same results. In this study, every effort was made so that generalization was credible in areas such
software development methodology. Particularly in the literature review process, which rested on scholarly areas of
interest, study was substantive enough so the mainstream view of research was reflected.
Every effort was made to ensure potential contribution to existing body of knowledge, this research attempts to make
co-relation possible between various project success outcomes and project goals. One particular goal was to
establish a relationship between projects that emphasize on certain definitions of project success and on the
development styles that emphasize on project methodology or other factors that influence it. What was found was
rather the middle way which emphasized that a project outcome that was deemed to have been successful in scope,
quality and cost was negatively co-related to the project technique that overly emphasized on the other factors over
methodology while the balanced approach was deemed to be the best potential outcome.
It has been identified that, as depending on the immediate goals and emphasis of a project team, a different set of
factors tend to emerge. While over-all, a balanced approach is suggested with the confirmation of H3, research has
also found other views prevalent in data analysis. For example, in the research, a projects schedule was found to
influence the view that methodology was more important than other factors ( = 0.79). This outcome confirms that for
software projects that tend to want to seek to finish development within a tight time-frame, methodology election
process takes centre stage.
Likewise, what was found that projects which preferred to focus on scope of their software projects tended to align
closely to the view that both methodology and other factors were important ( = 0.5). This view is supported in
literature where a balanced view tends to inculcate the best of both ideologies. In a balanced approach, it is expected
that a methodology election process looks at the over-all picture and will be influenced by issues emerging from
control structures, staff experience, criticality, impact and availability of technology intermediation tools along with
leadership.
The balanced approach has also been found in support where the emphasis of end-user involvement in software
development projects was found wanting. It was found in the model that opinions where end-user involvement in
software development was desired methodology ( = 0.5) and other factors ( = 0.62) were validated in the model
analysis. This not only reflects the prevalent view that a balanced approach will enable the best of both worlds but
also the current opinion on either sides of the methodology; one side which prefers the central and rigid control of a
highly documented plan while the other prefers the freedom of development creativity with minimal documentary
restrictions. In both sides, user-involvement is deemed critical, and, with a view on other factors, emphasis may be
kept wide.
As such, it is to be noted that software development projects are complex undertakings that are often extremely hard
to manage and there are no quick-fixes or a one-model-fit-all solution to the collective, that is a software
development project. The findings of this research initiative should underline the fact that a balanced approach is
often one that is necessary. While it may be entirely possible for a conditioned software development team to conduct
its affairs in a manner that is unique to it, its not entirely feasible for the diligence of that successful team to be
passed down to another team without some form of opportunity cost, hence the balanced approach is the one that
best fits this research question.

References:
Blanchard, B. S., & Fabrycky, W. J.(2006) Systems engineering and analysis (4th ed.) New Jersey: Prentice Hall.
p.31
Davenport, T.H.; Jarvenpaa, S.L. and Beers, M.C. (1996) Improving knowledge work processes. Sloan Management
Review, v37(4), pp. 53-65.
Davenport, T. H. and Prusak, L. (1998) Working Knowledge. Harvard Business School Press, Boston Massachusetts.
Easterby-Smith, M., Thorpe, R., and Jackson, P. R. (2008). Management Research (3rd ed.). Los Angeles: Sage
Hass. K., (2007) "The Blending of Traditional and Agile Project Management," Published in PM World Today, Vol. 09.
Hiatt, J. and Creasey, T.J. (2003) Change Management: The People Side of Change, Loveland, CO: Prosci
Research.
Kappelman LA, Mckeeman R, Zhang L (2006). Early Warning Signs of IT Project Failure, The Dominant Dozen.
Inform. Syst. Manage., 23(4): 31-36.
Kristoffersen, S. and Ljungberg, F. (1999) Mobile use of IT In Proceedings of the 19th Information systems Research
Seminar in Scandinavia, Finland.
Parikh, M. A (2002), Knowledge acquisition through case study development: a student research perspective,
Communication of the Association for Information Systems, Vol. 8, pp. 360-379
Royce, W. (1970), "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON 26
Royal Academy of Engineering and the British Computer Society (2004). The Challenges of Complex IT Projects,
The Royal Academy of Engineering
Safon, V (2008) IT and the East: How China and India Are Altering the Future of Technology and Innovation,
Management Decision, Vol. 46 Iss: 5, pp.813 814
Schmidt, R. (2001) "Identifying Software Project Risks: An International Delphi Study, Journal of Management
Information Systems (17)4, pp. 536.
Schach, R. (1999), Software Engineering, Fourth Edition, McGraw-Hill, Boston, MA, pp. 11.
Schwalbe K., (2007), Information Technology Project Management, 6th Edition, Course Technology, NY
Schwaber, K., and Beedle, M. (2002). Agile Development with Scrum. Upper Saddle River, NJ: Prentice-Hall.
Selic, B. (2009) "Agile Documentation, Anyone?" IEEE Software (26)6, pp. 1112.
Sommerville, I. (1996), Software Engineering, Fifth Edition, Addison-Wesley, Reading, MA, pp. 14.
Sommerville, I (2004), Software Engineering, 7th edition, Pearson Education
Steffens, W., Martinsuo, M. & Artto, K. (2007). Change decisions in product development projects. International
Journal of Project Management. 25 (7), 702-713.
Standish Group (1995), Chaos. http://www.standishgroup.com/chaos.html July 10, 1997.
Szalvay, V,. (2004) "An Introduction to Agile Software Development," Danube Technologies
Tiwana, A and Keil, M. (2004). The One-Minute Risk Assessment Tool, Communications of the ACM, 47(11): 7377

Walker, D (2009) Project Reviews, Assurance and Governance, International Journal of Managing Projects in
Business, Vol. 2 Iss: 3, pp.457 - 459