The Relational Infrastructure Framework for Complex Projects

Development & Evidence Record

Overview

This record documents how the framework developed from Version 1.0 through Version 2.0, including major changes in architecture, the research and cases used during development, corrections and refinements, and the ongoing review process.

Want the current framework without the full development history? Go directly to Version 2.0 for a shorter overview of the framework.

Why This Framework Is Being Developed

The Growing Case for Relational Infrastructure

Complex projects increasingly span organizational, sectoral, geographic, and technological boundaries. Research on large interorganizational projects shows that this kind of work depends on coordination across independent organizations, while a systematic review of 105 studies identifies collaboration, autonomy, interdependence, and governance as recurring features of project networks (Roehrich, 2024; Lins et al.).

Digital transformation is extending that complexity. The Organisation for Economic Co-operation and Development (OECD) has documented how digital transformation changes relationships, markets, ecosystems, and interactions among people, organizations, and governments (OECD, Going Digital). Research on technological convergence similarly shows emerging systems being integrated across people, workflows, organizations, and external partners (World Economic Forum and Capgemini, 2026).

Together, these changes show that many complex projects depend on work crossing organizational, technological, and institutional boundaries. That creates a stronger context for examining the relational infrastructure around them.

Scope of the Framework

What Is a Complex Project?

A complex project, within the context of the Relational Infrastructure Framework, is a project where people, teams, organizations, institutions, disciplines, or communities must coordinate across boundaries and depend on one another to move the project forward.

These boundaries can include differences between departments, professions, regions, institutions, or organizations that have their own structures, responsibilities, and ways of working.

The Six Relational Conditions

Earlier versions of the framework were organized around eight pillars. Version 1.1 began moving away from treating those pillars as a sequence or lifecycle. As Version 2.0 has developed, the framework has shifted toward six relational conditions that can coexist and interact across a complex project.

Relational conditions are like weather conditions for a project. They help describe what different parts of the project's relational environment are like at a given time. Understanding those conditions can help you see where friction may be coming from and where attention may be needed as the project grows or changes.

The six relational conditions in Version 2.0 are listed below. Each can take different forms, change over time, and be experienced differently across the same project.

How the Framework Evolved

The original framework had eight pillars. As the framework developed, five were not carried forward as independent relational conditions. Some became practices rather than conditions. Others were divided across the new architecture or absorbed into conditions that better matched the relational issues involved.

This section documents what happened to each one.

Identifying Strategic Momentum entered the framework as one of the original eight pillars, focused on recognizing early signs of interest, participation, connection, and willingness to move work forward. Later research explored these dynamics through relational-energy research and eventually led to the broader language of relational signals.

Identifying Strategic Momentum remains useful for understanding how movement begins and develops around a project. However, it was removed from the core because momentum describes movement developing over time rather than a relational condition examined alongside the other six.

Flexible Strategic Direction began as one of the original eight pillars, focused on adapting a project's direction as new evidence changed assumptions, risks, or opportunities, while still moving forward rather than starting over each time something shifted.

Flexible Strategic Direction remains a useful practice for how projects adjust course. However, it was removed from the core because strategic adaptation is an activity a project does, not a relational condition it sits inside. Where a change in direction creates relational friction, that friction is now examined through whichever of the six conditions is actually involved.

Parallel Incubation and Testing appeared among the original eight pillars, focused on giving new ideas a protected space to develop and be tested before facing full visibility or scrutiny.

Parallel Incubation and Testing remains a useful practice for how projects develop ideas safely. However, it was removed from the core because it describes an innovation method a project uses, not a relational condition. Relational problems that surface during testing, including who gets included or how disagreement is handled, are now examined through the six conditions rather than through this pillar directly.

Community Space & Active Contributors also came from the original eight pillars, combining several different concerns at once, including having a dedicated home for collaboration, a usable way for new contributors to get involved, and the social experience of participating, along with early signs of overlap with other teams or institutions.

Those concerns were separated as the architecture was reorganized. Entry and contribution routes became part of Participation Pathway. The social conditions surrounding participation are now examined through Relational Environment. Overlap and connection across teams or institutions falls under Boundary Integration.

Community Migration rounded out the original eight pillars, and was the only one marked optional from the start, since not every complex project involves an existing community moving into a new environment.

Because it applied to a narrower set of situations, Community Migration was not carried forward as an independent condition. Its relational questions, including participation, crossing organizational or platform boundaries, the social climate of the move, or whether capability survives the transition, are now examined through whichever of the six conditions applies to what is happening during a given migration.

Corrections, Refinements, and Research Limitations

The development of this framework involved mistakes, corrections, abandoned approaches, repeated searches, and changes in thinking. This section does not document every one. It focuses on key challenges that affected, or could have affected, the framework’s architecture, research, or interpretation.

These examples are included to make parts of the development process visible. They may also be useful to others using AI in research or developing frameworks of their own.

Important Research Corrections

How practitioner experience was used

During the transition from eight pillars to six relational conditions, examples from Nick’s project experience were shared with AI models as part of an adversarial review. The purpose was to challenge the emerging conditions, identify overlap, and expose weaknesses.

The review began treating individual examples from Nick’s professional background as tests of whether a condition belonged in the framework. If a relational condition was not evident in one example, that absence could be interpreted as a reason to weaken or remove it. The examples were never intended to be used as a pass-or-fail standard for the conditions.

Once the problem was identified, the affected analysis was reset. The conditions were reopened and examined using a wider body of evidence, including published research, cases drawn from outside Nick’s experience, counterevidence, and comparisons among the six conditions.

Keeping Version 2.0 open during research

At one point, an AI review treated Version 2.0 as though its development was nearly complete and classified additional research as work for a later version. This conflicted with the actual status of Version 2.0, which remained under active development.

The interpretation was corrected, and the additional research remained part of the Version 2.0 development cycle.

This reinforced the need to make the status of a developing framework clear when giving research instructions to AI systems.

Checking the research sources

Sources used to support the six conditions later went through additional source checking. This included returning to original publications where possible rather than relying only on earlier AI analysis.

The purpose of this research was to examine whether the relational dynamics represented by each condition were supported by existing research, rather than relying only on Nick’s professional experience. This research can strengthen the foundation for individual conditions, but it does not by itself validate the six-condition framework as a whole.

The research record makes the same point. Research can support the dynamics described by the individual conditions without validating the framework as a whole.

Adversarial testing served a different purpose. It was used to challenge the framework, look for weaknesses and overlap, examine outside cases and counterevidence, and test whether parts of the architecture needed to change. Surviving those challenges strengthened the framework during development, but adversarial testing is not treated as empirical validation.

Research Gaps and Limitations

Some early research was not recorded with enough source information to recover every original citation later. Three earlier research anchors could be recovered with high confidence, while other areas required additional source reconstruction. Later research passes were used to rebuild and check those parts of the record.

Some of the supporting research focuses on individuals, teams, or other smaller settings rather than Complex Projects as a whole. Those studies can help explain particular relational dynamics, but they do not directly show that the same findings operate in the same way across an entire Complex Project.

AI research systems also had different capabilities. Some could search current sources, while others relied partly or entirely on pretrained knowledge. An early Gemini review, for example, did not independently verify every research source or read every paper in full. Its findings were therefore treated as AI analysis requiring later source verification, rather than as published research findings.

Conceptual and Architectural Refinements

Some changes were corrections because something had gone wrong. Others happened because additional research helped clarify what a condition meant or where an idea belonged in the framework.

Relational Environment, for example, was initially understood too much like a single project-wide climate. Further examination showed that broader relational patterns can exist while teams, organizations, roles, and participant groups experience very different local conditions. This led to the weather and microclimate explanation now used in the framework.

Other changes involved deciding whether an idea represented a relational condition at all. Original pillars from earlier versions were eventually understood as practices, processes, or concerns better represented through the six conditions. Those changes are documented separately in the framework’s development history.

These examples do not capture every correction or refinement made during development. They show some of the challenges encountered, how they were addressed, and lessons that may be useful to others doing similar work.

Evidence Trail

Research Sources

These sources support the reasoning and evidence behind each of the six relational conditions. Where possible, sources were checked against the original publication for details such as publication information, sample size, method, and reported findings.

A source’s presence here means it informs the condition, not that the six conditions together form a validated framework. Some sources support more than one condition and appear more than once. Ratings reflect the current state of each condition after this review, not a claim of proof.

Shared Perspective

Grounded, needs refinement

• Mathieu, Heffner, Goodwin, Salas & Cannon-Bowers (2000). The Influence of Shared Mental Models on Team Process and Performance. https://doi.org/10.1037/0021-9010.85.2.273. Historical anchor; 56 two-person teams in a simulated task. Strong on mechanism, small on scale.
• DeChurch & Mesmer-Magnus (2010). The Cognitive Underpinnings of Effective Teamwork: A Meta-Analysis. https://doi.org/10.1037/a0017328. 231 correlations across 65 studies linking team cognition to teamwork and performance.
• DeChurch & Mesmer-Magnus (2010). Measuring Shared Team Mental Models: A Meta-Analysis. https://doi.org/10.1037/a0017455. 23 studies, 1,511 groups; shows how a shared mental model is measured changes what relationship you find.
• Turner, Chen & Danks (2014). Team Shared Cognitive Constructs: A Meta-Analysis. https://doi.org/10.1002/piq.21163. Compares six shared-cognition constructs; not identically related to performance. Partially verified — full results text not independently inspected.
• Healey, Vuori & Hodgkinson (2015). When Teams Agree While Disagreeing. https://doi.org/10.5465/amr.2013.0154. Theoretical paper showing apparent agreement can mask real underlying difference, and apparent disagreement can mask real underlying similarity.
• Zaccaro, Dubrow, Torres & Campbell (2020). Multiteam Systems: An Integrated Review and Comparison of Different Forms. https://doi.org/10.1146/annurev-orgpsych-012119-045418. Shows component teams can hold different local cognitive states while coordinating around a shared goal.
• Mathieu, Rapp, Maynard & Mangos (2005). Scaling the Quality of Teammates' Mental Models. https://doi.org/10.1002/job.296. Counterevidence: sharedness alone did not predict performance — the quality of what was shared did.
• Lim & Klein (2006). Team Mental Models and Team Performance. https://doi.org/10.1002/JOB.387. 71 real-world action teams; both similarity and accuracy predicted performance, not similarity alone.
• Mesmer-Magnus & DeChurch (2009). Information Sharing and Team Performance: A Meta-Analysis. PubMed 19271807. Counterevidence: an apparent shared-perspective failure can actually be an information-distribution failure.

Relational Environment

Grounded, needs refinement

• Frazier, Fainshmidt, Klinger, Pezeshkan & Vracheva (2017). Psychological Safety: A Meta-Analytic Review and Extension. https://doi.org/10.1111/peps.12183. 136 samples, over 22,000 people, nearly 5,000 groups. Historical anchor for this condition.
• Luciano, DeChurch & Mathieu (2018). Multiteam Systems: A Structural Framework and Meso-Theory of System Functioning. https://doi.org/10.1177/0149206315601184. Conceptual framework explaining why one project should not be treated as one uniform social climate.
• Zaccaro, Dubrow, Torres & Campbell (2020). Multiteam Systems: An Integrated Review and Comparison of Different Forms. https://doi.org/10.1146/annurev-orgpsych-012119-045418. Different component teams can develop different affective and cognitive states.
• Edmondson (1999). Psychological Safety and Learning Behavior in Work Teams. https://doi.org/10.2307/2666999. Field study of 51 teams in one company; also found psychological safety was partly explained by leadership and context, not purely relational.
• Schilke & Lumineau (2023). How Organizational Is Interorganizational Trust? https://doi.org/10.5465/amr.2022.0040. Shows trust cannot automatically be aggregated from individuals up to an organizational level.

Participation Pathway

Grounded, needs refinement

• Ansell & Gash (2008). Collaborative Governance in Theory and Practice. https://doi.org/10.1093/jopart/mum032. Synthesis of 137 collaborative-governance cases.
• Reed, Vella, Challies, et al. (2018). A Theory of Participation. https://doi.org/10.1111/rec.12541. Typology showing engagement effectiveness depends on power dynamics and whose knowledge counts.
• Ballesteros & Dickey-Collas (2023). Managing Participation Across Boundaries. https://doi.org/10.1016/j.marpol.2022.105389. Case study of an intergovernmental boundary organization; the same stakeholder can hold different participation roles in different arenas.
• Bauer, Erdogan, Ellis, Truxillo, Brady & Bodner (2025). New Horizons for Newcomer Organizational Socialization. https://doi.org/10.1177/01492063241277168. 183 studies meta-analyzed; individual-level onboarding, a smaller unit of analysis than this framework's scope.
• Newig, Jager, Challies & Kochskämper (2023). Does Stakeholder Participation Improve Environmental Governance? PubMed 37829149. 305 cases across 22 democracies; the closest scale match found for this condition. Representation, communication, and decision-making power each mattered independently.
• Quick & Feldman (2011). Distinguishing Participation and Inclusion. https://doi.org/10.1177/0739456X11410979. Argues being invited to participate is not the same as being included.
• Fung (2006). Varieties of Participation in Complex Governance. Frames participation as an institutional-design problem, which is both evidence for the phenomenon and a caution that some failures are governance failures, not relational ones.
• Bryson, Crosby & Stone (2006). The Design and Implementation of Cross-Sector Collaborations. https://doi.org/10.1111/j.1540-6210.2006.00665.x. Places participation inside a broader collaborative architecture.

Boundary Integration

Well grounded

• Langley, Lindberg, Mørk, Nicolini, Raviola & Walter (2019). Boundary Work among Groups, Occupations, and Organizations. https://doi.org/10.5465/annals.2017.0089. Identifies both integration and separation as legitimate forms of boundary work.
• Santistevan (2022). Boundary-Spanning Coordination. https://doi.org/10.1016/j.jwb.2021.101291. Qualitative study inside one multinational enterprise, more than 60 respondents; boundary spanning itself needs coordination when many people span different boundaries at once.
• Jæger & Pedersen (2020). Understanding Organizational Boundaries. https://doi.org/10.5278/ojs.globe.v9i.4286. Boundaries can be formal or informal, visible or imagined; "boundaryless" organizations do not actually eliminate boundaries.
• Xu & Lauritzen (2022). Understanding Organizational Boundaries in an Interorganizational Context. https://doi.org/10.5465/AMBPP.2022.17449abstract. Conference abstract only; no full paper available, so this is weaker conceptual support rather than a primary source.
• Yeow, Faraj & Xiao (2018). Boundary Organization Practices for Collaboration in Enterprise Integration. https://doi.org/10.1287/isre.2017.0743. Five-year longitudinal case, 169 interviews across 101 people. One of the strongest sources in the current bank.
• Satheesh, Klijn & Eshuis (2023). The Impact of Boundary Spanning by Public Managers on Collaboration and Infrastructure Project Performance. https://doi.org/10.1080/15309576.2022.2137212. 158 survey responses across 58 Dutch infrastructure projects; boundary spanning strengthens collaboration, which relates to performance.
• Leicht-Deobald, Backmann, de Vries, et al. (2025). A Contingency Framework for the Performance Consequences of Team Boundary Management. https://doi.org/10.1177/01492063231206107. Meta-analysis, 85 studies, 10,848 teams. Positive overall effect, contingent on activity type and target.
• Manning (2017). The Rise of Project Network Organizations. https://doi.org/10.1016/j.respol.2017.06.005. Legally independent organizations can remain operationally interdependent across projects.
• Sydow (2022). Studying the Management of Project Networks. https://doi.org/10.1177/87569728211061814. Conceptual piece; current coordination occurs inside a network context, not an isolated project.
• Steen, DeFillippi, Sydow, Pryke & Michelfelder (2018). Projects and Networks. https://doi.org/10.1177/875697281804900201. Conceptual/methodological; argues for a network lens on temporary organizations. Partially verified — complete text not independently inspected.
• Söderlund, Vaagaasar & Andersen (2008). Relating, Reflecting and Routinizing. https://doi.org/10.1016/j.ijproman.2008.06.002. Single case study; three mechanisms of developing project competence.

Continuity of Capability

Grounded, needs refinement

• Galan (2023). Knowledge Loss Induced by Organizational-Member Turnover, Part I. https://doi.org/10.1108/TLO-09-2022-0107. Systematic review, 91 empirical studies.
• Galan (2023). Knowledge Loss Induced by Organizational-Member Turnover, Part II. https://doi.org/10.1108/TLO-09-2022-0108. Distinguishes codifiable knowledge from relational "know-whom" knowledge, which the paper itself calls underexplored.
• Argote & Guo (2016). Routines and Transactive Memory Systems. https://doi.org/10.1016/j.riob.2016.10.002. Routines can be resilient to turnover; transactive memory systems are more membership-dependent. Also counterevidence — not all capability continuity is relational.
• Massingham (2008). Measuring the Impact of Knowledge Loss. https://doi.org/10.1177/1350507608096040. Single case study inside one defense organization. Qualified full-text verification.
• Lorenzoni & Lipparini (1999). The Leveraging of Interfirm Relationships as a Distinctive Organizational Capability. Wiley record. Longitudinal study of three firm networks. Partially verified — complete text not independently inspected.
• Carmeli & Azeroual (2009). How Relational Capital and Knowledge Combination Capability Enhance Performance. https://doi.org/10.1002/sej.63. 122 knowledge-work units.
• Collins & Hitt (2006). Leveraging Tacit Knowledge in Alliances. https://doi.org/10.1016/j.jengtecman.2006.06.007. Relational capabilities help build relational capital, which facilitates tacit-knowledge transfer between partners.
• Aaltonen & Turkulainen (2018). Creating Relational Capital through Socialization in Project Alliances. https://doi.org/10.1108/IJOPM-02-2017-0091. Two infrastructure alliance cases; formal and informal socialization both used to build and maintain relational capital.
• Rungsithong, Meyer & Roath (2017). Relational Capabilities in Thai Buyer-Supplier Relationships. https://doi.org/10.1108/JBIM-02-2017-0027. 156 partnerships, 312 respondents.
• Blonska, Storey, Rozemeijer, Wetzels & de Ruyter (2013). Decomposing the Effect of Supplier Development on Relationship Benefits. https://doi.org/10.1016/j.indmarman.2013.06.007. 185 suppliers; counterevidence that high relational capital can sometimes reduce buyer benefits.
• Manning (2017); Sydow (2022); Steen et al. (2018); Söderlund, Vaagaasar & Andersen (2008) — see full citations under Boundary Integration above. Cross-listed as supporting evidence for cross-project persistence.

Influence Alignment

Grounded, needs refinement

• Mitchell, Agle & Wood (1997). Toward a Theory of Stakeholder Identification and Salience. https://www.jstor.org/stable/259247. Foundational typology built on power, legitimacy, and urgency.
• Pfeffer & Salancik (1978). The External Control of Organizations: A Resource Dependence Perspective. Foundational theory that power flows from resource dependence between organizations. Partially verified — this is a book, and the complete original text was not inspected cover to cover.
• Baker, Gibbons & Murphy. Informal Authority in Organizations. https://doi.org/10.1093/jleo/15.1.56. Formal theoretical model showing informal authority can arise through relational contracts even when formal decision rights sit elsewhere.
• Deng, Liu & Wu (2021). Complexity Relationship between Power and Trust in Hybrid Megaproject Governance. https://doi.org/10.1155/2021/8814630. 116 responses across Chinese urban rail megaprojects; power asymmetry linked to worse governance outcomes, power sharing to better ones.
• Purdy (2012). A Framework for Assessing Power in Collaborative Governance Processes. https://doi.org/10.1111/j.1540-6210.2011.02525.x. Identifies authority, resources, and legitimacy as distinct sources of power, including control over who gets to participate.
• Ran & Qi (2018). Contingencies of Power Sharing in Collaborative Governance. https://doi.org/10.1177/0275074017745355. Challenges the assumption that shared or balanced power is always preferable.
• Provan & Kenis (2008). Modes of Network Governance. https://doi.org/10.1093/jopart/mum015. Counterevidence — some apparent influence problems may be artifacts of the governance structure chosen, not a relational failure.
• Emerson, Nabatchi & Balogh (2012). An Integrative Framework for Collaborative Governance. https://doi.org/10.1093/jopart/mur011. Places influence inside a larger system of governance regimes and institutional context.

Relational Infrastructure Framework for Complex Projects Development Record

Shared Perspective

• Do participants understand how their work connects to the larger project?
• Where are groups working from assumptions that have never been made explicit?
• Which differences in perspective are useful, and which are leading to incompatible action?

Relational Infrastructure Framework for Complex Projects Development Record

Relational Environment

• What happens when someone makes a mistake or raises a concern?
• Who appears comfortable asking for help, and who does not?
• What happens when someone disagrees with a person who has greater influence?

Relational Infrastructure Framework for Complex Projects Development Record

Participation Pathway

• If someone wants to contribute, where do they begin?
• Where do people commonly get stuck between initial interest and actual contribution?
• Can participants move toward greater responsibility as their knowledge and capability grow?

Relational Infrastructure Framework for Complex Projects Development Record

Boundary Integration

• Which boundaries does this project depend on crossing successfully?
• What happens when one group needs something from another?
• Where does translation need to occur between different professional, institutional, technical, or community languages?

Relational Infrastructure Framework for Complex Projects Development Record

Continuity of Capability

• Which people could leave and significantly disrupt the project?
• What capability would actually disappear with them?
• When someone changes roles, how are their relationships transferred, not merely their files?

Relational Infrastructure Framework for Complex Projects Development Record

Influence Alignment

• Who actually influences decisions across this project?
• Is that the same group that formally holds decision authority?
• Are people being given responsibility without enough influence over the conditions affecting their work?

Project Cases from Nick's Professional Experience

These are selected project cases drawn from Nick’s professional experience and used during development of the Relational Infrastructure Framework. They are not an exhaustive record of his work. The cases were considered alongside published research and external cases to help examine how the six relational conditions appeared across different project settings.

• Founder repeatedly bypassing available team expertise in consequential decisions.
• Large residential/community facility where management made consequential decisions while resident perspectives had little apparent influence.
• Leadership decisions whose wider project constraints were not understood by contributors, creating avoidable morale and interpretation problems.
• Leader who encouraged community-originated ideas while participants showed care, follow-through, and ownership.
• Hospitality leader who openly relied on team expertise and recognized transferable capability beyond narrow industry credentials.
• Skilled nursing dining-room intervention where menu frustration and social energy were redirected into participation and community activity.
• Hotel/community pool case where perceived legitimacy and invitation affected whether residents used a shared space.
• Volunteer/nonprofit project where eager participants were placed into activity that did not align with project needs.
• Global open-source project where contributors could possess skills yet lack sufficient shared understanding of how contribution worked.
• Livestream project where paid and unpaid participants experienced visibly different relational conditions.
• Hackathon where low-status/title salience, welcome, and legitimate participation created a strong sense of mattering.
• Central-person dependency case where a task list did not reproduce the capability lost when a key person stepped away.
• Open Library handoff/transition case used to examine whether capability survives beyond documentation.
• Premature formalization and community-to-event transition cases used to examine changes in relational conditions under scale and structure.

External Published Cases Used to Test the Framework

These are some of the external cases used to test the Relational Infrastructure Framework. They helped examine whether the six conditions could identify relational issues across different projects and settings. They were also used to look for overlap, missing areas, and situations the framework might incorrectly treat as relational.

Key Decisions

This section records selected decisions that changed the framework’s architecture, scope, or interpretation in ways that could otherwise be lost or misrepresented in later versions.

Origins

Where the Framework Began

The Relational Infrastructure Framework for Complex Projects was created by Nick Norman, drawing from patterns he observed across more than 15 years of work.

His background began in hospitality, retail, and customer service, then expanded into communications, community building, and large digital and hybrid ecosystems. Across these environments, relationships were often central to how people participated, collaborated, and worked through change.

As projects became larger and crossed more organizational and regional boundaries, Nick noticed recurring friction. Funding, technology, capable people, and strong ideas were not always enough. Growth could introduce new participants, shifting responsibilities, competing needs, and decisions that became harder to navigate.

Those patterns eventually raised a larger question. What happens to the relationships around a project as it grows? The first version of the framework was created to organize those observations into something others could examine and use.

Putting this to use

How to Use This Framework

Explore the six conditions. Use them to examine a project, whether it is new or already underway. They can help surface relational friction that might otherwise be easy to miss.

The six relational conditions are not meant to be treated like steps, and they are not listed in any particular order.

You can use a real project or make up a project scenario and use AI to examine it through the six relational conditions and see where friction may be emerging. Or you can try the free diagnostic demo to apply the framework and get a simple picture of where relational friction may be showing up. Try the diagnostic →

See how the framework is being used and developed. Nick is writing about the Relational Infrastructure Framework as it develops, including how it can be applied, tested, and understood in practice. Read the framework series →

Bring the framework into a conversation. If it would be useful to explore the framework with a team or audience, Nick is available for speaking, workshops, podcasts, and other discussions.