NSF CISE Research Initiation Initiative (CRII)

From NSF program director Jeremy Epstein: The Computer and Information Science and Engineering (CISE) Research Initiation Initiative (CRII) program is for research and teaching faculty in the first two years of their appointments.  In 2014-15, the first year of the program, there were 76 awards under this program.

There will be a webinar for potential CRII applicants on Aug 5 1pm-2pm, describing the goals and requirements of the program, and changes for the 2015-16 program.  Register by Aug 4.

Proposal submissions are due on Sept 30.

DARPA DSO Proposer’s Event

As posted on the CCC blog, the Defense Advanced Research Projects Agency (DARPA) Defense Sciences Office (DSO) is sponsoring a Proposers Event on July 21-22 to provide information to potential proposers on the objectives of the anticipated Defense Sciences Office (DSO) Office-wide Broad Agency Announcement (BAA) releasing sometime in June 2015. Note that the event will be webcast, and advance registration is required for both the in-person meeting (by June 30) and the webcast (by July 14).

Of the technical areas supported by the DSO, theoretical computer science work seems a closest match for “Mathematics, Modeling, and Design”: Development and implementation of advanced mathematics and modeling tools for applications of interest to U.S. national security. Example topics: novel mathematical advances that accelerate discovery in physics, chemistry, and materials science; new approaches to electromagnetic modeling and simulation; major conceptual advances that lead to novel computation at scale; advanced mathematics and modeling tools needed to efficiently propagate multiple sources of uncertainty to make accurate predictions about stochastic, complex systems; representational and computational foundations for new design approaches and tools; and techniques to enhance the capability for humans to understand, construct and optimize complex engineering systems.

Highlights from STOC presentation

Since there wasn’t time to go through the full CATCS Report during the STOC business meeting last week, here are a few items of note.

And many upcoming deadlines:

NSF CAREER Program Webinar

NSF CAREER Program Webinar

May 26, 2015 1:00 PM  to 3:00 PM (Eastern Daylight Time, New York, GMT-04:00)

The NSF CAREER Coordinating Committee is hosting a webinar to provide an overview of the NSF Faculty Early Career Development Program (CAREER) and to answer participants’ questions about development and submission of CAREER proposals.

The webinar includes an overview presentation followed by a question-and-answer period.  For more details, see http://www.nsf.gov/events/event_summ.jsp?cntn_id=134940

STOC grant-writing panel recap

Moses Charikar and I organized a grant writing panel at STOC 2013. The panel was well attended and I think (or at least hope) provided useful information to the audience, thanks to our great panelists: Joan FeigenbaumPiotr IndykBala Kalyanasundaram, and Salil Vadhan.

Panelists had many insights on aspects of achieving funding, some highlights that stuck in my memory:

1) There are many funding opportunities out there apart from the “obvious” sources (i.e., NSF theoretical foundations) – check those out.  Don’t be afraid to contact people with lots of funding experience for advice or even to ask (if appropriate) to join future large projects.

2) That said, you should always make sure that you actually want to do the proposed research, and shouldn’t join a project you don’t care about just for the funding. This is particularly true for large projects or funding from “mission oriented” (as opposed to “basic science oriented”) agencies, where the funding often comes with plenty of strings attached.

3) If you work in theoretical CS in the U.S., you should definitely consider applying  for grants from the Computing and Communication Foundations division (and in particular the Algorithmic Foundations program). Grants have gotten bigger and competition smaller than people may remember from past years, and it’s definitely worth the trouble.

4) NSF program officers are your friends, they are more than happy to talk to you, and can often help you find the right program for your proposal.

5) Especially (but not only) in NSF CCF grants, people understand that theory research is unpredictable. If you’ve done good research in the area, nobody will blame you for not solving the particular problems you set out in your proposal. That said, the proposal should have a mix of problems of various difficulty and “speculativeness”.  If the proposal just lists some important open problem without suggesting that you have any new approach to solve them, it’s unlikely to get funded.

6) Collaborative projects are much easier to manage when it’s 2-3 PI’s (primary investigators) who are close collaborators than project involving a large number (say 7 or more) PI’s.

7) Writing a proposal involves making choices – how big the team, one area or interdisciplinary, contain everything you want to work on or leave topics for future proposals, apply to NSF or to more  “mission oriented” sources of funding. All those choices are non-trivial and have pros and cons, which you’d do well to consider carefully and consult with people who’s had experience.

8) Proposals (especially but not only large multidisciplinary ones) often don’t get funded in the first attempt. People said they found that the proposal became better and the team more cohesive in future iterations.

While some of the advice is universal, we did not have a panelist with specific expertise in funding outside the U.S. We hope to have some guest posts on this blog about this topic in the future, though in the meantime we would welcome tips about resources on grant writing in the comments.

One such resource that could be very useful was collected by Moses Charikar and Piotr Indyk – this is a collection of  successful NSF CAREER proposals  along  with retrospective comments by the authors. We are truly grateful to these researchers for making available this valuable resource to anyone that is considering submitting a grant proposal. Salil Vadhan also made available his multi-disciplinary grant proposal.

People might also find useful  Joan Feigenbaum’s presentation from the event.

Advice from Sanjeev Arora on writing grant proposals

In advance of the grant writing panel to be held this Saturday 8pm at STOC, Sanjeev Arora put together some very useful tips for people writing grant proposals. These tips as well as others will be discussed on Saturday by our panelists: Joan Feigenbaum, Piotr IndykBala Kalyanasundaram, and Salil Vadhan.

The panel will be moderated by Moses Charikar and me.

Advice on writing a research grant proposal.

Sanjeev Arora

Professor of Computer Science,
Princeton University

April 2013

  1. Approach it with a positive attitude: it is a necessary part of your job along with writing papers, giving good talks, following the research in your field, PhD advising etc. Remember: the better you get at it, the less frequently you need to do it.What I like about the current peer review system (at least in computer science) is that it allows young researchers with good, imaginative proposals to get funded, leaving more senior researchers in the dust.  I’ve seen it happen a lot.

    Another positive aspect for me is that this system forces me to evaluate myself every couple of years, and figure out what I should do next.

  2. Don’t forget the basics: a grant proposal has to identify a problem or set of problems; outline what is lacking in current approaches; and sketch how you will address these deficiencies and solve the problem. Along the way it should argue that you are the right person to do this work. Usually it’s best to weave your past track record subtly into the entire narrative instead of relegating it to a separate section at the end. Keep in mind that reviewers are asked to judge the proposal based upon the research that is being proposed, and not merely upon the past track record of the PI. (Of course, in practice reviewers rely a lot upon the past track record.)Also, it is useful —for proposer as well as the reviewer— if the proposal states concrete “project goals” sprinkled throughout the writeup. (Create a separate latex environment for this.) Instead of saying something wishy washy like “We plan to further explore area x”  say: “Project Goal 4: Use technique blah to design a polynomial time algorithm for problem foo.” Ideally this concrete goal should come after a paragraph or two where you have sketched the prior art, and explained the importance of this goal.

    Avoid the temptation to cut and paste text verbatim from your recent papers (or even worse, actual theorems riddled with messy parameters). A research proposal is more like an expository article geared to a broad audience —at least the couple of opening sections.

  3. In addition to getting the basics right, you should pay attention to the other stuff and do your groundwork. Carefully read the program solicitation, and if possible, talk to NSF program officers.  They attend conferences, answer emails, take phone calls, etc.  Obviously, they will be most candid in face to face conversations. (Keep your conversation short and to the point, though.) They can give you a sense of funding trends and current buzzwords at NSF, saying things like: “There are three buzzwords in the program solicitation but the last one is more important to us than the first two.” Or “Your work seems relevant to area X and there is a program in area X that is looking to fund foundational work.”  Colleagues can also be useful in this process.Such groundwork is especially useful for a new funding program that is in the pipeline. If you know about it in advance, you could have a proposal idea ready —or collaborators lined up—when the solicitation comes out. In general it is much easier to get funded in the first year or two of a new program, before it gets overwhelmed by “proposal pressure.”
  4. While writing your proposal, be sure to address the buzzwords you have discovered as part of (3). I don’t mean to make all this sound shallow or dishonest. Obviously, if your work has no implication for national security, you shouldn’t claim any. But if there happen to be some, do point them out. (Don’t exaggerate; reviewers are smart.) Another example: if you enjoy working with high school students and have an excellent track record in it, consider making that a component of your proposal. There are no fixed rules, and anything that helps you stand out from the crowd is fine and good.Put yourself in the reviewers’ shoes as you  write. They have limited time and have usually received highly specific instructions from NSF (usually including the buzzwords from the solicitation).  Make it easy for them to evaluate your proposal. Use short sections with descriptive titles, especially “Broader Impact”, “Postdoc mentoring plan” etc. that NSF wants them to specifically comment on. Use short, declarative sentences that are easy to parse.
  5. Conversely, if you are ever asked to serve on a selection panel, take careful notes on what worked in the proposals you reviewed and what didn’t. What aspects did the panel dislike? Of course, the quality of research is the most important aspect. But panels can be harsh on good researchers who clearly didn’t put in the time in crafting a good proposal, or who had obviously not read the solicitation carefully.
  6. Ask colleagues for advice as well as examples of their successful proposals. (Do it indirectly so you don’t put them on the spot. Most people are happy to help.) Ask colleagues who are not in your subarea as well. I find it very stimulating to read a well-crafted proposal not in my research area.
  7. Work out a writing schedule that works for you. I like to do a 1-page sketch to collect my thoughts and then modify it as I ponder it for several weeks. But then I do the actual writing fairly close to the deadline when I am more focused and efficient. If you plan to seek feedback on your draft, allow time for that.


Crosscutting solicitations are often judged by panels composed of people from different specialities. So write appropriately. Suppose you wish to work on theory problems arising in computer systems. Be sure to read some successful systems proposals and learn what aspects are important to systems reviewers. Talk to systems colleagues and learn a bit of their lingo. A day or two of such legwork will really pay off, and also improve your research.

Most panelists will not know your past record, and it has to come through clearly in the proposal.

The “groundwork” aspect described earlier (talking to program officers, etc.) is  very important for crosscutting program. Some program officers will even go to the trouble of listening to your proposal idea and give you valuable feedback. Sometimes they will give you feedback on a rejected proposal and suggest changes that could allow it to succeed in future.

Things like broader impact, training of underrepresented groups, etc. can be very important.  Pay attention to the solicitation’s “buzzwords.” All of this advice is is especially relevant for larger projects. Again, I don’t mean to advocate any dishonesty; just keep those aspects in your mind.

Often crosscutting proposals involve collaboration. The proposal usually should contain contributions from all team members, but one individual should take charge to make the proposal read well. Panels look for the following: Does this collaborative team make sense? How likely is it that these people will actually work together? Have they collaborated before? If your team involves people in different geographical locations, you need to sketch out a plan for how this collaboration will happen: regular meetings, joint postdocs, whatever. (It is wise to give such a plan even if all people are in one place. Sometimes solicitations will require such plans.) Also give a rationale for the team’s composition. (“Doing such a project calls for a mix of skills x, y, z. On our team we have skills x, y, z.”) Ideally do this mental exercise sufficiently ahead of the deadline so you can seek additional collaborators if you realize your team needs to be fleshed out.