Departmental BPC Plan Checklist

This page contains checklists for document structure, tone and clarity, and content for your Departmental BPC Plans, common mistakes and solutions PIs can make when writing their Departmental BPC Plan, and information for how a PI can use their Departmental BPC Plan to write a Connected Project BPC Plan.

Checklist

Each Departmental BPC Plan should include the components in the following checklists to be submitted for verification by BPCnet. Your final version should be no more than two pages in total.

Is limited to 2 pages.
Follows the NSF’s current guidelines on formatting in the Proposal & Award Policies and Procedures Guide (PAPPG).
At the beginning of the document, includes:
- The institution’s name and the name of the department.
- A line for BPCnet staff to insert your effective dates upon Verification of the Departmental BPC Plan.
- The name, role, and contact information for the individual(s) responsible for overseeing the Departmental BPC Plan.
If submitting for verification, include a 1” square box at the top right corner within the margins to reserve space for BPCnet’s verification stamp.
- See the Departmental BPC Plan template for an example of this box.
If submitting for verification, is submitted as an editable Word document.

Uses respectful, person-centric language when describing people.
- Population descriptors should be combined with person descriptors, for example “Hispanic students” rather than just “Hispanics”
- A person cannot be “diverse” – diversity is a characteristic of a population having many dissimilar constituents.
Defines any terms used to describe multiple populations of people.
- For example, “Our Plan will focus on [students/faculty] who are [insert your intended populations]. In the rest of the document, we will refer to these [students/faculty] as “[students/faculty] from underrepresented populations in computing”.”
Does not imply that populations that are underrepresented in computing are homogeneous or deficient in some way.
- For example, an activity description should not say “all women want to contribute to society.”

1. Context

Includes relevant, currently available data that is related to the goals.
- For example, if your goal is to increase the representation of women faculty, included data should relate to gender.
- If data are not available, you can collect data as a goal. BPCnet has a curated list of resources for Data and Evaluation/Measurement.
Includes data that does not violate privacy or make people feel singled out.
- If including the numerical measure you seek to improve would violate privacy, you may include a note that the data has been omitted.

2. Goals

Identifies the BPC goals the department is focusing on.
Sets all goals to be specific, measurable, attainable, relevant, and time-bound (SMART).
Focuses all goals on at least one population included in the NSF CISE definition of BPC.
- You must include at least one of these populations who are identified by NSF CISE as underrepresented in computing: Women, American Indians, Alaska Natives, Blacks and African Americans, Hispanics and Latinos, persons with disabilities, Native Hawaiians, and Other Pacific Islanders.”
- You may also include additional populations for BPC (e.g., veterans, first generation, LGBTQ). For example, a goal could focus on increasing representation of students who identify as Black or LGBTQ, and every activity aligned with this goal needs to focus on both populations. A goal may not focus only on LGBTQ students.
Includes an identifier for each goal for reference elsewhere in the document (e.g., G1, G2).

3. Activities and Measurement

Includes identifiers for each activity for easy reference in a Project BPC Plan (e.g., A1, A2).
Identifies which goal(s) each activity is intended to help achieve using the identifiers set in the goals section (e.g., G1, G2).
Includes a clear description of what will occur as part of each activity.
Includes an explicit connection to BPC for each activity.
Identifies how outcomes will be measured for each activity.
- Some intended outcomes may be difficult to measure; in such cases, it is sufficient to measure an intermediate outcome. For example, it is sufficient to measure the number of students who receive funding to attend a diversity conference instead of the long-term impact of their attendance.
Identifies a contact person for each activity.

Common Mistakes in Departmental Plans

The following list of common mistakes and solutions may help you with your Departmental BPC Plan. Click on an item to view the solution to a specific mistake.

Deciding what to include in your BPC plan

Don’t assume your BPC activities need to be novel or creative.

Instead, use or adapt existing programs or develop partnerships in your local context. Check out the Resource Library on BPCnet.org for a listing of existing BPC activities your department can participate in.

Don’t necessarily include everything your department is doing.

Instead, describe the activities that would benefit from faculty involvement during the timeline of the plan. Consider having an internal document to list all activities and additional department-specific context.

Don’t over-promise or describe a scope that you don’t have the resources or expertise to carry out.

Instead, describe a scope of activities consistent with your capacity, context, institutional resources, and partnerships. Consider focusing your plan on data collection if you are just getting started.

Don’t assume that all K-12 student outreach will broaden participation in computing.

Instead, create a plan that uses an inclusive curriculum and pedagogy within a context that serves K-12 students who are from groups underrepresented in computing.

Don’t forget to include at least one activity that contributes to each goal.

Instead, consider writing a SMART goal for each of your activities or a goal shared by multiple activities. (Note: You can include additional activities that do not align with one of your goals.)

Don’t write your plan to benefit “all students” only.

Instead, make sure your plan addresses the underrepresentation within computing of women, African Americans, Hispanics, American Indians, Alaska Natives, Native Hawaiians, Pacific Islanders, and/or persons with disabilities.

Don’t plan to improve a number you don’t know.

Instead, include a goal to measure it first.

Writing your BPC Plan

Don’t omit definitions of acronyms that describe groups of people.

Instead, enumerate the groups covered by the acronym. For example, instead of “historically underrepresented groups (HUG)” say “students from historically underrepresented groups in computing (HUG; i.e., students who are American Indian or Alaska Native, Black or African American, Hispanic or Latino, Native Hawaiian or Pacific Islander)”.

Don’t imply that students or faculty from groups underrepresented in computing are lacking ability or other individual characteristics that would require you to lower your standards.

Instead, identify how your plan addresses biases in evaluation or gaps in opportunity.

Don’t forget to describe your context through comparisons.

Instead, include your local context (e.g., the number and demographics of students in your department compared to people at your institution, region, state). If you don’t have the relevant data, include collecting this data as part of your activities.

Don’t provide instructions to your faculty about how they can get involved.

Instead, include that information in an internal document.

Don’t claim current activities are successful without evidence.

Instead, hedge your claims, include currently available evaluation data, or include activities to collect relevant data.

Don’t conflate group and individual terms in your writing.

Instead, if an activity is benefiting people, use terms where people are the subject. For example, instead of saying you will fund participation by groups that are underrepresented in computing, say you will fund participation by students belonging to groups that are underrepresented in computing.

Don’t refer to individuals as “underrepresented”.

Instead, describe the populations they are part of (or identify with) as underrepresented. For example, “students from populations underrepresented in computing” rather than “underrepresented students”.

Don’t refer to individuals as “diverse” as a euphemism for their race, gender, or disability status.

Instead, use “diverse” only when you mean that a population contains a mix of people not typically considered part of the same population.

Implementing your BPC Plan

Don’t forget to measure the impact of your BPC activities.

Instead, include data collection as part of your activities from the start.

Don’t leave your plan on the shelf.

Instead, schedule regular meetings with the team to revisit your Departmental BPC Plan and measure your progress. Revise as needed.

Supporting PIs Using a Departmental BPC Plan

PIs using this Departmental BPC Plan should be able to answer the following questions for their Project BPC Plans, per the NSF CISE definition of a meaningful Project BPC Plan:

Is there a plan to measure the outcome(s) of the activities?

Does the plan describe a goal using institutional or local data?

Does the plan identify the characteristics of participants from an underrepresented group, including school level (e.g., African-American undergraduates or female high-school students)?

Does the plan describe activities that address the goal(s) and intended population(s)? Is there a clear role for each PI and co-PI?

Does the plan describe how the PI is prepared (or will prepare or collaborate) to do the proposed work?