Solution Adoption and Sustainability Plan Template
Purpose:
The Solution Adoption and Sustainability Plan provides a structured way to plan how a co-developed solution will be adopted, integrated, maintained, and sustained beyond its initial development phase. It supports the transition from development to consistent, real-world use within operational workflows. Specifically, this tool helps teams:
- Clarify who will use, own, and maintain the solution over time.
- Plan for training, onboarding, and user support needed for adoption.
- Identify institutional, technical, data, and resource dependencies that affect sustainability.
- Reduce risk associated with staff turnover, data changes, and funding constraints.
- Support responsible handover, long-term maintenance, or transition to partner ownership.
- Support the goals of the Solution Co-Development Toolkit by explicitly addressing adoption and sustainability, helping ensure that solutions are not only well-designed, but also usable, maintainable, and resilient over time.
How and When to Use This Tool:
This tool should be initially completed during Phase 2 of the co-development process (initial draft). It should be revisited and updated at key points throughout subsequent phases of co-development as the solution matures, user needs evolve, and sustainability considerations become clearer.
NASA Earth Action Solutions Co-Development Toolkit, v0.1 | 95
1. Solution Information
Solution Title:
Co-Development Partners and Primary Implementing Partner(s):
List the organizations involved in co-developing the solution and identify the primary implementing partner(s) responsible for operational use. (Refer to the Stakeholder Mapping outputs to ensure this section clearly identifies the specific stakeholders and user groups targeted for adoption and long-term sustainability.)
Intended Operational Environment and Sustainability Requirements:
Describe where and how the solution is expected to operate (e.g., internal agency systems, cloud-based platforms, partner-managed infrastructure).
2. Adoption Strategy
This section describes the overall approach for enabling and supporting adoption of the solution by its intended users. The adoption strategy should outline the context, assumptions, needs, expectations, roles, and risks associated with transitioning the solution from development to routine operational use.
The adoption strategy should address:
- How the solution will be introduced and integrated into existing partner workflows
- What users and implementing partners need in order to adopt the solution successfully
- Assumptions about institutional capacity, staffing, and resources
- Expectations for user engagement, training, and support
- Roles and responsibilities related specifically to adoption and operational use
- Key risks to adoption and how they will be mitigated
2.1 Adoption Goals
This section should define what successful adoption of the solution looks like from an operational and user perspective. Adoption goals should focus on actual use, integration into workflows, and ownership, rather than technical performance or development milestones.
Adoption goals should be specific, practical, and time-bound, and aligned with the needs and capacity of the intended users and implementing partners. Including a temporal element helps teams:
- Set realistic expectations for adoption,
- Support accountability and progress tracking, and
- Inform how long resources and support should be planned for.
Examples (select and tailor as appropriate, including a timeframe):
- Integrated into the partner's annual reporting workflow within 12 months of deployment
- Used by analysts each season starting in the first operational year
- Validated for operational decision-making by the end of the pilot phase
- Transferred to and managed by the partner's internal team within 1–2 years
- Replacing or reducing reliance on manual or legacy methods over a defined transition period
2.2 End-User Readiness
Assess partner readiness in practical terms:
- Institutional mandate alignment
- Existing workflows the solution will support
- Technical capacity (software, hardware, staff skills)
- Data access constraints
- Training needs
- Barriers to Organizational Adoption Readiness: (e.g., staffing changes, competing priorities, approval processes) (Refer also to the Needs Assessment tool)
2.3 Engagement and Co-Development Traceability
This section should document how user engagement and co-development activities informed the adoption approach. It provides traceability between user input and adoption decisions, helping demonstrate that the solution and its adoption pathway are grounded in real user needs and constraints.
You may use the table below as a reference to document user engagement and traceability.
| Engagement Element | Description / Evidence | Reference Links (optional) |
|---|---|---|
| User interviews, focus groups, or co-design sessions | ||
| Key user needs identified | ||
| Key user priorities and constraints | ||
| How user feedback was incorporated into adoption planning | ||
| Open feedback items or deferred requests (future versions) | ||
| Stakeholder expectations regarding adoption timeline |
2.4 Training, Knowledge Transfer & Onboarding Plan
This section describes the training and onboarding activities required to enable effective and sustained adoption of the solution. The focus should be on ensuring that intended users have the knowledge, skills, and support needed to use the solution confidently within their operational workflows. Training and onboarding plans should be tailored to the capacity of the implementing partner and reflect the complexity of the solution, expected frequency of use, and level of institutional ownership.
You may use the table as reference below to document training and onboarding plans.
| Training / Onboarding Element | Description | Owner / Responsible Party | Timeline / Frequency |
|---|---|---|---|
| Required training materials (SOPs, slides, videos, job aids) | |||
| Training sessions (content, duration, format) | |||
| Delivery format (virtual, in-person, hybrid) | |||
| Onboarding workflow (e.g., pre-training → hands-on → certification) | |||
| Ongoing support mechanisms (helpdesk, office hours, maintainer contact) | |||
| Local champions / focal points |
NASA Earth Action Solutions Co-Development Toolkit, v0.1 | 96–97
3. Sustainability Strategy
This section should describe the overall strategy for ensuring the solution can be maintained, supported, and used over the long term beyond the initial development and deployment period. The sustainability strategy focuses on practical considerations related to technical upkeep, data continuity, institutional ownership, and resourcing.
The sustainability strategy should clearly describe:
- How the solution will remain technically functional over time, including the expected duration of support and maintenance (e.g., short-term, medium-term, or long-term horizons)
- How data will be updated, managed, and stewarded
- Who will own and maintain the solution after development
- What resources are required to sustain operations
- Key risks to sustainability and how they will be addressed
3.1 Sustainability Objectives
This section should define the long-term outcomes the solution is expected to achieve once it has moved beyond initial development and deployment. Sustainability objectives should reflect what success looks like after the project period, including expectations for ownership, resourcing, and continuity, with clear indication of whether sustainability is intended for a defined time horizon (e.g., short- or medium-term) or for ongoing/perpetual operation. Sustainability objectives should reflect what success looks like after the project period, including expectations for ownership, resourcing, and continuity.
Examples (select and tailor as appropriate):
- Solution runs annually with minimal outside support
- Data and code kept current beyond the project period
- Partner internalizes workflow and maintains ownership
- Solution is resourced and staffed appropriately for sustained operation
- Knowledge is retained across staff turnover
- Feedback loops are established to capture user input, outcomes, and impact after the project period (e.g., usage feedback, outcome metrics, economic or decision-support impacts) to inform ongoing improvement and future use cases or case studies
Make references to the Solutions Implementation and Impact Monitoring Plan.
3.2 Technical Sustainability
This section should describe how the solution will remain technically functional, reliable, and maintainable over the long term. It should focus on the systems, workflows, and dependencies that enable continued operation after initial development and deployment.
You may use the table below to document technical sustainability considerations
| Technical Sustainability Element | Description | Owner / Responsible Party | Notes / Dependencies |
|---|---|---|---|
| Repository location and ownership (e.g., GitHub, internal systems) | |||
| Version control and release strategy | |||
| Update frequency (annual, seasonal, ad hoc) | |||
| Required technical skill sets for maintenance | |||
| Software, library, API, or cloud dependencies requiring monitoring | |||
| Level of automation in processing pipelines | |||
| Location of technical documentation and maintenance guides |
3.3 Data Sustainability
This section should describe how the data required to operate the solution will be maintained, updated, and managed over the long term. It focuses on ensuring continuity, reliability, and accessibility of data beyond the initial project period.
You may use the table below to document data sustainability considerations.
| Data Sustainability Element | Description | Owner / Responsible Party | Notes / Dependencies |
|---|---|---|---|
| Data inputs required and update schedule | |||
| Data retention rules and time horizons | |||
| Storage locations and backup procedures | |||
| Identified data steward(s) or responsible team(s) | |||
| Plan for data source changes or discontinuation (e.g., sensor or collection updates) |
3.4 Institutional Sustainability
This section should describe the organizational and governance conditions that ensure the solution continues to be used and supported beyond initial development. Institutional sustainability focuses on ownership, integration into routine processes, and continuity within the implementing organization, rather than technical or data considerations.
You may use the table below to document institutional sustainability considerations.
| Institutional Sustainability Element | Description | Owner / Responsible Party | Notes / Dependencies |
|---|---|---|---|
| Long-term owner of the solution (organization and responsible team) | |||
| Integration into formal workflows, mandates, or reporting cycles | |||
| Cross-training or redundancy plans to manage staff turnover | |||
| Requirements for institutionalizing the workflow (e.g., SOPs, approvals, policy alignment) | |||
| Alignment with ongoing national, regional, or organizational programs |
3.5 Resource Sustainability
This section should describe the human, financial, and infrastructure resources required to sustain the solution across its lifecycle, from early operations through long-term use. Resource sustainability focuses on ensuring that the solution can be maintained at an appropriate level of effort without relying on short-term or ad hoc support. This section should consider both expected resource needs under normal operation and the minimum level of support required to keep the solution functional if resources are constrained.
You may use the table below to document resource sustainability considerations.
| Resource Sustainability Element | Description | Estimated Level / Cost | Notes / Assumptions |
|---|---|---|---|
| Estimated annual level of effort to sustain operations | |||
| Required expertise and roles (e.g., developer, data manager, analyst) | |||
| Cloud, compute, or storage costs | |||
| Non-labor costs (e.g., travel, meetings, licensing) | |||
| Minimum support requirements to keep the solution operational | |||
| Budget planning considerations (funding sources, cost-sharing) |
NASA Earth Action Solutions Co-Development Toolkit, v0.1 | 98–100
4. Roles and Responsibilities Upon Successful Transfer
This section should define the roles and responsibilities after the solution has been transferred to operational use. It clarifies ownership, accountability, and points of contact to support sustained operation, maintenance, and user engagement over the long term. The roles listed here should reflect the post-handover state, rather than development or build-phase responsibilities. This section helps ensure continuity by making clear who is responsible for the solution once initial development activities conclude.
You may use the matrix below to document roles, responsibilities, and organizational ownership.
| Role | Responsibility | Assigned Person/Team | Organization |
|---|---|---|---|
| Solution Owner | Oversees long-term operation | ||
| Technical Lead | Code maintenance and updates | ||
| Data Steward | Data updates and QA/QC | ||
| Product Lead | User engagement and roadmap | ||
| Training Lead | Training and onboarding | ||
| Support Contact | First-line troubleshooting | ||
| Documentation Lead | SOPs and manuals | ||
| Communications Lead | Outreach and awareness |
NASA Earth Action Solutions Co-Development Toolkit, v0.1 | 101
5. Adoption Milestones & Timeline
This section should document the key milestones and timeline associated with solution adoption, from initial onboarding through full operational use and handover. The milestones should focus on user readiness, operational integration, and transition to sustained ownership, rather than technical development tasks.
List major activities and estimated dates.
| Milestone | Description | Owner | Date |
|---|---|---|---|
| User onboarding complete | All analysts trained | ||
| Pilot season operational | Workflow run end-to-end | ||
| Performance reviewed | Partner sign-off | ||
| Full operational adoption | Solution integrated into annual cycle | ||
| Handover complete | Ownership transferred |
You may convert this into a Gantt chart for the final toolkit.
6. Risk Assessment and Mitigation
This section should identify adoption and sustainability risks that could affect the solution's long-term use, maintenance, or impact. Risks listed here should focus on operational, institutional, data, resource, and user-adoption considerations, rather than technical build or development risks, which are addressed in other toolkit resources.
List key risks and proposed mitigation strategies below.
| Risk Area | Description | Likelihood | Impact | Mitigation Strategy |
|---|---|---|---|---|
| Technical | Loss of key developer | Med | High | Cross-training and documentation |
| Data | Source data changes | Low | Medium | Monitoring and adaptable scripts |
| Institutional | Staff turnover at partner | High | High | Train multiple focal points |
| Resource | No funding for maintenance | Med | High | Define minimum support level of effort |
| Adoption | Low user uptake | Low | High | Co-design and hands-on training |
NASA Earth Action Solutions Co-Development Toolkit, v0.1 | 102–103
7. Handover & Long-Term Maintenance Plan
This section should describe how the solution will transition from development to operational use and sustained ownership. It outlines the conditions and processes required to ensure a smooth handover, continuity of operations, and long-term maintenance after the initial development phase concludes.
You may use the table below to document handover and long-term maintenance elements.
| Handover & Maintenance Element | Description | Owner / Responsible Party | Timing / Frequency |
|---|---|---|---|
| Handover conditions (e.g., training completed, pilot executed, documentation finalized) | |||
| Required documentation (user guides, SOPs, technical and data documentation) | |||
| Knowledge transfer activities (training sessions, shadowing, walkthroughs, recorded demos) | |||
| Post-handover contacts (technical, data, operational support) | |||
| Expected update cycle after handover (code, documentation) | |||
| Conditions for re-engagement (major upgrades, data changes, system modifications) |
8. Exit or Retirement Plan
This section should document the end-of-life pathway for the solution, outlining how it will be responsibly retired, archived, or replaced if it is no longer needed, supported, or effective. Planning for exit or retirement helps ensure transparency for users and preserves access to relevant code, data, and documentation.
Use the table below to document exit or retirement considerations.
| Exit / Retirement Element | Description | Owner / Responsible Party | Timing / Triggers |
|---|---|---|---|
| Criteria for retiring or replacing the solution (e.g., no longer meets user needs, replaced by newer system, loss of data availability, lack of resources) | |||
| Steps to archive code and data (final versioning, storage location, documentation, access permissions) | |||
| Communication plan for users (advance notice, timelines, alternatives, points of contact) | |||
| Migration path to alternative solutions, if required (data transfer, workflow transition, user guidance) |
NASA Earth Action Solutions Co-Development Toolkit, v0.1 | 104