flowchart LR
A[1. Charter<br/>aims, data, roles,<br/>authorship plan] --> B[2. Set up<br/>repo, data access,<br/>variable dictionary]
B --> C[3. Analyze<br/>locked analysis plan,<br/>reproducible notebooks]
C --> D[4. Synthesize<br/>figures, dashboards,<br/>drafts]
D --> E[5. Disseminate<br/>abstract, manuscript,<br/>brief]
E --> F[6. Archive<br/>OSF/Zenodo, changelog,<br/>authorship audit]
11 Project Management and Workflow Systems
This chapter describes how a project moves from idea to product, and the systems that keep work findable, trackable, and reproducible. The goal is low cognitive load and high mentee independence.
11.1 The project lifecycle
- Charter. Complete the Project Pod Charter: aims, datasets, access rules, roles, deliverables, authorship plan discussed at the start, and weekly task structure.
- Set up. Create the GitHub repo (use the repo checklist), establish data access and the variable dictionary, and stand up the project tool board.
- Analyze. Lock a statistical/ML analysis plan (pre-registered or internally locked) before looking at outcomes; work in reproducible notebooks (Chapter 13).
- Synthesize. Produce figures, dashboards, and drafts using the planning templates.
- Disseminate. Submit abstracts, manuscripts, briefs, and dashboards (Chapter 16).
- Archive. Deposit code/data appropriately, update the changelog, and run an authorship audit (Chapter 21).
11.2 Workflow systems
We standardize on a small, deliberate toolset so members can move between projects without relearning everything.
| Layer | Tool(s) | Purpose |
|---|---|---|
| Operational hub | RIPLRT Bench | Institute workbench / operational dashboard for day-to-day lab workflow (Section 11.3) |
| Task & project tracking | ClickUp and/or GitHub Projects | Tasks, owners, due dates, status, sprints |
| Code & versioning | GitHub (Git) | All code, issues, pull requests, code review |
| Documents | Google Drive / OneDrive | Drafts, shared materials, meeting notes |
| Analysis & reporting | Quarto / R Markdown, R/RStudio, Python | Reproducible notebooks, manuscripts, dashboards |
| Sample inventory | Aliquary | System of record for samples, freezer/box maps, barcode lookup, aliquots, freeze–thaw (Section 17.5) |
| Lab notebook (experimental) | eLabNext (when wet-lab / assay work applies) | Experiment records, protocols/SOPs — not sample inventory (that is Aliquary) |
| Structured data capture | Qualtrics or REDCap (if applicable to the project) | Survey/clinical data capture |
| Archiving & open science | OSF, Zenodo, FigShare | Preregistration, archival, DOIs |
NotePlaceholder: exact tool instances
Specific accounts, workspace URLs, and license details (ClickUp workspace, GitHub org, Drive structure, Qualtrics or REDCap instance, OSF projects, Aliquary tenant, RIPLRT Bench access tiers) are confirmed during onboarding and recorded per project in the pod charter. Tooling may evolve; the principles (one source of truth, version control, reproducibility) do not.
11.3 RIPLRT Bench
RIPLRT Bench is the Institute’s own operational dashboard / workbench — the hub where day-to-day lab workflow is meant to live alongside our project, code, and document tools. It is built and operated for RIPLRT; it is not a third-party project tracker and it does not replace GitHub, ClickUp, or Aliquary. Think of Bench as the front door to operational status; use the specialized tools for code, tasks, documents, and sample inventory.
Account access is provisioned at onboarding and revoked at offboarding (Chapter 20).
NotePlaceholder: RIPLRT Bench features and access tiers
Exact Bench capabilities, screens, modules, and access tiers (who sees what) are not yet confirmed in this manual. Until they are written here, treat Bench as the operational hub at https://bench.riplrt.com, follow your mentor’s walkthrough at onboarding, and record project-specific Bench use in the pod charter. PI to confirm and replace this callout.
11.4 Task hygiene
A task is only real if it has:
- An owner (one person, even if others help).
- A due date (or an explicit “no date — backlog” status).
- A definition of done (what the deliverable is).
- A link to where the work lives (repo, doc, or board).
We review the board in weekly check-ins: what shipped, what’s blocked, what’s next. Blocked tasks get surfaced early — “no surprises.”
11.5 Managing the portfolio without overload
The portfolio spans population-scale surveillance to molecular modeling. To keep it sane:
- Pods, not heroics. Work is distributed across pods with defined roles (Chapter 7), not concentrated on one or two people.
- Project operating manuals. Each major project keeps a two-page operational summary so anyone can orient quickly and mentees can work independently.
- One lead metric per goal. Per the IAP cadence, each strategic goal carries a single lead metric so progress is legible.
- Quarterly review rhythm. We score progress against milestones each quarter (Chapter 21) and re-plan rather than letting work drift.
11.6 Aligning daily work to strategy
Project work should ladder up to the group’s SMART goals (the 12/36/60-month roadmap in the IAP). In practice:
- Each pod’s deliverables map to a named SMART goal (e.g., “RespRisk v1.0 forecasting workflow,” “manuscript pipeline,” “mentee-integrated production”).
- When prioritizing, we ask: does this advance a SMART goal and the through-line? If a request doesn’t, it goes to the backlog or gets declined — protecting time for the work that matters most.