Source-linked AI summary
A Perspective-Based Understanding of Project Success
Laurie McLeod, Bill Doolin, Stephen G. MacDonell
TL;DR
Project-success research faces ambiguity in defining outcomes and has relied heavily on objectivist approaches. This study uses a longitudinal case study to examine stakeholders’ subjective evaluations and develops a framework showing how those evaluations differ across perspectives and time.
Problem
Project success and failure are difficult to define, while project-management research has relied predominantly on objectivist approaches.
Source: §I · p. 1, §II · p. 2Method
An in-depth longitudinal case study of an IS development project examined stakeholders’ perceptions and evaluation criteria.
Source: §III · pp. 4–5Results
The case study found that project outcomes are interpreted differently across stakeholder perspectives and time, with evaluations drawing on process, product, and organizational criteria.
Source: §VII · p. 12, §VIII · p. 15Takeaways & Limitations
The framework treats evaluations as situated in stakeholder expectations and contexts, allowing multiple project evaluations that may differ across people and time.
Source: §VII · pp. 14–15The findings come from a single IS project case study, making this an initial empirical exploration.
Source: §VIII · p. 15
Abstract
from arXiv · showhide
Answering the call for alternative approaches to researching project management, we explore the evaluation of project success from a subjectivist perspective. An in-depth, longitudinal case study of information systems development in a large manufacturing company was used to investigate how various project stakeholders subjectively perceived the project outcome and what evaluation criteria they drew on in doing so. A conceptual framework is developed for understanding and analyzing evaluations of project success, both formal and informal. The framework highlights how different stakeholder perspectives influence the perceived outcome(s) of a project, and how project evaluations may differ between stakeholders and across time.
I. INTRODUCTION
Project success is ambiguous and cannot be captured reliably by a single objective criterion: evaluations reflect stakeholder perspectives, expectations, and context. The paper motivates a subjectivist approach to examine these differences and their implications for evaluating project outcomes.
I. INTRODUCTION
- Objectivist approaches dominate project-success research despite concerns that success and failure remain problematic and project-management knowledge is fragmented.The authors respond to calls for alternative approaches, including subjectivist research that treats success and failure as socially constructed.Source: §I · p. 1
- The study examines how IS-project stakeholders perceive outcomes and choose evaluation criteria, with broad success understandings relevant to managers assessing project progress.IS projects involve internal and external stakeholders with potentially different goals and criteria.Source: §I · p. 2
II. LITERATURE REVIEW
- Project success spans process, product, organizational, and strategic objectives, while the iron triangle focuses narrowly on delivery constraints and may conflict with broader judgments.Process criteria include time, cost, and specification; product and organizational criteria include use, satisfaction, benefits, and business objectives.Source: §II · pp. 2–3
- Evaluations may change over time: process criteria matter during delivery, product criteria after implementation, and business or strategic benefits over longer periods.Assessments can shift as situations and contexts evolve.Source: §II · p. 3
- Different stakeholder groups may judge success by different criteria, reflecting their expectations, interests, and organizational or professional contexts.For example, managers may prioritize process, users product impacts, and senior management business objectives.Source: §II · p. 4
- Project outcomes are interpreted through sense making and negotiated perceptions, making formal success judgments potentially political while informal evaluations also shape project decisions.Unvoiced expectations and unequal influence can affect which interpretations become the official account.Source: §II · p. 4
III. THE CASE STUDY AND RESEARCH METHODS
The study used an in-depth, longitudinal case study of an outsourced IS development project at a large manufacturing company. Multiple participant perspectives and qualitative records were analyzed to trace how interpretations of the outcome developed over time.
III. THE CASE STUDY AND RESEARCH METHODS
- The researchers conducted an in-depth, longitudinal case study of an IS development project at AlphaCo, a large manufacturing company, involving outsourced solution development.The project combined commercial package acquisition with largely on-site outsourced development.Source: §III · pp. 4–5
- The project replaced spreadsheet models used to manage AlphaCo’s IT outsourcing contract with a database solution.The models supported contract evaluation and performance reporting.Source: §III · p. 5
- Fieldwork followed the project from mid-2005 to mid-2007, including 558 on-site hours and 33 semistructured interviews.Participant observation was intensive for eight months, followed by site visits as project work became sporadic.Source: §III · p. 5
- Interviews, meetings, field notes, project documents, and organizational materials provided evidence about participants’ experiences and interpretations.Some interviewees were interviewed repeatedly as developments and issues emerged.Source: §III · p. 5
- The case-study design enabled contextual observation and access to multiple, potentially shifting interpretations of the outcome.The analysis focused on stakeholder perceptions of the outcome rather than on the project itself.Source: §III · pp. 5–6
- The analysis used thematic comparison and preserved chronology to build a narrative of project events and activities as they unfolded.The researchers read and reread the materials, comparing themes around project content, context, and process.Source: §III · p. 6
IV. THE ISOM PROJECT
The ISOM project was initially framed as a simple, low-risk migration, but delays and problems prolonged the work and reduced its organizational currency. The account focuses on completion and early use, when stakeholder assessments could stabilize yet still change with circumstances.
IV. THE ISOM PROJECT
- The feasibility report characterized the spreadsheet-to-database migration as simple, with no major delivery threats expected by the end of 2005.The only anticipated constraint was the availability of two key users to work with developers and test the solution.Source: §IV · p. 6
- In practice, delays and problems prolonged the project, while organizational events overtook it and reduced its currency.The paper focuses on completion and early solution use as especially relevant to evaluating outcomes.Source: §IV · p. 6
- Stakeholder perceptions tend to stabilize around completion and early use, but can shift as situations and context change.This qualifies the study’s focus on that period as relevant rather than definitive.Source: §IV · p. 6
A. Solution Development
Development proceeded through iterative building, testing, and amendment, but the negotiated delivery date was missed. Testing, operationalization, and completion of the solution’s two functions continued into 2006 amid data, system, and organizational disruptions.
A. Solution Development
- SoftCo developers iteratively built, tested, and amended the MDS solution with input from the external project manager and intended primary user.Delivery had been negotiated for early December 2005.Source: A. Solution Development · p. 6
- By the end of 2005, the solution was largely complete but remained untested and undocumented as development fell behind schedule.Milestones were revised after development quickly slipped behind schedule.Source: A. Solution Development · p. 6
- In early 2006, testing and operationalization were delayed by data corruption, solution problems, spreadsheet errors, and a major IS restructuring.Contract performance reporting worked from late February, while contract evaluation was not completed until mid-May.Source: A. Solution Development · p. 6
B. Project Closure Under Pressure
Pressure to demonstrate benefits and close the project coexisted with unfinished work and unresolved reconciliation. Stakeholders treated closure differently, and restructuring prevented the planned formal review.
B. Project Closure Under Pressure
- The ISPO pushed formal closure for portfolio reporting even though the project’s Development phase was incomplete, to support capitalization in the current financial year and avoid a “red light.”The project was marked “Complete” in Tracking the day after Gary filed the closure report.Source: B. Project Closure Under Pressure · pp. 6–7
- Gary regarded the solution as essentially complete despite unresolved reconciliation, but wanted sign-off from Claire, Dave, and others before closing with SoftCo.Reconciliation problems originated in AlphaCo’s original models and data.Source: B. Project Closure Under Pressure · p. 7
- The June meeting brought some closure for AlphaCo’s team, while SoftCo viewed the final training session as the solution handover.Only Gary and Vince attended an earlier training session intended to raise awareness; Vince was later transferred overseas and made redundant.Source: B. Project Closure Under Pressure · p. 7
- The MDS installation took four months rather than the usual two weeks, mainly because of IT infrastructure change-request delays and server instability.Source: B. Project Closure Under Pressure · p. 7
- The formal review expected after the project was marked complete never occurred, as restructuring disrupted the project office and displaced the review among larger priorities.The sponsor also reported that restructuring disrupted several IS projects.Source: B. Project Closure Under Pressure · p. 7
C. (Non)Use of the MDS Solution
The MDS solution was used sporadically as restructuring weakened demand for its reports, while staff capacity and knowledge constrained further use. AlphaCo applied different criteria to project monitoring and overall success, but benefits realization was not implemented.
C. (Non)Use of the MDS Solution
- The MDS was intended for ISOM’s monthly contract reporting, with senior managers, the Board, and others as indirect users of its information.Source: C. (Non)Use of the MDS Solution · p. 7
- Restructuring shifted reporting priorities away from outsourcing-contract performance, removing an important source of organizational legitimacy for the MDS reports.Stuart introduced monthly cost-center reporting, and Gary anticipated the MDS might again be useful once reporting needs were clarified.Source: C. (Non)Use of the MDS Solution · pp. 7–8
- From completion through July 2007, the MDS solution was used only sporadically, partly because Gary’s knowledge and staff capacity limited its potential and expansion.Dave also said the relatively small project fell off the radar during restructuring.Source: C. (Non)Use of the MDS Solution · p. 8
- A 2007 demonstration suggested potential future demand, but Stuart’s absence left senior management unaware of the solution and blocked its escalation.Source: C. (Non)Use of the MDS Solution · p. 8
- AlphaCo had no single formal definition of project success or failure, despite a perceived history of problematic IS project outcomes.Source: §V · p. 8
- For active-project monitoring, the ISPO used time, scope, and budget criteria to track performance and identify projects needing follow-up.Source: §V · pp. 8–9
- Overall success criteria were broader but unsettled, including quality, client acceptance, and benefits; business benefits realization was recognized but not implemented.Source: §V · p. 9
VI. STAKEHOLDER PERCEPTIONS OF THE ISOM PROJECT OUTCOME
No formal evaluation of the ISOM project was conducted. Instead, stakeholders made informal evaluations shaped by their own perspectives, interests, and expectations.
VI. STAKEHOLDER PERCEPTIONS OF THE ISOM PROJECT OUTCOME
- The ISOM project received no formal evaluation.Source: §VI · p. 9
- Stakeholders made informal assessments of the project outcome.Source: §VI · p. 9
- Those assessments reflected stakeholders’ differing perspectives, interests, and expectations, and were summarized in a stakeholder analysis.Source: §VI · p. 9
A. AlphaCo ISPO
The ISPO emphasized process compliance, reporting, time, and budget. By its iron-triangle criteria, the project met specifications and budget but ran slightly over time.
A. AlphaCo ISPO
- The ISPO focused on process compliance, reporting, financial control, quality assurance, time, and budget, and pressed for formal closure to avoid dashboard warning signs.Source: A. AlphaCo ISPO · p. 9
- By the ISPO’s iron-triangle criteria, the project met specifications and stayed within budget but ran slightly over time.Source: A. AlphaCo ISPO · p. 9
- Work continued after formal closure to reconcile the solution, while associated costs required separate approval; including them in the project costs would still have kept it within budget.Source: A. AlphaCo ISPO · p. 9
B. SoftCo
SoftCo developers viewed the MDS solution positively while noting late delivery, and project manager Marie weighed specifications, time, budget, knowledge transfer, and the client relationship.
B. SoftCo
- SoftCo developers believed the MDS solution largely met its intended specifications, though Nancy noted it was not delivered on time.Their evaluation emphasized a workable solution and timely delivery.Source: B. SoftCo · p. 9
- Marie said the constrained schedule left insufficient time to transfer MDS knowledge to the ISOM team.The contract time frame and budget had been underestimated during negotiations.Source: B. SoftCo · pp. 9–10
- Marie treated delivery to specifications, on time, and within budget as practical criteria, while considering the schedule and budget unrealistic.She was confident the solution would achieve its intended purpose.Source: B. SoftCo · pp. 9–10
- Despite expecting a financial loss on the project, Marie hoped it would strengthen SoftCo’s relationship with AlphaCo.She hoped the client would recognize SoftCo’s ability to deliver.Source: B. SoftCo · p. 10
C. AlphaCo Project Team
AlphaCo project participants evaluated success through different process, product, and organizational concerns, with assessments shifting from solution acceptance toward implementation and demonstrable benefits.
C. AlphaCo Project Team
- Frank’s acceptance process covered nine criteria, including specifications, user satisfaction, training, documentation, support, business benefits, scalability, and knowledge transfer, but was not completed after he left.Gary took over and focused pragmatically on testing and implementation.Source: C. AlphaCo Project Team · p. 11
- Claire and Gary regarded the project as successful in process and product terms despite delivery delays, valuing the team, supplier relationship, and useful solution.Their favorable assessments included anticipated uses and the solution’s reported improvements over the previous approach.Source: C. AlphaCo Project Team · p. 11
- Gary’s later lack of MDS use eroded his detailed knowledge and shifted his assessment toward the solution being overcomplicated and not intuitive.By mid-2006 he had described himself as a confident user.Source: C. AlphaCo Project Team · p. 11
- Dave saw the built solution as successful and expected it to improve reporting, but remained concerned that its business benefits were not demonstrated.He treated development and final deployment as distinct and emphasized the solution operating as intended.Source: C. AlphaCo Project Team · p. 11
D. AlphaCo IS Senior Management
Senior managers considered requirements, delivery, actual use, and organizational value, while the project’s changing context weakened the perceived case for the solution.
D. AlphaCo IS Senior Management
- James judged that the solution met requirements and would improve the area, but noted delayed implementation and identified actual use as a key test of success.Time, cost, and specifications mattered to him, though they were not day-to-day concerns.Source: D. AlphaCo IS Senior Management · pp. 11–12
- The project’s strategic importance declined over time, and James viewed its business and strategic benefits as limited relative to projects delivering direct business value.It had initially been considered necessary to maintain AlphaCo’s business.Source: D. AlphaCo IS Senior Management · p. 12
- After James left and Stuart brought different priorities, organizational demand for MDS weakened and its anticipated knowledge-transfer and scalability benefits remained unrealized.Gary was the only user with knowledge of the solution, and Claire used Excel for contract renegotiation modeling.Source: D. AlphaCo IS Senior Management · p. 12
VII. DISCUSSION
The discussion frames project success as a situated, subjective evaluation shaped by stakeholder expectations and context, varying across criteria, scope, and time. The case shows why a single success judgment cannot capture these differences.
VII. DISCUSSION
- The case confirms multidimensional project outcomes and finds singular success criteria inadequate to capture evaluations spanning process, product, and organizational impact.Stakeholder interpretations depend on their perspectives, expectations, and context.Source: §VII · p. 12
- Evaluations broadened from process criteria among project participants to product criteria among closer stakeholders and organizational-value criteria among higher-level stakeholders.Nearly all participants used the iron triangle at some point, alongside other criteria such as design quality, teamwork, user satisfaction, and benefits.Source: §VII · p. 12
- Criteria operated on different timelines: process during the project, product after implementation, and organizational objectives over a longer post-implementation period.The team’s evaluation shifted from concern at the planned delivery date to success after acceptance, then frustration over unproven benefits.Source: §VII · pp. 12–13
- Stakeholder interests differed: SoftCo developers emphasized delivery quality and timeliness, while project managers and ISOM analysts also considered satisfaction, product use, and benefits.Dave’s need to justify the investment made demonstrable usefulness central to his evaluation.Source: §VII · p. 13
- Organizational restructuring reduced the solution’s perceived relevance, while Gary’s experience of using and not using it shifted his evaluation.SoftCo’s interest in securing AlphaCo as a client also shaped its project actions and evaluation.Source: §VII · p. 13
- The ISPO’s reporting and compliance interests privileged institutional requirements in a negotiated project evaluation, sometimes over the ISOM team’s interests.Pressure to close the project before a completed solution reflected formal reporting needs.Source: §VII · p. 13
- Stakeholder expectations shaped which criteria seemed relevant, including the ISPO’s emphasis on compliance and targets rather than directly monitoring client acceptance.Existing criteria such as the iron triangle could be drawn from project-management practice rather than devised by stakeholders.Source: §VII · p. 14
- Although stakeholders converged when judging whether a successful solution had been produced, senior management appeared less convinced than Gary and Dave about its organizational value.Product success outweighed late delivery for many stakeholders during the project, before remaining stakeholders focused more on strategic benefits.Source: §VII · p. 14
VIII. CONCLUSION
The case shows that project success is evaluated through context-shaped sense-making, with perceptions differing across stakeholders and potentially over time. The perspective-based framework supports analysis of these evaluations and highlights practical uses for researchers and project managers.
VIII. CONCLUSION
- Project outcomes are interpreted differently across stakeholder perspectives and potentially over time through context-shaped sense-making.Stakeholder criteria may focus on project process, product, and/or organizational objectives.Source: §VIII · p. 15
- The framework directs attention to how evaluations emerge over time across stakeholders whose expectations reflect societal, organizational, and work contexts.It can explain multiple, potentially conflicting evaluations of a project outcome.Source: §VIII · p. 15
- For researchers, the framework serves as an analytical and sensitizing device to guide empirical data collection, analysis, and presentation.It provides criteria for investigating subjectivity and the role of context in project evaluation.Source: §VIII · p. 15
- Including multiple perspectives in formal evaluations encourages wider criteria, since one client-driven view may not capture success for all stakeholders.The authors connect broader inclusion in project performance and evaluation with more beneficial outcomes for stakeholders.Source: §VIII · pp. 15–16
- Project managers should seek regular stakeholder feedback during projects, which may help address emerging user-related problems or avoid escalating commitment.Awareness of high-level evaluations can also keep broader organizational objectives in view.Source: §VIII · p. 15
- Attending to organizational history and product use may facilitate learning from past projects, while the empirical findings rest on a single IS project case.The authors describe the study as an initial empirical exploration and note that subjectivist research entails time-consuming fieldwork and detailed qualitative analysis.Source: §VIII · p. 15