Wednesday, September 13, 2023
Context: In my role as division director of IIS, I’m sending out a short message to the IIS mailing list on the Second Tuesday Every Month (STEM). Here’s the installment for September 2023. (I’m a day late this time. Sorry.)
Hi IIS Community,
NSF has to be really careful about how it communicates with the outside world. As a professor, it reminds me a lot of the way I need to communicate with students in a big class. I follow rules like:
Make sure all announcements, including any assignment clarifications, go out to everyone.
Make sure there’s a place (the syllabus) that everyone can refer back to to make sure they can confirm rules and expectations when there’s ambiguity or confusion.
Make the rules for the class (in the syllabus, say) as clear and easy to understand as possible.
Don’t make jokes, as they are easily misunderstood.
Ok, I typically ignore the last one, but I probably shouldn’t.
Playing the role of the syllabus at NSF is the PAPPG (Proposal & Award Policies & Procedures Guide):
https://new.nsf.gov/policies/pappg .
NSF folks pronounce it “PAP-jee”. It is the official external source for information about NSF's proposal and award processes. It also covers post-award topics and is updated regularly to reflect the current rules. When there are differences between different versions, it’s important to keep in mind that a version of the PAPPG applies to all proposals or applications submitted while that version is effective. (You can see on the PAPPG page when each version was effective.)
Like a syllabus, it’s important to refer to the PAPPG when there are questions about procedure. But also like a syllabus, very few people have read the PAPPG cover to cover. Maybe that applies to you. I don’t know. My point is just that NSF takes the job of making the PAPPG accurate and complete very seriously.
Much like a syllabus doesn’t typically detail all the assignments used in a class, the PAPPG doesn’t describe all of the particular funding programs at NSF. For that, there are solicitations and DCLs, which I’ll talk about next.
A solicitation is an announcement about a particular funded program. The “funded” part here is important. It means there’s actual money behind the program. Here’s an example of a solicitation that was released since I arrived at NSF:
https://new.nsf.gov/funding/opportunities/safe-learning-enabled-systems .
It includes information like a synopsis of the program, how much money is behind it ($9,999,999, in this case), an estimate of the number of awards (funded projects) that will result, relevant deadlines, restrictions on proposals or proposal teams, a list of cognizant program directors you can go to with questions, and other details so that the solicitation is your almost-completely-self-contained source for what you need for applying to the program. You know, for those who haven’t read the PAPPG.
In contrast, a DCL (“dee-see-ell”) is a “Dear Colleague Letter”. These are less formal than solicitations, but more formal than the name “Dear Colleague Letter” implies. (For me, it brings to mind a “Dear John Letter”, but the two really are quite different.) At NSF, a DCL is an official communication with the research community, but not necessarily one with money behind it. DCLs can be used to announce new procedures, requests for information or interest, and the availability of supplemental funding for particular uses. For example, the availability of cloud credits for CISE grantees (which I mentioned in STEM #2), was announced as a DCL:
https://www.nsf.gov/pubs/2022/nsf22087/nsf22087.jsp .
DCLs and solicitations go through different approval processes internally, which is another reason for the distinction.
Of course, on the “much more informal” side of the spectrum are NSF’s webinars, and, oh!, emails like this one!
Interestingly, I learned last week that there are cultural differences between directorates at NSF in the use of DCLs and solicitations. The Engineering directorate, ENG, doesn’t use solicitations. Instead, they let the community know what they are looking for using DCLs. I can see pros and cons of that approach. The cultural difference matters, though, because there are some programs that CISE and ENG do together, like in robotics. The NSF program directors are very clever in finding ways to make things work across directorates despite these differences.
Ok, I was joking about the funding for the Safe Learnable-Enabled System program. It’s a $10M program. I just wanted to be able to say that this message was a day late and a dollar short.
Until next time!
-Michael