"In progress" research tells a program director one thing: you tried. It does not reliably tell them you finished, produced anything useful, or will have something real by the time they decide whether to interview you. That's why PDs discount it. Not because they hate research. Because they're grading evidence, not effort.
I've seen applicants load ERAS with half-built projects, protocols, chart reviews that never got analyzed, "manuscript in preparation" lines that stayed in preparation forever. Reviewers catch on fast. They have to. They're reading hundreds of applications, and anything fuzzy gets mentally downgraded in seconds.
This article is the fix. At this point you should stop thinking, "How do I make this sound impressive?" and start thinking, "What can I make verifiable before review season?" We're going to walk through the actual reviewer mindset, the timing problem, and a month-by-month, week-by-week, and day-by-day plan to turn shaky "in progress" entries into credible research signals.
What PDs Are Really Scoring When They See "In Progress"
PDs aren't admiring your intentions. They're asking a brutally practical question:
Can I trust that this turns into something real, soon?
Usually, they're scoring three things at once:
Momentum
- Did you move the project beyond talk?
- Is there analysis, a draft, a figure, an abstract, a submission?
Productivity
- Do you finish what you start?
- Is this one of several outputs, or just academic wallpaper?
Verifiability
- Can your role and status be checked quickly?
- If asked in an interview, can you explain the question, methods, endpoint, and current state without rambling?
The common reasons "in progress" gets downgraded are painfully predictable:
- No defined endpoint
- "Working on a cardiology outcomes project" means nothing.
- No primary outcome
- If you can't state what you're measuring, the project isn't mature.
- Unclear authorship
- Are you first author? One of seven students? Just "helped" with data collection?
- Timelines that don't fit the cycle
- If the IRB just went in and the chart pull hasn't started, that project is irrelevant for this season.
Here's the evidence ladder PDs use, whether they say it out loud or not:
Completed output beats promised output. Every time.
A published manuscript is strongest. An accepted abstract or delivered poster is strong because it's concrete and dated. Analysis underway with a draft can help if described well. Protocol-only work is weak. Not worthless. Just weak.
At this point you should audit every project on your CV and ask: Where am I on the ladder, really? Not where your mentor says it's "heading." Not where you hope it'll be by winter. Where it is today.
The Timeline Reality: When PDs Need Proof (and When Your Work Must Be Ready)
This is where applicants get burned. The residency application cycle moves faster than many research projects.
By the time your "interesting project" finally becomes a poster next spring, the program may already have:
- reviewed your ERAS,
- offered or denied an interview,
- formed an impression of your scholarly productivity,
- and built a rank list.
Late results can help. They usually don't replace missing core evidence.
So the rule is simple:
If you can't credibly estimate a deliverable by the review period, don't lean on that project as a major application strength.
Reframe it instead around verifiable milestones:
- IRB approved on date X
- Data collection complete
- Preliminary analysis performed
- Abstract drafted
- Submission planned for named meeting by date
That doesn't make weak work strong. But it does make vague work readable.
At this point you should line up your projects against the calendar, not your optimism.
Month-by-Month Playbook: Turn "In Progress" Into Credible, Reviewable Outcomes
Here's the Timeline Guide version. Three tracks run in parallel:
- Data/Productivity track
- Documentation track
- Messaging track
4-6 months before ERAS
At this point you should:
- pick one to three projects max that can realistically mature in time,
- define the primary endpoint for each,
- confirm your role and authorship position with the supervisor,
- identify the nearest tangible product:
- abstract,
- poster,
- manuscript draft,
- completed analysis.
Checklist:
- Research question in one sentence
- Primary outcome defined
- Dataset or source identified
- Your concrete job assigned
- Deliverable and target date chosen
3 months before ERAS
At this point you should:
- have active data collection or analysis underway,
- produce at least one table, figure, or summary result,
- create a project folder with dated proof of progress,
- draft language for how the project will appear on ERAS.
Documentation to gather:
- IRB or exemption status
- Analysis file/version
- Abstract shell
- Meeting target or journal target
- Mentor-confirmed status line
2 months before ERAS
Now the project needs shape. Not vibes. Shape.
At this point you should:
- finish data collection if possible,
- run baseline analyses,
- draft the abstract or manuscript skeleton,
- ask your mentor for a hard yes/no on what will be true by submission day.
Messaging track:
- Replace "ongoing study of..." with specifics.
- State your role plainly.
- Use dated status markers when allowed and appropriate.
Example:
- Weak: "Investigating outcomes in heart failure patients; manuscript in preparation."
- Better: "Retrospective cohort study of 214 heart failure admissions evaluating 30-day readmission predictors; performed data cleaning and multivariable analysis; abstract draft completed August 2026."
1 month before ERAS
At this point you should:
- freeze your descriptions to what is true now,
- avoid magical future-tense claims,
- prepare a one-sentence verbal explanation for interviews,
- decide what can be updated after submission.
Before submission checklist:
- Every project has a real endpoint
- Every status label is defensible
- Your role is explicit
- One near-term deliverable exists
- Mentor agrees with representation
After submission
At this point you should only send updates for real milestones:
- abstract accepted,
- poster presented,
- manuscript submitted,
- manuscript accepted.
Do not send "still working on it" updates. Nobody cares.
Week-by-Week & Day-by-Day: What to Do Starting Now (Even If Your Project Is Already "In Progress")
If your project is already labeled "in progress," don't panic. But don't leave it vague either. Fix it fast.
This week: triage the project
At this point you should answer five questions:
- What is the exact research question?
- What is the primary endpoint?
- What has already been completed?
- What is my authorship role?
- What is the next dated deliverable?
Use this PD-readable checklist:
A strong entry scores 5/5. Most weak entries are sitting at 1 or 2.
14-day mini-sprint
Days 1-2
- Pull every file related to the project.
- Write a three-line summary:
- question,
- methods,
- current status.
- Confirm authorship with the project lead.
Days 3-4
- Define or rewrite the primary endpoint.
- Clean the dataset or verify data source integrity.
- Make a list of missing variables.
Days 5-6
- Run a baseline analysis.
- Generate one table or figure.
- If you can't generate a figure, the project is less advanced than you think.
Days 7-8
- Draft an abstract skeleton:
- background,
- methods,
- results,
- conclusion.
- Fill in placeholders honestly.
Days 9-10
- Ask mentor/senior author for feedback with a deadline.
- Request a realistic statement of next milestone:
- submission date,
- presentation target,
- manuscript plan.
Days 11-12
- Rewrite the ERAS entry so it's specific and defensible.
- Remove puffed-up verbs and future promises.
Days 13-14
- Practice explaining the project out loud in 45 seconds.
- Save documentation proving status in case interviewers ask.
A clean ERAS research entry should include:
- project type,
- topic,
- your role,
- current stage,
- dated milestone,
- next deliverable.
Avoid:
- "major contributor"
- "significant involvement"
- "publication pending" unless it actually is
- "manuscript in preparation" with no details. That phrase is abused to death.
After ERAS Submission: How to Update Programs Without Over-Claiming
Send updates only when something changed in a way a reviewer can respect quickly.
Good update triggers:
- abstract accepted,
- poster date confirmed,
- manuscript submitted,
- manuscript accepted or e-published.
Bad update triggers:
- still collecting data,
- mentor says paper is "moving along,"
- draft exists somewhere in Google Docs chaos.
At this point you should keep updates brief and proof-oriented. Think mini-LOI, not autobiography.
A good structure:
- one-line thank you or expression of interest,
- one concrete update,
- date and status,
- one sentence on relevance if needed.
Example:
- "I wanted to share a brief update to my application. Our retrospective study on postoperative delirium predictors was accepted for poster presentation at the regional ACP meeting on January 12, 2027. I conducted the data analysis and co-drafted the abstract."
That works because it's dated, specific, and verifiable. No chest-beating. No nonsense.
What to Do If You Have Nothing Yet, Ethically Strengthen Your Research Signal
If your current project is basically a protocol and a dream, stop pretending it's your application's research backbone.
At this point you should decide whether to continue, pivot, or reframe.
Continue
Choose this if:
- data are accessible now,
- analysis can happen soon,
- a real deliverable is likely before review season.
Pivot
Choose this if your current project is stuck in approvals or slow enrollment. Better options:
- retrospective dataset analysis,
- focused systematic review,
- quality improvement project with a narrow endpoint and proper oversight.
Reframe
Choose this if the work won't mature in time but you still participated meaningfully. Present it honestly and make sure your main research signal comes from something tangible.
Best strategy? Own a component with a named product:
- data cleaning,
- literature extraction,
- figure creation,
- statistical analysis,
- abstract drafting.
That's how you turn "helped with research" into something real.
Summary: A Practical Rule for "In Progress" Research on ERAS
PDs discount "in progress" research because they need proof, fast. That's not unfair. It's rational. They're making decisions on compressed timelines, and vague projects don't help them trust your academic follow-through.
So your job is straightforward:
- convert status into outcomes,
- document milestones with dates,
- state your role clearly,
- and write the ERAS line so a tired reviewer can believe it in five seconds.
At this point you should choose one project today, assign it a near-term deliverable date, and rewrite the entry around what is verifiable now, not what you hope exists later.
That one move fixes more applications than another month of wishful thinking ever will.