Major Program Value Creation and Capture: The S 3 Framework for Mitigating Risk Propagation to Maximize Opportunities

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. ²⁶

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, ²⁷ 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 ²⁸ 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 ²⁹ 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. ³⁰ Building repositories such as data lakes and intranet systems with commonly agreed-upon indexing ³¹ 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. ³² Given major programs are distributed across several different sites, achieving such granularity is likely to be highly resource-intensive. ³³ 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, ³⁴ 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, ³⁵ 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.

Initializing Step: Baseline System Mapping

The first step of applying S³ in practice necessitates building a baseline map of the program. This combines cognitive mapping with open and axial coding methods. ³⁶ 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. ³⁷ 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 S³ 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.

OPEN IN VIEWER

Table 1.

Implementation Guidelines for Applying S³.

S3 Implementation Guidelines
1. Map the Program: Identify Key Components and Stakeholders	Components: Break down the major program into its key components (For example, in the case of a major tunnel program, key components may be: Geotechnical, Mechanical, Electrical, Plumbing, Ventilation, Safety, among others)
	Stakeholders: List all major stakeholders, including governmental bodies, sub-contractors, local communities, environmental groups, investors, and future users. These are any entity that influence the key components and that socially or physically intersect with the program, even those beyond program delivery
	Interviews, Focus Groups, and Workshops: To verify and update the map, conduct interviews, focus groups, and workshops to consult with each relevant stakeholder to ensure no prominent component or stakeholder is missed.
2. Scoping: Identify Priorities and Thresholds	Metric Criticality: Evaluate metric criticality based on the set of metrics that matter most to the success of the program. Consider factors like impact on time, cost, safety, benefits realization, and quality.
	Influence: Determine the influence of stakeholders on program metrics and hence where disruptions will make the program most vulnerable. Looking at the number of linkages going into or out of the baseline map can be helpful (i.e., degree centrality ). More linkages to a stakeholder reflect vulnerability to disruptions that can occur due to bottlenecks within the program (endogenous disruption). Less linkages to a stakeholder reflect vulnerability to disruptions that can occur from unanticipated outside events (exogenous disruption)
	Simulation: Look at past data or conduct a realistic scenario to gauge at what point along a critical metric do you see a tipping point for which a disruption becomes clear. As known disruptions arise, gauge whether this threshold helped you anticipate them and if not, change the threshold.
3. Scaffolding: Coordinate Proximation Organizations	Information Criticality: Evaluate information criticality based on which stakeholders in your baseline map are critical to how information flows throughout the program. Looking at the shortest paths between any part of the map and which stakeholders are most found on these shortest paths can be helpful (i.e., betweenness centrality ). Tie frequency (i.e., how often is a link between two stakeholders mentioned) may also help in gauging information criticality.
	Indexing and Access: Determine where information is stored and who has access to it. This could be something as simple as a spreadsheet to as sophisticated as an Intranet system with generative AI backend to search for information and who possesses said information.
	Mismatches: Look for mismatches that necessitate additional scaffolding. Mismatches could occur if information critical stakeholders are not able to access existing information or are not part of information storage, as well as could occur if the key metric outputs to achieve program success are disconnected from key information inputs. When mismatches are identified, scaffolding should be updated to bridge those gaps.
4. Sensing: Stress-Test Nodes and Ties	Social Criticality: Evaluate social criticality based on whether a prominent stakeholder is missing, which would undermine program credibility or reinforce historic disparities.
	Executive Attention: Focus on where the attention is placed from senior program leaders to determine which stakeholders may be missing. Senior leaders often balance time constraints with need for information through connecting to the most connected others in a program (i.e., eigenvector centrality ). Look at those most connected others and if they come from the same organizations, professions, and/or geographies, then there may be a prominent blind spot which needs attention.
	De-centering: Finding blind spots necessitate getting out of one’s head. Such ways to do this is hiring external advisors from nontraditional program backgrounds, leaderless meetings to ensure the leader is not oversteering the conversation, and even bringing out the more introverted voices in a program.
5. Deploy Action	Experimentation: Select a pilot project that probes into a hypothesis that posits how a key criticality will drive program success or not. Ensure you test one hypothesis at a time to ensure learning is unambiguous. Finding what works and what does not work is equally valuable. If something works, consider scaling it up as part of program objectives. If something does not work, update the baseline map or your scoping, scaffolding, and/or sensing to account for this finding.
6. Regular Review and Update	Review and Update: Regularly review and update the map to reflect program progress, changes in stakeholder criticality, change in informational needs, and reassess missingness based on new components or risks that emerge with program learning.

Our choice was the Oman 2040 vision document. ³⁸ 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 S³ 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.

OPEN IN VIEWER

Figure 2.

Illustrative methodological approach for implementing the S³ 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 S³’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 S³ website, and our axial coding scheme can be specifically found in Table A1 on the Project S³ 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 S³ framework.

Major programs are so distributed that keeping a census of all the possible connections, let alone consequences, is highly difficult. ³⁹ 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 S³ 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 S³ 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 S³ 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. ⁴⁰ 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, ⁴¹ 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. ⁴² 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. ⁴³ Simple rules are heuristics or rules of thumb. While heuristics can generate bias when answers are known, ⁴⁴ they can be useful when dealing with issues of complexity and ambiguity that are less known and are typical in major programs. ⁴⁵ 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). ⁴⁶

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, ⁴⁷ 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. ⁴⁸ 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. ⁴⁹

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. ⁵⁰ We chose the Harasiis because this tribe resides in one of the most remote and desolate places in the Sultanate. ⁵¹ A group this remote is a useful candidate for what the sensing component under the S³ 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 S³ via a Realistic Hypothetical Scenario: Peacekeeping Missions

To both add granularity to how we implement S³ 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 S³ 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). ⁵² 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 S³ 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 S³ 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.

Scholarly Contributions from S³

We see S³ 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 ⁵⁷ ; how capabilities are arrayed into repeatable configurations that can be deployed across many projects ⁵⁸ ; and even possible guidelines for how to build such capabilities to handle the uncertainty inherent in major programs. ⁵⁹ Similarly, the literature on coordination details how to effectively build coordination, ⁶⁰ how to routinize coordination, ⁶¹ especially in more distributed organizational and team settings, ⁶² and who is most likely asked to engage in such coordination work. ⁶³ 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. ⁶⁴ While recommendations exist for how to distill such system complexity, ⁶⁵ 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. ⁶⁶

S³ 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, S³ helps major program managers more quickly hone into where in the program is most critical to build absorptive capacity ⁶⁷ 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 S³ helps home in on the most critical program interdependencies for which such investments are likely to be most impactful.

Practitioner Contributions from S³

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 S³ 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.

OPEN IN VIEWER

Table 2.

Summary Playbook for Practitioners to Deploy S³ 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, S³ 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 S³ 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.