The following is a proposal development tool for Catalyst / Knowledge Exchange grant applicants— specifically, a set of tips to consider when writing a proposal.

These tips are informed by an analysis of reviewer comments about proposal submissions to prior calls for collaborative science 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 Catalyst / Knowledge Exchange 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. 

Download a PDF of the proposal tips

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 need statement to at least one reserve management or knowledge exchange 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. 
• 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 work being proposed and the management or knowledge exchange need it is meant to address is not direct and specific, i.e., the proposed activities are a few steps removed from addressing a specific management or knowledge exchange 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. 
  • The relatively short time frame of these  grants will require an efficient, well-managed process for engaging users.  
    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.  
    Keep in mind that the goals and type of proposed work should dictate the engagement approach as well as the breadth and depth of engagement planned during the project.
• 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.

• 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 methods 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 relatively short time frame of these grants will require an efficient, well-managed process for engaging users. See tips under the collaborative process section above.
• The scope of sampling, monitoring, and/or other data collection methods presented in the 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 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:

• The proposal encompasses too many activities, and each 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 complete the project 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 the overall project. It is not clear when, where and how user feedback will be integrated into the project 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 or knowledge exchange 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 or knowledge exchange need and primary users should already have been introduced in section 1 of your 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, as well as to longer-term impacts to coastal and estuarine health and resilience. 
• 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 an 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. 
• Explain how the intended outcomes will influence coastal health and resilience.

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 or knowledge exchange need, e.g., how the anticipated outcome explicitly addresses the management or knowledge exchange 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 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 or knowledge exchange 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.