ODIN Canvas for *Build* Domain

# ODIN Canvas for *Build* Domain By *JeremyB, Harsha, Randall, Tevo, Juan, Vani* Feb.21, 2024 `v1.0` Delegator(s): *ODIN* <details open> <summary>1. Primary Driver / Purpose</summary> 🏗️ **This is where creators, innovators, projects, and ideas take shape and go from concept to working prototype, and from idea to useful product *(anticipated impact)*. Builders need spaces to collaborate, share knowledge, coordinate action and build community *(requirement)*.** The ***Build*** space is a necessary and emergent co-mingling of the efforts of the onboarding/learning domains and the efforts of the governance/sustainability domains *(relevance)*. The invested energy and shared explorations into ODIN's evolutionary principles need support to be applied consistently in new and novel ways *(situation)*, and without a dedicated space being held for that purpose, that energy and effort will dissipate *(effect)*. </details> <details open> <summary>2. Key Responsibilities</summary> 1. **Build** open source, internal ODIN enabling infrastructure (*requirement)* so that ODIN can organize and share radical decentralized collaborative efforts *(anticipated impact)*. 2. **Clarify** drivers for creators, builders, projects and ideas with Driver Mapping *(requirement)* so that participants can see clear patterns of coordination and collaboration across ODIN *(anticipated impact)*. 3. **Ensure** that innovators and innovation teams can always see and take a "next step" by engaging in formal consent and reasoned decision-making processes *(requirement)* so that building is an "always on" phenomenon in ODIN *(anticipated impact)*. </details> <details open> <summary>3. Direct Recipients of Value and Deliverables</summary> *Note, we are trying to be somewhat non-specific here, so that the participants are free to create value according to their expertise, strengths, and interests, and based on what they learn as their work proceeds.* 1. **ODIN members:** coherent, simple, but adaptable and integrated infrastructure modules *(deliverable)* for proposals, logbooks, backlogs, and other documentation to help observe the principles of transparency and accountability *(requirement)*. This is so that ODIN members can have a shared understanding of roles, intiatives, and agreements enabling them to navigate these spaces effectively as they pursue their own initiatives *(anticipated impact)*. 2. **Build Space Participants:** Driver Mapping support and tooling, including govtool modules and dedicated discussion space for exploring and developing driver descriptions, and facilitating recursive integration of questions and concerns about drivers *(deliverables)*. This is so that builders are able to present their ideas clearly and effectively *(requirement)* in order to better enable others to understand collaborations or coordinate co-creation *(anticipated impact)*. 3. **Build Space Participants:** dedicated "next step" support for builders in the form of Driver Response documentation (reference, tutorials, how-tos, explanations) and facilitation of consent processes for co-creation of proposals and reasoned decision-making *(deliverables)*, so that builders are engaged in collaborative process, aware of backlogs (relevance and priority), and always working towards and making decisions *(requirements)*. This will enable builders to be more effective while continuously improving as they learn about the space and their project through consent mechanisms. </details> <details> <summary>4. Dependencies</summary> *Who is the team (or role keeper) dependent on, from other parts of the organization or the outside world, and what deliverable(s) do these people provide?* List key dependencies – the products, services, information etc. essential to the work of the team/role – both from **within the organization** and from the **outside world.** Describe who provides them, and clarify expectations about the delivery if helpful - … - … - … </details> <details> <summary>5. External Constraints</summary> *What are important external constraints to the team’s (or role keeper’s) autonomy and influence?* Constraints may be related to customer requirements, to the outside world, to essential stakeholders in the organization, to shared resources, to other responsibilities the members of the team or person in the role may have, or to the preference of the delegator. - … </details> <details> <summary>6. Key Challenges</summary> *What are the most important known (or anticipated) challenges the team (or role keeper) might face?* Consider the outside world, the organization itself, the delegator and the specific delegatee(s). Look for - risks and vulnerabilities - variables (e.g. weather) - uncertainty and complexity - lack of skills or resources. 1. … 2. … 3. … </details> <details> <summary>7. Key Resources</summary> *What are essential resources the team or role keeper can make use of?* Examples: time allocation, supply of money, privileges and permissions, facilities, hardware, software, materials, internal or external service providers, products, stock, etc. - … - … - … </details> <details> <summary>8. Delegator Responsibilities</summary> *What responsibilities can the team (or role keeper) rely on the delegator to take care of to support them to successfully account for this domain?* Responsibilities should be specific and measurable, so they can be reviewed and developed over time. - ODIN should support alternative education spaces so that the build space can focus on helping builders quickly move through processes like drivers and consent in their initiatives. This should ensure that Build space participants are familiar with our tools and processes. - ODIN should support the ability of governance and sustainability members to engage with the Build space in order to facilitate organizational level decisionmaking (for example, fund allocation, or required org level documentation) so that the Build space is not interrupted or disrupted in its ability to help its memebers - … </details> <details> <summary>9. Competencies, Qualities and Skills</summary> *What competencies, qualities and skills are required – or at least preferable – to successfully achieve the purpose of this domain?* Consider what you listed as Key Responsibilities, Key Deliverables and Key Challenges. - … - … - … </details> <details> <summary>10. Key Metrics and Monitoring</summary> *What are the critical indicators of progress, project health or performance?* Prefer simple, continuous and actionable metrics related to the domain's purpose, key responsibilities, challenges, deliverables, and delegator responsibilities, and define specific targets, acceptable range or tolerance. - … - … - … </details> <details> <summary>11. Evaluation Schedule</summary> *What are the critical indicators of progress, performance, project health, etc, how frequently will they be measured and by whom?* Describe a schedule (or frequency) for evaluating the success of the team (or role keeper), the process used, and who should take part in which parts of the evaluation. … </details>