nep platform sow template - canarie · web viewfor example, receiving requests for projects that...

Research Software ProgramLocal Research Software Support

Funding Call 1:

Statement of Work Template

Institution / Organization (Lead Contractor): [please respond]

Project Authority: [please respond]

Research Software Program – Local Research Software Support – Call 1: Statement of Work of 15

Table of Contents

INSTRUCTIONS.................................................................................................................................3MANDATORY CRITERIA.....................................................................................................................4SCORING CRITERIA..........................................................................................................................6TIMELINE.........................................................................................................................................8RISK ASSESSMENT AND MITIGATION................................................................................................9DELIVERABLES AND MONITORING....................................................................................................9APPENDIX A – RECOMMENDED ACTIVITIES.....................................................................................10APPENDIX B – STANDARD LOCAL RESEARCH SOFTWARE SUPPORT METRICS.................................11APPENDIX C – INSTITUTIONAL SUPPORT........................................................................................15APPENDIX D – RESEARCHER SUPPORT..........................................................................................15APPENDIX E – PARTICIPANT BIOS..................................................................................................15


Instructions

Your Statement of Work (SOW) must follow the format and sequence outlined below. This requirement ensures consistency in proposal submissions and fair consideration for all applicants. Submissions that do not follow this format and sequence or do not address the items specified may not be accepted for evaluation.

Instructions regarding the information that must be addressed in each section are presented in green under each heading.

Before uploading your SOW: Delete this instruction page Update the Table of Contents Have your institution’s Research Accounting / Research Services or your organization’s

Finance department review the completed SOW and prepare the Preliminary Project Budget.

Upload your SOW as a .pdf document in the Proposal Submission Form. Upload your Preliminary Project Budget as an .xls document in the Proposal Submission

Form.


Mandatory CriteriaPlease address each of the following mandatory criteria:

1. Explain how the proposed Local Research Software Support Team activities will allow researchers to make use of Canadian digital research infrastructure (networking, compute, storage and/or sensors).

[Please respond here. Maximum of 250 words]

2. Explain how the proposed project contributes to one or more of CANARIE’s Expected Results:

a. enhances opportunities for collaborative knowledge creation and innovation within Canada’s research and education communities through the maintenance and development of the CANARIE Network and related tools and services;

b. expands the research and education community’s access to and utilization of the CANARIE Network and the availability of tools and programming that increase the effectiveness of its use; and,

c. enables the creation of innovative Information and Communications Technology (ICT) products and services and accelerates their commercialization in Canada.


3. Please provide information to support that the Local Research Software Support Team activities proposed are technologically feasible and economically viable in the timeframe of the project plan.


4. All funded work must be performed in Canada. Please identify the locations(s) at which the funded work will be performed.



5. The Lead Contractor must be a Canadian university, college, corporation or other legally

recognized entity. Please provide the organization’s URL.


6. No more than half of the membership and Board of Directors of the Lead Contractor can be composed of representatives or agents of the federal government. Please provide a list of Board members or provide the list via the relevant URL.


7. In-kind contributions must be at least 15% of total eligible project costs. This is to be demonstrated in the Preliminary Project Budget.

CONFIRMED ☐

8. New software developed using CANARIE funding must be made available for other researchers to use at no cost, through the CANARIE Research Software Registry.

CONFIRMED ☐

9. The Team Lead must be in place by September 1, 2020 or funding may be rescinded.CONFIRMED ☐


https://science.canarie.ca/

Scoring Criteria

Applicants must clearly address each of the following sections:

Institutional Commitment to the Local Research Software Support TeamDiscuss the commitment of the Lead Contractor, and any participating institutions to the Local Research Software Support Team. As part of this section:

a. Include a Letter of Support from the Vice-President, Research (VPR)’s office (in Appendix C of this document).

b. If the proposed Team does not fall under the VPR organization, also include a Letter of Support from the head of the organization that will be responsible for the Team (in Appendix C).

c. Describe the plan for maintaining the team after CANARIE funding ends.d. Discuss the Project Authority’s (PA) role and describe how they will support the Team.


Researcher Support for this InitiativeDiscuss the extent of support from researchers at the institution(s) for this initiative. As part of this section:

a. Include at least three (3) letters of support from researchers at the participating institution(s) who plan to make use of the Team’s services (in Appendix D). These letters should briefly describe any projects these researchers have in mind for the Team.

b. Describe any additional initial projects that are planned for the Team.


Researcher Terms of EngagementDescribe the plan for engaging researchers at the institution and discuss how it will maximize researcher participation in this initiative. List any faculties/schools/departments that the Team will not be supporting and explain.



Project Selection PlanExperiences in other countries and with the Local Research Software Support Pilot suggest that the Team will be chronically oversubscribed; describe what criteria will be used to select which projects the Team will work on. Address the following:

a. How will researchers request the services of the Team?b. What will be the mechanism for the Team to evaluate and prioritize such requests?c. How long the Team will support a single project?d. How many projects the Team would typically take on simultaneously?e. How long to you expect a typical project to take?f. What percentage of an individual Team member’s time be dedicated to a single project?g. Are there any Recommended Activities (see Appendix A) that you don’t believe the Team

will be involved in? Why not?h. Do you expect Team members to be engaged in activities other than those listed as

Recommended Activities (see Appendix A)? If so, please describe.i. How will you avoid losing the interest of the research community as a result of turning

down a large number of projects?


Staffing PlanTimely recruitment of staff and announcement of the Team to researchers is vitally important to Local Research Software Support Teams as they have a limited funding window in which to demonstrate their value to the institution. Address the following:

a. How soon after funding do you expect the first team member to be in place?b. How will you manage new hires so that the Team will not be unduly overloaded with

onboarding activities while at the same time, coming up to speed as quickly as possible?c. How do you see this new Team fitting in to your organization? Include:

a. Which department will the group be part of?b. Will they be part of a larger team? If so, please describe what the larger team

does.d. Describe any existing groups that support computational researchers from a technical

perspective at your institution and discuss how the Team will interact with such groups.


MetricsAddress the following:


a. What metrics (both quantitative and qualitative) do you propose collecting to capture the value of the Team to the institution and its researchers? How will these metrics be collected?

b. What quantitative metrics do you propose collecting to demonstrate effective management of the team and its activities? How will these metrics be collected?

c. Will you be collecting all of the standard Local Research Software Support Metrics listed in Appendix B? If no, please explain.


TimelineThe table below describes significant tasks and milestones related to the Local Research Software Support Team. Please:

d. Provide dates for the first three items.e. Add any items that you feel are significant (researcher engagement activities, surveys,

internal project calls, etc.).f. Do not change items 4 – 8. These are required as part of the CANARIE Research Software

Program.g. Re-order and renumber the items in the table as required.

Key Task Due Dateyyyy-mm-dd

Milestones / Deliverables(Must be Tangible and Measurable)

1 Hire Team Lead Team lead starts work.

2 Hire second funded member of Team Second funded member joins Team.

3 Hire third funded member of Team Third funded member joins Team.

4 Yearly report and review (FY 2021) 2021-03-31

Summary of Team activities in 2020 including an update on the plan for sustaining the team post-CANARIE funding.

5 Documentation update for FY 2022 2021-04-01

As-needed updates of terms of engagement, project plan, and metrics. Approved by both the PA and CANARIE.

6 Yearly report and review (FY 2022) 2022-03-31

Summary of Team activities in 2021 including an update on the plan for sustaining the team post-CANARIE funding.

7 Documentation update for FY 2023 2022-04-01

As-needed updates of terms of engagement, project plan, and metrics. Approved by both the PA and CANARIE.

8 End of project report 2023-03-31 Final report and metrics delivered to CANARIE


Risk Assessment and Mitigation

Describe any risks (including non-HR risks) that could reasonably arise during this project and outline a mitigation strategy for each risk.

Description Probability(Low/Med/High)

Impact(Low/Med/High) Mitigation

Deliverables and MonitoringPlease take note of the requirements for project deliverables and monitoring listed in this section. This is for information only and you are not required to add content here.

Item DetailsYearly deliverables, due at the end of March

1. A summary of activities over the year, including lessons learned/best practices, and an update on the plan for sustaining the team post-CANARIE funding.

2. Updated Researcher Terms of Engagement, if required.3. Updated list of metrics, if required.4. Updated timeline for the upcoming year, if required.

Technical Reporting 1. Status meetings via videoconference will be held at 4-week intervals to review results including measured metrics and progress against the timeline.

2. CANARIE will hold formal project reviews in Mar 2021 and Mar 2022 to test that the value of each project can be demonstrated.

3. A final report will be required at the end of funding, in Mar 2023.


Appendix A – Recommended ActivitiesBased on experiences from other countries and from the Canadian pilot, CANARIE recommends that Local Research Software Support Teams undertake the following activities:

1. Providing support to researchers on:a. Existing software they may be able to make use ofb. Development environmentsc. Languages, libraries and 3rd party softwared. Development methodologies and software project managemente. Team composition and recruiting

2. Surveying existing software, including software available from science.canarie.ca3. Assisting researchers in proposal writing (for software components of research proposals)4. Software architecture, including architecture to support use of Canadian digital infrastructure5. Development/modification to science-facing (i.e. numerical analysis, statistical, model,

simulation) software6. Integration of existing software7. Management of other research software developers in group, as appropriate8. Group promotion and researcher engagement within the institution9. Interfacing with similar groups at other institutions, either directly or through a formal

organization10. Other activities that participants deem necessary, with the approval of CANARIE


Appendix B – Standard Local Research Software Support MetricsThe following metrics were developed with the participation of the Local Research Software Support Pilot participants. We ask that all funded participants put mechanisms in place to collect these metrics and report them to CANARIE. These metrics may change as a result of lessons learned during this Call.

Project Metrics

Metric Projects CompletedDescription: A list of projects the Team has successfully completed.Collection Method: Simple enumerationPurpose: Demonstrate impact of Team on university research community

Notes: It will be up to each Team to define when a project is “complete”.

Metric Projects DeclinedDescription: A list of projects requested by researchers that the Team has declined to

work on.Collection Method: Simple enumerationPurpose: - Fine tune communications with researchers

- Demonstrate need for team- Team management

Notes: It would be useful to indicate why each project was declined. For example, receiving requests for projects that are not appropriate may indicate that the messaging to researchers needs to be adjusted. Similarly, declining a large number of projects while completing relatively few may indicate that the team is taking on projects that are too large and may be better off consulting with project staff.

Metric Projects AbandonedDescription: A list of projects that the team started working on but stopped prior to

completion.Collection Method: Simple countingPurpose: - Fine tune communications with researchers

- Analysis for continuous improvement- Team Management

Notes: It would again be useful to track why each project was abandoned, to assist in continuous improvement activities.


Metric DisciplinesDescription: A list of the research disciplines involved in the completed projectsCollection Method: Collect this information from researcher once project has been accepted.

Delete if project later abandoned.Purpose: - Demonstrate applicability of the Team to the university research

community at-large.Notes: We ask researchers to use the NSERC code table when reporting their

discipline, but many find that it is not fine-grained enough and make up their own.

Reuse MetricsThese metrics track the time savings realized by reusing existing software. Institutions may also choose to track the associated cost savings. This is really one metric, but as there are different aspects to software reuse, separate entries are listed.

Metric Time saved by reusing team-developed softwareDescription: This metric measures the time savings realized when software

developed/enhanced by the team for one project is reused in other projects. Each time such a piece of software is reused (after initial development/enhancement), the time saved is incremented by the original development time.

Collection Method: Teams will track this using internal controls and may also choose to track cost savings.

Purpose: Demonstrate the value of the Team to the institutionNotes:

Metric Time saved by reusing software the team became familiar with but did not create

Description: This metric measures the time savings realized when a member of the Team learns a new software package for one project and that software is used again on subsequent projects. In this case, the cost avoidance is the ramp-up time.

Collection Method: Teams will track this using their internal controls and may also choose to track cost savings.

Purpose: Demonstrate the value of the Team to the institutionNotes: This metric should apply only to software components that the majority of

research software developers would not be familiar with. So for example, the Python interpreter and common libraries wouldn’t qualify.


Research Outputs

Metric PapersDescription: A list of published papers based on the work of the Team. This includes

papers published by the Team themselves as well as papers published by Researchers whose projects the Team contributed to.

Collection Method: Teams will require periodic follow-up with alumni as this is a long-term metric.

Purpose: - Demonstrate the value of the Team to the institution- Publicity for the institution

Notes: Suggest that whenever possible, software developed by the Team be assigned a DOI in order to aid in citation.

Metric CitationsDescription: A list of published works that cite the papers described above. If possible, it

would be useful to track citations of citations as well, to demonstrate the reach of the Team’s work.

Collection Method: When collecting the “Papers” metric, Teams should note the “Cite As” information and periodically search for citations.

Purpose: - Demonstrate the value of the Team to the institution- Publicity for the institution

Notes:

Institutional Metrics

Metric Publicity for the InstitutionDescription: A list of press releases, blog posts, articles, etc. that reference the Team

and the home institution.Collection Method: Both the Team and CANARIE will be involved in this. For example, Team will

know about internally created promotion and CANARIE will know about anything we contribute.

Purpose: Demonstrates the value of the team to the institutionNotes: If a Team contributes to a project that makes use of the R&E network,

CANARIE will be happy to write an article to contribute to inthefieldstories.net.


Grants

Metric GrantsDescription: Grants received as follow on to work the Team had already done. Both

number of grants and dollar amount would be useful here.Collection Method: Teams will require periodic follow-up with alumni as this is a long-term

metric.Purpose: Demonstrate value of the Team to the research communityNotes:

Qualitative Metrics

These are stories and quotes from the researchers who have worked with the Team to showcase their perception of the Team’s value.

Metric Short QuotesDescription: Quotes from researchers the Team workedCollection Method: Team to ask researchers for a quote as part of the project completion

processPurpose: Demonstrate value of the Team to the research communityNotes: Archived internally by the team. As such quotes will have value to others,

researchers should be asked for permission to share their quotes more publicly.

Metric Case StudiesDescription: A long-form paper describing the full process involved in the Team assisting

a researcher and the impact of the Team’s work on the research. This would not be done for all projects, just projects with significant team involvement and a big research impact.

Purpose: - Demonstrate value of the Team to the research community- Publicity for the institution

Notes: Team to ask researchers to participate as part of the project completion process


Appendix C – Institutional SupportPlease attach a letter of support from the Vice President of the department that the Team will be part of.

If the Team will not fall under the VPR, please attach a letter of support from the VPR as well.

Appendix D – Researcher Support Please attach at least three (3) letters of support from researchers at your institution who are interested in using the services provided by the Team.

Appendix E – Participant BiosPlease attach one (1) page bios for the Project Authority (PA) and Team Lead (if known).


nep platform sow template - canarie · web viewfor example, receiving requests for projects that...

Documents