The following is a proposal development tool for collaborative research grant applicants— specifically, a set of tips to consider at the pre-proposal stage of the application process.
These tips are informed by an analysis of reviewer comments about pre-proposal submissions to prior calls for collaborative research applications, as well as program staff observations from prior review processes.
How to use these tips:
- The tips are organized by the first four project narrative headers as specified in the Request for Collaborative Research Pre-Proposals, and includes a fifth section with tips about overall proposal presentation. Applicants are encouraged to review the tips alongside the proposal guidance to gain insight about the kinds of details to include in each section of their narrative, as well as suggestions for how to present the information.
- At the end of each subsection of tips, there are also a few observations about common proposal mistakes. These are another way to share insights about how best to present the information.
- These tips are not exhaustive of what should be included in every proposal, nor is it likely that every tip is relevant or necessary to consider for every proposal.
- Keep in mind that every review process is unique; while these tips stem from characteristics of past success and are a helpful reference, they do not guarantee future success.
- Additional resources for scoping, designing, and enhancing collaborative science can be found in the Guide to Collaborative Science.
1) Statement of Need and Response to User Needs
Clearly articulate the need the project will address.
- Keep your statement of need simple and direct.
- Provide the broader context for the project, underscoring its importance and timeliness, but be sure to focus on the issue, or aspect of the issue, that the project will realistically be able to tackle within the project period.
- Connect the problem statement to at least one reserve management need.
Describe the primary users and their needs clearly and in a way that demonstrates their connection to the project.
- Primary users are those most instrumental in developing the project, most directly engaged in the project, and who stand to benefit the most from the outputs.
- There should be a natural link between the need the project seeks to address and the primary users you identify. Be explicit about this link, indicating what aspect of the problem users are interested in and their associated needs.
- State why you have chosen to collaborate with the particular set of users you identify, i.e., explain why being responsive to these users matters for addressing the issue.
- Be explicit about how the project will meet the needs of the users, i.e., explain why they care about the project, how it meets their needs and makes a difference for their work.
- There are many ways to present the users associated with a project in your proposal but it is important to be as specific as possible. This could include identifying individual users, naming groups of users the project will engage, e.g., a specific reserve or organization, government department, agency, working group, or some combination thereof.
- While there may be others who will benefit from and have been engaged in the project in a less direct way, it is sufficient to focus on primary users.
- Because this grant program is meant to address reserve needs, it is appropriate to think of the reserves as one of the project’s primary users, even if the project is led by reserve staff. Be explicit about which aspects of the reserve program will benefit from the project (i.e., land stewardship, training programs, monitoring etc.)
- See tools for understanding intended user needs and reflections on engaging users.
Demonstrate that the primary users are supportive of the proposed project and have been engaged in and shaped its development. Include details about how users have been involved in and helped to shape the project. This signals to reviewers that users are interested in the project. It is also an opportunity to demonstrate how the project is responsive to user needs.
- Discuss how users were involved in identifying the project need and developing the proposal.
- How did initial engagement with users occur? E.g., workshops, surveys, existing working relationships.
- Provide a few specific examples of how user input helped to guide the focus of the proposal.
- Consider including a few brief quotes from primary users that articulate as specifically as possible how the project will benefit their work and help to address the problem.
Common mistakes observed in proposals, i.e., what to avoid doing:
- The connection between the research being proposed and the management need it is meant to address is not direct and specific, i.e., the science is a few steps removed from addressing a specific management need.
2) Project Approach
Describe and justify the customized collaborative process that the project will follow to ensure iterative engagement with users.
- Different types of projects and user groups necessitate different engagement strategies, so the collaborative process should be tailored to the proposed work and the users involved. For example, you might find that close collaboration with a single, highly relevant user group may be sufficient to develop a strong proposal. Or it may be appropriate to identify and engage individual users as representatives of critical groups, rather than designing a process that engages all potential users.
- While describing the collaborative approach, provide the rationale for selecting it. Reviewers often respond positively when, in addition to being presented the approach, they are provided the rationale for the chosen approach. Some important considerations:
- Roles. Generally describe the roles of various users in the process. Do they make up an advisory group? Are some, or all, involved directly on the project team? What are the responsibilities and expectations of these roles and why are they well-suited to the users?
- Timing. Identify the moments in the project when it will be most meaningful to involve users. Being responsive to users often requires an iterative process throughout the lifecycle of the project, and engagement at just the beginning and end may not be sufficient. Be explicit about why the moments you identify are appropriate for the work and the users.
- Reciprocity. Build in mechanisms that contribute to reciprocal relationships, e.g., ask users what kind of support they need to participate in the project as you intend them to be involved, and build that into your approach and budget. Seek and articulate a shared understanding of how users will benefit from involvement in the project.
- Communication.
- Work with your users to identify their preferred mode of communication for engaging in the project, e.g., regular in-person team meetings, conference calls, one-on-one conversations, and build this mode(s) of communication into your process.
- Establish two-way communication with users so their feedback, input, knowledge, and/or needs can be incorporated into the project as it progresses. Single-direction reporting out to users through communications like newsletters or reports is insufficient to achieve true co-production.
- Anticipate the need to be adaptive. Build in mechanisms for being flexible and adaptive to user input, e.g., seek feedback on outputs with sufficient time ahead of the project end date to be able to incorporate changes.
- Justify your approach. For collaborative methods, our typical reviewers are not looking for scholarly citations to justify a theoretical collaborative framework. Rather, they want to understand why a particular collaborative approach or method is being proposed; the justification for the approach is important for them to confirm it is appropriate and will succeed.
- For example, it is important to go beyond stating that a focus group or survey will happen — explain why it is needed and how you know it is appropriate for the project and users.
Clearly describe the methods that will be employed in the proposed project.
- Applicants are not expected to provide a detailed research plan at the pre-proposal stage. Instead, present a clear, concise, and logical overview of the proposed technical methods.
- Technical methods should be appropriate, justified, and should be sufficiently tied to existing knowledge, research, and/or literature.
- There should be a clear connection between the research being conducted and the outputs that will be produced.
If new data are being collected to supplement existing data, be clear about the extent the project will be using each, and what gaps new data will fill.
Ensure that the project scope is realistic given the proposed budget and timeline.
- The scope of sampling, monitoring, and/or other data collection methods presented in the pre-proposal must be feasible within the timeframe of the grant and the requested budget.
- The budget should accommodate data management activities to ensure any new data generated by the project are appropriately available at project completion.
Ensure that the proposed outputs can be reasonably developed within the time and budget constraints of the grant
- The outputs identified in the pre-proposal must be achievable within the scope of the grant.
- If outputs are particularly ambitious, consider providing iterative goals/milestones or metrics to track output development over the timeline of the grant.
Common mistakes observed in proposals, i.e., what to avoid doing:
- Different research questions within the same proposal are not integrated with one another.
- The proposal encompasses too many research activities, and each question is not explored in sufficient detail, i.e., the proposal focuses on breadth over depth.
- Specific methods, approaches, or frameworks that will be used to conduct the research are not adequately explained. This is a particular issue when describing social science, qualitative research, and the development of decision-support tools.
- The collaborative approach does not detail how user feedback will be integrated into overall research. It is not clear when, where and how user feedback will be integrated into the research design and process OR users are only engaged at the very end of the project.
3) Outputs and Outcomes
List the planned outputs (products) and anticipated outcomes (impacts) separately, paying close attention to the definitions of each in the RFP to avoid confusing them.
Clearly connect the dots between a management need, the primary users, how the planned project outputs benefit users, and how use of the planned outputs will lead to desired outcomes.
- The management need and primary users should already have been introduced in section 1 of your pre-proposal, so you do not need to repeat the content here.
- Present the outputs and outcomes in a straightforward manner, making clear the connection to the needs of the primary users.
- Indicate how you know the outputs are appropriate for meeting the needs of users. Explain how users were involved in identifying the outputs that would be useful to them, e.g., they were identified via a user survey/needs assessment or planning workshop.
- Explain how the primary users will use the outputs in their work.
- Explain how the outputs will help to achieve intended outcomes.
Common mistakes observed in proposals, i.e., what to avoid doing:
- Outputs are included without context or the necessary expertise to develop them, e.g., the proposal suggests the team will develop communication or educational material without adequately explaining why and how it fits in the context of the project and who has the expertise to develop such materials.
- Outputs are not connected to the outcomes, which in turn are not adequately connected back to the management need, e.g., how the anticipated outcome explicitly addresses the management need.
4) Team
Demonstrate that the project team is well-qualified to complete the proposed work.
- Team composition and competency feed directly into reviewer confidence that the project approach can be successfully carried out as proposed.
- The team section of the proposal should briefly, and clearly, explain roles. Tables can be used effectively for this purpose.
- As you describe each team member and their role, it should be clear why their expertise and experience are critical to completing the project.
- Be sure to include each of the required roles as stated in the RFP, i.e., project lead, fiscal lead, and collaborative lead.
- Team member resumes can be customized to demonstrate expertise and experience relevant to their identified roles.
Common mistakes observed in proposals, i.e., what to avoid doing:
- Expertise to conduct qualitative research is not adequate, e.g., the team lacks someone with the credentials and/or experience to conduct activities such as focus groups and interviews.
- Resources and personnel for conducting the proposed engagement activities are not sufficient. Some proposals have elaborate co-production and community engagement plans without allocating sufficient funds or personnel to operationalize the plans adequately.
- Outputs are included without the necessary expertise to develop them, e.g., the proposal suggests the team will develop communication or educational material without adequately explaining who has the expertise to develop such materials.
5) Overall Proposal Presentation
Write a high quality proposal narrative.
- Produce a proposal that is well-written, flows well, and is easy for reviewers to read and comprehend.
- Review and edit carefully to ensure the proposal narrative is polished.
- Reviewers notice and often comment when a proposal contains numerous grammatical, spelling, or formatting mistakes.
Include all information in the proposal as required by the RFP: Follow the RFP requirements closely. Reviewers note when proposals do not follow the guidelines and/or do not include all required sections.
Ensure that the proposal narrative is clear, concise, and provides the reviewer with relevant details. Give equal thought to all key aspects of the project. Clearly present all aspects of the project, including: the management need, proposed technical and collaborative methods, outcomes and outputs, and overall project approach/process. Do not assume that reviewers will understand something that is only implied, vague, or loosely connected. Use the evaluation criteria to identify where there may be too much or not enough detail.