How to keep track of large editorial projects

Last updated 13 June 2023

To date, my longest-running project has been going for six years (and counting). In another case, I took over the project in 2019 but its first iteration had been published in 2007 (and goodness knows how many years it was in preparation before that). These are both large editorial projects with thousands of articles, even more contributors, and an evolving gaggle of freelancers and other suppliers to shepherd.

Managing information and files is therefore not just desirable – it is the fundamental way I keep these projects on track, maintain my understanding of the big and small pictures, anticipate issues, ensure quality and consistency over time, and generally avoid feeling like I’m the proverbial decapitated chicken.

This post shares eight processes and structures that I’ve put in place to help me achieve this. The principles apply whether I’m working as a project manager or an editor.

1 Think ahead

In some of my projects, the files go through 15 or more iterations, many of those with multiple contributors or versions. There might also be different workflows running concurrently. It’s therefore crucial to ensure that my folder naming and structuring are logical and scalable, so I can quickly find any version of any file whenever I need it (and so that it’s always clear which version is the latest and changes don’t disappear into a black hole).

It’s also crucial to ensure that naming conventions will be clear to everyone else involved with the project, whatever their expertise or task focus. (Tip: the name ‘Proofs’ is rarely a good choice for a folder!)

2 Make major project decisions accessible

I never want to be wasting time digging around to remind myself of a decision I made about a project six months or even six years ago. That’s why I keep a log of all major project decisions categorised by topic (referencing, metadata, etc.) so I can quickly find a previous decision if the same issue comes up again much later.

A secondary edict here is not to have too much confidence in your own memory. Unless something is face-smackingly obvious (and sometimes even then), I write it down. Especially when I’m managing multiple projects at once over multiple years, I can’t assume I’ll perfectly remember why a decision was made or even what it was.

Project log versus style sheet

For me, the log is separate from the style sheet. A style sheet is a whole other vital area of documentation that I’m deliberately not covering here. Whereas a style sheet is about what the final product should look like, in contrast my log is about how that gets done – processes, lines of communication, responsibilities and so on.

3 Get comfortable with spreadsheets

Up-front disclaimer: I love spreadsheets. My fiancé and I have a spreadsheet for everything. When one of us discovers a clever new way of using a function in Excel or Google Sheets, it’s the hot topic in our household for days (I’m only mildly exaggerating here). So, when I get the chance to track 2,500 articles over time in a spreadsheet, I’m a very happy bunny.

But you don’t have to love spreadsheets – just develop a cordial working relationship with them. I like using conditional formatting and other tricks to help me understand the status of articles and flag issues. However, the basics are more than enough.

4 Subdivide proportionately

It’s crucial to divide huge gluts of files into batches or groups for processing, but don’t make the groups too small. If you’re handling too many small batches or the deadlines for your batches end up too close together, things can quickly get confusing, especially if each batch goes through multiple stages and the batches overlap.

Sometimes it takes a bit of experimentation to find the optimum balance between frequency (i.e. how often you work on a new batch) and quantity (i.e. how many articles – or whatever – are within each batch). And sometimes the balance will be dictated by the client’s publishing schedule. I know the balance is right for me when I feel I can give each batch proper dedicated headspace but the amount of downtime isn’t so much that I feel disconnected from the project by the time the next batch arrives.

5 Count, itemise, then count again

Whenever I receive a batch of files, the first thing I do is count them to check I have the right number. Then I individually check that each file is the correct one, to ensure articles haven’t wandered and ended up in the wrong places.

Once I’ve done whatever I need to do to the files (copyedit them, collate their corrections, whatever), at minimum I’ll count them again. I might also do a second item-by-item check, depending on how complex the task was (especially if it involved moving files between folders).

I can’t count (sorry!) the number of times this process has flagged an issue, enabling it to be dealt with promptly rather than occasioning a mad panic later on.

6 Use checklists ad nauseam

Every project has oddities, exceptions and problems that require creative solutions. But I find those can be dealt with so much more smoothly when I’m not using all of my brainpower to deal with the basics.

As such, I always work with a clear (and pretty exhaustive) checklist of routine tasks specific to every project. My aim here is to make myself as bored as possible from the sheer drudgery of following the same checklist over and over and over again. For example, on my biggest current project, by the time I finish the current stage, I will have ticked off a total of 1,680 items on my checklist (that’s over the course of around 35 batches – even I’m not crazy enough to have a checklist of 1,680 items for a single batch!).

It can be monotonous, but in my experience no other approach is sufficiently reliable. You never want to find yourself breaking out into a cold sweat wondering, a month after a batch has been published online, ‘Hang on, did I ever check the image credits for that batch?’

7 Put up barriers

By ‘barrier’, I mean some sort of physical or visual obstacle that makes me stop and think before barrelling on to the next stage of a process. Examples include conditional formatting in spreadsheets, folder structures that force me to move files when I’m done with them so I can’t skip over things, and orange and red flags for problematic items (e.g. in Trello). I’ll also occasionally resort to the good old put-text-in-red-with-yellow-highlight-and-make-it-huge when something is really important. Sometimes, simple is best!

8 Default to doing it now

In many cases it really does make sense to leave a task until later – for example, if one author sends corrections on a book and you’re expecting corrections from another author later, there’s no point finalising the first author’s corrections as the second’s could raise unexpected issues that throw the first’s out the window. But, generally speaking, I always default to a ‘do it now’ approach. Over and over again, I’ve seen that the earlier issues are dealt with, the more it limits the damage they can do.

---

On some projects, it would be impossible to mentally keep track of where everything is at any one time. In such cases, it’s vital to have a clear, accessible and sustainable system that works for you and that enables you to quickly find the information you need.

What other methods do you use for managing large or complex projects? Let me know in the comments.