Abstract
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
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
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
The first “S” is
The second S is
The third S is
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
How can we potentially navigate this tension? First,
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
How can we potentially navigate this tension? First,
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
How can we potentially navigate this tension? First,
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
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
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
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
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
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
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
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
Summary Playbook for Practitioners to Deploy S3 Framework.
The second entails
The third entails
In so doing, major programs
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
Supplemental Material
Author Biographies
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.
