Before You Commit to an Asset Review: A Pre-Decision Checklist
Before agreeing to an asset review, work through these questions about your drive, your team and your goals so you know what the review should cover and what it should leave alone.
Priya Raman · · 7 minutes to read
Start with what you actually want to know
An asset review is only useful when it answers a question you already have. Before anyone opens a drive, write down in plain words what is bothering you. Perhaps editors keep asking which export is the approved one. Perhaps storage is filling faster than the work justifies. Perhaps a client has asked for footage from a shoot two years ago and nobody could find it in under an hour.
Each of those worries points to a different kind of review. A hunt for duplicates looks at file contents and sizes. A search for gaps looks at what should exist for each project and does not. A risk check looks at who can delete what. If you cannot say which of the three you care about most, the review will wander, and you will pay for a long inventory that ranks nothing.
I suggest writing two or three sentences and sharing them with everyone who touches the drive. Disagreement at this stage is useful. It tells you the review has to settle a question before it can recommend a structure.
- Which problem cost you the most time in the last quarter?
- Who complains about the drive, and what do they say?
- What would a good result look like in one sentence?
Check that you have a sample drive to work from
The learning and the review both depend on real material. The one prerequisite for this module is access to a sample project drive, and the same applies when deciding whether a review is worthwhile for your team. Without a representative slice of your files, any advice stays generic and cannot be tested against how your people really name and store things.
Choose a sample that includes one finished project, one project still in progress and one older job that nobody has touched for a while. Together they show how habits change under deadline pressure and how much decay sets in over time. A single tidy project will flatter you and hide the problems.
Confirm before you start that you are allowed to share it. Client footage often carries restrictions on who may view it. If the sample must be trimmed or anonymised, do that first, so the review does not stall halfway through while someone seeks permission.
- One finished, one active and one older project
- Read access for the person doing the review
- Clearance from clients where contracts require it
Decide what counts as a duplicate, a gap or a risk
Teams use these words loosely, and the review needs fixed meanings. A duplicate is not always waste. A proxy file, a graded copy and a client delivery may look alike in a listing yet each has a purpose. Agree beforehand which copies are intentional so they are not flagged as errors and then deleted by someone tidying in good faith.
A gap is something expected that is missing: a project with no final export, a shoot with no audio files, a folder with no readme explaining what it holds. A risk is anything that could cost you work if one person left or one disk failed, such as the only copy of a master living on a laptop.
Write down your own short definitions and keep them beside the inventory. When the findings come back, you can read them against your own rules rather than someone else's assumptions, and the recommendations will land closer to how you really work.
- Intentional copies: proxies, graded versions, deliveries
- Expected items per project, listed in advance
- Single points of failure, named plainly
Be clear about who will change files and who will not
A review looks at your files; it does not automatically reorganise them. That distinction matters, and it is worth settling before you decide. The consulting side of starfyrepo produces findings, a proposed organisation system and guidance for your team. Any hands-on moving, renaming or archiving of files is scoped and agreed separately, so nothing on your drive changes without a clear instruction from you.
Decide who on your side would carry out the changes if you choose to act on the findings. An editor in the middle of a delivery is the wrong person to spend a week renaming folders. A production manager with a quiet fortnight might be the right one, particularly with a checklist in hand.
Also consider backups. Whoever makes changes should confirm a recent copy exists first. It is a dull step, and it is the one people regret skipping when a rename script behaves differently from how they expected.
- Findings and proposals first, file handling only by agreement
- A named person on your side for any changes
- A verified backup before anything moves
Think about how the results will reach the team
A good report that sits in an inbox changes nothing. Before deciding, ask how you will share the outcome with the people who save files every day. A short session in which the findings are walked through, with examples taken from your own drive, tends to work better than a long document. People recognise their own folders and understand the point at once.
Plan for questions. Editors will ask why a naming rule exists and whether it slows them down. Producers will ask what happens to old projects. If you have thought about those answers in advance, the review becomes the start of a shared habit rather than a one-off audit that fades within a month.
Pick a date for a follow-up look, perhaps a few weeks after the changes begin. A second glance at the same sample drive shows whether the new habits hold when a busy shoot arrives, and it tells you honestly whether the proposed system fits.
- A walkthrough session using your own examples
- Answers ready for the questions editors will raise
- A planned second look at the same sample
A short list to take into the decision
Put the earlier points on one page and answer each in a line. If you can name your problem, supply a sample drive, define your terms, say who will handle changes and describe how the team will hear the results, you are ready to start and the review will be focused and affordable in effort.
If two or three answers are missing, that is useful information too. It may mean a short conversation inside your team should come first, so the review begins with agreement rather than argument. There is no benefit in rushing the start of a piece of work whose value depends on people accepting its findings.
Priya Raman, who teaches this module, usually asks for exactly this page before a first conversation. It keeps the discussion concrete, and it shows quickly whether an audit is the right next step or whether something simpler, such as agreeing a naming rule, would help first.
- Problem named in one sentence
- Sample drive available and cleared
- Definitions of duplicate, gap and risk agreed
- Owner of any file changes identified
- Plan for sharing and re-checking results
An asset review pays off when you arrive with a clear question, a representative sample and agreement on what will and will not be touched. Work through the list above with your team before you decide. If most answers come easily, you are ready to begin; if not, you have learned where to start. Either way, you will make the decision on facts about your own drive rather than on hope.
Send us a message
- Call us
- (505) 214-0873
- By email
- [email protected]