Because public datasets rarely isolate “BA departure” as a standalone variable, this report develops an indicative scenario model grounded in official and peer-reviewed evidence. Under a mid-project departure scenario, incremental cost impact is modelled at roughly 3–7% of budget for well-documented projects, 8–18% for moderately documented projects, and 18–35% for poorly documented projects. Indicative delay ranges from about 1–6 weeks in well-documented contexts to 10–24 weeks on large, poorly documented projects. Those ranges are materially below public “black swan” cases, but they are still large enough to change delivery outcomes, funding decisions, and stakeholder confidence (Boehm and Basili, 2001; Bloch, Blumberg and Laartz, 2012; Shared Services Canada, 2013).

The central managerial conclusion is direct. Replacing the person is necessary, but insufficient. The urgent work is to reconstruct memory, re-establish traceability, revalidate high-risk requirements, and harden governance so that the next departure does not trigger the same institutional amnesia. Organizations that are strongest at knowledge transfer materially improve project outcomes, which is why prevention belongs in operating model design rather than in ad hoc “heroic recovery” after a resignation has already happened (PMI, n.d.; IIBA, 2026; CIPD, 2026).

Introduction
A manager who loses a business analyst during a critical initiative usually says, “We need a replacement.” That is true, but it is strategically incomplete. The more serious loss is not the role-holder but the disappearance of context: why a requirement was framed in a particular way, which stakeholder objection was already resolved, what workaround is tolerated but temporary, which assumption was fragile, why one integration path was rejected, and which acceptance criterion is politically as well as technically important. In other words, the manager has not simply lost labour capacity. The manager has lost the project’s working memory. This is why teams often experience a departure as confusion rather than merely reduced throughput.

Official and empirical sources point in the same direction. PMI reports that nearly half of unsuccessful projects fail to meet goals because of inaccurate requirements management, and that poor requirements management is associated with significant waste, weak validation discipline, and unmet goals (PMI, 2014; Larson, 2014). Shared Services Canada’s synthesis of 19 audit and review reports across five countries concluded that large IT failures are rarely “IT factors” alone; they are more often management and change problems, involving weak governance, inadequate planning, poor business case analysis, scope creep, and failure to understand client needs (Shared Services Canada, 2013). In BA terms, those are all memory problems, because each depends on the preservation and disciplined use of project knowledge over time.

There is also a distinctly human-resource dimension. CIPD notes that high turnover is costly because it creates recruitment cost, training cost, and loss of knowledge, while many organizations still do not calculate the cost of turnover at all (CIPD, 2026). That finding matters here because a project-led resignation is often priced as a vacancy, not as a knowledge-risk event. The result is systematic underestimation. A manager may approve replacement spend while ignoring schedule erosion, stakeholder rework, re-elicitation effort, and latent defect leakage that will surface later as “project issues” rather than “turnover cost.”

Literature review and conceptual model
The intellectual starting point is the distinction between tacit and explicit knowledge. Nonaka and Takeuchi’s knowledge-creation model remains foundational because it explains that organizations do not operate only through documents; they create and mobilize knowledge through recurring conversion between tacit and explicit forms. Tacit knowledge matters precisely because much of what people know is difficult to fully articulate, yet practically decisive in real work (Nonaka and Takeuchi, 1995). In project settings, that means a requirements repository is necessary but never complete. A competent BA often holds crucial tacit content: stakeholder sensitivities, informal decision logic, the reasons behind scope boundaries, and the practical meaning of “done.”

More recent knowledge-transfer scholarship deepens the point. Argote and colleagues show that knowledge transfer affects organizational performance and competitive advantage and that it moves through mechanisms such as social networks, routines, organizational design, search, and personnel mobility (Argote et al., 2022; Argote et al., 2024). That is highly relevant to a BA departure, because analyst knowledge is embedded not only in files but in meeting rhythms, cross-functional trust, escalation routes, and the analyst’s own movement across business and technical domains. Once the knowledge holder leaves, the organization may retain documents but lose the transfer mechanisms that made those documents meaningful.

The turnover literature reinforces this. Galan and colleagues’ systematic review of 91 empirical studies on knowledge loss induced by turnover found wide-ranging effects at organizational and unit level and confirmed that turnover-generated knowledge loss is an established research problem rather than an anecdotal inconvenience (Galan et al., 2023). In software and digital-project environments, Robillard’s study of 27 developers and managers from three organizations found that turnover-induced knowledge loss affects quality and productivity, often forcing teams to reverse engineer prior work, recreate knowledge, or rely on incomplete guidance. Importantly, the study observed that internal transfers can produce knowledge loss comparable to complete departures, and that anticipation of departure materially influences mitigation success (Robillard, 2021).

Requirements engineering standards and bodies of practice supply the operational side of the model. IIBA defines traceability as the ability to track relationships from original stakeholder need through implemented solution, and states that traceability supports change control and assists scope, impact, risk, time, cost, and communication management (IIBA, 2026). ISO/IEC/IEEE 29148 positions requirements engineering as a life-cycle discipline with defined information items and management processes, rather than as a one-time elicitation exercise (ISO, 2018; IEEE, 2018). The implication is straightforward: project memory is not a metaphorical extra. It is the managed relationship structure that keeps business intent connected to delivery reality over time.

The conceptual model below synthesizes this literature. It defines project memory as the interlocking set of objectives, requirements, stakeholder context, decision records, change history, trace links, assumptions, and validation evidence that together preserve the project’s ability to reason consistently about change.

This model matters because it clarifies where setbacks really occur after a BA departs. The visible issue is a vacancy. The real issue is severed linkage. Once the linkages between business objective, requirement, rationale, owner, change history, and test evidence weaken, the team becomes slower at judging impacts, weaker at defending scope, and more vulnerable to late-stage surprises. That is why “project memory” is the more analytically useful term than “documentation.” Documentation is one repository. Memory is the living structure that makes the repositories coherent (Nonaka and Takeuchi, 1995; IIBA, 2026; Argote et al., 2022).

Empirical evidence and modelled impact
The empirical evidence is strongest when viewed across countries and source types. In Canada, Robillard’s McGill-based study documents how knowledge loss reduces delivery speed and forces teams into rediscovery. In Finland, Lehtinen and colleagues’ multi-case analysis of four failed software projects identified between 130 and 185 causes per failed project, with roughly half classed as “bridge causes,” linking multiple process areas. Common bridge causes included weak backlog discipline and lack of cooperation, which is exactly what one would expect when analytical context becomes fragmented (Lehtinen et al., 2014). In Canadian federal practice, Shared Services Canada found that weak project management produces long delays, large cost overruns, scope creep, and lack of clear criteria for work considered complete, while failure to understand client needs can directly undermine success (Shared Services Canada, 2013). The convergence across these sources is important: the problem is not local, sector-specific, or merely anecdotal.

Industry evidence shows the upper bound of what happens when memory loss is left to accumulate. McKinsey, drawing on more than 5,400 IT projects, reported that large IT projects ran on average 45% over budget and 7% over time while delivering 56% less value than predicted; every additional year increased cost overruns by 15%, and 17% of projects became “black swans” severe enough to threaten the organization (Bloch, Blumberg and Laartz, 2012). Public reports supply vivid examples. The Queensland Health Payroll System Commission of Inquiry found that the project’s contract price rose from AUD 6.9 million to AUD 25.7 million, the system cost more than four times the contract price paid to IBM alone, and delivery took three times longer than originally scheduled. Even after stabilization, the system required about 1,000 employees to process payroll data and was estimated to cost about AUD 1.2 billion over eight years (Chesterman, 2013). These cases are not “BA departure cases” in a narrow sense, but they show the tail risk when requirements context, governance discipline, and decision continuity all degrade together.

The FBI’s failed Virtual Case File provides a related governance lesson. In the follow-on Sentinel programme, GAO emphasized performance standards for contractor work, high-quality schedule and cost estimation, and a historical lessons-learned database that should be used when creating estimates (GAO, 2007). That recommendation is effectively an institutional-memory control: future work should inherit the structured knowledge of prior work rather than relearn it through failure.

Because direct public data on the isolated effect of “a BA resignation at week X” are scarce, the financial and timeline estimates below are modelled, not observed averages. The model assumes a mid-project departure around 45% completion; a replacement BA or interim consultant is identified within one to three weeks; the recovery effort includes stakeholder revalidation, traceability repair, and selective rework; and documentation quality is the principal moderator. The outer bounds are informed by the literature on avoidable rework, downstream defect cost, requirements failure, and turnover-induced rediscovery. Boehm and Basili estimate that current software projects spend about 40–50% of effort on avoidable rework, and that late defect correction is often much more expensive than early correction. PMI reports that poor requirements management is associated with major waste and unmet goals, while Robillard shows that reverse engineering and knowledge recreation directly slow delivery (Boehm and Basili, 2001; PMI, 2014; Robillard, 2021).

Assumptions used in the scenario tables. All illustrative dollar values are shown in CAD. To make the project-size bands operational, the examples use reference budgets of CAD 150,000 for a small project, CAD 1.5 million for a medium project, and CAD 10 million for a large project. Reference durations are 20, 40, and 78 weeks respectively. These are modelling anchors within the user-specified size bands; actual impacts scale approximately linearly with budget and non-linearly with schedule complexity. The model is deliberately conservative relative to extreme failure cases and should be read as the likely impact after the organization succeeds in finding a replacement BA, not the cost of a total programme collapse. The assumptions are anchored in the literature cited above and bounded against McKinsey’s large-project data and official inquiry findings.

These ranges are author estimates derived from the literature on avoidable rework, requirements-management failure, and turnover-induced knowledge loss, and should be used as planning ranges rather than as universal benchmarks.

These examples use the reference budgets and durations stated above. For projects materially more complex than the reference large case, or for regulated multi-vendor environments, the upper tail can exceed these ranges, as public-sector inquiries and black-swan research show.

The most important practical insight from the model is that documentation quality changes the economics more than project size alone. A small poorly documented project can lose proportionally more time than a much larger well-documented one, because short projects have less slack and fewer opportunities to absorb rediscovery. Conversely, large projects accumulate greater absolute cost because stakeholder alignment, interface complexity, and the number of dependent artefacts all rise with scale. In both cases, the departure amplifies existing governance quality rather than creating an entirely new problem. The manager should therefore read the event as a diagnostic of process maturity, not simply as bad luck.

Diagnostic checklist and recovery actions
The first managerial task is triage. The right question is not “How fast can we hire?” but “How much of the project’s memory is still reliable?” A strong diagnostic should establish whether the team can still answer five questions without the departed analyst: what problem the requirement solves, who approved it, what alternatives were rejected, what changed since approval, and how delivery or testing proves the requirement has been met. If the team cannot answer those questions quickly, you are in a memory-reconstruction exercise, not a normal replacement cycle. That distinction matters because issue logs, schedules, and staffing plans all need to be recalibrated immediately (IIBA, 2026; PMI, n.d.).

In practical terms, the highest-priority actions are these. First, freeze non-essential requirement churn for a short but real window, normally five business days. A project that keeps changing while it is reconstructing memory is compounding ambiguity. Second, form a recovery cell that includes the project manager, sponsor delegate, technical lead, QA lead, and replacement or interim BA. Third, produce an artefact inventory and mark each item green, amber, or red for reliability. Fourth, rebuild a decision ledger for the top twenty risk-bearing requirements, interfaces, and assumptions. Fifth, reconstruct or repair the traceability matrix for those items before full delivery resumes. Sixth, conduct a re-baseline conversation with the sponsor that explicitly distinguishes staffing delay from knowledge-recovery delay. Seventh, log “knowledge concentration risk” as a named project risk going forward, with treatment actions and an owner. These are not bureaucratic extras; they are the minimum actions that separate controlled recovery from accidental drift (IIBA, 2026; PMI, 2014; Shared Services Canada, 2013).

Governance and prevention
The long-term lesson is simple: if a project can lose its memory when one person leaves, it was under-governed before the resignation occurred. Standards and official practice all point toward the same remedy. ISO/IEC/IEEE 29148 treats requirements engineering as a life-cycle process with defined information items; IIBA positions traceability and requirements maintenance as continuous disciplines; PMI emphasizes that lessons learned need to be relevant and retrievable; and PMI’s knowledge-transfer research reports that organizations most effective at knowledge transfer improve project outcomes by nearly 35% (ISO, 2018; IIBA, 2026; PMI, n.d.). Prevention therefore requires process design, not motivational slogans.

A resilient governance model should set a minimum viable memory standard for every project. At a minimum, that standard should require a live business context pack, current stakeholder map, decision log, assumptions and dependencies register, traceability matrix, agreed acceptance criteria, and a short change-history narrative for major scope shifts. The strongest organizations do not wait for a project close-out to capture this material. They maintain it as a delivery asset. PMI’s knowledge and lessons-learned guidance is explicit that documented learning is only useful if it is retrievable and reused; otherwise it becomes archival decoration rather than operating capability (PMI, n.d.).

Decision records deserve special emphasis. Lightweight Architecture Decision Records, as advocated by Thoughtworks and Martin Fowler, are useful because they capture one important decision, its context, and its consequences in a compact, reviewable form (Fowler, 2026; Thoughtworks, 2016). In BA-heavy work, the same principle can be applied beyond architecture: major scope, policy, integration, and acceptance decisions should be logged with source, rationale, alternative options considered, and downstream effect. This is the best antidote to the familiar project disease in which everyone remembers that a choice was made, but nobody remembers why.

Traceability must also be treated as a living control, not as a compliance artefact. IIBA explicitly links traceability to scope, impact, change, risk, time, cost, and communication management. That makes it one of the few practices that simultaneously protects delivery discipline and onboarding speed. When a replacement BA can follow an auditable trail from business objective to requirement to test evidence, recovery is faster because the project is understandable without relying on one person’s oral history. Where traceability is absent, the organization is forced back into workshops, email archaeology, and stakeholder memory contests. That is expensive, slow, and politically brittle (IIBA, 2026).

Finally, prevention must include workforce design. CIPD notes both the negative performance impact of turnover and the fact that many organizations still do not calculate turnover cost. That should change. Every significant project should maintain a simple knowledge-risk view: where the analyst single points of failure are, how many critical decisions are undocumented, what proportion of priority requirements have current owners and acceptance criteria, and how long it would take for a new analyst to become productive. If those indicators are poor, the project is already carrying hidden schedule risk. In strategic terms, the best time to insure against project-memory loss is before anyone resigns.

Limitations and research gaps
The evidence base is strong on turnover-induced knowledge loss, requirements-management failure, and large-project underperformance, but it is weaker on business analyst departure as an isolated variable. Most peer-reviewed studies examine software contributors, project teams, or project-based organizations more broadly. Public inquiries usually report on failed programmes rather than on the immediate causal contribution of a specific BA exit. That means causal attribution must be made carefully. The mechanism is well supported; the exact marginal effect for any given sector, methodology, or regulatory setting is not yet pinned down by a dedicated longitudinal dataset (Galan et al., 2023; Robillard, 2021; Lehtinen et al., 2014).

The scenario estimates in this paper are therefore planning estimates, not actuarial guarantees. They assume a mid-project departure, reasonably prompt replacement, and partial rather than total institutional failure. They do not explicitly model regulated validation cycles, procurement delay, labour-market scarcity, or multi-jurisdictional approval overhead. In high-complexity contexts, the upper tail may be materially worse, as McKinsey’s black-swan findings and public-sector inquiries indicate. More Canadian empirical research focused specifically on BA turnover, requirements continuity, and recovery time would materially improve managerial forecasting.

Conclusion, appendix, and Requirementum QGR
Conclusion. The strongest conclusion from the literature and the official record is that a BA departure is not mainly a recruiting problem. It is a project-memory failure that exposes whatever was already weak in governance, requirements practice, and knowledge transfer. Managers who respond only by filling the seat may stabilize headcount while leaving the real damage untreated. Managers who respond by reconstructing decision history, repairing traceability, revalidating critical requirements, and institutionalizing memory controls are far more likely to recover schedule credibility and avoid repeated loss. The practical test is simple: if the project can still explain itself coherently after one analyst leaves, its memory is institutional. If it cannot, the project has been depending on personal memory all along.

Requirementum QGR. For positioning purposes, Requirementum’s QGR services can credibly be framed as a rapid project-memory recovery and governance-restoration offer. In this situation, the value proposition is not merely “we can supply a BA.” It is “we can reconstruct analytical context, restore requirements traceability, re-establish stakeholder alignment, rebuild decision discipline, and leave behind stronger project-memory controls than the project had before the disruption.” That is the commercially attractive distinction senior managers actually care about when timelines are under threat.

REFERENCES
Argote, L., Guo, J.M., Park, S.-S. and Hahl, O. (2022) ‘The mechanisms and components of knowledge transfer: The virtual special issue on knowledge transfer within organizations’, Organization Science, 33(6), pp. 2165–2180.

Argote, L., Fahrenkopf, E. and others (2024) ‘Knowledge transfer within organizations: Mechanisms, motivation, and consideration’, Annual Review of Organizational Psychology and Organizational Behavior, 11.

Bloch, M., Blumberg, S. and Laartz, J. (2012) ‘Delivering large-scale IT projects on time, on budget, and on value’, McKinsey Quarterly, 1 October.

Boehm, B.W. and Basili, V.R. (2001) ‘Software defect reduction top 10 list’, Computer, 34(1), pp. 135–137.

Chesterman, R.N. (2013) Queensland Health Payroll System Commission of Inquiry Report. Brisbane: Queensland Government.

CIPD (2026a) Employee turnover and retention. London: Chartered Institute of Personnel and Development.

CIPD (2026b) Retention guidance for people professionals. London: Chartered Institute of Personnel and Development.

Fowler, M. (2026) ‘Architecture decision record’. martinfowler.com.

GAO (2007) Information Technology: FBI Following a Number of Key Acquisition Practices on New Case Management System but Improvements Still Needed (GAO-07-912). Washington, DC: U.S. Government Accountability Office.

Galan, N., Sandberg, J. and von Krogh, G. (2023) ‘Knowledge loss induced by organizational member turnover: A review of empirical literature, synthesis, and future research directions (Part I)’, The Learning Organization, 30(2), pp. 117–135.

IIBA (2026a) ‘Understanding requirements and designs’. The Business Analysis Standard. Toronto: International Institute of Business Analysis.

IIBA (2026b) ‘Requirements life cycle management’. BABOK Guide KnowledgeHub. Toronto: International Institute of Business Analysis.

IEEE (2018) IEEE/ISO/IEC 29148-2018: Systems and software engineering—Life cycle processes—Requirements engineering. Piscataway, NJ: IEEE Standards Association.

ISO (2018) ISO/IEC/IEEE 29148:2018 Requirements engineering. Geneva: International Organization for Standardization.

Lehtinen, T.O.A., Mäntylä, M.V., Vanhanen, J., Itkonen, J. and Lassenius, C. (2014) ‘Perceived causes of software project failures—An analysis of their relationships’, Information and Software Technology, 56(6), pp. 623–643.

Nonaka, I. and Takeuchi, H. (1995) The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation. New York: Oxford University Press.

PMI (2014a) Requirements Management: Core Competency for Project and Program Success. Newtown Square, PA: Project Management Institute.

PMI (2014b) ‘I still don’t have time to manage requirements: My project is later than ever’, paper presented at PMI Global Congress 2014—North America.

PMI (2022) ‘Cost of change on software teams’. Disciplined Agile.

PMI (n.d.-a) ‘Lessons learned’. Newtown Square, PA: Project Management Institute.

PMI (n.d.-b) ‘Capturing the value of project management through knowledge transfer’. Newtown Square, PA: Project Management Institute.

Robillard, M.P. (2021) ‘Turnover-induced knowledge loss in practice’, in Proceedings of the 29th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, pp. 1292–1302.

Shared Services Canada (2013) What Prevents Large IT Projects from Being Successful? A Synthesis of Common Risk Factors and Lessons Learned. Ottawa: Government of Canada.

Thoughtworks (2016) ‘Lightweight architecture decision records’. Technology Radar.