2.0 Program Development

2.1 Chapter Introduction

2.1.1 The What and Why of the Program

2.1.2 Context of This Chapter of the Guide

2.1.4 The Prototype

2.1.5 Availability and Priority of Instantiation Sites

_**

2.1.6 Adverse Forces

2.1.7 System Wide Master Plan

_**

2.1.8 Living System Alignment

2.1.9 Program Services and Support

2.2 Program Planning and Guidelines

2.2.1 The Meta Project Program Statement

Left Off Here TKTK Fold into The Lionsberg Handbook

2.2.2 The Prototype

The Prototype is a living conceptual model developed by the Program.  It is being developed in an effort to take the Conditions of Satisfaction articulated in the Meta Project Program Statement, and turn them into a working prototypical system that can be locally adapted and implemented.

The Prototype was developed to allow flexibility in responding to the emerging determination of the following:

  • The unique arrangement of any given System instance;
  • The scale of any given System instance;
  • The components of the System that will need to be designed, built, or transformed in any instance;
  • The geographic location of the instance, and
  • The unique sequences in which elements will be prioritized for instantiation.

By instance or Instantiation, we mean any local or global domain in which the System is implemented.

Given the uncertainty surrounding the condition of existing systems and forecasts of future population, demographic, and environmental changes, the Prototype is being designed to adapt to various needs, including 1) designing and building New System elements from the ground up, 2) transforming / remodeling existing system elements, and / or 3) removing and replacing elements of the Old that are incompatible with the New.

Like the Meta Project Program Statement and the Program, The Prototype is a “living” experiment.  At the early stages of development, the Prototype will be more general in nature, demonstrating the primary architectural features and operational criteria.  As the Program becomes more defined and reaches higher levels of articulation, the Prototype will evolve in its development as well.  Key development phases will include:

  1. Prototype Development and the Kit of Parts
  2. Preliminary Design and Site Adaptation
  3. Detailed Design, Build, and Operationalization Documents
  4. Prototype Control
  5. Prototype Replication and Scaling

The following section will discuss Phase 1 - Prototype Development and the Kit of Parts.  Phases 2-4 will be reviewed in detail in subsequent sections of this Guide.

The initial development of the Prototype will result in a conceptual Kit of Parts. The kit of parts represents the primary potential physical, structural, cultural, and technological elements necessary to support the various programmatic components identified in the MPPS.  Whether the instantiation is a new build, and transformation, or a remove and replace, the Kit of Parts approach ensures a design solution that provides uniform and interoperable opportunity for any individual, organization, or community to develop and achieve its Potential and flourish in local and global community.

The following describes some preliminary components included in the kit of parts:

2.2.2.1 Integrated Architecture Plan (IAP)

The Integrated Architecture Plan orients all IPD Teams to the total Program design, why it is crucial to our survival as a species, and why it is critical to optimize for the success of the total System, rather than any sub-system. This is crucial to ensuring that all sub-systems are designed to be interoperable and help all other sub-systems Spiral Upward towards the Goal. In order to prevent IPD Teams from inadvertently wasting time, money, energy, and sub-optimizing, no IPD Team or initiative should be initiated or integrated without a thorough understanding of its relationship to the IAP and the Meta Project as a Whole.

2.2.2.2 Physical and Systems Plans and Specifications

Plans and specifications will be developed based on the most current MPPS and any further Program development or modifications.  All architectural plans will be developed indicating purpose, intention, requirements for local and global interoperability, the general scope and scale configurations, materials and technology requirements, Conditions of Satisfaction, and all other information appropriate to the specific element being addressed, to an appropriate level of detail to allow for budgeting, planning, and design-build proposals from IPD Teams.

2.2.2.3 Integrated Safety and Security Plan (ISSP)

The Integrated Safety and Security Plan, or ISSP, is a design document which records safety and security systems, their related operational decisions, and staffing in one document.

The development of the ISSP starts as an extension of the MPPS and continues in logical steps to its completion.  The ISSP is being developed to reflect the full range of safety and security issues, from minimum to high degrees of severity and risk, considering the realities in different parts of the world.

The final work product is a Integrated Plan that combines all of these components into a highly descriptive document, and comprehensively defines and directs safety and security design requirements for each instance, and for the Whole.

2.2.2.4 Structural Building Blocks

Major structural building blocks and sub-systems for the System are shown, including how they are connected to local / fractal instantiations to ensure global interoperability and resource flow. Each essential element will be identified and shown, as well as optional additional elements. Requirements will be identified to help calculate the load that each element of the system will be required to bear to prevent local failure, and how energy and resources will be allocated to meet the loads. General requirements for the foundations of the systems and infrastructure will be identified. Scale and scope requirements will be identified in ranges for budgeting and planning purposes.

2.2.2.5 Logistics and Distribution Systems

Major logistics and distribution systems and their general functions will be determined, with a focus on the connection / Handoff Points points where local meets regional meets global systems. Resource distribution systems and their general functions will be determined.  The general layout of the central (if any) and regional distribution hubs will be included.  Systems, equipment, facilities, loads, sizing, and placement will be identified for the global and regional scales. Standards and best practices for all major system components will be articulated, as well as delivery guides for the "last mile" connections to local instantiations.

2.2.2.6 Toxins and Waste

Disposal and cleansing systems for toxins and waste, and their local, regional, and global interrelationships and impacts will be determined. Primary sources and Root Causes of waste and toxins will be identified, and frameworks will be established to empower local instantiations of the System to stop waste and toxins at their source, while cleansing and regenerating the Living System. Major toxin and waste hubs will be identified, with plans for short and medium term management and long term elimination. Special attention will be paid to systems and methodologies for dealing the small percentage of sites and causes driving the bulk of pollution.

2.2.2.7 Disaster Prevention and Emergency Response

Disasters will be analyzed and categorized, and root cause analysis performed. Appropriate prevention and response systems will be intelligently established based on risk analysis amplified for future uncertainty and unpredictability. All planning and analysis should be based on the fact that we are entering an entirely unpredictable new season of life on earth, which may be far less stable than the recent past until the System has been established, the wounds have been healed, and New normal is forged. Systems that are fragile to unpredictability  should be transformed. Systems that are globally dependent should be relocalized. This analysis should apply to disasters of every type, across all systems, including but not limited to natural, political, social, and health systems. This element of the plan should not be underestimated. In seasons of historic transition and transformation, we cannot overprepare or become overly antifragile.

2.2.2.8 Energy

Energy systems, and their local, regional, and global interrelationships and impacts will be determined. Primary requirements and loads will be established and listed by region. General fractal deployment concepts to make the energy from the sun, wind, and gravity available in all domains of inhabitation will be articulated. Major energy transport systems will be re-evaluated, and a global plan established for local and regional energy sovereignty and access enacted.

2.2.2.9 Aesthetics, Recreation, and Comfort

The basic patterns that foster a sense of beauty, recreation, and comfort in a community will be identified and mapped in a Pattern Language that can be fractally replicated at appropriate local scales. Major systems and facilities that impact community spaces will be identified, and recommendations provided for creating life-giving patterns of coherence in any local space.

Planning and budgeting shall include provisions to provide for aesthetics, recreation, and comfort in addition to pragmatic function.

2.2.2.10 Water Systems

Plans for healing and regenerating the living waters of the earth shall be established. The major water systems shall be mapped and articulated by watershed. Local watershed councils shall be established to learn together and share best practices for transforming watershed health. A basic global water quality monitoring system shall be established rooted in decentralized local Citizen Science. Frameworks shall be established for identifying the root causes of water pollution, and stopping water pollution at its source.

The water that cleanses and gives life to all things is not for sale or exploitation. All global water agreements shall be re-evaluated as necessary to return water sovereignty to local communities and ecosystems. All rights to pollute or exploit water shall be systematically revoked and transformed into agreements of stewardship for the wellbeing of all generations of life.

2.2.2.11 Land Systems

Plans for healing and regenerating the land and soil shall be established. The major land systems shall be mapped and articulated. Local land councils shall be established to learn together and share best practices for transforming land and soil health. A basic global land-quality monitoring system shall be established rooted in decentralized local Citizen Science. Frameworks shall be established for identifying the root causes of land and soil degradation, and stopping degenerative activity at its source.

The land and soil that nourishes and gives life to all things is not for sale or exploitation. All global land agreements shall be re-evaluated as necessary to return land sovereignty to local communities and ecosystems. All rights to pollute, degenerate, or exploit land shall be systematically revoked and transformed into agreements of stewardship for the wellbeing of all generations of life.

2.2.2.12 Air Systems

Plans for healing and regenerating the air all life breathes shall be established. The major air systems shall be mapped and articulated. Local air councils shall be established to learn together and share best practices for transforming air health. A basic global air-quality monitoring system shall be established rooted in decentralized local Citizen Science. Frameworks shall be established for identifying the root causes of air quality degradation, and stopping degenerative activity at its source.

The air that all life breathes is not for sale or exploitation. All global air agreements shall be re-evaluated as necessary to return air sovereignty to local communities and ecosystems. All rights to pollute, degenerate, or exploit the air shall be systematically revoked and transformed into agreements of stewardship for the wellbeing of all generations of life.

2.2.2.13 Food Systems

Plans for ensuring that all life has access to pure high quality food shall be established. The major food systems and supply chains shall be mapped and articulated. Local food councils shall be established to learn together and share best practices for transforming food sovereignty. A basic global food-quality monitoring system shall be established rooted in decentralized local Citizen Science. Frameworks shall be established for identifying the root causes of food quality and agricultural land quality degeneration, and stopping toxic foods and food-practices at their source. Fractally replicable building blocks shall be established to systematically re-localize, re-naturalize, and re-complexity food systems to ensure local and regional food sovereignty.

2.2.2.14 Capital and Debt Systems

Plans for healing and regenerating individuals, organizations, and communities plagued by existing capital and debt systems shall be established. Major systems of capital and debt shall be mapped and articulated. Local capital councils shall be established to learn together and share best practices for transforming the local creation and exchange of value. A basic global capital-quality monitoring system shall be established rooted in decentralized local Citizen Science]]. Frameworks shall be established for identifying the root causes of capital and debt exploitation, and for stopping harmful capital and debt activity at its source.

The regenerative creation and exchange of Value amongst the inhabitants of the earth is not for sale or exploitation. All capital and debt agreements shall be re-evaluated as necessary to return financial and economic sovereignty to local communities and ecosystems. All rights to degenerate and exploit people, communities, and ecosystems shall be systematically revoked and transformed into agreements of stewardship for the wellbeing of all generations of life.

Special care shall be taken to ensure that systems of exchange cannot be boxed in or subjected to totalitarian or oligarchical manipulation or control.

2.2.2.15 Economic Systems

Plans for the overall production and consumption of goods shall be established, in a way that rightly relates all other components to one another and the Living System.

2.2.2.16 Systems of Regenerative Justice

Plans for healing and regenerating individuals, organizations, and communities plagued by corruption, injustice, or oppression shall be established. Major systems of sovereignty and justice shall be mapped and articulated. Local sovereignty and justice councils shall be established to learn together and shared best practices for transforming and establishing local systems of sovereignty and justice. A basic global sovereignty and justice monitoring system shall be established rooted in decentralized local Citizen Science. Frameworks shall be established for identifying the root causes of injustice and lack of individual and local sovereignty, and for restoring justice and sovereignty to all individual beings.

The individual sovereignty and worth of all sacred forms of life, and especially of creatively conscious human beings, is not for sale or exploitation. All systems of justice and delegation of authority shall be re-evaluated as necessary to return individual and local sovereignty and justice to local communities and ecosystems The System shall ensure that all authority flows properly from its Source throughout the living system without corruption or interruption. All rights to exploit any form of life, or remove its individual sovereignty or Free Will, shall be systematically revoked and transformed into new agreements which establish and respect the irrevocable sovereignty, rights, and responsibilities of each individual being in direct right relationship to all other beings and their Source.

2.2.2.17 Community Development System

All components of the System will integrated into a integrated Community Development System, through which any local community can progressively discover and realize its unique potential in harmony with all other global communities engaged in the System.

2.2.2.18 Organizational Development System

An Organizational Development System shall be developed, through which any organization can progressively discover and realize its unique potential in harmony with all other organizations engaged in the System.

2.2.2.19 Human Development System

A Human Development System shall be developed, through which any individual can progressively discover and achieve their unique potential in harmony with all other individuals engaged in the System.

2.2.3 Program Requirements

2.2.3.1 Plans and Specifications

The total concept and design of The Prototype will be articulated in a set of Lionsberg Plans and Specifications. The Plans and Specifications shall outline not only the functioning of the System and Prototype, but also the way in which it will be instantiated locally, and the way in which all instantiations can interoperate for the good of All.

The Plans and Specifications, this Program Delivery Guide, the Meta Project Program Statement, and the The Book of Lionsberg manuscript will be formatted and made available digitally in as many languages as possible relatively simultaneously around the globe. This is critical so that the pattern language can be activated in unison by IPD Teams around the world, around interconnected local and regional nodes, so that the pattern of transformation / global movement towards the Goal cannot be interrupted by any attack.

2.2.3.2 Program Schedule

An overall Program Schedule will be developed and will reflect key milestones established in conjunction with the plans and pull planning sessions including all key stakeholders for each phase.

The schedule will be broken out into a Work Breakdown Structure that will incorporate all relevant systems, goals, and Action Domains, as well as regional and cultural Integration Domains.

The Program Schedule shall either be unified with, or reflect all elements of, the System Wide Master Plan.

The full schedule will be updated, cycled, and published no less than every month, with a formal update presented to the Receiver each month.

2.2.3.3 Planning System

The Program Schedule shall be part of an integrated Planning System.

2.2.3.4 Mission Control

A Mission Control function or guild shall be established to provide rigorous monitoring, controls, and variance reporting spanning the entire Program.

Mission Control shall include intelligent Dashboards that track activity, progress, and issues across the entire Program to facilitate high quality and timely Decision Making. At a minimum, the Mission Control Dashboard will flag issues and variances, and provide Green, Yellow, and Red health indicators for all key teams, projects, and domains, as well as for the Program as a Whole.

2.2.3.5 Domain Councils

Each Action Domain and each Integration Domain will establish a Domain Council to discern and guide intention and strategy. Domain Councils operate in service and support to the leaders, organizations, and best ideas being generated in a given domain. The highest intention and strategy that the Domain Councils can discern should be funded / empowered / accelerated for successful IPD Team implementation.

Domain Councils will be responsible for protecting and continuously elevating the quality of the intention and strategy for the domain.

2.2.3.6 Integrated Project Delivery Teams (IPD Teams)

IPD Teams will voluntarily take responsibility for executing on the intention and strategy discerned by the Domain Councils, and for regularly reporting on progress, issues, and improvements.

IPD Teams will be sovereign and autonomous, and take action on a purely voluntary basis in response to the needs and critical path discerned by the Whole.

IPD Teams will not be directed or controlled from "above".

IPD Teams will be intentionally cultivated and balanced by the Federation to ensure a proper array of personality types, skill sets, and leadership on each team. IPD Teams will be designed so that they can function and carry out their Commitments regardless of connection to the Meta Project infrastructure and services that support them.

The global network of IPD Teams should plan for periodic separation in their ability to communicate with and receive support from Headquarters / the Core Enterprise.

Eventually, it may be wise for each IPD Team to have an embedded Headquarters element to serve as a advocate / liason between Headquarters and the IPD Team, and operate as a voice of the Whole in the event of any disruption in communications or support.

2.2.3.7 Guilds / Communities of Practice

Guilds will take responsibility for organizing, training, mentoring, and sharing knowledge among various trades or communities of practice.

Guilds should establish programs for discerning aptitude, apprenticing, and ensuring continuity of development and deployment among its members throughout the Whole.

Guilds should coordinate with one another and the IPD Teams to ensure appropriate representation of the right skills and perspectives, at the right times, for the right reasons among the various teams and System elements.

2.2.3.8 Headquarters

The Receiver and Program Manager shall establish a digital, and physical if necessary, Headquarters to guide, empower, and coordinate the efforts fo the globally distributed IPD Teams.

Headquarters will be the nominal "place" from which the Core Enterprise operates in service of the Whole.

Headquarters shall ensure that IPD Teams, while operating in functional unity, are each strong, self-sustaining and capable of surviving and accomplishing their Goal even if they were to lose contact with Headquarters or a portion of the distributed network of IPD Teams for a significant period of time.

Headquarters shall train, empower and embed HQ elements in each IPD Team as necessary to represent and advocate for the integrity, understanding, and optimization of the Whole to the IPD Team, and to advocate for the sovereignty and local issues and needs of the IPD Team to Headquarters.

2.2.3.9 Services and Support

The Program Manager and Core Enterprise will establish operational criteria for the Service and Support functions required to empower the network of IPD Teams.

This includes determing logistically how to connect up thousands or millions of such teams around the world with the knowledge, resources, services, information, and technology they need to efficiently advance.

2.2.3.10 Logistics and Supply Chains

The global logistics and supply chain should be evaluated, and should include efforts to simultaneously leverage joint scale and purchasing power for resource intensive components of the System, while focusing on local sourcing and capacity building to strengthen local domains. Logistics and supply chain systems should ensure that IPD Teams have a way to communicate needs and gaps in resources, in a way that the Program can efficiently respond to.

2.2.3.11 Consulting Guilds

Experts will be required in a variety of areas. The following consulting guilds have been identified as key early participants in the future refinement of the prototype and kit of parts. These consulting guilds may substantially overlap with, or be folded into, the domain councils.

1.     Regulatory and Code Consulting - A strategy and plan will be developed to keep the Program in compliance with various global jurisdictions, while transforming laws and authority where they stand in the way of the wellbeing of life.

2.     Security Consulting - Communication, electronic, IT, software, hardware, conferencing, and physical security systems will be identified, described, specified, and mapped. Security plans for global operations in dangerous zones shall be specified and mapped. Security plans, as they are developed, should provide frameworks for identifying and transforming the root causes of violence and fear in an area.

3.     Health and Wellness – All primary components of health and wellness shall be identified, along with the basic process and frameworks for giving people the opportunity to progress from their current state of wellbeing, towards their best and highest potential, by diagnosing and curing the root causes of illness and suffering. Major system components will be mapped, and plans for fractal deployments developed. These plans should include a global tele-wellness platform to link international resources to underserved local needs.

4.     Learning – A strategy and plan will be developed to provide a system of interactive, project-based, life-long learning and development for all project participants. This platform should be developed in such a way it can be extended into a learning and development platform available to the entire Global Community, to ensure that every being has the opportunity to discover and achieve their potential.

5.     Work Flow Consultants / Value Stream Mapping – Utilizing the value stream mapping (VSM) process (or better), functional spaces and staffing will be adjusted based on the analysis and benchmarking of current and industry best practices. The work will provide updates to the staffing and space needs resulting in the basis of operations development and training.

6.     Military and Law Enforcement - A strategy and plan will be developed for engaging with local military and law enforcement, across the highly complex range of quality and corruption present around the world. Plans will be developed to leverage and connect forces of goodwill, while neutralizing and protecting against corrupt forces.

7.     Energy - This effort will define energy usage and allocation. Based on current operating practices and future design opportunities, energy use and conservation strategies will be developed to provide for best practices related to procurement and consumption. Energy modeling will be performed as the design options are developed to support and inform system and utilization choices. The modeling will include demand analysis, seasonal profiles, and plans for regional balancing. Options for evaluation will include design/build/operate feasibility and scalability.

2.2.3.12 Functional Organization Chart

Deployment of appropriate resources requires organizing around the processes necessary to efficiently and effectively complete each phase of the Program. A single Functional Organization Chart (“FOC”) should be developed and maintained, which views all IPD team members as members of a single entity, as if they all operated within a single organization.

This view is designed to use the best resources available on the Program regardless of that resource’s “home” organization.

The FOC first describes functions, or categories of processes, required to successfully complete the program in the fastest and most cost-effective manner.  Within each function, the relevant processes are described.  For each specific process, each task needed to complete the process is designated and then each task is broken down into a job description.

This level of functional systems mapping should occur in concert with the Value Stream Mapping efforts elsewhere.

2.2.3.13 Redundancy Among All Functions and Domains

In the distributed global Federation of sovereign individuals, organizations, and communities, every function and every domain should have redundancy.

No one sovereign owns any functional or domain area, and all single points of failure should be specifically and progressively eliminated.

2.2.4 Quality and Safety

In contrast to traditional quality and safety programs where the greatest emphasis on quality and/or safety occurs during the build / implementation phase, Integrated Delivery requires all stakeholders to maintain an integrated, collaborative focus on quality and safety starting with planning, through design, through build, through activation and continuing on into operations.

The importance of bringing the long term considerations of resource consumption, quality, and safety, considered over the entire lifecycle of the system or facility, back into the planning and design phase cannot be overemphasized.

Considerations of quality and safety are woven into the fabric of the entire Program.

2.2.4.1 Quality

Quality serves as a basis for design throughout the Program.  “Built-in Quality” is a key component of Lean Integrated Delivery because it assumes that the final product must meet the customer’s definition of Value.

An early understanding of the customer’s Conditions of Satisfaction related to Quality influences both design and implementation while helping to reduce waste.

Waste in the context of Quality covers two main ideas:

  1. Quality that exceeds the customer’s requirements. This results in taking unnecessary steps to over process the work.
  2. Quality less than the customer’s requirements. This results in unacceptable work requiring repair or rework, scrap, replacement production, re-inspection and delay.

In a Program such as this, one must distinguish between Design Quality (what level of facilities, systems, and infrastructure is required) and Build Quality (how do we avoid rework, trade damage, etc.)

During the planning and prototype development processes, the Program will invite a number of stakeholders to assist in defining acceptable levels of Quality for various applications throughout the Program.  Those stakeholders and their contributions may include:

1.     A group that visits various parts of the world to investigate the ranges of Quality of Life currently available. The level of Quality described in the Meta Project Program Statement is based, in part, on preliminary parts of this investigation.

2.     End users of the New World will be brought in to the early stages of prototype development to refine needs and expectations including what level of Quality would be required in an instantiation of the System.

Quality has been reviewed in the early stages of design and will be constantly reviewed throughout design and implementation.  Defining the appropriate level of build Quality will help to eliminate:

  1. Errors and defects allowed to accumulate for corrective action at a later date;
  2. Follow-on inspections necessary to ensure quality is met; and
  3. QA/QC inspectors who remain at odds with what is acceptable due to misunderstandings regarding the level of Quality.

2.2.4.2 Safety

The Program recognizes the importance of a program-wide view of Quality and Safety.  Effective safety management throughout planning, design, implementation and operationalization can minimize risk to the health and safety of people who build, occupy and maintain an instantiation of the System. Safety concerns are addressed in four specific areas of Program Delivery:

  1. Safety-In-Intention
  2. Safety-In-Planning
  3. Safety-In-Design
  4. Safety-In-Action

Developed safety strategies are based on the following principles:

  • Projects contain inherent risks. This truth is acknowledged by the Program. Individual training and motivation, posters in work areas, and stand-up safety programs are not enough.
  • Procedures alone cannot guarantee safety. Safety is culture. It comes from having skillful and knowledgeable workers who are alert to known safety concerns.  It also requires an organization committed to continuously improving safety through continual monitoring and feedback from the task sites. Moreover, responsibility and vigilance by all workers is important to create a culture where the the gap between procedures and practice is constantly narrowed.
  • Human error is a symptom of trouble deeper inside the system. People do not intentionally cause accidents or injure themselves. Where breaches occur, it is necessary to look further into the system to determine both the human and system failures.

The section below reviews Safety-in-Intention and Safety-In-Planning.  Subsequent sections will describe Safety-In-Design and Safety-In-Action as they apply to the development of the Program.

Safety-in-Intention

Even before planning and design, Safety begins in the very inception of the idea. If a Program of Action is not conceived from the beginning with the right heart and intention, the proper considerations will not be integrated through all subsequent phases, and people and the Living System will be harmed.

Safety-in-Planning

Traditionally decisions on site logistics and building sequencing are made by the General Contractor and given to the subcontractors to execute. This command and control structures leads to performance pressures. Pre-task planning is well intentioned but usually focuses on productivity and not on safety.

Materials are often brought to the project earlier than needed and stored on site where they end up being moved or relocated, often causing injuries to workers or damage to the goods.

By including a diversity of stakeholders as early as possible in the project, and ensuring those stakeholders are the people actually leading the work and not just executives, a more realistic Logistics and Sequencing Plan can be developed.

More accurate schedules based on Pull Planning result in safer and higher quality work.

Any Constraints to the schedule that may arise can be identified and viewed by the team, and mitigated prior to starting work. This is critical to the reliability of Commitments.

Safety in planning is important for the following reasons:

  • The Logistics and Sequencing Plan will be considered in planning and design phases to ensure the constructability of the project. For example, to prove safer equipment access, the distance between buildings might be adjusted.
  • The build sequencing of the systems, facilities, and infrastrcuture will be reviewed by the IPD Teams to minimize logistics conflicts.
  • Integrating Safety considerations into BIM helps all stakeholders gain understanding of what decisions were made and why.

2.2.4.3 Environmental Quality

The Receiver began addressing the total integration and harmonization of the System with the Living System that contains it from the beginning.

Environmental Quality efforts are intended to address the fact that every intention is implemented in the context of a preexisting reality.

Effort is required to analyze and understand the existing forces and conditions, and to coordinate with the local community and environment in advance of any local instantiation.

This Environmental Process is critical to ensure that the localized design wisely reconciles the existing forces and conditions, and that the site is ready for implementation without delay when the designs are ready and resources are secured.

Core activities include:

  • Analyzing and processing of local environmental documents, and facilitating their approval.
  • Initiating early communication with local communities and stakeholders to educate the community about the Program, and identify areas of priority and concern.
  • Consideration of legal or social challenges for any given site.
  • Implementing adopted environmental regeneration measures.

Draft and Final Environmental Impact Reports

The production of Draft and Final Environmental Impact Reports for each of the potential sites is required prior to detailed design of that project.

The process of preparing a DEIR/FEIR, including documents to be produced, environmental issues to be analyzed, and public review periods, is stipulated by local regulations in many areas. Where no such regulatory requirement exists, or where the Program’s internal requirements exceed the requirements of a local jurisdiction, the more rigorous Program process will be applied. Generally, a DEIR/FEIR being prepared for the Receiver adheres to the following process:

1. The Project Initiator issues a Notice of Preparation (NOP) in the community being considered for a project.  The NOP must be circulated for a 30-day public and governmental agency review period before the Receiver may issue the Draft EIR (see below).  The NOP generally describes the project and the environmental issues to be reviewed.  Comments received during the review period are addressed in the FEIR.

2. The DEIR describes the impacts the Project is anticipated to have on the environment.  The DEIR also proposes mitigation to address those impacts.  A Draft EIR is issued to the community and to “responsible” agencies, i.e. relevant public agencies, for review and comment.  The DEIR must be circulated for 30 days, which allows the community and responsible agencies the opportunity to submit written comments on the DEIR.  If appropriate, a public meeting is also held in the community during the 30 day review period to obtain oral comments.

3.     The Project Initiator issues a Final EIR, which is made up of the Draft EIR, written responses to comments received, and changes, if any, to proposed mitigations.  The Final EIR must be circulated for 10 days before the Receiver can certify the document and subsequently approve the project.

4.     Prior to approving the project, the Receiver must assess whether or not the FEIR was completed in compliance with the imperative for environmental regeneration based on independent judgment and analysis.  If the Receiver chooses to certify the EIR and approve the project, the following steps are triggered:

  • Resolution Certifying the Final Environmental Impact Report
  • Statement regarding approval, any additional findings of fact or overriding considerations.
  • Initiation of Mitigation Monitoring and Reporting Program (MMRP).

5.     Following completion of the EIR, the Project Initiator and Receiver remain responsible for ensuring the MMRP is properly implemented.

6.     The Environmental Quality process often identifies the need for certain additional analyses that may result in the requirement for government permits.  The analysis and potential permits will be called out in the MMRP.  As the process involved in obtaining these permits is usually lengthy, commencement of the analysis and permitting process should begin as early as possible, even before completion of the Environmental Quality process, in order to avoid delays. A table summarizing the potential regulatory permits needed for the project should be included in the Project Plan.

7.     The Environmental Quality process should be developed with multiple “right sized” approaches to the process, depending on the scope and relative impacts of a project. It is critical to balance the need for adequate procedure to avoid Program Participants initiating and funding ill-advised or damaging projects, while simultaneously avoiding unnecessary bureaucratic delay.

2.2.4.4 Public Outreach

Public outreach is necessary early and often prior to and during DEIR/FEIR preparation.  It is also necessary during and after implementation of each facility, including ongoing communication with local jurisdictions and elected officials.  A Communication Plan should be developed for each site so that communication with stakeholders can be proactively and intentionally maintained.

Public outreach goals of the Communication Plan include the following:

  • Provide consistent and accurate information to stakeholders

  • Strengthen relationships with the communities where the new systems, facilities and infrastructure will be located, including:

    • Implementation of a Local Outreach Program focused on local hiring and material purchasing to promote maximum local economic benefits, where feasible
    • Listening and prioritizing local needs and ideas; and
    • Cooperative efforts to mitigate area-specific impacts.
  • Commit to explore opportunities for improved, long-term partnerships between the new instantiations and emergency service providers, law enforcement, and other local authorities.

  • The following resource material should be generated for potential sites and used prior to initiating outreach efforts:

    • Master database of contacts and stakeholders for each site, including legislators, local elected officials, regional and local administrative and law enforcement officials, local power structures, and regional and local community leaders and activists.
    • Informational material for distribution, including “Frequently Asked Questions” and site specific project brochures.
    • Local Outreach Policy to promote hiring local labor, contracting with local businesses, and purchasing goods and services locally
    • Formal notices for public meetings.

2.2.5 Navigating Power Structures

The Program is aware that every domain in and on which it will act is occupied by various Power Structures. These power structures must be mapped and understood in advance of an instantiation.

Tremendous time and resources can be wasted by entering a domain, selecting a site, and then fighting your way up through the various overlapping and potentially corrupt power structures for approval one layer at a time.

Instead, higher order power structures should be understood, engaged and aligned in advance, such that the lower order power structures are neutralized or made helpful, rather than harmful, to progress.

The importance of this learning and reality cannot be ignored.

2.2.6 System Wide Master Plan (SWMP)

A System Wide Master Planning Process is recommended to coordinate and align all on-going activities within the System.

Relevant stakeholders should be convened to review and consider all legal, legislative, executive, community, security and wellbeing concerns that impact decisions on the system-wide master plan (SWWMP). The plan needs to consider short term, medium term and long term goals and needs of the System across All generations of life.

Such a plan is necessary to ensure coordination and interoperability between all Projects in all Domains.

Issues to be addressed include the following:

1.     What is the current system’s capacity to deal with the wellbeing of All?

2.     What are the current Needs and primary Gaps?

3.     How are current needs prioritized and sequenced?

4.     What are the anticipated needs over time?

5.     How can services and operations between all systems, facilities, and infrastructure be coordinated and harmonized throughout the System?

6.     What basic System components should be available in all communities to provide adequate Quality of Life? What are the Conditions of Satisfaction defining adequate Quality of Life?

7.     What predictable or potential technology innovations need to be coordinated within the System?  What current structures or processes are predicted to be eliminated by new technology?  How does the global community plan for transitions to new technological innovations?

  1. Recognizing that all people and technologies will change over time, how will the Community address continuity and continuous improvement in process and culture across time and space?

The final SWMP will make recommendations for facilities, services and infrastructure necessary over time to address all of the concerns raised by stakeholders.  This will include recommendations on funding for building new systems, transforming existing systems, or removing and replacing existing systems as required.

2.3 Service and Support Planning

Integrated Delivery helps apply Production Control through the Project Lifecycle.

Most control should happen at the local level because that is where the major Flows of Work occur.

However, some amount of Work will be more efficiently processed from a central location.

These functions will be carried out through the Core Enterprise.

Care should be taken to avoid fragilizing the System by over-centralizating. Recognizing both the increased efficiency of some centrally handled functions, and the fragilization of the System that could eliminate effectiveness, it is critical that the central services and infrastructure are purpose-built to create individual and local strength and resiliancy, rather than dependency. #principle

For certain activities which require substantial capacity, security, or more controlled environments, a central hub will be more efficient and effective.

Eventually, this central hub should be complexified into a network of interoperable regional hubs.

The initial hub should likely have two components:

1.     Physical campus / hub

2.     Digital campus / hub

Over time, these hubs will likely evolve, replicate and complexify towards an interconnected and non-fragile-to-cascading-disruption network / system of regional hubs that will foster all levels global, regional, and local redundancy, interoperability, empowerment, and sovereignty.

The Program has determined that the following tasks should be initially coordinated from the central hub:

1.     Core Information Technology (including BIM) that connects, coordinates, and empowers the network.

2.     Program-level Financial Management

3.     Reporting (maintaining the Program Record and necessary reporting to the Community / Federation and its designees)

  1. System-Wide Master Planning
    
  2. Prototype Control/Consolidation of Lessons Learned
    
  3. Prototype Development and Continuous Improvement
    
  4. Program Platforms for coordinating and measuring progress
    
  5. Serving and Supporting the distributed network of [[IPD Teams]]. 
    

2.3.1 Service and Support Planning

Recognizing the the Program inherenlty involves millions of local instantiations of the System, Service and Support Planning should be focused on discerning what the total set of needs and problems are likely to be faced by each Individual and Team working on the Program, and what can be done to best serve, support, and empower All.

Service and Support Planning provides administrative, operational and technical support for the entire Program to ensure it runs smoothly and in a lean manner.

The specific focus of Service and Support Planning is implementing and providing a Service and Support System that empowers successful Project execution, along with individual, organizational, and community development and capacity building.

Basic components and considerations include:

  • Administrative Support
  • Operational Support
  • Compliance Support
  • Information Management
  • Financial Management - including preparation and processing of invoices, managing cash flow projections, managing Commitments, budgets, cost codes, projections, and performance management
  • Technology Platforms and Support
  • Process Support
  • Templates and Current Best Understandings
  • Culture and Social Support
  • Governance Support
  • Legal Support
  • Learning and Human, Organizational, and Community Development Support

In short, Service and Support Planning should focus on how to create the ladders that each individual, organization, and community can efficiently climb towards their Potential, while ensuring that the individual and local elements do not become dependent upon the Core Enterprise.

2.4. Information Technology

Like all other elements of the System, Information Technology should be developed with a view not only to the hardware and software used to advance towards the Goal, but also the way those tools are configured, supported, and adopted throughout the Program.

Technology should be developed withing the concept of a multi-generational Culture and System of Systems purpose-built to evolve and transform across time.

The Program provides a unique challenge in dealing with information management systems.  Bringing together thousands of different organizations and institutions and providing the technology for them to “speak” with each other across different platforms and through firewalls is challenging.   In addition, Program Participants may view themselves as social, economic or political competitors in the Old Game.

Program information management must protect those relationships and concerns, without creating social or technological walls that block the flow of data, information, knowledge, or wisdom that is essential to the Flow of Work in the Program.

Program level information management is owned and maintained by the Program Manager, for the benefit of the Receiver.

Information Technology Stack Should Include Consideration Of:

  • Building Information Modeling
  • Architectural, Engineering, and Systems Design software
  • Ordering and clash detection across multiple platforms
  • Real-time estimating (model based costing)
  • Records Management and Archives.
  • Financial management.
  • Communication
  • Calendaring
  • Commitment logging
  • Collaboration processes
  • Social and Cultural processes
  • Governance processes
  • Protocols and processes
  • Work Structuring
  • Procurement
  • Logistics
  • Value Stream Mapping
  • Creation and access to A3s
  • Scheduling
  • Budgeting
  • Templates
  • Dashboards
  • Business Intelligence
  • Environmental Intelligence
  • Political Intelligence
  • Social Intelligence

Program Hardware

The PM will develop a plan for the hardware and capacity required to run all Program technology.

Due to the scope of the Program, hardware will need to acquired and administered by each Project, and likely each individual.

This will create significant security issues and will force the system to be built as if there would be compromised and infected hardware on the System at all times.

Rather than build a Safe System, we will need to build a Strong System.

Considerations for hardware selection include:

  • Security protocols. Security clearances. Anticipation of attack and attempts to compromise from both within and without the systems.
  • Expandability, upgradability, ease of maintenance and improvement.
  • Ability to cope with the vast differences in conditions and connectivity (or lack thereof) at various Instantiation Sites.
  • Platform selections will need to consider access issues for all categories of stakeholders who will need to connect in varous ways.

Interoperability Vs. Standardization

Due to both the vast diverstity of stakeholders and the Pattern Language that Program Participants are attempting to embody, in nearly all cases technology should be looked at with a view towards Interoperability rather than standardization and centralization.

It will be both impactical and unwise to attempt to choose central technologies, and force the Sovereign Autonomous elements of the Federation to use them.

Therefore Minimum Viable Standards Of Interoperability should be developed and maintained.

Multi-Generational Process Continuity

The Program is designed to run over multiple generations spanning hundreds or thousands of years.

Over this timeframe, every single technology for every single Function will evolve and transform countless times.

As the same time technologies are coming and go, there must be something relatively "eternal" that we relate to.

The "eternal" element is That Which Is Guiding The Transformation.

At the most abstract level, this can be thought of as the Spirit animating and inspiring the Program.

The Spirit inspires the articulation of the Intention of the Program, for instance as represented in the Program Statement.

And that Program Statement can be thought of as calling forth a continuously improving / transforming System or Way, composed of sub-systems and processes.

In order for something to improve across generations, the central animating "instruction manual" that instructs the energy in the system how to organize itself and behave must be maintained and improved as each instantiation of the logic passes its learnings forward.

The core of this DNA pertains to the elements of the System, and their relationships.

Relationships in a system can be viewed as a Process that defines how the elements of the System collaborate and relate in order to produce Throughput of the Goal of the System.

This Process, including the Process by which the Process is elevated and transformed, is what has continuity across subsequent generations of people, organizations, and technologies.

Overtime, every person and every technology will die. It is the Process, the Culture, the Way that remains throughout the generation.

Therefore, the survival of the Program and the Community / Federation acting it out depends upon the ability to continuously improve the core animating Processes, and to continually pass them on to subsequent generations.

The Data Model

Both the need for interoperability, and the need for continuity across subsequent transformations of people and technology, demands that a Data Model be designed and implemented that is capable of helping the Federation accomplish these elements of the Total Nested Hierarchy of Goals.

However immediately upon considering the notion of attempting to get all people and technologies working with a standard data model, it becomes once again clear that "The Data Model" is another issue of Interoperability rather than standardization.

Minimum Standards Of Interoperability

Once again, we arrive back at defining the minimum viable Standards Of Interoperability required for a decentralized Federation of Sovereign and Autonomous Individuals, Organizations, and Communities to Function.

This time, we approach the concept from the view of data and technology, and it leads back to the same Pattern Language.

Special Action Teams

For those few areas where some degree of standardization is wise and necessary to facilitate collaboration, the first step is collaboration on a comprehensive statement of mutual expectations and Conditions of Satisfaction for the area in question.

This is best accomplished by forming a Special Action Team to focus on the specific area. Special Action Teams should folow the basic Pattern Language for organizing and federating, come into existence, meet regularly, and exist for as long as they are required. In this case, Special Action Teams should be charged with developing collaborative understanding, acceptance criteria, processes, protocols, and procedures, and then designing and implementing them across the required teams.

Designing and Implementing should be done in the Way all such elements of the Program are done.

Consensus on products, usage, best practices, procedures and protocols should be made pursuant to a comprehensive Decision Making Process that specifically includes input and support from the right diversity of stakeholder groups.

Ordering and Clash Detection Across Multiple Platforms

Recognizing the diversity of source materials and technologies, a Process for Ordering and Clash Detection across multiple platforms will be required.

Real-Time Estimating (Model Based Costing)

One of the most significant challenges and opportunities of the Program is leveraging the principles of BIM and Model Based Costing to extrapolate the total costs of the Program in real-time.

This can be done in statistical ranges based on the average costs to connect each individual, organization, and community to the System.

Or said another way, it can be accomplished by understanding the costs and resources required to implement The Prototype, multiplied by a differented range of Instantiation costs across 10 billion individuals, 10 million organizations, and 10 million communities.

Viewed from this lens, it will become apparent that the Services and Infrastructure required to Instantiate the System will be the most important area for investment, along with building the skill and capacity of those charged with its implementation.

Optimizing the use of a Prototype, visually understandable through BIM, locally adaptable, tied to a real time resourcing model, requires continuous improvement and re-assessment of the strategies for learning and implementation across the total set of instantiations.

Records Management

A Record is a document or other electronic or physical object generated or received by an entity, which serves as Evidence of an activity or transaction engaged in by the entity, that requires retention for some period of time.

Records management is the process by which an organization:

  • Determines what types of information should be considered records
  • Determines how active documents (which will ultimately become “records”) should be handled while they are in use, and how they should be collected once they are declared to be records
  • Determines in what manner and for how long each record type should be retained to meet business, legal, and/or regulatory requirements
  • Researches and implements technological solutions and processes to help ensure that the organization complies with its records management obligations in a cost-effective and non-wasteful manner
  • Performs records-related tasks (i.e. disposing of expired records, or locating and protecting records related to external events such as legal discovery).

Document Control

Document Control oversees the comprehensive document management system used on the Program.

Document Control establishes and maintains procedures for document management, archiving and records requests for the Program. This should be done through a computer-indexed filing system or better.

The Document Locator (TBD) is the Program’s document management software solution for capturing, managing, sharing, and securing the documents and information. Document management spans the entire document life cycle, from electronic origination or document scanning, through collaboration, workflow management and document sharing, to version control, auditing, document retrieval and document storage.

The Document Locator interfaces with other standard software such as MS Word, Excel, PowerPoint, Outlook, and their Google or open source equivalents.

This interface allows Program participants to electronically collaborate on documents using version control and the check in/check-out features.

Financial Management

Financial management records are discussed in another section.

Other Records Management:  Additional capabilities of the Records Management system include the following:

  • Improved communication through use of common calendars and notifications
  • Common repositories for program documents using versioning, capturing feedback, discussions, review and approval processes
  • File sharing with partners, including A3’s and Commitment Logs
  • Effective meeting management, including tracking minutes, tasks and team decisions
  • Possibly - Ability to manage sensitive information restricting access to “need to know”. This is a counter value to the need for transparency, and needs to be thoughtfully discussed, and the Process related to transparency thoroughly documented.
  • Tracking program team resource skills, expertise and experience in a way that can be easily searched.
  • Ability to search content and easily locate information
  • “Single Point of Truth” Program-wide, promoting visibility and accountability.
  • Multiple Points of Truth - that are free to validate or disagree with the Single Point of Truth.

Communication

The Program should the following communication processes. Note -these need to become real processes actually in use on the program.

  • Common calendaring – selection of software calendaring that overcomes the firewalls of various entities.
  • Commitment logging – From start to finish, a hallmark of lean processes is the making and keeping of reliable promises which get recorded and tracked.  PM will find a non-labor-intensive system to do this across diverse and remote places.
  • Access to records and BIM – The defensive firewalls of the various organizations and institutions in the Core Enterprise are virtual barriers to access to records and BIM files.  The Technology Guild should design and continuously improve a solution to overcome these challenges.
  • Collaboration processes – Collaboration takes place best when face-to-face, but with an inherently global mission, teams must become world-class a virtual collaboration. Virtual collaboration solutions should include ways to efficiently map across the different management and coordination solutions in place.
  • Protocols and Processes – For all of the above challenges, finding the IT solution is only one part of the challenge.  The Core Enterprise team must then collaboratively develop the policies, protocols and processes which knit all the solutions together and weave them into the daily work habits of hundreds, thousands, and eventually millions or billions of people around the world.

Work Structuring

The Program should use software and technological solutions to address the following issues of project delivery:

  • Alignment
  • Design
  • Engagement
  • Procurement
  • Planning
  • Scheduling
  • Budgeting
  • Logistics
  • Value Stream Mapping
  • Creation and access to A3s
  • Performance Management
  • Continuous Improvement

Blockchain (Or Similar)

It is anticipated that many of the ultimate processes and applications of the New System will run on a New network of blockchains.

The Blockchain Guild should develop, prototype and scale.

(This is non-obvious – should be explained on par with the BIM System)

Measuring and Exchanging Value

A new system will be established to allow Program participants to notice, measure, validate, and exchange value as they create it.

This system will enable new currencies within the Prototype. The current hypothesis is that local communities should be empowered to locally exchange value (make and keep commitments that produce throughput of their goals), while remaining interoperable with global exchange mechanisms.

Measuring and exchange of Value will be a core element used for allocation of resources.

Security

Security includes protection of data, prevention of “hacking” or other unauthorized intrusion in the system, back-up, standardization of platforms and software, support and maintenance capabilities for the system.  The Program approaches those issues as follows:

  • Security:  Appropriate access to information is essential for the Program.  Security includes electronic access controls.  Electronic access is managed by role-based rights when possible.
  • Storage (Data):  A data storage protocol will be developed, implemented, and continuously improved.
  • Backup:  Data backup is the foundation of any disaster recovery program.  The backup should provide the ability to restore lost data in a reasonable time frame, to a distributed network of regional and local systems that may not be able to communicate with one another for long periods of time. System architecture should ensure that data is stored in locations designated for comprehensive security and backup, and not fragmented across many different locations such that it is not possible to comprehensively reassemble.
  • Software:  All program-wide applications will be purchased and installed by the Program team to promote standardization and control licensing.
  • Virtualization: Server, workstation and application virtualization are used to leverage hardware capacity.  Such virtualization provides access to applications and data regardless of firewall or client platforms.
  • Service and Support:  The Program Service Desk should provide easy access to support service not only for IT, but for other services as well.
  • Monitoring and Reporting: The total set of IT should provide monitoring and reporting of systems and processes throughout the Program, in a way that empowers timely decision making and navigation towards the Goal.

2.5 Financial Management

Left off here.