Project Management for Research Projects
You can't estimate what you haven't discovered yet. You can still measure how fast you're moving, and that turns out to be most of what a research team needs.
The estimate problem is not a discipline problem
Ask a research team when a literature review or an experiment will conclude, and a confident answer is usually a sign they haven't started yet. This isn't a failure of planning skill; it's the nature of the work. A hypothesis can be confirmed on the first pass or need six more angles nobody anticipated. A dataset can be clean or a month of cleaning. Committing to a date before doing the work means committing to a guess dressed as a plan.
Most project tools handle this badly: they ask for a due date up front and then treat every miss as a failure of execution rather than what it actually was, new information changing the picture. Teams respond by either padding every estimate absurdly or quietly stopping using the tool for anything that matters.
ShipSprint doesn't ask a research team to pretend it knows the ending. It tracks pace instead, and lets the forecast update honestly as the picture changes. That's really the whole shift: the forecast is built from what the team actually finished, so it's allowed to be wrong in either direction rather than committed to a number nobody believed to begin with.
The real question isn't "when will this finish"
Most research leads already know the honest deadline question is unanswerable in the way a sponsor wants it answered. The more useful questions are quieter ones: is the team still moving at the rate it was last month, or has something stalled without anyone flagging it? Is one thread absorbing all the attention while three others sit untouched? Those are answerable, and they're usually more predictive of whether a milestone will land than any date written down at the start.
A board that tracks pace rather than a due date lets a lead ask those questions on a Tuesday instead of discovering the answer at a review meeting three months in, when the option to redirect effort has mostly closed.
What forecasting from velocity can tell you, and what it can't
Delivery forecasts here are calculated from the team's measured velocity as sprints complete: how much got done, not how much was promised. For research work, that number is honest in a way a fixed deadline isn't: it tells you the rate at which hypotheses are being tested, angles closed off, or sections drafted, based on what actually happened recently.
Be clear about the limits, because overclaiming here would be its own kind of dishonesty. Velocity can tell you the pace has slowed, that a sprint produced less than the last three, or that a milestone is trending later than planned. All of that surfaces weeks early rather than on the day something was due. What it cannot tell you is whether the underlying question has an answer, or whether the next experiment will be the one that works. No tool can forecast a discovery. What ShipSprint forecasts is your team's throughput against the plan you currently believe in, and it updates that forecast the moment the plan changes, which is most weeks, for research.
What research teams actually need tracked
Forecasts come from measured velocity, not a date someone guessed in a kickoff meeting. When the pace changes, the forecast changes with it, immediately, not at the next status update.
Per-column WIP limits keep a research board honest about how many open questions a team is actually chasing at once, rather than letting "in progress" become a graveyard of half-started threads.
Write-ups, negative results and half-formed hypotheses live next to the tasks that produced them, with page history, so the reasoning behind a dead end is preserved, not lost when the thread goes cold.
A finding buried in a page, like "we should re-run this with the larger sample," can become a task on the spot, so it doesn't just sit there until someone remembers.
Research stalls for legitimate reasons: waiting on a dataset, an ethics approval, someone else's output. One tap flags it with context attached, rather than it just quietly not moving.
Five seconds next to the task just finished. No screenshots, no activity tracking: a week that was mostly reading still counts as a week worked.
When a team is chasing several hypotheses or workstreams in parallel, the owner command center answers "where's the whole project" without anyone reconciling five separate updates.
Honest signals for research leads
- A slowing velocity trend surfaces before a milestone date, so a lead can ask "why" while there's still time to act on the answer
- Scorecards are leave-adjusted, so a researcher who was out for a week doesn't read as someone who underperformed
- The Monday digest rolls up progress across every open thread without anyone writing a status report
- Nothing here promises to predict a scientific outcome; it tracks how the team is moving, which is a different and more honest thing
- A wiki page can hold a negative result as usefully as a positive one, so the next person doesn't repeat a dead end nobody wrote down
When a research project does need a date
Not every deadline attached to research work is fake. Funding cycles end, conferences have submission dates, a stakeholder needs a preliminary answer by a specific quarter regardless of how clean the science is. Those constraints are real and shouldn't be pretended away either. The honest way to hold them is to treat the external date as fixed and let the forecast tell you, as early as possible, whether the team's actual pace will get there. That's a different exercise from setting the date as if it were achievable and hoping the work cooperates. When the forecast says no, that's information a lead can act on: descope, add a hand, or renegotiate the date while there's still room to have that conversation.
Common questions
By forecasting pace, not outcome. The forecast is built from how much the team has completed recently, projected forward against what's currently planned. It tells you whether you're moving at the rate you expect, and flags early if you're not. It doesn't and can't predict whether the research question itself will resolve on schedule.
No. Many research teams use continuous-flow boards with WIP limits instead of sprint cadences, and rely on cycle time rather than sprint velocity. The forecasting works from either, so a team can adopt whichever framing fits how the work actually happens.
The built-in wiki, with page history so you can see how a line of thinking evolved. Any sentence on a page, a citation to chase, a method to try, can be converted directly into a task, which keeps notes from becoming a place where good ideas go to be forgotten.
No. The same pattern fits any work where the destination is uncertain but the pace still matters: market research, user research, product discovery, R&D. If estimates feel like fiction, velocity-based forecasting is usually a more honest fit than a fixed due date. See ../../product.html for the full toolset.
Related pages
See it on your own work.
A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.
14-day full-access trial · sample project included · no card required