In book publishing I rarely used to hear the term ‘workflow’, but it has become more common – primarily, I think, because of the increasing influence of information technology. Publishers’ adoption of the word doesn’t necessarily mean very much – sometimes it’s just a case of using a new word to describe a cranky old system. In my experience the publisher that used the word most was, ironically, the one in which projects moved least smoothly. ‘Workflow’ there meant ‘lurching from one silo to another’.
Nevertheless, I like the word, with its evocation of smoothness. It has set me to designing a workflow system afresh for our own imprint. Whilst doing so I have kept in mind, as an ideal, the action of pouring a glass of Boddington’s beer from a can. I kept thinking how I’d like the production of books to be as smooth as that. My objectives were three-fold:
1. to map out a workable set of practices, so that we could – barring acts of God – tell what would happen to a project before we even commissioned it;
2. to define the decision points as carefully as possible, since it is such points that create friction in the system; in particular, the objective here was to achieve the greatest simplicity consistent with strong quality control;
3. to produce a system that is readily communicable to stakeholders – authors, editors etc.
The first task was to try to see things afresh. To do so I explored new product development (interestingly not a very characteristic phrase in book publishing) in other industries. I found myself reading case studies from, in particular, the software and pharmaceutical industries. The resource I found most useful was a book by Joanne T. Hackos called Managing Your Documentation Projects. For me, this book was ‘half-in, half-out’: half-in, because it is about producing texts; half-out, because it assumed an IT setting.
Under Hackos’s influence, we divided the workflow system into five phases, as follows:
I. Project plan
II. Content specification
Much of what we included within these five phases is of course entirely conventional. For example, the outline of Phase I runs as follows:
The author produces a book proposal. This will be reviewed by P&H staff and will then, if deemed sufficiently promising, sent to a peer reviewer.
1. Book proposal
2. Internal review
3. 1st peer review
4. Outcome: reject / resubmit / proceed to next stage
No surprises there.
Some parts of the system, however, are more distinctive. For example, Phase II includes the following three components:
1. Cognitive walk-through
2. Outcome: reject / resubmit / contract
3. In the event of contracting the project: Product matrix
This certainly has – for publishers – a less familiar look. The ‘cognitive walk-through’ consists of a Powerpoint presentation outlining the book. There is a slide for each component of the table of contents (including frontmatter and endmatter, both of which are at risk of neglect in the commissioning process). For each chapter, there is one slide. The text on each of these slides consists of the chapter title plus the headings used within the chapter. There are also slides for drafts of each of the main figures to be included in the text.
This may sound like nothing more than the ‘contents’ part of a standard book proposal, presented in a different form. To some extent it is. However, the form of presentation does make a difference. In book proposals, chapter outlines often take the form of continuous prose. The translation here into headings seems to help authors to ‘tell the story’ better. It also – because the headings are samples of texts to be used in the actual text, rather than precis – nudges them towards the actual writing.
The slide format also helps us: each time we’ve worked through a presentation we’ve found ourselves seeing the book afresh. Slide sequences seem better suited than proposals to prompting editorial gestalts.
The product matrix consists of a table with three columns, namely:
1. Essential benefit
2. Feature producing the benefit
3. Out-of-bounds criteria.
Fo example, in one of the books we commissioned we wanted the benefit of the table of contents being readily searchable. The feature that would produce that benefit was plain chapter titles that included the key search term(s) for each chapter (and little else). And the ‘out-of-bounds criterion’ was inclusion of titles of lyrical or evocative phrasing.
In my experience, standard commissioning and development processes usually do cover the three types of points above. However, this is sometimes done informally, through conversation or e-mail. The risk here is that points may be left implicit or ambiguous – and there is no concise record to refer to later. Negotiating a matrix helps to make the commercial rationale of the book explicit. Having a concise, readily consultable, record of key points helps to ensure that the project remains on course over the months that follow.
Another somewhat innovative feature of our workflow is the borrowing of terms from software development. Terms like ‘alpha’ and ‘beta’ version are now widely understood, even beyond the world of software – yet, despite their usefulness, publishers have tended not to use them. Instead, publishing tends to use terms such as ‘text’, ‘typescript’, and ‘draft’. The problem with these terms is that they are ambiguous. Is the typescript what the author produces (since in the digital age we can hardly refer any more to ‘manuscripts’ – though some publishers still do) or what the typesetter produces, or both? We can try to qualify the term with an adjective like ‘final’, but what is final for one type of editor (commissioning, development, managing, or copy-editor) might not be for another. The result is the risk of confusion. Fo example, authors sometimes deliver a typescript, believing it is for comment and review, when the publisher was expecting something ready for copy-editing.
Our workflow specification contains three successive versions: (1) the alpha version (text 95% complete + figures 100% complete); (2) the beta version (100% complete bar the index + development editing complete + all permissions obtained in writing); and (3) the gamma version (copy-edited + fact-checked).
The outline of Phase V reads as follows:
We will evaluate the book, the publishing process, and the project management. We will also, where appropriate, begin planning the next edition.
1. evaluate product 1.0
2. evaluate project management and team members’ contributions
3. new edition (2.0) planning
Nothing in this phase is innovative conceptually – yet creative types don’t invariably do these things in practice, at least not formally (comments along the lines of ‘That turned out pretty well – I really like the cover’ don’t quite cut the mustard!).
The workflow system I have outlined here is now in operation. To date, it hasn’t required much revision, though we will need to produce an alternative version for edited books. The main task ahead is – borrowing again from Hackos’s approach – is to build in a second dimension, so that the workflow for a project is specified not only by phase but also by level (where the higher the level, the greater the publisher input – for example, in development editing).