Research computing readiness checklist

← All writing

Most small and mid-sized institutions already qualify for free national computing resources like the OSPool and NSF ACCESS. What they usually lack isn't eligibility, it's a clear read on where they stand and a plan for the first pilot. This checklist gives you both: a readiness assessment you can run in an afternoon, and a pilot checklist to walk one researcher across the line.

For the reasoning behind this list, the companion article covers why small campuses miss out on national research computing and what closing that gap actually takes.

Ticks are for this browsing session only. Nothing you check is stored or sent anywhere.

1. Do you know your demand?

• You can name at least one researcher whose analysis currently runs for days on a laptop or desktop.
• You've asked around in at least two departments outside the sciences (social science, business, humanities), not just the ones that sound computational.
• You know whether anyone on campus has used a cluster before, even at a previous institution, and could act as an informal reference.
• You've checked whether a grant proposal already promises computing the campus can't currently deliver.

2. Do you know what's already available?

• You know whether your institution is already a member of a regional or national computing consortium (many are, without anyone noticing).
• You've looked at the OSPool for independent, high-throughput jobs and NSF ACCESS for larger or memory-heavy workloads, and have a rough sense of which fits your researcher's problem.
• You know that most of this capacity is free at the point of use for US-based researchers, funded by public money, not something your budget has to absorb.
• You've identified Campus Champions or CaRCC as communities to join rather than problems to solve alone.

3. Do you have a point person?

• Someone, even at a fraction of their time, owns the question of national computing access. It doesn't need to be a new hire or a new office.
• That person has a way to reach outside help for the first few months (a consultant, a regional facilitator, or a community mailing list) rather than reading documentation cold.
• Leadership knows this is a bridge role for a semester or two, not a permanent staffing commitment, so it's easier to say yes to.

4. Is the first workload actually ready?

• The researcher's analysis already runs correctly on their own machine, just too slowly. (Fixing broken code and moving to a cluster are two different projects; don't combine them.)
• The workload is described as multiple independent runs (many files, many parameter combinations, many simulations) rather than one giant tightly coupled job, since that shapes which venue fits.
• Input data size and format are known, and there's a plan for getting data onto the resource and results back off it.
• If the data involve people or are otherwise sensitive, that's flagged before the pilot starts, not discovered mid-run.

5. Pilot checklist: the first researcher

• A fit conversation happened and a specific venue was chosen for this workload, not "the cluster" in the abstract.
• Accounts and a starter allocation are requested. This should take days, not months.
• The existing R or Python workflow is packaged into something a scheduler can run: a container or environment file and a submit script.
• A small test batch ran and the output was checked against a known result before scaling up.
• The full run completed, and the researcher saw for themselves how much faster it was than their laptop.
• Someone documented what worked, in plain language, so the next researcher doesn't start from zero.

6. Making it stick

• A short, informal session ("what your laptop can't do") is scheduled to show other researchers what just happened, since word of mouth drives the second and third users more than any policy memo.
• Someone is tracking basic impact: hours saved, proposals that now credibly promise computing, or a researcher who kept using it after the pilot.
• The campus has decided, honestly, whether it needs local infrastructure at all yet, or whether national resources cover the next year or two while real usage data accumulates.
• If local infrastructure is on the table, the decision is being made from a year of actual usage patterns, not a guess made before anyone ran anything.

The test that matters at the end of a pilot isn't whether the job finished. It's whether the researcher would choose to run their next job the same way without being asked.