Abstract
Large-scale, mission-critical initiatives are increasingly deployed through major programs or assemblies of projects that span and situate across sectors, industries, and/or geographies. To better track risk propagation within major programs, this article reconceptualizes them as temporary ecosystems or interlinked organizations whose project-based interdependencies last until the program’s conclusion. This basis motivates our S3 framework and its three unifying themes. Scoping identifies program vulnerabilities to disruptions. Scaffolding develops digital and organizational tools to connect program skills with needs. Sensing engages with those oft-excluded in programs. We then apply this framework to the Oman Vision 2040 program and a hypothetical peacekeeping mission scenario to demonstrate the framework’s practicality.
Keywords
Now put yourself in the shoes of Dutch entrepreneur Boyan Slat. Also in 2013, he founded the nonprofit Ocean Cleanup to address the critical issue of ocean plastic pollution. The nonprofit estimates that over 5 trillion pieces of plastic currently litter the ocean. Most are caught in five garbage patches, of which the largest is the Great Pacific Garbage Patch. 4 The Ellen MacArthur Foundation argues that solving this problem will require at least $150 billion. 5 To mitigate this problem, Slat and team are coordinating across several technologies, from numerical modeling of where wastes will most circulate, field sampling, and remote sensing that verifies such modeling and tracks such waste in real time, all the way to retrieval technology that traps such waste and brings it onshore for recycling.
What do these challenges of Okada in space and Slat in our oceans have in common? Each is a major program trying to address a globally pressing challenge. While major programs are critical for tackling large-scale and complex societal challenges, prior work in project management notes that we still know very little about how to deliver value from these programs. 6 They are “major” in that these complex ventures involve multiple diverse and interdependent stakeholders, 7 typically costing $1 billion or more, taking many years to develop and deliver, and impacting millions of lives. 8 They are “programs” in that these initiatives are a distributed assembly of projects across wide spatial, temporal, and/or sectoral distances that need to be sequenced in a chain, interlinked as a network, and/or simultaneously managed as a portfolio. 9
Managing such large-scale initiatives presents complexities that are distributed and yet interdependent, and so cannot be devolved down to individual projects within the program. Yet while most recognize a programmatic focus is crucial and distinct, existing frameworks still end up devolving down to the project level. Ika and Munro note, “To make things worse, even rarer are those contributions that take a portfolio or program approach to the delivery of grand challenges,” and they later note that the focus is still “on lonely or discrete megaprojects, not portfolios or programs.” 10 This has been a perennial problem as Artto and colleagues argue that from their review of the literature, “it is not clear what are the distinctive features and differences between projects and programs and their management.” 11 This is still so problematic that a 2023 special issue has been summoned on program management. The call argues in the very first paragraph that “projects and programs are often used as synonyms causing fragmentation and confusion in theory and practice.” 12 As a case in point, one of the most cited pieces in project management argues that “megaprojects are sometimes also called major programs.” 13 At best, programs are treated as a discretized set of projects; at worst, programs are not even conceptually separated from projects.
This lack of conceptual sharpness between projects and programs matters because when we devolve major programs down to their constituent project parts, we assume that their risks are separable, modular, or aggregated by simple addition. By risk, we simply mean “known unknowns” (i.e., things we can attach a probability), as opposed to uncertainty, or “unknown unknowns” (i.e., things for which we are unaware or cannot foresee and therefore cannot attach a probability). 14 More specifically to major programs, this refers to risks around the proverbial “iron triangle,” namely risks that increase scheduling delays, that increase cost overruns in relation to the initial allocated budget, and that change requirements.
This neglects that risks (and their driving complexities) can propagate, whereby risk in one project can cascade into another, and they are interlinked in ways that make them difficult to separate or aggregate. 15 For instance, with Astroscale, if one removal satellite moves a piece of debris incorrectly off its orbital trajectory, this piece of debris is not just disposed improperly, its incorrectly altered trajectory risks hitting other debris removal satellites, thereby hindering other parts of the program. With Ocean Cleanup, if the numerical models make an unanticipated error, they may not just incorrectly locate the origins and destinations of ocean plastic; they also risk misdirecting the ships with retrieval technologies for collecting said plastic. Simply put, in a major program, the challenges on any single project do not just hinder that project but can propagate and impact other linked projects, even if those linked projects otherwise proceed according to plan. When we devolve a program down to its constituent project parts, we also assume a devolution of its risks, thereby neglecting the coordination and governance challenge of how to mitigate risk propagation between projects. 16 This inter-project coordination fundamental to major programs and their risk propagation is understudied. 17
Our aim then in this essay is to help practitioners overcome these challenges. We have created a framework that stays at the program level to help stakeholders better coordinate the creation, protection, distribution, and transformation of value within the design and delivery of major programs. For our purposes, we define value as the tangible and intangible benefits that a program creates for its stakeholders. More specifically, we focus on the distributed governance challenge of managing risk propagation between projects within a major program and how that impacts the program’s delivered value. In so doing, we widen the aperture from projects as temporary organizations that help us understand discretized project risks 18 to programs as temporary ecosystems. Given that ecosystems are interacting organizations that depend on each other’s activities, 19 this keeps the focus on mapping interdependencies between projects to better understand how risk propagates throughout a major program’s life.
The result is an analytical framework that we call S3. The overall aim of this framework is to develop a foundational and actionable toolkit for use early in the design of major programs that is more attentive to risk propagation. While several works exist around capabilities and coordination in projects and organizations, 20 this framework contributes to these works by not just integrating these prior insights into a single program-level relational framework, but also by adding greater clarity as to where one ought to build such capabilities and coordination when taking such a programmatic view.
The first “S” is scoping, which focuses on setting priorities. Program stakeholders inherently come from a wide array of perspectives and have to trade off between many competing demands. 21 By engaging in wide stakeholder consultation to hopefully build consensus around where the major program is most vulnerable to which kinds of disruptions, scoping helps set priorities for where risk propagation is most critical and potentially pernicious.
The second S is scaffolding, which focuses on information sharing. Given such stakeholder diversity, information is dispersed and fragmented, with each stakeholder likely only getting a partial and incomplete picture of the program. 22 In developing technologies and organizational structures that connect major program skills (who knows what) with needs (who requires what), scaffolding helps improve information sharing to increase the speed by which risk propagation is detected and addressed.
The third S is sensing, which focuses on situational awareness. As major program stakeholders hail from different sectors, geographies, and cultures, how to situate the program across these several different societal contexts is a highly complex affair prone to slippage and mis-specification. 23 In sharpening detection around those who have been historically missing and marginalized in major programs, sensing helps more widely identify possible unanticipated sources of risk propagation.
Figure 1 defines the core motivations behind our framework. Each “S” is distilled into a key fundamental issue on which practitioners should focus when managing major programs and tactics for navigating that tension. For interested readers, we provide the scholarly basis in both the engineering and social sciences for how we arrive at each of these tensions in greater depth on our online digital companion to the article, which is available on the Project S3 website: https://www.sbs.ox.ac.uk/research/research-areas/major-programme-management/project-s3.
Motivation for S3 framework.
We show one methodological approach by which to apply S3 in the context of Oman Vision 2040, which serves as an illustrative example and demonstration. This major program represents how the Sultanate of Oman (herein referred to as “the Sultanate”) views its most pressing challenges and the basis for future projects it hopes to deploy for tackling these challenges by 2040. We choose to demonstrate S3 with a national vision as such undertakings seek to inspire the major program of work needed to address national ambitions and recognize the need to do so in a distributed manner. Therefore, we want to demonstrate the capabilities of S3 under what can be viewed as one of (if not the) most extreme programmatic conditions for which to operate such a tool. We apply S3 to this national vision document to posit possible areas to prioritize focus based on where risks could most propagate and present challenges (scoping), to identify those domains that must coordinate information and collaborate around said challenges (scaffolding), and to construct scenarios that account for excluded stakeholders and linkages to stress test these assumed priorities (sensing).
While Oman 2040 serves as our core illustrative example, we see the model’s application as relevant to major programs of many different forms. We can envision this framework applying to a new generation of major programs that are prone to unanticipated disruptions. Beyond national strategic plans and visions, these could be major programs that are having to navigate increasingly turbulent environmental change such as net zero initiatives that seek to decarbonize various industry sectors. 24 These could be major programs that must navigate increasingly unpredictable sociopolitical turmoil, such as those around peacekeeping missions, refugee settlements, and infrastructure repairs amid conflict. 25 Finally, this could also apply to “big science” major programs that seek to develop technologies amid uncertain scientific trajectories and ferment, such as those around space technology, additive manufacturing and 3D printing, blockchain, artificial intelligence, quantum computing, and fusion energy. To explore such extensions, we follow our worked Oman Vision 2040 example with a hypothethical peacekeeping mission scenario to ponder how S3 could generalize to other contexts.
Conceptualizing S3
Scoping: Bounding and Learning—Setting Priorities to Alleviate and Mitigate Risk Propagation
Scoping focuses on navigating the tension between bounding and learning. To bound, major program leaders want to shield their program ecosystem from disruptions that they cannot handle and therefore want to set generous “safety factors” that reduce their likelihood of impacting the program (i.e., risk alleviation). However, these same leaders also want to motivate learning from disruptions. In so doing, stakeholders can more quickly identify and reduce spillovers from those inevitable events that bring new risks that were not anticipated at the program’s onset (i.e., risk mitigation). Scoping is therefore about setting priorities that can simultaneously bound, protecting from insurmountable criticalities, while also leaving room for learning within those bounds, identifying and quickly addressing unanticipated issues.
How can we potentially navigate this tension? First, set initial tolerance thresholds. The aim is to anticipate and alleviate the occurrence of disruptions that the program cannot tolerate. Second, experiment with new practices. Inevitably, some unexpected disruptions will arise. The aim here is to trial new practices to help program stakeholders more quickly detect such unexpected disruptions and mitigate their negative impacts from propagating to other parts of the program. Third, change thresholds based on learning over time. As program stakeholders learn from trialing new practices, they will gain greater insights into which practices successfully curb negative propagation and which ones will not. In this manner, they will be better equipped over time to manage more disruptions. The aim then becomes to expand the initial boundary conditions based upon that learning, whereby disruptions that were previously not considered are increasingly included and managed. To be clear, we are not saying one can predict all possible disruptions. We simply argue that by starting with worst-case bounds and learning from the consequences of the disruptions that occur, we can better prepare for and adapt to subsequent future disruptions. In short, these tactics provide a means for improving our capabilities to “predict and prevent” disruptions in major programs over time. 26
Scaffolding: Executing and Envisioning—Information Sharing for Quicker Detection of Risk Propagation
The question then becomes how to provide information adequately, quickly, and clearly enough to facilitate and act upon the priority setting and learning from scoping. This is where scaffolding comes in. Scaffolding focuses on navigating the tension between executing and envisioning. To execute, major program leaders want to ensure information is comprehensible to stakeholders, so they know how to quickly act upon it. That said, major programs often take five or more years to complete, 27 so these programs likely come into fruition in a future world that is different from the one in which programs are conceived. Major program leaders need to ensure the information provided does not just provide clarity on how to currently act but also on how to better envisage how to act in a future world that is yet to exist. Scaffolding is about information sharing that is simultaneously comprehensible and explainable so stakeholders can act on it, while also helping stakeholders reimagine the possible so they can continue to effectively act in the future world that the program will occupy.
How can we potentially navigate this tension? First, build organizational tools. The aim here is to coordinate stakeholders with readily understandable tools as simple as Gantt charts, responsibility assignment matrices, Slack channels, or even Excel sheets 28 that help people understand who knows what, does what, needs what, and when. Second, build digital tools. The aim here is to coordinate stakeholders with tools 29 such as digital twins or immersive reality that integrate with aforementioned organizational tools to help stakeholders collectively ponder different future possibilities that may necessitate adaptation over time. Third, codify and store learning over time. We tend to forget quickly, which can result in a depreciation rather than an appreciation of knowledge over time. 30 Building repositories such as data lakes and intranet systems with commonly agreed-upon indexing 31 can allow stakeholders to quickly search and find information accrued over time. In short, these tactics help build an underlying information structure that helps stakeholders: quickly comprehend what to do, when, and with who; collectively envision new possibilities for the future world in which the program will come into existence; and store learning as to what has worked or not over time.
Sensing: Detecting and Resourcing—Situational Awareness for Unforeseen Risk Propagation Sources
The challenge is then how to identify potential sources of risk propagation that may nonetheless be unforeseen from prior scoping and scaffolding efforts. This is where sensing comes in. Sensing focuses on navigating the tension between detecting and resourcing. To detect, major program leaders want to identify missing or marginalized stakeholders as quickly as possible to more accurately ensure they are accounted for and valued in the program. However, detecting such stakeholders requires very high-resolution data, often at the level of a few meters or a few individuals. 32 Given major programs are distributed across several different sites, achieving such granularity is likely to be highly resource-intensive. 33 To then resource such detection, major program leaders need to divert computational and human resources away from currently understood program stakeholders and objectives. Sensing is therefore about situational awareness that is both agile in its detection of missing and marginalized stakeholders and achievable with as few resource diversions as possible.
How can we potentially navigate this tension? First, identify communities that are in the gaps of existing infrastructure. Existing street and broadband networks, especially where they do not go, 34 can provide repeatable configurations that help program leaders gain insight into who may have been historically missing in prior large-scale initiatives. The most critical of these infrastructure systems will naturally be those that the major program needs to fulfill its objectives. Second, engage with key thought leaders within these communities. Communities often have a few key champions to whom they may go to seek advice or support, 35 and so these individuals often have an accurate pulse on community needs and interests. Engaging with such members early and often will help major program leaders know more quickly where there may be community concerns or opportunities. Third, keep track over time to note any changes in community behavior and preferences. Maintaining engagement with these key thought leaders over time will help provide valuable input as to when community perspectives may change as the program develops and evolves. In short, these tactics help constantly investigate what is missing in major programs to quickly identify and then mitigate unforeseen sources of risk. These tactics progressively and slowly escalate commitment and granularity to ensure the most efficient allocation of limited programmatic resources. Using existing large-scale infrastructure networks can help identify key community gaps; increase granularity by identifying the key leaders in those communities; and maintain engagement with such leaders over time. This can ensure that such detection is done in resource-efficient ways.
Applying S3
Initializing Step: Baseline System Mapping
The first step of applying S3 in practice necessitates building a baseline map of the program. This combines cognitive mapping with open and axial coding methods. 36 The aim of this is to translate data from archival documents, such as strategic plans or interviews with program stakeholders, into a map of the perceived cause-effect linkages between different program components. 37 In the Implementation Guidelines section and Table 1 below, we also show how different network centrality measures can be applied directly to these maps to further help practitioners apply S3 in tangible and targeted ways. Ideally, one would create such maps across several documents or interviews to ensure an adequate capture of stakeholder consensus. Given our intent here is to demonstrate a proof-of-concept for illustrative purposes, we chose a document for which there was already stakeholder consensus.
Implementation Guidelines for Applying S3.
Our choice was the Oman 2040 vision document. 38 This document represents the Sultanate’s vision for key initiatives that will guide a major program of work for what they would like to achieve as a country by 2040. In the document, they detail an extensive stakeholder consultation process by which they sought consensus, which makes this an attractive document to build a methodological proof-of-concept for how to apply S3 in practice. Besides strategy documents, this framework can use other kinds of data (e.g., interviews, archival documents, or surveys) insofar as this data captures perceived cause-effect linkages within the major program.
To be clear, while we present the steps linearly for clarity, this is very much an iterative process whereby steps are revisited when key omissions are discovered. Those key emissions for which one should revisit a previous step are captured in the small circular arrows in Figure 2. For instance, in this first step, see the circular arrow between the “Map the Program” and “Identify Priorities & Thresholds” steps in Figure 2. This arrow notes that if, in identifying priorities and thresholds, some stakeholders realize there are fundamental omissions that are leading to a lack of consensus around what ought to be these priorities and thresholds, then the baseline map should be revisited.
Illustrative methodological approach for implementing the S3 framework.
While there are tools to automate these mapping processes (such as cogmapr in R), we elected to conduct the document analysis and mapping by hand and captured the results via the mapping tool Miro, so we can reveal to the interested reader more transparently our steps. These Miro maps are available in the manuscript’s online Supplementary Materials, as well as on the Project S3’s website provided in the Introduction. To that end, our open coding of the original document as a downloadable CSV sheet is available on the Project S3 website, and our axial coding scheme can be specifically found in Table A1 on the Project S3 website’s online Appendix. We also supply a more detailed discussion of the methodology that we used to build this baseline map in that online Appendix as well (see the section entitled “Constructing the Baseline Systems Map”). One crucial point to highlight is that the assumptions made in the coding process for constructing our systems map are not central to this article. While they are debatable and open for discussion, the essential methodological point here is to establish a demonstrable starting point, the baseline cognitive map (see Supplemental Material, Figure 1A), for which to begin applying the S3 framework.
Major programs are so distributed that keeping a census of all the possible connections, let alone consequences, is highly difficult. 39 One must make prioritization choices and trade-offs as to what to most predominantly track and trace in a major program. This is precisely the contribution of the S3 framework; it is designed to help major program managers devise different possibilities for which to make such decisions in a more systematic and informed manner. That said, Table A2 in the Project S3 website’s online Appendix provides mapping protocol guidelines that can help inform how deep you may want to go when developing your initial map to make this more manageable.
Step 2: Identifying Priorities and Thresholds (Scoping)
Once we have the baseline map, this is where S3 begins to show its novelty. The first step is the scoping step, which is to prioritize those parts of the program map that could be susceptible to disruption and thereby interrupt program deployment. In essence, what we are attempting to do is take our initial complex baseline map and identify what we call a minimum viable system (MVS) of interest, or the minimum number of nodes and linkages needed to adequately analyze and act upon possible disruptions. 40 Recall a major program is an assembly of projects, each providing a key set of products and services into the major program. As such, an MVS is conceptually the smallest consideration of minimum viable products (MVPs), the stakeholders who provide and are responsible for these MVPs, 41 and the minimum linkages needed between these MVPs for sustainable and responsive action.
We can imagine this scoping step happening in two ways. The first is to prioritize the most salient parts of the system itself. This assumes the key disruptions are endemic or endogenous to the system. From this perspective, we can prioritize the nodes with the greatest number of linkages (see Supplemental Material, Figure 2A). These examples are not exhaustive and are for demonstration purposes only. Practitioners can use these same steps illustrated in Figure 2A to identify other foci that reflect what they deem as critical.
The second scoping approach is to prioritize salient exogenous events that could destabilize the program, especially if attention to the existing major program is not placed there. Figure 3A (see Supplemental Material) illustrates a possible exogenous event for demonstration purposes; again, one can envisage many other scenarios. This event is specifically salient to the Sultanate currently and was not foreseen when this vision document was crafted, namely the newly announced plans for establishing the India-Middle East-Europe Economic Corridor, or IMEC. IMEC is expected to rival China’s Belt and Road Initiative and thus would disrupt the entire trade system in the region. The worry could be that the IMEC’s proposed route could drive trade away from the country, which makes it a particularly salient disruption for the Sultanate. 42 This suggests an important stressor to Oman Vision 2040 is through the lightly considered node of Trade, one of the Economy nodes in blue. Another salient exogenous event of interest could be pandemics such as COVID-19, which is also a salient crisis prior to the construction of this document. This would activate the lightly touched Health node, one of the Support Mechanisms family of nodes in red.
Once we have established a set of candidate disruptions (endogenously and/or exogenously) that could change how we operate a major program, we need to ascertain a threshold for when a candidate disruption goes from a “what if” scenario to an imminent reality. To come up with a structured way to set these thresholds, we can leverage the notion of simple rules. 43 Simple rules are heuristics or rules of thumb. While heuristics can generate bias when answers are known, 44 they can be useful when dealing with issues of complexity and ambiguity that are less known and are typical in major programs. 45 Moreover, in grounding heuristics in prior data, one can ensure heuristics are more reflective of learning to date. Like scoping, simple rules are constructed around key bottlenecks, which, in our case, is our candidate disruptions. There are five types of rules: how-to (how a process is executed), boundary (which opportunity to focus on and not), priority (rank of bounded opportunities), timing (synchronize managers with pace of opportunities and other parts of the company), and exit (when to pull out of an opportunity). 46
For example, a boundary rule could be that the Sultanate will develop a rapid response plan to the potential IMEC-driven trade disruption if a 20% decline is observed in foreign direct investment to the Sultanate’s trade logistics infrastructure. The threshold of 20% can be adjusted based on whether that percentage adequately allows the Sultanate to respond to such a disruption. The key is to establish rules that achieve the right balance between structure and flexibility, 47 and this likely requires implementing these rules over several iterations to identify what is that right balance.
One continues to revisit this scoping step until an adequate threshold is specified that is agreed to achieve the right level of preparedness for the disruption of interest (see the small circular arrow between the “Identify Priorities & Thresholds” and “Coordinate Proximate Organizations” step in Figure 2). More specifically, we establish an initial set of simple rules that cover some or all the aforementioned five simple rule types. We then see if applying these rules helps us better detect disruptions. This could be as simple as setting up Google news alerts with these rules to ascertain if our simple rules are accurately capturing disruptions aligned with the appropriate scenarios of interest. Another possibility is to run simulations, akin to “red teaming,” that try to artificially create conditions that most closely mimic these disruptions to ascertain which thresholds help best manage these occurrences. If disruptions are captured, then the rules provide adequate support. However, if key disruptions are missed, then the rules need to be revisited and fine-tuned to capture the features of these missed disruptions. We stop once we achieve an adequate capture of the disruptions that are deemed most critical to the program.
Step 3: Coordinate Proximate Organizations around Anticipated Disruptions (Scaffolding)
Once we have scoped and set thresholds for our key disruptions, we are now ready to develop support structures to coordinate faster detection and response to said disruptions. In step 2, our focus was on the most prominent nodes; in step 3, we now turn to the most frequent ties as opposed to the most linked and proximate organizational nodes. This is based on the notion that the most frequent ties define what information is most likely passed and where this is most likely housed within the program; this will help us better ascertain who knows what (see Supplemental Material, Figure 4A). Although we focus on tie frequency to illustrate how this works, another option is to find those particular ties where a majority of critical informational paths flow (i.e., those paths that represent the shortest distance between each pair of nodes). Coordinating across these most frequent ties and connected set of nodes can serve as the base scaffolding for the system.
Up until this point, we have focused on how to execute but not how to envision via scaffolding. While this would help execute program objectives under current circumstances, this may not be adequate as conditions change in the future and would require us to revisit our scaffolding structure. This is the revisit condition for the small circular area between the “Coordinate Proximate Organizations” and “Stress-Test Nodes and Ties” steps in Figure 2. Perhaps in developing augmented reality or other tools, we can help stakeholders envision how disruptions of interest may occur in different possible future environments. Included in those simulations would be information that stakeholders would theoretically possess from the current scaffolding structure. In grappling with these disruptions in these new environments, a piece of information is identified as needed to craft an appropriate response and is not available in the current scaffolding architecture. This would necessitate revisiting and updating the existing scaffolding in place. We achieve completion when our scaffolding provides adequate information for the key responses needed for our disruptions of interest in different possible environments. This is akin to the notion of saturation, whereby once little information arises from another iteration of possible disruptive “what ifs,” we would stop our exercise and move onto the next step.
Step 4: Stress-Testing for Missing Nodes and Ties (Sensing)
We know information is often biased toward where we have more data and experience. 48 This is where stress-testing based on marginalized stakeholders for which we have little data becomes crucial. For that, we should explore new ties and nodes not adequately covered in the current system. Marginalized ethnic communities, and even stakeholders without a voice such as nature, are often missing and important to consider during this step. To do this, one adds previously unconsidered nodes and ties and evaluates whether these either create novel disruptions (from the scoping step 2) or change the information needed to solve the issues presented by these previously unanticipated considerations (from the scaffolding step 3).
One scenario that can offer learning to the Sultanate is what happened with marginalized communities in the neighboring Kingdom of Saudi Arabia (KSA). As KSA launched Neom, their new megacity project, the development site was unexpectedly found to encroach on the historic lands of the Howeitat tribe, which created unanticipated challenges for this project. 49
We conducted a stress test of our map to a similar possible scenario in the Sultanate, namely a scenario whereby a prominent project encroaches on the lands of one of the Sultanate’s nomadic peoples, the Harasiis tribe. 50 We chose the Harasiis because this tribe resides in one of the most remote and desolate places in the Sultanate. 51 A group this remote is a useful candidate for what the sensing component under the S3 framework aims to capture as a marginalized community (see Supplemental Material, Figures 5A and 6A).
In particular, we note three possibilities. The first is strengthening existing ties. For instance, if the Harasiis feel they are compromised and fight as did the Howeitat tribe, then clearly this strengthens the importance of the connection between Oman Vision 2040 and the perception of Sustainable and Inclusive Development, one of the yellow Society nodes. This would make even more imperative the need to get in front of this issue and address it amicably to ensure development in the Sultanate is indeed truly socially inclusive. Also given the Harasiis live in Jiddat-il-Harasiis, which also has a vital set of wadis, this clearly strengthens the importance of the linkages between Oman Vision 2040 and Natural Resources, one of the purple Environment nodes. In other words, if the Harasiis obstruct advancement, this could constrict vital natural resources needed to implement Oman Vision 2040. Moreover, how this is handled will clearly increase scrutiny on judiciary governance and performance, hence the stronger linkages between Governance and Performance nodes, two of the Legislative, Judiciary, and Governance nodes in olive green, and Oman Vision 2040.
The second is the emergence of new ties. For instance, depending on how the Sultanate handles such a situation with the Harasiis tribe, this could impact the Sultanate’s social standing as it did for the KSA with the Howeitat tribe. If handled well, their social standing would increase; if handled poorly, their social standing may decrease. Also given the Harasiis’s location and assuming the idea is to construct a development akin to Neom, then the Infrastructure node, one of the Support Mechanism nodes in red, would also arguably be activated. In Oman, a complex history with oil industries could lead to a potential complex future with non-oil industries as well. This is further compounded by the complex history of the Harasiis tribe with oil, which may activate the Non-Oil node, one of the Economy nodes in blue, to ensure buy-in and greater internal cohesion of the tribe toward future endeavors. Note we could also stress test removal of certain ties, but when the idea is to stress test additional possibilities, we err on the side of greater inclusion and less on exclusion.
The third is that to increase sensing (in this case information sharing pertaining to the Harasiis tribes and other nomadic tribes), the scaffolding may also have to improve to account for such added information. In this case, the scaffolding structure may need increased information channels to nodes such as Infrastructure, Obstacles, and Non-oil as these could now be necessary to include in the base scaffolding to account for such tribes in an adequately informed way.
So far, we are using inferences based on proximate cases to socially “sense” where to further probe (i.e., using experiences with Neom to inform possibilities in Oman). However, to verify these assumptions, we will likely need to go to these areas physically and engage with these tribes directly. Nomadic tribes and other such marginalized communities are precisely those communities where we lack prior data and thus there is greater danger in overly relying on distant, and likely biased, inferences. As with previous steps, if any of these scenarios and others reveal additional crucial paths that were previously unknown, then we may need to revisit our prior scoping and scaffolding steps to ensure we include those nodes and ties and stress test again (the circular arrow between the “Deploy Action” and “Stress-Test Nodes and Ties” in Figure 2).
Final Step: Deploy Action
We are now ready to deploy an action based on our scoping, scaffolding, and sensing analysis. For the sake of demonstrating what such an action could look like, we will assume the boundary rule for the IMEC disruption that we discussed earlier. The rule was that the Sultanate will develop a rapid response plan to an IMEC-driven trade disruption if a 20% decline is observed in foreign direct investment to the Sultanate’s trade logistics infrastructure. The action in this scenario is the development of a rapid response plan. If the deployed action (rapid response plan in this case) was successful at bringing us back to an acceptable threshold (mitigating the 20% FDI reduction in this case), we revise the threshold for the rule since we would have arguably gained invaluable operational knowledge that improves our preparedness for such a disruption.
If the deployed action was not successful at bringing us back to an acceptable threshold, there could be two reasons. The first is if the action itself (i.e., the rapid response plan) was poorly managed. If that is the case, we revisit the action and redeploy it with better management (the circular arrow between “Map the Program” and “Deploy Action” in Figure 2). However, if the action failed due to unsupported assumptions of the original system map, then we iterate on the loop in Figure 2 and use the action to interrogate what we have learned and how we need to update the system map. In this way, the deployment of action(s) not only helps us to address critical challenges but also helps us to continuously iterate and strengthen the robustness of the system map. Even when deployed actions prove unsuccessful, their failures are a source of learning, hence the value of these actions, especially if done as small experiments that minimally divert resources.
Implementation Guidelines for S3 via a Realistic Hypothetical Scenario: Peacekeeping Missions
To both add granularity to how we implement S3 while also expanding the generalizability of this framework, let’s consider the hypothetical scenario of a multi-stakeholder peacekeeping major program that we fictitiously call PeaceBridge. PeaceBridge is deployed to keep the peace within a country that is just emerging from civil conflict that we fictitiously call NormaLand. While a hypothetical scenario, this is not far removed from scenarios that may be needed in light of current conflicts in the Middle East and eastern Europe. You serve as a consultant to the program, and you have decided to deploy the S3 framework to facilitate your work on this task.
You first build a baseline map for PeaceBridge. This comprises key components such as troops, barracks, and supply lines and maps the stakeholders that provide them such as defense ministries, construction companies, and shipping providers. To ensure a complete map, you conduct interviews, focus groups, and workshops to consult with key stakeholders such as former NormaLand combatant groups, government leaders, and peacekeeping experts, among others, to update the map and ensure it is as comprehensive and holistic as possible.
You are now ready for scoping. To do this, you focus on critical metrics that you deem as most impactful on program success. This could be deployment speed, supply costs, number of days without local access to basic necessities such as water, food, and shelter, and even the number of local community employment opportunities to help track post-conflict recovery and peace. Assuming that these metrics will drive where attention and communication is placed, you identify the stakeholders most critical for these metrics based on the number of linkages in the map to those stakeholders (or what network scholars call degree centrality). You work with PeaceBridge program leaders to set a threshold that would trigger program leaders to channel focus on these stakeholders when a disruption occurs that introduces vulnerabilities that could undermine success. Such a disruption could be a resumption of tensions or shipping backlogs that reduce key peacekeeping armaments or food supplies. To gauge the robustness of this threshold, you use past peacekeeping data or conduct realistic scenarios that could happen during the program to determine whether the set thresholds are fit for purpose. If these thresholds miss what prior data or simulated scenarios identify as warning signs of a disruption to come, then these thresholds are recalibrated.
Once scoping is deemed adequate, you now look into PeaceBridge scaffolding. To do this, you focus on critical information seen as most critical in tracking the aforementioned key metrics. To find the stakeholders proximate to this critical information, you look at how information flows within your map. In particular, you look at all the shortest paths between any two stakeholders in the baseline map and look for which stakeholders are most often on these paths (what network scholars call betweenness centrality), and/or you look for which stakeholders are in most frequent communication. You then look at how information is currently indexed or stored and which stakeholders have access to it. This could be as simple as a spreadsheet or as sophisticated as an Intranet system with a generative AI backend to help stakeholders search for different kinds of information and ascertain who has it. PeaceBridge would then look for mismatches between program objectives, information flows, indexing, and access. For example, if a critical metric is deployment speed but information tends to go to the operations teams but not to the general of the military outfit, then scaffolding needs to be updated to ensure the general is also plugged into that information flow. In this way, information flows, indexing, and access dictate the current state of the scaffolding and mismatches identify gaps that need to be bridged with updated scaffolding.
Once scaffolding is established and deemed adequately linked, you now engage in sensing. To do this, you focus on stakeholders who may be socially critical. To find stakeholders whose missingness may undermine program credibility or reinforce historic disparities, you look at where senior program leaders place their attention. Senior leaders will try to balance their time constraints and their informational needs through limiting ties only to the most connected program members (or what network scholars call eigenvector centrality). 52 You then look at these most connected members and you see they largely emanate from similar organizations, professions, and/or geographies. You see this as potential for the leadership to miss other potentially important stakeholders outside of these identified similarities, and you recommend ways for the leadership to get “outside of their heads” to explore these potential blind spots. Some ways are hiring external advisors from nontraditional program backgrounds, periodic leaderless meetings to gauge where focus goes when leaders are not steering the agenda, or even looking to bring out the more introverted voices on the program team, just to name a few possibilities.
You are now ready to deploy an action to gauge the robustness of the mapping and S3 exercise. Through your work, you and the leaders think a key influence on deployment speed will be navigating a particularly mountainous region in NormaLand. To probe into this hypothesis, you split the peacekeeping team into two and have one scale this mountainous terrain, and another navigate a flatter nearby terrain and see how long it takes both teams to reach a common destination point deemed mission critical. You measure the time difference between the two teams. If the time difference is within threshold, then resorting to soldiers on foot may be adequate. If the time difference is outside of the threshold, then you consider adding faster non-human assets such as drones. However, this may also necessitate adding drone location data to your existing scaffolding platform, so the peacekeeping military and operations teams can track drone whereabouts. You do several such probes until you have a MVS for which you are confident to scale as part of the delivery phase of the mission. After each program stage or milestone, you institute regular reviews and updates to assess what went well and what did not, and you use that information to evaluate any additional changes that need to be made to the mapping and S3 exercise that was deployed upon initiation of the mission. Table 1 summarizes the implementation guidelines used here in a more generalized way, so the reader can envision a wider range of applications beyond Oman Vision 2040 and this hypothetical peacekeeping mission.
Discussion
In this piece, we make the case for a framework that stays at the level of programs as opposed to projects to help us better capture not just individual project risk but the propagation of risk between projects within a program. Keeping such propagation in mind, we argue major programs are best conceptualized not as temporary organizations but as temporary ecosystems, or interlinked organizations whose project-based interdependencies last until the conclusion of the program. From that change in perspective, we propose the S3 analytical framework for understanding how value is derived from a major program. This framework has three parts. The first S is scoping—mapping where a major program is most vulnerable and to which kinds of disruptions. The second S is scaffolding—developing structures that coordinate across the program to link skills (who knows what) with requirements (who needs what). The third S is sensing—identifying and engaging those historically marginalized in major programs.
We then applied this framework to Oman Vision 2040 as a methodological proof-of-concept for this approach. The methodological approach developed here takes advantage of recent scholarly calls in the project management literature to leverage systems tools to help address the distributed governance challenges that typify major programs. 53 Our particular methodological advance here is that a key deficiency of these tools is that the resulting system maps can become quite elaborate, to the point they begin to lose practical value. 54 To address this, the methodological approach underpinning S3 is the development of tools, as well as accompanying heuristics and network measures, that are designed to help reduce this complexity by prioritizing where to explore in a system to better inform decision-making. In taking this approach, we employ insights regarding the value of system constraints 55 to help make these tools more actionable and usable.
Figure 2 integrates all the steps of implementing S3. Notably, one should not forget the small circular arrows at each step as these are conditions for which one may need to revisit prior steps, and these critically stress the nonlinear and iterative nature of this framework. To further help action these insights for practitioners, we provide a more generalized set of implementation guidelines in Table 1 that we apply to an illustrative hypothetical peacekeeping mission, and we also provide additional mapping and implementation guidelines in the mauscript’s Supplemental Material, as well as the Project S3 website (https://www.sbs.ox.ac.uk/research/research-areas/major-programme-management/project-s3).
We see this approach as generalizable not just to vision documents, such as those used here, but also to the strategic cases of other large-scale initiatives. 56 These could even be coded dynamically across strategic case updates to see how the framework’s diagnosis of a major program would evolve over time. Beyond this, we see this approach generalizable to other qualitative data such as interviews and other kinds of distributed major programs such as net-zero initiatives, peacekeeping missions, and “big science” programs such as quantum computing and fusion energy, to name just a few.
Scholarly Contributions from S3
We see S3 as especially contributing to the literature around capabilities and coordination in project management. This literature has shown how capabilities come together and are disassembled across projects 57 ; how capabilities are arrayed into repeatable configurations that can be deployed across many projects 58 ; and even possible guidelines for how to build such capabilities to handle the uncertainty inherent in major programs. 59 Similarly, the literature on coordination details how to effectively build coordination, 60 how to routinize coordination, 61 especially in more distributed organizational and team settings, 62 and who is most likely asked to engage in such coordination work. 63 Besides integrating these prior insights into a single program-level relational framework, we add to these literatures through adding greater clarity as to where (and not just who and how) one ought to build such capabilities and coordination when taking a programmatic view. This gap has important theoretical implications.
Namely, programs have many interdependencies that necessitate thinking at an ecosystems level to better identify and address quickly how risks may propagate throughout the program. However presently, the predominant systems thinking tools that advance such thinking become cognitively and computationally difficult to interpret when they incorporate the entirety of program linkages. 64 While recommendations exist for how to distill such system complexity, 65 they are abstract in their conceptualization and so how to implement them onto oft-used systems mapping tools remains unclear. The challenge then is again to decide where in the program to build such capabilities and coordination, especially given the time and labor-intensive processes needed to build and refine them in major programs of such significant size and scope. 66
S3 reconciles this by developing ways to scope the program system through simple rules and simplifying network measures that begin to help managers better isolate the critical features of their major programs and the novel capabilities and coordination mechanisms needed at these criticalities. Specifically, S3 helps major program managers more quickly hone into where in the program is most critical to build absorptive capacity 67 for detecting and managing disruptions more quickly. Moreover, in focusing not just on the critical direct nodes but also the indirectly tied nodes that feed into these criticalities (i.e., the support scaffolding that inform such critical system junctions), we can shift from focusing not just on alleviation (i.e., where to reduce risks) but also mitigation (i.e., how to stop the bleeding when a risk is not fully reducible as is oft the case with complex programs). While the prior literature on capabilities and coordination helps provide key tools for how to build capabilities, this framework helps provide a compass for where to effectively engage in such capability-building. Capability-building is a labor and time-intensive process, so S3 helps home in on the most critical program interdependencies for which such investments are likely to be most impactful.
Practitioner Contributions from S3
Table 2 translates the insights here into a playbook that can help practitioners better deploy these insights and understand how this impacts value from a major program. In the Project S3 website, we go into further detail as to possible protocols and guidelines for which one can use to gain additional insight into how to deploy this playbook. The first entails mapping the major program system. The resolution of such mapping depends on program scope and the manager’s locus of control and authority. Scoping focuses on mapping flows between all the elements in the program. In this manner, major program leaders can detect more quickly where disruptions will be most acutely felt in the major program. Scaffolding focuses on mapping capabilities across the entire set of actors within a major program. In this manner, major program leaders can more quickly grasp who knows what and connect that to who needs what within the distributed initiatives that typify a major program. Sensing focuses on mapping stakeholders in a major program, either involved directly or adjacent to program activities. In this manner, major program leaders are forced to more reflexively ask whether all stakeholders are accounted for and how to engage them sooner in the program’s development.
Summary Playbook for Practitioners to Deploy S3 Framework.
The second entails identifying criticalities. Scoping identifies, as well as ranks and prioritizes, disruptions, and the key stakeholders that proximate the locus of such shocks. More colloquially, this entails ascertaining what keeps you up at night (disruption) and who can help you rest (those proximate to the disruption). Scaffolding identifies bottlenecks, namely ,disconnects between who knows what and who needs what that are delaying the completion of work or hindering the development of novel knowledge and techniques to handle unforeseen challenges. This entails building support structures that help close such informational holes more quickly and efficiently in ways that are situated within program aims and objectives. Sensing identifies gaps, namely, those stakeholders who have been historically missing and excluded and who are critical to both achieving and sustaining program aims. This entails building new information channels to identify those who previously remained anonymous, to the program’s detriment.
The third entails coordinating action. Scoping coordinates learning, namely between those organizations that proximate where prioritized disruptions are anticipated to impact the program most acutely. This entails new contractual mechanisms and experimentation to help build the psychological safety to engage in such learning. Scaffolding coordinates expertise, namely with those who have key knowledge and skills to help complete program work. This entails new digital and organizational tools to identify such at-hand skills more quickly. Sensing coordinates engagement, namely with those stakeholders who have not been included in such programs historically but are recognized as consequential to its delivery and benefits. This often entails working with communities who intersect such programs and developing new approaches that set and iterate objectives as well as periodic reviews to ensure continued consensus and compliance.
In so doing, major programs transform value. Scoping helps protect value from disruptions that can present additional costs that can reduce value. Scaffolding helps create value through identifying expertise and skills more quickly and how they can be recombined in novel ways to generate new techniques that enhance program objectives. Sensing helps distribute value in ways that ensures those historically excluded from such programs also receive their fair share of program benefits.
Overall then, S3 is akin to an early warning detection system. Each of the three components alert to potential critical absences and risk propagation that can undermine ability to protect, create, and/or equitably distribute value. Through this process of mapping the system; setting priorities and thresholds, identifying the right support structures; stress-testing for missing nodes and ties, and deploying actions, we are unifying what previously was individual project-level risk assessments into a more integrated program-level perspective. Concisely put, previous work focused on project “trees”; we are assembling these together to better see the program “forest.”
This work is only the start. We have in this essay sketched out a provocation to progress an approach to major program thinking and delivery in ways that map onto and scale to the increasingly distributed features of our global grand challenges. We see these novel challenges in the world today, and we assemble the S3 framework as a first armature on which to build a new generation of tools, components, and practices in support of major programs seeking to tackle these new pressing challenges of our time.
Supplemental Material
sj-docx-2-cmr-10.1177_00081256251324255 – Supplemental material for Major Program Value Creation and Capture: The S3 Framework for Mitigating Risk Propagation to Maximize Opportunities
Supplemental material, sj-docx-2-cmr-10.1177_00081256251324255 for Major Program Value Creation and Capture: The S3 Framework for Mitigating Risk Propagation to Maximize Opportunities by Daniel Erian Armanios, Marc J. Ventresca, Maher K. Itani and Malcolm McCulloch in California Management Review
Supplemental Material
sj-pdf-1-cmr-10.1177_00081256251324255 – Supplemental material for Major Program Value Creation and Capture: The S3 Framework for Mitigating Risk Propagation to Maximize Opportunities
Supplemental material, sj-pdf-1-cmr-10.1177_00081256251324255 for Major Program Value Creation and Capture: The S3 Framework for Mitigating Risk Propagation to Maximize Opportunities by Daniel Erian Armanios, Marc J. Ventresca, Maher K. Itani and Malcolm McCulloch in California Management Review
Footnotes
Acknowledgements
The authors are grateful for the comments and suggestions from Andy Buschman, Saul Betmead de Chasteigner, Andrew Davies, Matthias Holweg, Martina Huemann, Giorgio Locatelli, William Ocasio, Rafael Ramirez, Christine Unterhitzenberger, as well as seminar participants at the 2023 British Academy of Management (BAM) Annual Meeting—Project Experiences Track and at the University of Illinois Urbana-Champaign Gies College of Business’ Illinois Strategic Organizations Initiative (ISOI). The authors also want to thank three anonymous referees, editor Nuno Gill, and editorial staff members Paul Lee, Kora Gonzalez, and Gundars Strads for their useful comments and editorial guidance that helped to significantly improve the manuscript. An earlier version of the paper was presented as part of the first author’s Inaugural Lecture at the University of Oxford.
Supplemental Material
Supplemental material for this article is available online.
Notes
Author Biographies
Daniel Erian Armanios is the BT Professor and Chair of Major Programme Management at the Saïd Business School, with a Courtesy Appointment in the Department of Engineering Science, and a Professorial Fellow at St Anne’s College at the University of Oxford (email:
Marc J. Ventresca is an Associate Professor of Strategic Management at the Saïd Business School and a Governing Body Fellow of Wolfson College at the University of Oxford (email:
Maher K. Itani is a Senior Advisor for Oman’s National Vision 2040 (email:
Malcolm McCulloch is a Professor of Energy Systems in the Department of Engineering Science and a Governing Body Fellow of Christ Church at the University of Oxford (email:
Supplementary Material
Please find the following supplemental material available below.
For Open Access articles published under a Creative Commons License, all supplemental material carries the same license as the article it is associated with.
For non-Open Access articles published, all supplemental material carries a non-exclusive license, and permission requests for re-use of supplemental material or any part of supplemental material shall be sent directly to the copyright owner as specified in the copyright notice associated with the article.
