Why Digital Transformation Demands a New Kind of Project Leader
To the Digital Transformation Project Manager
If you are a Digital Transformation Project Manager, you were trained the same way as every other project manager. You sat through the same curricula, studied the same frameworks, and earned the same credentials. PMP, PRINCE2, SAFe, and their equivalents have developed a global system to train project professionals to competently apply best practices.
Those credentials work well in environments where the scope is understood and well defined before work begins, the deliverable can be clearly assessed at completion, and the success criteria remain stable throughout the program lifecycle. Examples include construction, infrastructure, and product development with well-defined specifications. In those domains, rigorous methodology training and certification are precisely what the role requires.
Digital transformation is not one of those domains. The organization asking you to lead a transformation program is placing you in conditions that the standard credential and training system was not designed to address. The deliverable is ultimately organizational change through technology, not a physical asset or a working software release. Even when the change is articulated at inception, it rarely occurs as expected. It cannot be observed at technical completion and cannot be governed with the tools the methodology provides. The mandate of a DX initiative is categorically different from a traditional one.
Organizations that engage in a DX initiative are hiring project managers whose formal preparation is insufficient for the challenges it presents. Neither party has the language or awareness to name this mismatch. This paper examines this gap and offers a more accurate model for the role.
SECTION 1
The Role and Its Structural Contradictions
1.1 What the DX PM Is Asked to Do
The scope of the DX PM role has expanded significantly over the past decade. PMI’s 2025 Pulse of the Profession describes project professionals as needing to evolve from tactical troubleshooters into strategic value creators, who can operate at the intersection of business acumen, stakeholder influence, and organizational outcomes. [5] A 2025 systematic review of 66 peer-reviewed articles confirmed that DX programs require behavioral, strategic, and institutional changes extending well beyond technical deployment. The PM is expected to manage a living system of competing priorities, shifting organizational requirements, human resistance, and political dynamics, while carrying the formal accountability of a delivery owner. [7]
Standard project management credentials develop the skills required for the tactical role. They fall short in supporting the strategic one. The gap between what the credential system trains for and what DX delivery demands is the structural starting point for everything that follows.
1.2 An Undefined Role
The shared definition of the DX PM role is not a consideration before work begins. This is the first structural problem the practitioner encounters, and it is fundamental.
In most organizations, the criteria for selecting and assigning a DX PM are not formally established. Research on project selection in digital transformation is reasonably developed; organizations have frameworks for deciding which initiatives to fund. The criteria for matching a PM to those initiatives are largely absent from the literature, which itself signals the question is not being asked rigorously. Peter Carr’s Digital Transformation Project Management Assessment Tool, developed through the University of Waterloo’s Watspeed Program, notes that the selection of PMs for DX programs often fails to consider the capability requirements that DX work demands. [21]
In practice, organizations list capabilities associated with senior business and technology leadership when posting for DX PM roles: executive influence, conflict management, strategic thinking, and negotiation. These are the skills of a change leader. But job descriptions are written to attract candidates, not to define authority. The actual PM role is typically structured as a coordinator in a matrix organization, with no budget control, no direct reports, and no formal seat at the governance table. The people writing the job description and the people who designed the role structure are not the same; the posting describes what the organization wishes the PM to do. The structure determines what they are empowered to do. The two are rarely reconciled before the assignment is made. [7][4]
The result is a role with full accountability and an assumed scope of authority that nobody has formally granted. PMI’s own research on project success factors consistently shows that effective executive sponsorship (active participation, sufficient authority, and clear decision rights granted to the PM) is one of the strongest predictors of project outcomes. [4][15]
When that sponsorship is absent or nominal, the PM absorbs the resulting vacuum, taking on decisions and consequences that belong to the governance layer above them, without that expansion ever being named or agreed to.
Without a defined boundary, the PM defaults to full accountability. That is the mechanism behind the PM’s over-functioning behavior.
1.3 Where the Role Sits in the Organization
Most DX programs operate through matrix organizational structures, in which the project manager coordinates resources who report to functional department heads. The people the DX PM depends on for delivery, including technical staff, business analysts, change management resources, and process owners, are borrowed. They are not under the PM’s authority.
Research on PMO participation in digital transformation documents this tension. Project managers are expected to function simultaneously as integrators of a broader organizational vision and as service providers operating within a traditional hierarchy. These two roles are structurally incompatible in organizations that have not redesigned their governance to accommodate cross-functional programs. [8]
When priorities shift, borrowed resources return to their functions. When decisions stall at the executive level, the PM cannot compel resolution. The role sits at the intersection of the demand for delivery and the organizational conditions that enable it.
SECTION 2
An Unrecognized Professional Population
2.1 The DX PM Is Assumed to Belong to the General PM Category
Project management research has accumulated substantially over the past three decades. There is rigorous literature on PM burnout, authority gaps, stakeholder management, role ambiguity, and professional resilience. The research is substantive, and the findings are relevant.
When you search for studies focused on DX PMs, the literature is empty. There are no dedicated surveys of the DX PM experience. There are no longitudinal studies of how DX PM careers unfold. There are no comparative studies of what distinguishes DX PMs who remain effective from those who burn out or leave the field.
The project management field has not recognized that the DX PM role is a distinct category warranting its own research. The assumption is that a project manager in digital transformation faces the same conditions and is subject to the same success factors as a project manager in any other domain. This paper argues that the assumption is wrong.
2.2 What Makes DX Structurally Different
The distinction is not about complexity. Construction megaprojects are complex. Infrastructure programs are complex. It is about the nature of the deliverable and what that means for how the work can be structured, measured, and declared complete.
A construction PM delivers a physical asset with defined specifications. Requirements are established before ground is broken. Completion is unambiguous. Scope change is costly and visible.
The DX PM is delivering an intangible structure that has not been clearly designed before delivery begins. The false assumption, embedded in most programs, is that the structure being built is the technology itself, the hardware, and the software. It is not. The real structure is a new model of working: an upgrade in behaviors, skills, talent, business processes, and workflows. These elements are broadly understood in concept but loosely defined in practice. They are the organizational and behavioral requirements that underpin the technical ones, and they cannot be assessed at go-live. [9][10]
The DX PM performance is measured against technical completion metrics: milestones, budget, and go-live date. Technical completion, however, does not equal transformation. Go-live can be declared while nothing has changed in how people work. [9] At technical completion, the PM is off-boarded. The gap becomes visible in the organization’s performance later.
2.3 What the Absence of Data Means
The research gap on DX PMs is not a neutral observation. It reflects a failure to recognize that the people most directly exposed to the structural failure of digital transformation have a distinct enough experience to warrant dedicated study.
General PM burnout data exists and is relevant. General PM authority-gap research exists and is relevant. However, using that data to describe the DX PM experience is equivalent to using a construction worker’s injury data to describe the risk exposure of deep-sea welders. The surface category is the same. The structural conditions are not.
DX PMs are compared to peers who work in domains with different structural conditions. When they struggle, the default interpretation is that the problem is competence.
This paper establishes the argument for why that gap exists, documents what the DX program outcome research implies about practitioner experience, and names the absence of data as a problem the field has not addressed. The evidence does not exist. That is the point.
The absence of dedicated research on DX PMs as a distinct professional population is not a gap in the literature. It is evidence that the field has not yet recognized the category. That recognition is part of what this paper is attempting to establish.
SECTION 3
Four Persistent Challenges
The challenges below are persistent because they are embedded in the structural conditions of how DX programs are organized, governed, and resourced. They are grounded in DX program outcome research and in project management literature, where the structural conditions described are directly applicable to digital transformation initiatives. They do not represent the full range of difficulties in the role, but the ones with the most consistent evidence base and the most direct connection to the structural properties of DX work.
How the PM Enters the Work
A project manager trained in traditional best practices enters every new DX program with what the credential system taught them.
They build the foundation, identify stakeholders, map dependencies, and establish the baseline against which progress will be measured. This is professional practice applied correctly. At this stage, nothing feels unusual.
As the PM builds out the plan and reaches out to fill the gaps, a fracture appears. The structure they were handed at initiation does not fully reflect reality. The sponsor is too busy to respond, stakeholders are unclear about their role, and the assumed alignment was never confirmed.
Reality unfolds during execution. An executive raises a concern that signals a fundamentally different understanding of the program’s objective. End users raise questions that indicate they were never consulted. Competing agendas emerge at the stakeholder level. Scope assumptions that seemed settled are challenged.
The PM responds the way they were trained: close the gaps, chase the decisions, keep the program moving. They work harder. They absorb more. They make assumptions when clarity is unavailable, because the alternative is paralysis.
This is the terrain where the four challenges operate. The DX PM adapts to these challenges, the best they can with the tools and knowledge they have. What they often miss is an underlying and unfamiliar kind of tension and discomfort that signals something different from business as usual. A sense of limited control, of uncertainty, of unfamiliarity, a sense that they’re lacking something, but they’re not sure what it is.
Challenge 1: Accountability Without Authority
The Structural Condition
The DX PM takes on accountability for program outcomes by default, not by formal designation. The levers that determine those outcomes, including budget authority, resource allocation, executive decision-making, vendor compliance, and stakeholder prioritization, sit elsewhere. In matrix organizations, this is the default structural arrangement.
PMI’s own library acknowledges that project managers state that they lack the authority to direct the teams they lead. This gap is structural, not incidental: in matrix environments, the PM coordinates people who do not report to them, in programs that require sustained cross-functional cooperation, without the formal leverage to compel it. [19]
In DX environments, this gap is amplified because the required scope of cooperation spans more hierarchies over a longer duration. A 2024 study of project managers in weak-matrix organizations found that unclear role and responsibility boundaries produce ongoing anxiety about decision-making authority. Project managers in these environments describe second-guessing decisions, navigating power struggles with functional department heads, and absorbing consequences that belong to the governance layer above them. [14]
The Consequence
Role ambiguity, including uncertainty about the actual scope of one’s authority, shows a moderate-to-high correlation with the exhaustion and reduced personal accomplishment dimensions of burnout. [12][13] The PM experiences reluctance to escalate in some cases because escalation feels like failure, stress about making decisions they are privately uncertain of, and fatigue that does not resolve after rest. [27]
The specific pattern documented is over-functioning: taking on decisions that are not theirs to make, absorbing consequences that belong to governance, and investing sustained effort in situations where structural conditions rather than execution quality determine the outcome.
Challenge 2: The Alignment Illusion
The Structural Condition
Gartner’s 2024 CIO and Technology Executive Survey, drawing on responses from more than 3,100 CIOs and 1,100 executive leaders, found that only 48 percent of digital initiatives enterprise-wide meet or exceed their business outcome targets. [2] PMI’s 2025 Step Up report identified the strategy-execution gap as the primary obstacle to transformation success, cited by 35 percent of senior executives. [4]
DX programs commonly begin with a shared narrative: executives, business units, technology teams, and vendors appear to agree on objectives, timeline, and expected outcomes. That alignment is typically declared at kickoff but rarely holds through the transition to active delivery.
Programs are approved by executives based on strategic rationale. However, they are scoped by technology teams based on system capabilities. They are delivered by project teams managing requirements. And are experienced by business users living in the impact zone. These four groups are solving different problems simultaneously and calling it the same program. Research on digital transformation identifies the underlying cause as a cognitive model gap: The misalignment between the mental models experienced leaders use to make decisions and the logic that digital transformation requires. [8] The DX PM is the person formally responsible for holding this in a coherent relationship without the authority to resolve it.
The Consequence
The PM absorbs the friction produced by parties with materially different interests and perspectives as their personal workload: repeated re-scoping conversations, competing revision requests, and escalations that resolve nothing structurally. For the PM, this produces a growing sense that they are spinning their wheels and exerting unnecessary effort to hold things together and keep the program on track. Decision latency accumulates against the PM’s delivery commitments while the authority to compel decisions rests with others.
The alignment problem is not a communication failure the PM can solve with better meeting facilitation. It is a governance failure that places the cost of irreconcilable expectations on the person with the least authority to resolve them.
Challenge 3: The Methodology Mismatch
The Structural Condition
The 2025 systematic review of 66 peer-reviewed articles found that traditional project management approaches, often linear and control-focused, are structurally ill-suited to the ambiguity and interdisciplinary demands of digital transformation. Methodology-organization misalignment, methodology-people misalignment, and methodological tensions were the primary friction points identified. [7]
Agile methodologies, often cited as a potential alternative, were developed to address complexity and iterative uncertainty. Their iterative, adaptive structure helps when requirements emerge during delivery. However, agile addresses how work is executed. It does not address the organizational ambiguity about what the work is for, what success means, and who is authorized to decide. That is a different problem, and it is the one DX programs consistently encounter. [7]
PMI’s global Pulse of the Profession survey found that 52 percent of projects experienced scope creep or uncontrolled changes to project scope. A figure that had risen from 43 percent five years prior. [16] In DX programs, scope instability typically reflects the normal process by which organizational and behavioral requirements become clearer during delivery, a process that no existing governance structure is designed to accommodate cleanly.
The Consequence
The PM arrives with the right credentials and applies them correctly. The methodology still does not fit the environment. The gap between what the tools can govern and what the program requires falls on the PM to manage without a clear framework to guide their decisions. Over time, that gap erodes confidence in professional instincts that are, in fact, sound.
Challenge 4: Boundary Spanning Without Organizational Support
The Structural Condition
The project manager’s role in complex programs has been characterized in the research literature as that of a boundary spanner: a person who operates between multiple organizational units, stakeholder groups, and institutional logics, translating requirements, managing relationships, and maintaining coherent progress across domains that do not share the same priorities or language. [8][17]
Research on boundary-spanning roles documents two consistent structural stressors: role conflict, from having to satisfy stakeholders with competing objectives simultaneously, and role ambiguity, due to the absence of clear criteria with which their performance will be assessed. Both are amplified when the boundary spanner lacks organizational support. Studies on boundary spanning in public-private infrastructure projects found that without adequate organizational support, boundary spanners experience high levels of role stress, with direct consequences for job satisfaction. [17][18]
The DX PM spans more boundaries than almost any other project management role: between executive strategy and operational delivery, between technical teams and business users, between the organization’s current state and the future state the program is meant to create, and between vendor delivery obligations and organizational adoption requirements. This work often runs throughout a multi-year program.
The Consequence
The research on boundary spanning consistently finds that the absence of organizational support is a direct predictor of role stress and job dissatisfaction. [17] The practical consequence is the gradual erosion of the PM’s ability to distinguish between what is structural (out of their control) and what is personal, a distinction that is foundational to professional sustainability in this role. What the PM experiences is a functional isolation: the difficulty of getting information, timely decisions, and the cooperation the role requires from the people who hold them, a growing uncertainty about who the right person is for a given escalation, and diminishing confidence that the executive layer is aligned with where the program is actually going.
The DX PM is not trained to be a strategist, a negotiator, a politician, and a translator simultaneously. The role, as it exists in most organizations, requires all four. The absence of structural support for this reality is a gap in the role design, not a problem with the practitioner.
SECTION 4
The Cumulative Personal Cost
4.1 Burnout as a Structural Outcome
Burnout is classified in the International Classification of Diseases (ICD-11) as an occupational phenomenon resulting from chronic workplace stress that has not been successfully managed. It is characterized by overwhelming exhaustion, cynicism, and detachment from work, and a diminished sense of personal effectiveness. [12][25]
The conditions that produce burnout are present in the structural analysis above. Role ambiguity and accountability without authority produce the exhaustion dimension. Sustained exposure to declared success that does not reflect actual organizational change produces the cynicism dimension. Repeated effort against structural conditions that execution quality cannot fix produces the reduced personal accomplishment dimension. These are documented outcomes of specific structural conditions, not individual reactions to difficult work.
No studies have measured burnout rates among DX PMs. However, the DX program outcome data, taken together with the burnout studies, imply a practitioner environment where the preconditions for burnout are structurally embedded rather than incidental.
4.2 The Professional Discernment Gap
These challenges collectively produce a specific professional erosion: the practitioner who loses the ability to distinguish between what is within their control and what is not. When accountability is total and authority is partial, when alignment is declared but not real, and when program outcomes are absorbed as personal events, the practitioner loses the diagnostic clarity to assess their own performance accurately.
That clarity is the foundation of professional sustainability in a structurally demanding role. The following section offers a model for recovering and maintaining it.
SECTION 5
A Model for Navigating What is Not Measured
The four challenges documented in this paper are structural. The research establishes it clearly. What the research cannot do, because the data does not exist, is describe what it means for a practitioner to operate in these conditions with situational awareness rather than without it.
The following framework is a perspective, grounded in the structural analysis outlined in earlier sections and in the reality of what transformation programs demand. Its purpose is not to prescribe behavior but to offer a model for thinking about the role with more precision than the standard credential and training system provides.
5.1 Three Variables, One Environment
Three factors interact to determine how navigable a project environment is for the practitioners inside it: ambiguity, complexity, and the uncertainty these parameters produce together.
Complexity is the number of interacting parts, dependencies, and stakeholders. It can be significant, but still manageable, given the right tools and experience. Sophisticated planning, modular delivery, and distributed coordination all address complexity effectively.
Ambiguity is something different and more corrosive. It is the absence of shared meaning among the actors involved: different stakeholders holding fundamentally different mental models of what the program is, what success looks like, and who is responsible for what. Ambiguity cannot be addressed with a Gantt chart or a risk register. It requires the parties involved to construct a shared understanding, which is a social and political process. Not a planning one.
Uncertainty is what ambiguity and complexity produce together. In a low-ambiguity environment, even high complexity generates bounded uncertainty: the system is complicated, but the direction is shared, so unknowns can be scoped, planned against, and managed. In a high-ambiguity environment, uncertainty compounds. When nobody fully agrees on what is being built or why, and when the system has many interacting parts, the future becomes genuinely opaque. It is not because of poor planning, but because the inputs to planning are unstable.
Standard PM tools address uncertainty downstream: risk registers, contingency plans, scenario analysis. They do not address ambiguity, which is the upstream cause. That is the structural reason why DX programs consistently overwhelm the methodology systems applied to them.
Projects do not fail because they are complex. They fail because the situation becomes illegible to the people trying to navigate it. Complexity is manageable when actors share a mental model. Ambiguity, when it is high, dissolves that shared model regardless of how capable those actors are individually.
5.2 Three Categories of Project Professional
If situational legibility describes the environment, different levels of legibility demand different kinds of practitioners. The PM who is well prepared with standard credential programs excels in a high-legibility environment. Placing them in a low-legibility environment without proper preparation is not a talent problem. It is a category error.
The three environments are mapped using what this paper calls the “Situational Legibility Index”TM, or SLITM. The SLI is a term introduced here for the first time. It does not correspond to an existing framework, measurement tool, or published instrument. The name is deliberate: legibility describes precisely what practitioners lose when ambiguity is high: the ability to read the situation accurately enough to act on it. The SLI is a conceptual scale for locating a project environment, not a scoring instrument. It is introduced to give practitioners and organizations a shared language for a distinction that the field has not yet named.
What follows are three categories of PM, each corresponding to a level of situational legibility. Each is described along three dimensions: the required skill stack, the stance the PM must adopt in the work and with the people around them, and the human capabilities that determine whether the PM can sustain effectiveness in that environment. The archetype labels draw on the Jungian tradition of twelve archetypes, a well-established framework in organizational psychology for describing the characteristic orientation a person brings to their role. [26]
The table below presents a simplified view of how the three variables interact across the SLI. This is a conceptual model, not a scoring instrument.
| Ambiguity | Complexity | Uncertainty Produced | Situational Legibility |
| Low | Low | Low | High |
| Low | High | Moderate | Moderate |
| High | Low | High | Low |
| High | High | Very High | Very Low (Opaque) |
| Category 1: The Delivery Manager Archetype: The Ruler | Environment: High Legibility | |
| Environment | High situational legibility. Construction, infrastructure, hardware delivery. Requirements are well established before work begins. The deliverable is physical and observable. Completion criteria are unambiguous. |
| Skill stack | Scope definition, scheduling, cost control, risk registers, contract management, vendor coordination, formal change control. The full body of standard PM methodology applies and performs well here. |
| Stance | The Ruler archetype commands order, establishes structure, and drives toward defined outcomes through authority and discipline. The PM’s value is in discipline and control. The methodology frameworks PMs are trained in are, in essence, Ruler tools. |
| Human capabilities | Precision, methodical attention, follow-through, composure under pressure, the ability to hold multiple dependencies in mind simultaneously. These are strengthened by structured experience and are well-served by standard certification. |
| Category 2: The Adaptive Manager Archetype: The Creator and Explorer | Environment: Medium Legibility | |
| Environment | Medium situational legibility. Product development, IT projects, agile delivery. Some requirements are known; others emerge. The destination is understood; the path adjusts. |
| Skill stack | Agile frameworks, iterative planning, backlog management, stakeholder engagement, hybrid methodology design. The PM works within defined sprints toward an evolving but bounded destination. |
| Stance | The Creator builds through iteration rather than blueprint. The Explorer advances without a complete map, adjusting as terrain reveals itself. Together they describe the adaptive PM who generates value through discovery as much as execution. Authority is shared; value comes from maintaining rhythm and removing friction. |
| Human capabilities | Tolerance for iteration, comfort with incomplete information, the capacity to hold direction loosely while maintaining forward momentum. The ability to distinguish productive ambiguity from unproductive confusion. These can be developed through experience in adaptive environments. |
| Category 3: The Transformation Navigator Archetype: The Magician and Sage | Environment: Low Legibility | |
| Environment | Low situational legibility. Digital transformation and large-scale organizational change. Ambiguity is high, requirements are emergent, success criteria shift, and the deliverable is intangible, defined by changes in behavior rather than technical specifications. Uncertainty is at its highest because both ambiguity and complexity are maximized simultaneously. |
| Skill stack | All of Category 1 and Category 2, plus: stakeholder influence without formal authority, signal reading across organizational layers, political navigation, organizational behavior literacy, change management principles, business acumen at the strategy level. The skill stack is the largest. Standard certification covers the smallest proportion of it. |
| Stance | The Magician’s domain is transformation: making things happen in conditions where cause and effect are not linear, seeing patterns others cannot see, working in the space between what exists and what needs to become. The Sage brings accumulated knowledge, the ability to name what others sense but cannot articulate, and pattern recognition under sustained complexity. Together, they describe what Category 3 demands. The Navigator is not executing a plan. They are maintaining direction in a situation where the terrain, the destination, and the people involved are all changing simultaneously. |
| Human capabilities | Tolerance for sustained ambiguity without premature resolution. The ability to hold contradictions without collapsing them into false clarity. Pattern recognition under incomplete information. The capacity to make visible what others in the system cannot see. The willingness to deliver unwelcome signals to people with more formal authority, without aggression and without capitulation. These are not learned in certification programs. They are developed through experience, reflection, and deliberate practice. In Nassim Taleb’s terms, it’s antifragility: not merely the ability to survive turbulence, but the capacity to develop and grow stronger through it. [11] Each difficult program, navigated with keen awareness, yields new pattern recognition, new signal-reading precision, and new understanding of where organizational dysfunction lives. The Category 3 PM comes out of each program with capabilities they did not have going in. That is a different proposition entirely from resilience. |
5.3 The Categorization Problem
Organizations hire Category 1 and Category 2 practitioners, apply Category 1 and Category 2 evaluation criteria, and place them in Category 3 conditions. When the practitioner cannot navigate effectively, the organization interprets it as a competence failure. The practitioner often interprets it the same way. Neither party has the language to name what happened.
The practitioner who locates themselves in Category 3 with awareness gains something specific: an accurate description of the terrain, and a model for what that terrain demands. Not a prescription. An orientation. A different way to step into the role before the program begins.
The Category 3 project manager who operates with that awareness enters their next program differently. They know the credential system did not fully prepare them for that environment. They know ambiguity is the primary threat, not complexity. They know their value is not only in executing a plan, but also in maintaining orientation throughout the program. They know the boundary between what is structurally produced and what is personally within their control. That knowledge does not make the structural conditions easier, but provides the practitioner a means to prepare and protect themselves.
The DX PM shortage is not a headcount problem. It is a categorization problem. The field is producing Category 1 and Category 2 practitioners at scale. Category 3 is a different professional preparation, and it begins with understanding what the environment demands.
Conclusion
This paper has made two related arguments. The first is structural: Conditions specific to digital transformation produce the challenges that DX PMs face, and those conditions are distinct enough from other project domains to warrant treating the DX PM as a separate professional category.
The second argument is about recognition: that category does not yet exist in the research literature. Its absence reflects a failure to study the practitioners most directly exposed to the structural failure of digital transformation. The data gap is not incidental. It is evidence that the profession has not yet asked the right questions about this group.
The framework in Section 5 is a perspective, not an empirical finding. Its purpose is to give DX PMs a more accurate model for observing and understanding the environment that they’re operating in, and to be aware of what that environment demands.
The DX PM who recognizes their situation in this paper has encountered a description of structural conditions. Not a verdict on their individual capability. This distinction matters. The weight of delivery is real, and its origin is now clarified.
METHODOLOGY AND SOURCE NOTE
This paper draws on peer-reviewed academic literature retrieved from PMC, ScienceDirect, SAGE, and ResearchGate; practitioner and industry research from PMI, McKinsey, Gartner, and Bain; and publicly available studies from recognized project management bodies including PMI and APM.
Statistical data covers DX program outcomes or is identified as general PM population data in citations. DX PM-specific quantitative data does not exist in the published literature; where this absence is relevant, it is named as a finding rather than worked around. The framework in Section 5, including the Situational Legibility Index and the three-category model, is the author’s perspective, grounded in the structural analysis of the preceding sections and offered as a conceptual model rather than an empirical finding.
References
The following sources are cited in this paper.
[1] McKinsey and Company (2023). Losing from day one: Why even successful transformations fall short. McKinsey Insights. mckinsey.com
[2] Gartner (2024). CIO and Technology Executive Survey: Digital Initiative Success Rates. Gartner Newsroom. gartner.com
[3] Bain and Company (2024). Transformation: A Company’s Most Important Bet. Bain Insights. bain.com
[4] PMI (2025). Step Up: Redefining the Path to Project Success with M.O.R.E. pmi.org
[5] PMI (2025). Pulse of the Profession 2025: Business Acumen. pmi.org
[6] PMI (2024). Pulse of the Profession 2024: The Future of Project Work. pmi.org
[7] Gonçalves, L. et al. (2025). Digital Transformation in Project Management: A Systematic Review and Research Agenda. Systems, 13(8), 625. doi.org/10.3390/systems13080625
[8] Simard, M. and Aubry, M. (2025). The Project Management Office’s Active Participation in a Digital Transformation. Project Management Journal. doi.org/10.1177/87569728241242029
[9] Vial, G. (2021). Understanding Digital Transformation. Routledge. doi.org/10.4324/9781003008637
[10] Tabrizi, B., Lam, E., Girard, K., and Irvin, V. (2019). Digital Transformation Is Not About Technology. Harvard Business Review. hbr.org
[11] Taleb, N.N. (2012). Antifragile: Things That Gain from Disorder. Random House.
[12] Maslach, C., Schaufeli, W.B., and Leiter, M.P. (2001). Job burnout. Annual Review of Psychology, 52, 397-422.
[13] Thomas, J.L. and Mengel, T. (2013). Preparing project managers to deal with complexity. International Journal of Project Management, 26(3), 304-315.
[14] Boller, M. (2024). The Mental Toll on Project Managers in Highly Functional, Siloed Organisations. instituteprojectmanagement.com [Practitioner article]
[15] Cooke-Davies, T. (2002). The real success factors on projects. International Journal of Project Management, 20, 185-190.
[16] PMI (2018). Pulse of the Profession 2018: Expanding the Value Delivery Landscape. Project Management Institute. pmi.org
[17] Stamper, C.L. and Johlke, M.C. (2003). The Impact of Perceived Organizational Support on the Relationship Between Boundary Spanner Role Stress and Work Outcomes. Journal of Management.
[18] Satheesh, K. et al. (2024). Enabling boundary spanners in public-private collaboration. Public Administration. doi.org/10.1111/padm.12927
[19] PMI (various). Influence Without Authority and Navigating Through Internal Politics. pmi.org/learning/library
[20] PMI (various). The Blame Game: Who Is to Blame When a Project Fails? PMI Learning Library.
[21] Carr, P. (2025). Improve your digital transformation project management. engineering.com [Practitioner article]
[22] Ochoa Pacheco, P. and Coello-Montecel, D. (2023). How do project managers’ competencies impact project success? PLOS One, 18(12). doi.org/10.1371/journal.pone.0295417
[23] Columbia University School of Professional Studies (2025). The Rising Demand for Project Managers. sps.columbia.edu
[24] ELG Research (2015). Accountability Without Authority. elg.net [Practitioner blog]
[25] World Health Organization (2019). International Classification of Diseases, 11th Revision (ICD-11). who.int
[26] Jung, C.G. (1968). The Archetypes and the Collective Unconscious. Princeton University Press.
[27] Wiewora, A. and O’Connor, P. (2021). Knowing When to Embrace Ambiguity and When to Fear It: Developing the Ability to Manage Uncertainty in Project Management. PMI Sponsored Research. pmi.org