Common Proposal Errors Exposed

Here are some of the most common mistakes on proposals.

A duplicate new proposal is submitted unnecessarily.
A user who doesn’t get time sometimes submits an identical proposal in the next cycle. The reviewers get crabby when this happens! Actually, it’s the beam time request that didn’t get time, not the proposal. The proposal is still valid for a total of six cycles or until the number of shifts recommended by the Proposal Review Panel is used. What to do instead: Reuse the current proposal. Go to the existing proposal, choose the Beamtime Request tab, and click the link “Make New Request.” (And be sure to click “Submit” on the new request.) On the new beam time request, you can use the “Progress” field to describe new developments that might influence decisions about allocations. Also, the score of proposals that have not received time is improved; see the FAQ page and the User Policies and Procedures page.

Parallel time on multiple beamlines is requested incorrectly.
Occasionally a user wants time on two beamlines in the same cycle, for different kinds of analysis. Often the two beamlines are marked as first and second choice on one beam time request. Time can be allocated on only one. What to do instead: Make two separate beam time requests for the same cycle, with different first-choice beamlines. (Be sure to indicate scheduling constraints on both requests and clearly explain in the body of the proposaly why both beamlines are needed.)

“Project” status is requested when not appropriate.
Sometimes users ask for project status (guaranteed time over multiple cycles) without making a compelling argument. What to do instead: Double-check the description linked next to the project status question in the proposal form. There must be a reason intrinsic to the research that necessitates predictable access over multiple runs, and this need must be well justified in the proposal. If in doubt, consult the User Office.