In general, project complexity and project dynamism are recognized as potent characteristics that influence, usually in a negative way, the outcome of software development projects. However, with respect to the two dominant paradigms for managing software development projects (i.e., plan-based project approach and agility-based project approach), there is less agreement as to which one is better. Emerging research suggests that the preeminence of one approach over another is a matter of fit between the project management approach and the project context, including its complexity and dynamism. We contribute to this line of research by studying the moderating influence of the two project management approaches on the relationship between project complexity and project dynamism on project outcomes. Our analysis of data gathered from a survey of software development professionals shows that managing dynamism is critical for realizing project success, and an agility-based project approach is best suited for mitigating dynamism’s negative effects on project success.
AçikgözA.GünselA.BayyurtN.KuzeyC. (2014). Team climate, team cognition, team intuition, and software quality: The moderating role of project complexity. Group Decision and Negotiation, 23(5), 1145–1176.
2.
AndresH. P.ZmudR. W. (2002). A contingency approach to software project coordination. Journal of Management Information Systems, 18(3), 41–70.
3.
AustinR. D.DevinL. (2009). Research commentary: Weighing the benefits and costs of flexibility in making software: Towards a contingency theory of the determinants of development process design. Information Systems Research, 20(3), 462–477.
4.
BaccariniD. (1996). The concept of project complexity—A review. International Journal of Project Management, 14(4), 201–204.
5.
BarkiH.RivardS.TalbotJ. (2001). An integrative contingency model of software project risk management. Journal of Management Information Systems, 17(4), 37–69.
6.
BarlowJ. B.GiboneyJ.KeithM. J.WilsonD.SchuetzlerR. M.LowryP. B.VanceA. (2011). Overview and guidance on agile development in large organizations. Communications of the Association for Information Systems, 29, 25–44.
7.
BarryC.LangM. (2003). A comparison of ‘traditional’ and multimedia information systems development practices. Information and Software Technology, 45(4), 217–227.
8.
BaskervilleR.Pries-HejeJ. (2004). Short cycle time systems development. Information Systems Journal, 14(3), 237–264.
9.
BatraD.XiaW.VanderMeerD.DuttaK. (2010). Balancing agile and structured development approaches to successfully manage large distributed software projects: A case study from the cruise industry. Communications of the Association for Information Systems, 27, 379–393.
10.
BesnerC.HobbsB. (2012). An empirical identification of project management toolsets and a comparison among project types. Project Management Journal, 43(5), 24–46.
11.
BoehmB. (2002). Get ready for agile methods, with care. IEEE Computer, 35(1), 64–69.
12.
BoehmB.TurnerR. (2003). Using risk to balance agile and plan-driven methods. IEEE Computer, 36(6), 57–66.
13.
BoehmB.TurnerR. (2005). Management challenges to implementing agile processes in traditional development organizations. IEEE Software, 22(5), 30–39.
14.
BurnsT.StalkerG. M. (1961). The management of innovation. London, England: Tavistock Publications.
15.
CaoL.MohanK.XuP.BalasubramaniamR. (2009). A framework for adapting agile development methodologies. European Journal of Information Systems, 18(4), 332–343.
16.
ChapmanR.HylandP. (2004). Complexity and learning behaviors in product innovation. Technovation, 24(7), 553–561.
17.
ChowT.CaoD.-B. (2008). A survey study of critical success factors in agile software projects. Journal of Systems and Software, 81(6), 961–971.
ClarkK. B. (1989). Project scope and project performance: The effect of parts strategy and supplier involvement on product development. Management Science, 35(10), 1247–1263.
20.
CobbC. G. (2011). Making sense of agile project management: Balancing control and agility. Hoboken, NJ: John Wiley & Sons, Inc.
21.
CollyerS.WarrenC. M. J. (2009). Project management approaches for dynamic environments. International Journal of Project Management, 27(4), 355–364.
CompeauD. R.HigginsC. A. (1995). Computer self-efficacy: Development of a measure and initial test. MIS Quarterly, 19(2), 189–211.
24.
ConboyK. (2009). Agility from first principles: Reconstructing the concept of agility in information system development. Information Systems Research, 20(3), 329–354.
25.
CrawfordL.HobbsB.TurnerJ. R. (2005). Project categorization systems. Newtown Square, PA: Project Management Institute.
26.
DonaldsonL. (2001). The contingency theory of organizations. Thousand Oaks, CA: Sage Publications.
27.
DönmezD.GroteG. (2018). Two sides of the same coin–how agile software development teams approach uncertainty as threats and opportunities. Information and Software Technology, 93, 94–111.
28.
EisenhardtK. M.TabriziB. N. (1995). Accelerating adaptive processes: Product innovation in the global computer industry. Administrative Science Quarterly, 40(1), 84–110.
29.
ElbannaA.SarkerS. (2016). The risks of agile software development: Learning from adopters. IEEE Software, 33(5), 72–79.
30.
ErikssonM.LilliesköldJ.JonssonN.NovoselD. (2002). How to manage complex multinational R&D projects successfully. Engineering Management Journal, 14(2), 53–60.
31.
FlyvbjergB.BudzierA. (2011). Why your IT project may be riskier than you think. Harvard Business Review, 89(11), 601–603.
32.
GeraldiJ. G.AdlbrechtG. (2007). On faith, fact, and interaction in projects. Project Management Journal, 38(1), 32–43.
33.
GeraldiJ.MaylorH.WilliamsT. (2011). Now, let’s make it really complex (complicated): A systematic review of the complexities of projects. International Journal of Operations & Production Management, 31(9), 966–990.
34.
GriffinA. (1997). The effect of project and process characteristics on product development cycle time. Journal of Marketing Research, 34(1), 24–35.
35.
HarrisM. L.CollinsR. W.HevnerA. R. (2009). Control of flexible software development under uncertainty. Information Systems Research, 20(3), 400–419.
36.
HartmanB. W.FuquaD. R.JenkinsS. J. (1986). The problems of and remedies for nonresponse bias in educational surveys. The Journal of Experimental Education, 54(2), 85–90.
37.
HayesR. H. (2002). Challenges posed to operations management by the “new economy.”Production and Operations Management, 11(1), 21–32.
38.
HobdayM. (1998). Product complexity, innovation, and industrial organization. Research Policy, 26(6), 689–710.
39.
HowellD.WindahlC.SeidelR. (2010). A project contingency framework based on uncertainty and its consequences. International Journal of Project Management, 28(3), 256–264.
40.
JiangJ. J.KleinG. (1999). Risks to different aspects of system success. Information & Management, 36(5), 263–272.
41.
JørgensenM. (2016). A survey on the characteristics of projects with success in delivering client benefits. Information and Software Technology, 78, 83–94.
42.
JørgensenM. (2018). Do agile methods work for large software projects? In GarbajosaJ.WangX.AguiarA. (Eds.), Agile processes in software engineering and extreme programming(XP 2018. Lecture Notes in Business Information Processing 314). Berlin, Germany: Springer.
43.
KautzK.MadsenS.NørbjergJ. (2007). Persistent problems and practices in information systems development. Information Systems Journal, 17(3), 217–239.
44.
KimC. S.PetersonD. K. (2003). A comparison of the perceived importance of information systems development strategies by developers from the United States and Korea. Information Resources Management Journal, 16(2), 1–18.
45.
LarsonE. W.GrayC. F. (2011). Project management: The managerial process. New York, NY: McGraw-Hill.
46.
LawrenceP. R.LorschJ. W. (1967). Organization and environment: Managing differentiation and integration. Boston, MA: Harvard University Press.
MabertV. A.SoniA.VenkataramananM. A. (2003). Enterprise resource planning: Managing the implementation process. European Journal of Operations Research, 146(2), 302–314.
49.
MarupingL. M.VenkateshV.AgarwalR. (2009). A control theory perspective on agile methodology use and changing user requirements. Information Systems Research, 20(3), 377–399.
50.
MaylorH. (2001). Assessing the relationship between practice changes and process improvement in new product development. Omega, 29(1), 85–96.
51.
MaylorH.VidgenR.CarverS. (2008). Managerial complexity in project-based operations: A grounded model and its implications for practice. Project Management Journal, 39(1 Suppl), S15–S26.
52.
McLeodL.MacDonellS. G. (2011). Factors that affect software systems development project outcomes: A survey of research. ACM Computing Surveys, 43(4), 1–56.
53.
MookerjeeV. S.ChiangI. R. (2002). A dynamic coordination policy for software system construction. IEEE Transactions on Software Engineering, 28(7), 684–694.
54.
MoormanC.ZaltmanG.DeshpandeR. (1992). Relationship between providers and users of market research: The dynamics of trust within and between organizations. Journal of Marketing Research, 29(3), 314–328.
55.
MorganG. (2006). Images of organization. Thousand Oaks, CA: Sage Publications.
56.
MurrayJ. P. (2000). Reducing IT project complexity. Information Strategy: The Executive’s Journal, 16(3), 30–38.
57.
NerurS.BalijepallyV. (2007). Theoretical reflections on agile development methodologies. Communications of the ACM, 50(3), 79–83.
58.
NguyenT. N. (2006). A decision model for managing software development projects. Information & Management, 43(1), 63–75.
59.
ParrA.ShanksG. (2000). A model of ERP project implementation. Journal of Information Technology, 15(4), 289–303.
60.
PichM. T.LochC. H.De MeyerA. (2002). On uncertainty, ambiguity, and complexity in project management. Management Science, 48(8), 1008–1023.
61.
Project Management Institute (PMI). (2017). A guide to the project management body of knowledge (PMBOK® guide) – Sixth edition. Newtown Square, PA: Author.
62.
RamasubbuN.BharadwajA.TayiG. K. (2015). Software process diversity: Conceptualization, measurement, and analysis of impact on project performance. MIS Quarterly, 39(4), 787–807.
63.
SauserB. J.ReillyR. R.ShenharA. J. (2009). Why projects fail? How contingency theory can provide new insights – A comparative analysis of NASA’s Mars Climate Orbiter loss. International Journal of Project Management, 27(7), 665–679.
64.
SchmidtR.LyytinenK.KeilM.CuleP. (2001). Identifying software project risks: An international Delphi study. Journal of Management Information Systems, 17(4), 5–36.
65.
ShenharA. J. (2001). One size does not fit all projects: Exploring classical contingency domains. Management Science, 47(3), 394–414.
66.
ShenharA. J.DvirD. (2007). Reinventing project management: The diamond approach to successful growth and innovation. Boston, MA: Harvard Business Press.
67.
SligerM.BroderickS. (2008). The software project manager’s bridge to agility. Upper Saddle River, NJ: Addison-Wesley.
68.
SussmanS. W.GuinanP. J. (1999). Antidotes for high complexity and ambiguity in software development. Information & Management, 36(1), 23–35.
69.
TatikondaM. V.RosenthalS. R. (2000). Technology novelty, project complexity, and product development project execution success: A deeper look at task uncertainty in product innovation. IEEE Transactions on Engineering Management, 47(1), 74–87.
70.
ThamhainH. J. (2004). Linkages of project environment to performance: Lessons for team leadership. International Journal of Project Management, 22(7), 533–544.
71.
TiwanaA.KeilM. (2010). Control in internal and outsourced software projects. Journal of Management Information Systems, 26(3), 9–44.
72.
TuunanenT.RossiM.SaarinenT.MathiassenL., (2007). A contingency model for requirements development. Journal of the Association for Information Systems, 8(11), 569–597.
73.
VidgenR. (2002). Constructing a web information system development methodology. Information Systems Journal, 12(3), 247–261.
74.
WallaceL.KeilM.RaiA., (2004a). Understanding software project risk: A cluster analysis. Information & Management, 42(1), 115–125.
75.
WallaceL.KeilM.RaiA. (2004b). How software project risk affects project performance: An investigation of the dimensions of risk and an exploratory model. Decision Sciences, 35(2), 289–321.
76.
WhiteD.FortuneJ. (2002). Current practices in project management—An empirical study. International Journal of Project Management, 20(1), 1–11.
77.
WilliamsT. M. (1999). The need for new paradigms for complex projects. International Journal of Project Management, 17(5), 269–273.
78.
WindelerJ. B.MarupingL.VenkateshV. (2017). Technical systems development risk factors: The role of empowering leadership in lowering developers’ stress. Information Systems Research, 28(4), 775–796.
79.
WysockiR. K. (2009). Effective project management: Traditional, agile, extreme. Indianapolis, IN: Wiley Publishing Inc.
80.
XiaW.LeeG. (2005). Complexity of information systems development projects: Conceptualization and measurement development. Journal of Management Information Systems, 22(1), 45–83.
81.
YoungD. K.BeebeN. L.DietrichG.LiuC. Z. (2016). An empirical examination of an agile contingent project/method fir model. Communications of the Association for Information Systems, 39, 267–296.
82.
YuM.-C. (2017). Customer participation and project performance: A moderated-mediation examination. Project Management Journal, 48(4), 8–21.
