REVISITING IT PROJECT UNCERTAINTY: OPERATIONALIZING THE SAMBAMURTHY–ZMUD MODEL FOR DE-RISKING DIGITAL TRANSFORMATION PROJECTS

International Journal of Information Sciences and Techniques (IJIST) Vol.15, No.6, November 2025 DOI : 10.5121/ijist.2025.15601 1 REVISITING IT PROJECT UNCERTAINTY: OPERATIONALIZING THE SAMBAMURTHY–ZMUD MODEL FOR DE-RISKING DIGITAL TRANSFORMATION PROJECTS Irshad Abdulla Beedie School of Business, Simon Fraser University, Vancouver, Canada ABSTRACT Uncertainty in project deliverables remains a pervasive source of IT project failure, yet its structural origins are rarely operationalized. Sambamurthy and Zmud (2017) proposed a conceptual model linking IT project uncertainty to two fundamental dimensions: (1) the clarity or ambiguity of project deliverable specifications and (2) the number, diversity, and power of stakeholders involved. Despite its strong resonance with practice, this framework has not been empirically developed or tested. This paper extends and operationalizes the Sambamurthy–Zmud model by defining measurable constructs for project deliverable specification clarity and stakeholder structure complexity and by theorizing their joint effect on IT project risk. Drawing on information processing theory, stakeholder theory, and sociotechnical systems perspectives, the paper argues that IT project uncertainty is not merely a descriptive condition, but a primary driver of project risk. A conceptual model and testable hypotheses are proposed to guide future empirical research and managerial practice in digital transformation projects. KEYWORDS Digital Transformation, Technology Project Uncertainty, Technology Project Risk, Deliverable Specification, Project Stakeholders 1. INTRODUCTION Information technology (IT) projects continue to experience high rates of failure, budget overruns, and benefit shortfalls. Decades of empirical and practitioner studies identify “uncertainty” as one of the most persistent causes of risk (Lyytinen et al., 1998; Wallace et al., 2004; Tiwana & Keil, 2004). Yet, the term uncertainty remains conceptually diffuse and operationally underdeveloped. Sambamurthy and Zmud (2017) proposed a compelling and practice-aligned model that frames IT project uncertainty along two dimensions: (1) the clarity or ambiguity of project deliverable specifications and (2) the number, diversity, and power of stakeholders who influence project outcomes. According to this model, projects characterized by ambiguous deliverables and complex stakeholder structures exhibit higher levels of uncertainty, which in turn heightens project risk. While their framework provides a clear conceptual foundation, it remains largely pedagogical — introduced in their book Guiding the Digital Transformation of Organizations — and has not yet been elaborated or validated in the academic literature. This paper seeks to extend that model by International Journal of Information Sciences and Techniques (IJIST) Vol.15, No.6, November 2025 2 defining the constructs, grounding them in established theories, and linking them explicitly to project risk outcomes. The central premise is that reducing uncertainty reduces risk. Clarifying deliverable specifications and managing stakeholder structure structure complexity are therefore not administrative niceties, but core mechanisms of de-risking IT projects. The research question motivating this study is: How do deliverable specification clarity and stakeholder structure complexity jointly influence IT project risk? 2. THEORETICAL BACKGROUND 2.1. IT Project Risk and Uncertainty Risk in IT projects is commonly defined as the likelihood and impact of adverse events affecting project objectives (Barki et al., 1993). Uncertainty, by contrast, refers to the lack of clarity or predictability regarding those objectives and events. In project management research, uncertainty is viewed as a precursor to risk: ambiguous or unstable conditions increase the probability of negative outcomes (Chapman & Ward, 2003). IT projects, particularly large-scale digital transformation initiatives, operate under high uncertainty because deliverables evolve alongside emerging technologies and shifting organizational needs. Requirements often remain partially specified or contested across stakeholder groups, creating fertile ground for scope creep, design rework, and schedule delays. 2.2. The Sambamurthy–Zmud Model of Project Uncertainty Sambamurthy and Zmud (2017) position IT project uncertainty within a two-dimensional framework: 1. Clarity vs. Ambiguity in Deliverable Specifications – the degree to which project outputs are well-defined and understood. 2. Number / Diversity of Stakeholders – the structural complexity of the stakeholder environment influencing the project. Projects with high ambiguity and high stakeholder structure complexity are expected to experience the greatest uncertainty and therefore the highest risk. This framework offers a powerful lens for examining project failure causes but has not been translated into measurable constructs or empirically validated. This paper advances the model by defining each dimension operationally and theorizing their interaction through established organizational theories. 3. THEORETICAL FOUNDATIONS 3.1. Information Processing Theory (Galbraith, 1973) Organizations must process information to resolve uncertainty. The amount of information processing required increases with task ambiguity and interdependence. Deliverable specification International Journal of Information Sciences and Techniques (IJIST) Vol.15, No.6, November 2025 3 clarity reduces the need for information processing; ambiguity increases it. Projects overloaded with unprocessed information are more prone to coordination failure and risk. 3.2. Stakeholder Theory (Freeman, 1984; Mitchell, Agle & Wood, 1997) Projects involve multiple stakeholders with varying salience (power, legitimacy, urgency). As stakeholder diversity and power asymmetry increase, alignment becomes harder, leading to contested interpretations of deliverables. This misalignment magnifies the impact of specification ambiguity. 3.3. Socio-Technical Systems Theory Projects succeed when the technical (specifications, systems, methods) and social (stakeholders, governance, communication) subsystems are aligned. Misalignment—such as ambiguous deliverables coupled with fragmented stakeholder interests—creates systemic project risk. Together, these theories help explain how ambiguity and stakeholder structure complexity interact to produce risk through elevated information processing demands, goal misalignment, and socio-technical imbalance. 4. CONCEPTUAL MODEL The proposed model conceptualizes IT Project Risk as an outcome of IT Project Uncertainty, which emerges from the interaction between deliverable specification clarity (DSC) and stakeholder structure complexity (SSC). Figure 1. Conceptual Model of IT Project Risk as an outcome of IT Project Project Uncertainty (Adapted from Sambamurthy and Zmud, 2017) When DSC is low (ambiguous deliverables), projects face greater risk due to misinterpretation of what actually needs to be delivered. When SSC is high (large number of stakeholders, or International Journal of Information Sciences and Techniques (IJIST) Vol.15, No.6, November 2025 4 stakeholders representing varying interests / parts of the organization), coordination challenges / meeting competing needs of stakeholders amplify the impact of any deliverable ambiguity. Thus SSC by itself is not of significance, the moderating impact of SSC on DSC is relevant. Conversely, high DSC and low SSC conditions yield lower uncertainty and reduced project risk. 5. CONSTRUCT DEFINITIONS AND OPERATIONALIZATION This section defines the key constructs underpinning the model of IT project uncertainty adapted from Sambamurthy&Zmud (2017). Following their proposition that uncertainty in project deliverable specifications and stakeholder structure complexity increase IT project risk, we expand each construct and provide preliminary operationalization guidance for empirical testing. 5.1. Project Deliverable Specifications Defining Project Deliverable Specifications Project deliverable specifications (also referred to plainly as deliverables) are the formal outputs that define what an IT project must produce to achieve its intended outcomes. In an IT project, each project deliverable serves a particular purpose that aids in achieving project objectives in some form or another; and there may be relationships between deliverables such that one deliverable informs or is a prerequisite for another. Each deliverable typically comprises different content required to satisfy the objectives of that particular deliverable. For example project charter deliverables may detail a set of decisions about project scope, functional design specifications may include descriptions of how the system functionality will be set up, and data design deliverables describe decisions about what data will be migrated from the old system to the new system being implemented in the project. Uncertainty in deliverable specifications arises from incomplete, inconsistent, or ambiguous definitions of “what success looks like” (Wallace, Keil & Rai, 2004; Tiwana & Keil, 2007). Reducing ambiguity in these deliverables is central to de-risking large-scale IT projects (Sambamurthy&Zmud, 2017). Building on Sambamurthy& Zmud’s (2017) proposition that uncertainty in project deliverable specifications contributes to IT project risk, we can operationalize this construct by identifying the key deliverables in large-scale technology projects and examining how clarity or ambiguity manifests in each. Table 1 in Appendix A synthesizes findings from the IS project management and systems engineering literature, combined with practical insights from large-scale ERP and digital transformation programs (e.g., Tiwana & Keil, 2007; Nelson, 2007; Barki et al., 2001; Keil et al., 2013). It lists and describes key deliverables in a digital transformation project, along with potential sources of ambiguity and mechanisms that can be applied to reduce such ambiguity. Operationalization of Deliverable Specification Clarity (DSC) Deliverable Specification Clarity (DSC) is conceptualized as a multi-dimensional construct comprising perceived clarity, documented ambiguity, and contextual interpretation. To assess this construct in the context of IT projects, three complementary components are proposed: the Deliverable Clarity Index (DCI), the Ambiguity Ratio (AR-0), and Qualitative Indicators (QI). Each serves a distinct yet reinforcing analytical role. International Journal of Information Sciences and Techniques (IJIST) Vol.15, No.6, November 2025 5 Deliverable Clarity Index (DCI) is a qualitative composite indicator measuring how clear, complete, specific, and consistent key project deliverables are in the eyes of project participants. It reflects the shared understanding of deliverables among project participants. DCI can be measured as a mean of Likert-scale survey responses (1–5) on items assessing core deliverables listed in Appendix A (e.g., project charter, requirements, data, integration, training, change management). Data for DCI can be gathered by surveying project team members, business stakeholders, and system integrators. The Initial Ambiguity Ratio (AR-0) can be seen as a diagnostic indicator quantifying the extent of unresolved, conflicting, or incomplete elements in deliverable documentation. It captures “objective” ambiguity present in project artefacts. This is a quantitative indicator counting ambiguous, conflicting, or incomplete items ÷ total documented items. AR-0 data can be gathered through project requirements logs, issue trackers, meeting minutes and design documentation. Gaps in AR-0 can manifest if a deliverable has never been developed in the project in the first place and hence does not show up as a denominator in the “incomplete items ÷ total documented items” AR-0 calculation. Similarly, if the deliverable is developed but is missing important content which project participants do not realize, these ambiguities are never documented in the issue tracker, meeting minutes etc. and may not show up in the numerator of “incomplete items ÷ total documented items” AR-0 calculation. Qualitative Indicators (QI) are thematic and narrative evidence providing contextual understanding of how clarity or ambiguity manifests in practice. It explains the why behind DCI and AR values. Measures include thematic coding of qualitative data to identify instances of misunderstanding, rework, or disagreement regarding deliverables. Interviews, project retrospectives, industry expertise and lessons-learned documentation are potential data sources. QI can be used to compensate for potential data gaps in AR-0 described above. Integration of DSC Components DCI, AR-0 and QI components are not redundant but rather complementary, leading to an overall Ambiguity Ratio (AR). DCI provides a subjective perception of clarity across stakeholders whilst AR-0 offers an initial objective documentation-based measure of ambiguity. QI supplies contextual insight, explaining patterns and relationships observed in DCI and AR-0. QI also allows for consideration of relevant project deliverables which may not have been developed at all in a particular project, or which may have been developed but are missing important deliverable content and such deficiencies do not show up in DCI or AR-0 assessments. Together, AR enables both quantitative assessment and qualitative interpretation of how clearly deliverables are defined and communicated within IT projects. Using both perceptual (DCI, QI) and empirical (AR-0) measures aligns with mixed-methods approaches in IS research (Venkatesh et al., 2013; Mertens, 2015). This triangulation ensures construct validity and enables multiperspective understanding—critical in complex, multi-stakeholder IT environments where clarity is socially constructed and often evolves dynamically (Lyytinen & Newman, 2008; Turner & Cochrane, 1993). 5.2. Stakeholder Characteristics Stakeholders are individuals or groups with a direct interest in or influence over project deliverables, and by extension, the overall realization of intended project outcomes. Their number and diversity shape the level of uncertainty during project execution (McKeen & Smith, 2003; Lyytinen &Hirschheim, 1987). We distinguish core stakeholders (those defining, approving, or International Journal of Information Sciences and Techniques (IJIST) Vol.15, No.6, November 2025 6 directly impacted by deliverables) from peripheral stakeholders (those indirectly affected but not influential in specification clarity). Number and Diversity of Stakeholders The number of stakeholders can be defined as the count of distinct core stakeholders and stakeholder groups directly involved in shaping project deliverables. Risks introduced by the number of stakeholders include coordination overload, increased communication noise, amount of effort required for training and change management. These risks can be measured and potentially mitigated by using stakeholder analysis, communication network density metrics and change impact assessments (Mitchell, Agle & Wood (1997); Barki & Hartwick (2001)). Diversity of stakeholders is another dimension of SSC (Sambamurthy and Zmud, 2017). This can be seen as the degree of heterogeneity in the core stakeholders’ functional role in the business, their desired project outcomes, their desire or time available to participate in project activities, competing priorities, culture, geography, or cognition. Misaligned frames of reference and conflicting decision logics are some of the risks that diverse stakeholders introduce. These risks can be measured and mitigated through stakeholder diversity index assessments (Shannon index), alignment workshops and running shared understanding sessions (Reich &Benbasat (2000); Martinsuo&Hoverfält (2018)). Stakeholder Power as an Omitted but Critical Dimension Sambamurthy and Zmud (2017) include power as a third dimension of stakeholder structure complexity, alongside the number and diversity of stakeholders. However, their treatment of the construct is relatively limited and conceptual. In their model, stakeholder power is presented in a manner analogous to other dimensions—where higher stakeholder power is assumed to elevate project risk—but without elaboration on what constitutes power, how it is distributed, or how it interacts with other dimensions of stakeholder complexity. The model does not specify what distinguishes high versus low stakeholder power, nor does it explain the mechanisms through which power asymmetries influence decision-making, coordination, or ultimately, project risk. For these reasons, power was excluded from the initial operationalization of stakeholder structure complexity in this study. Its omission reflects both conceptual ambiguity and measurement difficulty, rather than theoretical insignificance. Power remains a critical yet underexplored factor that future research must address (Mitchell et al., 1997; Aaltonen & Kujala, 2010). The challenge of conceptualizing and measuring power within information systems projects has long been recognized. Parrish (2006) characterizes power in IS contexts as a “wicked problem,” noting that “defining the problem is the problem in most cases.” Adopting a sociological perspective, Parrish proposed a taxonomy of power-related issues and a methodological approach to studying them, offering valuable foundations for future inquiry. Similarly, Hofstede’s (2011) work on organizational culture introduces the dimension of power distance—defined as the extent to which less powerful members of organizations accept and expect unequal power distribution. This notion highlights that inequality can be perpetuated not only by those in authority (e.g., project sponsors or executives) but also by those who accept such hierarchies (e.g., system users or implementation teams). Understanding stakeholder power through these theoretical lenses may enable richer conceptualizations of Stakeholder Structure Complexity (SSC). Future research should explore how variations in power distribution—both formal (authority, control over resources) and International Journal of Information Sciences and Techniques (IJIST) Vol.15, No.6, November 2025 7 informal (expertise, influence, legitimacy)—shape interactions among stakeholders, influence deliverable clarity, and amplify or mitigate project risk. Operationalization of Stakeholder Structure Complexity (SSC) Stakeholder Complexity Index (SCI) can be defined as the weighted composite measure of number of stakeholders × diversity of stakeholders. SCI can be informed by both qualitative and quantitative data sources. Qualitative data sources informing include stakeholder maps, governance records, and meeting transcripts coded for influence, conflict, and alignment patterns. Quantitative measures can be adapted from scales from Reich &Benbasat (2000) and Barki & Hartwick (2001) for evaluating stakeholder alignment and communication quality. 6. PROPOSED ANALYTICAL MODEL AND HYPOTHESES Building on Sambamurthy and Zmud’s (2017) conceptualization of IT project uncertainty, this study proposes a model in which deliverable ambiguity and stakeholder structure complexity jointly influence project risk. Specifically, project risk (PR) is modeled as a function of the Ambiguity Ratio (AR), the Stakeholder Complexity Index (SCI), and their interaction: PR = β0 + β1(AR) + β2(SCI) + β3(AR×SCI) + ε 6.1. Interpretation of the Model 1. β₀ represents the baseline level of project risk when both ambiguity and stakeholder structure complexity are minimal. 2. β₁ captures the direct effect of ambiguity in project deliverable specifications on project risk. 3. β₂ captures the direct effect of stakeholder structure complexity—defined by the number, diversity, and power of stakeholders—on project risk. 4. β₃ represents the interaction effect, indicating whether the risk impact of ambiguity becomes stronger (or weaker) as stakeholder structure complexity increases. 5. ε captures all other sources of project risk not explained by ambiguity or stakeholder structure complexity (random noise, unmeasured variables, etc.). 6.2. Theoretical Rationale Ambiguity in project deliverable specifications creates uncertainty in scope, requirements, and expected outcomes, which elevates the likelihood of rework, schedule delays, and misalignment between business and technical teams (Barki, Rivard, & Talbot, 2001; Wallace, Keil, & Rai, 2004). Meanwhile, stakeholder structure complexity—through competing interests, communication breakdowns, and decision bottlenecks—further amplifies these risks (Jiang, Klein, &Balloun, 1998; McLeod et al., 2012). When both ambiguity and stakeholder structure complexity are high, their joint influence is expected to compound project uncertainty, creating an environment where clarity deteriorates faster than mitigation mechanisms can respond. International Journal of Information Sciences and Techniques (IJIST) Vol.15, No.6, November 2025 8 6.3. Hypotheses H1:Deliverable ambiguity (AR) is positively associated with project risk (PR). Projects with more ambiguous deliverables will experience higher levels of perceived and realized risk. H2:Stakeholder complexity (SCI) is positively associated with project risk (PR). Projects involving a greater number, diversity, or power imbalance among stakeholders will face higher levels of project risk. H3:Stakeholder complexity moderates the relationship between deliverable ambiguity and project risk (AR × SCI). The positive effect of ambiguity on project risk will be stronger when stakeholder structure complexity is high. 6.4. Case Example A brief empirical study was conducted to operationalize and test the proposed model. The digital transformation project examined in this study involved modernizing recruitment processes for a large public-sector organization. Deliverable Clarity Index (DCI) Assessment DCI was assessed through a survey administered to ten project stakeholders, including the project manager, technical leads, business representatives, and various end users. Respondents rated each deliverable on a 0–5 scale, where 5 indicated a high level of clarity. The Initial Ambiguity Ratio (AR-0) was derived by counting the number of ambiguities identified within each deliverable and converting these counts to a 0–5 scale, with 5 representing the greatest observed ambiguity. Qualitative Indicators (QI) were extracted from semi-structured interviews and supporting project artefacts, such as status reports and meeting minutes, to provide contextual insight into sources of ambiguity. The final Ambiguity Ratio (AR) was determined by triangulating the DCI, AR-0, and QI results, producing an aggregated 0–5 score for each deliverable, where 5 represented the highest level of ambiguity. Deliverable DCI AR-0 QI AR 1. Project Charter & Plan 3 2 Different types of recruitment processes in scope not fully described. Variations of union / nonunion scope are vague. 2 2. Business Requirements 4 3 Business requirements included as a list but not clear how the requirements are realized in a business process. 2 3. Functional Design Specifications 3 1 Simply stated what module / function of the system will be configured to meet the requirement. Does not explain how the configuration will be done in the system, so full configuration effort not clear and quantifiable. Unclear what customizations are needed. Business reports / analytics not clear. 2 International Journal of Information Sciences and Techniques (IJIST) Vol.15, No.6, November 2025 9 Deliverable DCI AR-0 QI AR 4. Non-Functional Requirements (NFRs) & Designs 2 1 No analysis of expected increase in volumes of applicants post system implementation, so not possible to assess system performance impact. Backup / disaster recovery not mentioned. System look and feel is not clear. 1 5. Solution Architecture 3 1 Not clear what will be in the cloud vs on premises. Not clear how recruiters will access the system remotely, or how the system will be monitored and troubleshooting done. Unclear if some of this should be covered in the NFR deliverable. 1 6. Data Design 2 1 Key decisions about data migration (how much history) not addressed. Data archival approach unclear. 1 7. Integration Design 3 1 Interfaces listed but actual technology to integrate systems not defined. Not clear about re-use of existing interfaces vs net new to be built. Difficult to understand effort required. 2 8. Testing and Acceptance Criteria 2 2 Broad statements of outcomes to be tested rather than specific test cases linked to business requirements. 2 9. Training Deliverables 3 3 Adequate online and in person training, tailored to user personas. 3 10. Organizational Change Management Deliverables 3 3 Change management efforts informed other deliverables e.g. business requirements. 2 11. Project Dependencies 3 1 Known projects identified and best-efforts approach to synchronize dependencies. However no formal mechanism to track and monitor. 1 12. Transition and Deployment Plans 4 2 Well defined plans and roles and responsibilities. Not clear how a roll back will be performed in the event of a failed cutover. 2 13. The IT System 2 1 Overall system is functional. Several performance and usability issues to still be addressed. Project schedule and budget were impacted, as well as overall scope reduced. 2 Stakeholder Structure Complexity (SSC) Assessment SSC was evaluated based on the number and diversity of stakeholders involved in the project, supplemented by qualitative indicators extracted from project documentation and meeting records. Quantitative data captured the breadth and heterogeneity of stakeholder groups, while qualitative insights highlighted variations in interests, roles, and interdependencies. The overall Stakeholder Complexity Index (SCI) for this case was then assessed as 4 on a 0–5 scale, where 5 represents the highest level of complexity. This rating was derived through triangulation of the quantitative and qualitative evidence, reflecting a project environment characterized by numerous and diverse stakeholder groups with overlapping responsibilities. Number of Stakeholders Diversity of Stakeholders Qualitative Indicators Internal to organization – 500 Recruiters – union, non union, executive recruiters, temporary staffing. Union rules for recruitment may differ significantly, so diversity of recruiters / managers / internal applicants may need to be International Journal of Information Sciences and Techniques (IJIST) Vol.15, No.6, November 2025 16 APPENDIX A: AMBIGUITY IN KEY TECHNOLOGY PROJECT DELIVERABLES A digital transformation project generates multiple interdependent deliverables that collectively define its scope, architecture, and implementation trajectory. From an information processing perspective (Galbraith, 1973), each deliverable embodies a set of information requirements that must be clearly specified to reduce uncertainty and enable coordinated action among stakeholders. While ambiguity can emerge in any deliverable, not all deliverables exert an equal or direct influence on overall project risk. Table 1 identifies the core deliverables that most significantly shape project outcomes. For each, it outlines the deliverable’s purpose, explains why clarity is essential, and illustrates the typical forms of ambiguity that may arise along with mechanisms to mitigate them. In doing so, the table provides an initial structure for operationalizing deliverable ambiguity—linking theoretical constructs of uncertainty to tangible project artefacts. This framework offers a foundation for identifying which deliverables warrant prioritization when managing and empirically examining project uncertainty and serves as a basis for hypothesis development and validation in future research. Table 1. Key Project Deliverables, Sources of Ambiguity, and Clarity Mechanisms Deliverable Description / Scope What Needs to Be Clear What May Be Ambiguous Mechanisms to Reduce Ambiguity / Increase Clarity Representative References 1. Project Charter & Plan Foundational document defining project purpose, scope, delivery model, roles, responsibilities, resource plans, budget, and project management tools Scope boundaries, role clarity (incl. vendors/ system integrators), governance model decision making processes, project record management practices, milestones Diffuse scope statements, unclear accountabilities, incomplete resourcing assumptions. Business case and anticipated benefits are unclear, making it difficult to firm up the project charter deliverable. RACI matrices, detailed work breakdown structures (WBS), integrated project plans, formal governance charters PMI (2021);Barki et al. (2001); Nelson (2007) 2. Business Requirements Description of business problems, objectives, and needs that must be satisfied. Business outcomes, value drivers, success metrics framed within the context of business processes. Overly generic goals, scope creep, conflicting stakeholder interests, statements about business requirements with business process / workflow context. Confusing business requirements Joint requirements sessions, business case validation, business process modelling, prioritization matrices Tiwana & Keil (2007); Schmidt et al. (2001) International Journal of Information Sciences and Techniques (IJIST) Vol.15, No.6, November 2025 17 Deliverable Description / Scope What Needs to Be Clear What May Be Ambiguous Mechanisms to Reduce Ambiguity / Increase Clarity Representative References with system functionality. 3. Functional Design Specifications System set-up tasks and design, system process flows, and user interactions with the IT system User journeys, process variants, exception handling, system configurations and customizations Assumptions about inherent system capabilities, lack of description of how the business requirements will be met by the system. Prototypes, user stories, iterative walkthroughs Browning (2014); Boehm & Turner (2004) 4. Non-Functional Requirements (NFRs) & Designs System performance, reliability, usability, supportability, portability, accessibility, device compatibility Performance SLAs, response times, usability standards, device coverage Implicit expectations, lack of quantitative benchmarks, inadequate description of how the NFRs will be met ISO/IEC 25010 frameworks, usability testing, operational readiness reviews Chung et al. (2000);Mairiza et al. (2010); ISO/IEC 25010:2011 5. Solution Architecture Conceptual and logical structure of system components and relationships End-to-end description of the solution including technology stack, interfacing system, user access methods, backup and recovery procedures, security model. Undefined system boundaries, conflicting architectural patterns, unclear decision making processes Architecture review boards, reference models, architectural documentation standards Gregor et al. (2006); Zachman (1987) 6. Data Design Data models, data ownership, master data definitions, metadata, and data lifecycle management Data definitions, ownership, lineage, retention, and quality rules. Decisions about data to be migrated to the new system, decisions about how un-migrated data will be handled. Data overlap, inconsistent definitions, unowned data domains and unclear decisionmaking rights related to data, inadequate description of how data will be validated Data governance boards, data dictionaries, master data management policies Khatri & Brown (2010); Otto (2011); Strong et al. (1997) International Journal of Information Sciences and Techniques (IJIST) Vol.15, No.6, November 2025 18 Deliverable Description / Scope What Needs to Be Clear What May Be Ambiguous Mechanisms to Reduce Ambiguity / Increase Clarity Representative References 7. Integration Design Interfaces and data exchanges between systems, APIs, and message flows Integration protocols, data mapping, synchronization frequency Assumed API behavior, missing error-handling design, undefined volumes of data to be interfaced Interface control documents (ICDs), integration testing frameworks, API versioning Barki et al. (2001); Wallace et al. (2004) 8. Testing and Acceptance Criteria Test cases, defect classification, acceptance conditions Acceptance thresholds, UAT ownership, regression scope Disputed quality standards, differing “fit for purpose” views Acceptance criteria templates, thirdparty QA, validation signoffs Wallace &Keil (2004);Lyytinen et al. (1998) 9. Training Deliverables Materials, exercises, and simulations to enable end-user readiness Training scope, role coverage, delivery method Gaps in training coverage, unclear performance expectations Role-based training, learning analytics, feedback mechanisms Aladwani (2001); Prosci (2018) 10. Organizational Change Management Deliverables Change impact assessments, stakeholder engagement, communication plans, adoption measures Change impacts, adoption readiness, engagement responsibilities Misjudged resistance, misaligned communication cadence Stakeholder engagement plans, readiness assessments, change heatmaps Kotter (1996); Armenakis et al. (1999) 11. Project Dependencies Identification and sequencing of related or prerequisite initiatives Dependency list, critical path alignment, ownership Overlooked interdependencie s, timing mismatches Dependency matrices, integrated master schedules, riskadjusted plans Vidal & Marle (2008); PMBOK (2021) 12. Transition and Deployment Plans Migration to production, golive, support handover Go-live criteria, rollback strategies, operational support model Undefined readiness indicators, ownership gaps Simulation runs, stage-gate reviews, postimplementation reviews Nelson (2007); PMI (2021) 13. The IT System Built solution meeting the users needs, which will be at varying stages of completion in different project stages Where the system will be hosted (cloud, on-premises, hybrid), how updates to the build will be applied, how functional and non-functional requirements are achieved Multiple components may make up the whole system and each component may not be clearly defined Hosting model, technical specifications, as-built documents Galster et al. (2013); Bass et al. (2022)