Essential editorial project management

Welcome to this e-Learning module on project management. As its title suggests, the course concentrates on the basics that anyone interested in starting out in project management – whether working in house or for themselves – needs to know. It focuses on editorial project management – seeing publications through the production process, whether print or digital. The course contents are:

Unit 1: Introduction

Unit 2: What is editorial project management?

Unit 3: The project manager’s responsibilities

Unit 4: Defining the project

Unit 5: Starting the project

Unit 6: Finishing the project

If only two skills could be picked to define project management, they would be communication and organisation.

The PTC also provides expert courses that build on and complement this introductory module.

Introduction

Project managers working within publishing (‘editorial project managers’, which we’ll simply refer to as ‘project managers’ in this course for brevity) oversee the production of publications, from receipt of the typescript through to delivery of the print and/or electronic publication (e-publication) – as press-ready and/or device-ready files, or as printed and bound copies. They may handle all or just some of the stages. The skills needed and the overall principles apply regardless of the type of publication – whether it is a printed multivolume encyclopaedia, an online academic journal, a magazine published in both print and digital formats, or a Kindle novel or other e-book.

Managing a project requires taking overall responsibility for the publisher’s goals as set out in their brief – on budget, to deadlines and to the required quality. It also involves dealing not only with the publisher but also with suppliers and other stakeholders – authors, designers, typesetters, copy-editors, proofreaders and so on for editorial projects.

This unit describes the tasks expected of an editorial project manager, and the skills and qualities they need.

This course introduces project management as typically carried out in the publishing industry: projects are commissioned by the editorial department of a publisher, which passes projects to the production department, where each publication is overseen by a project manager during its manufacture.

The project manager may be an employee of the publisher (e.g., a desk editor) or self-employed, and the ‘production department’ may be an entirely different division from editorial (e.g., marketing), or perhaps not even a department but a person self-publishing, say, their novel; whatever the situation in reality, the principles in this course apply. Also, these principles relate to project management in general, so can also be used for products other than printed and digital publications such as websites.

What editorial project managers do

Core tasks

The management of any project can be broken down into core tasks. There are several ways to do this but in this course, we use the following six:

• assessing the project

• scheduling the project

• budgeting the project

• establishing a team

• supervising the project

• reporting to the publisher.

They are listed in the order they need to be carried out, though some will be ongoing throughout a project, such as supervision and reporting. These core tasks are discussed fully in Unit 3.

Editorial projects

Editorial project managers oversee all or some of the work involved in the production of publications. The following is a flowchart of the major stages in the production process for a typical publication – a textbook. There may be fewer or more tasks, depending on the project: for example, indexing is not required for a magazine; a job may be a print or an electronic publication, rather than both; and the project manager may also need to prepare marketing material.

The major stages shown in this flowchart are expanded below. The exact process will vary depending on the publisher and the project, but the following is typical. This course is not the place to go into detail about the processes involved in publishing, so the tasks are outlined only in brief here – but the PTC has courses that cover on them more comprehensively.

• Transmitter. The publisher’s editorial department checks that the typescript and any illustrations are free from obvious problems such as missing or outstanding material, and transfers it to the production department, along with documentation such as completed permission forms from the owners of any copyrighted material (e.g., illustrations). This process is called transmittal by the publishing industry. A transmittal form usually accompanies the typescript, detailing any information pertinent to the production of the publication: word and illustration counts, page size, hard or soft cover, design, print run, budget, special requirements, missing material and so on. 

• Assessment. The production department passes the typescript, illustrations and documentation to the project manager for assessment. They then put together a team, draw up briefs and commission suppliers (the copy-editor, proofreader, typesetter, etc.), confirm and allocate the budget, and create a schedule. Supplementary material – such as illustrations from a previous edition, or a copy of the previous edition for reference – may need to be obtained from the publisher.

• Design. This may be straightforward if the publication is to use an existing design. However, a new design can involve a lot of time and effort, with liaison necessary between the editorial department, the project manager, the author and the graphic designer.

• Copy-editing. The typescript and illustrations are sent to the copy-editor. Once the copy-editing has been completed, the material is returned to the project manager.

Copy-editing essentially involves three tasks:

• review of the typescript and illustrations to remove errors and to improve the overall quality of the writing 
• ensuring that the publisher’s requirements are incorporated, such as style and design points 
• preparing the typescript for the typesetter, such as identifying headings and the location of illustrations, and clarifying the required layout.

• Illustration. The copy-edited illustrations go to an artist for amending or redrawing, then back to the project manager for checking and finally to the typesetter. Photographs may occasionally need to be commissioned or obtained from an image library by the project manager.

• Typesetting. The copy-edited typescript and illustrations are sent to the typesetter, who subsequently supplies proofs to the project manager.

Typesetting is the process of arranging the text and illustrations in a publication according to an agreed design. The typesetter may be sent a previous publication to follow for style, or there may be a more formal arrangement such as supplying them with sample pages and a type specification form detailing the required design.

• Cover layout. Covers are usually created by a graphic designer rather a typesetter. Often, the publisher’s marketing department is involved, for example, supplying copy such as endorsements. Covers will need to be proofread.

• Proofreading. The project manager sends proofs to the proofreader, and also usually to the author and possibly others, such as the editorial department, for checking. All the sets of corrected proofs are returned to the project manager for collation.

Copy-editing and proofreading are often conflated, but they are actually quite different, and a publication needs both tasks carried out. Proofreading is the correction of errors, such as mistakes by the typesetter and oversights by the copy-editor – often called typos. There is no need to improve or reorganise the writing, as that is the copy-editor’s task and has already been done.

• Indexing. Assuming that an index is needed, the project manager sends a set of proofs to the indexer, who provides the project manager with the index copy. The copy is sent to the typesetter, and the resulting proofs follow the same process as for the proofs of the main body of the book.

• Proof collation. Proof changes from the author and anyone else who has reviewed the proofs (e.g., the editorial department) are assessed by the project manager for any problems (which may simply be that an amendment is unnecessary) and added to the proofreader’s set. The collated proofs are sent to the typesetter, who makes the marked changes and supplies revised proofs to the project manager for checking. One or two rounds of additional proofs and checking are usually necessary for the project manager to be satisfied that the publication is sufficiently error free for publication.

• Approval for publication. When the project manager is satisfied that all corrections have been made and checked, final proofs are sent to the publisher to be signed off, giving approval for publication. This is not a decision the project manager should take responsibility for – it must be their employer or client.

• Printing and e-publication preparation. Once the typesetter has been informed that a publication has been signed off for publication, they create the print-ready and/or e-publication files, and send them where instructed (e.g., to the project manager or a printer). Files sent for printing are accompanied by a print order form, detailing the number of pages, type of binding, paper choice, print run, delivery date, etc.

• Delivery. The printer delivers the bound copies to the specified location, such as a warehouse.

Qualities and skills needed by a project manager

Expertise

Project managers require an awareness of their area of work – in our case publishing. They do not need to be able to do any of the tasks involved in the production process, such as copy-editing, but sufficient knowledge is required to understand how the tasks are carried out and what is involved in order to be able to talk knowledgably to all those involved, to supervise, to solve or head off problems and so on. They also need to be familiar with publishing in general: for example, they need to know what the editorial department and commissioning and development editors do, and how copyright works. If a project manager does not know their subject area, it is unlikely that they will fully get a grip on their projects.

Project managers should also master the procedures, tools and technologies used in their job: for example, scheduling techniques such as the agile approach or critical path method, Microsoft Office and calendar apps. However, compared with, say, project managing the building of an office block, editorial project management is relatively straightforward, so you do not need to chart progress using expensive dedicated project management software or obtain a master’s degree in project management – you can, of course, but they are not prerequisites. The procedures and tools you require are covered in later units in this course.

Communication

The ability to communicate effectively is fundamental for project managers, and forms the greater part of their job. Both verbal and non-verbal skills are needed: despite the ubiquity of email and messaging apps, project managers often find themselves on the phone or in meetings (video and in person); and there will be reports (e.g., status updates) to write and perhaps presentations to give.

If a successful project manager could be described by only one trait, it would be as a good communicator: projects that fail generally do so because of because of a lack of good communication.

Leadership

Project managers are by definition leaders – they are in charge, and it is their responsibility to ensure that aims are realistic, schedules are attainable and budgets are sufficient, and to support and motivate everyone involved in a project. Essential qualities for a leader include good communication skills, clarity of vision, decisiveness, flexibility and skilful supervision.

Negotiation

Projects inevitably involve conflicts and competing interests, and project managers need to negotiate compromises that keep people happy while still achieving goals such as staying within budget and on schedule. Effective negotiation involves being able to analyse a problem to determine the core issues and their impact on the project, understanding the concerns of the people involved, and then, taking the point of view of everyone into consideration, proposing a solution that they feel they feel they can agree to.

Time management

Time management is all about delivering on time. A project manager is the kind of person who gets things done. They have to regulate not only their own time but also that of others involved in a project. They need to set an overall schedule, ensure that deadlines are met and adapt when delays occur. Time management skills include setting goals, prioritising, planning and scheduling.

Risk management

Unfortunately, as we all know, plans can fail and go awry – with delays and cost increases being most commonly met by project managers. So, project managers need to be able to identify potential risks to a project, and prevent or mitigate them – for example, building contingency into the schedule to account for possible delays, and checking the availability of key people in a project. Risk management requires an analytical mindset able to break something down to identify fault lines, followed by problem-solving, and also the ability to assign likelihood to a potential problem.

Introduction

Now that you know what editorial project management involves, and the traits and skills needed to do the job, we turn to the core tasks involved:

• assessing the project
• scheduling the project
• budgeting the project
• establishing a team
• supervising the team

Each is discussed in turn in this unit, focusing on the principles behind these tasks and ways of carrying them out. Later units concentrate more on the practical aspects of these tasks.

Assessing

Project managers need information on a project to manage it effectively. Information is required at the outset of a project: the goals need identifying, and an assessment made of whether they are achievable – and if so how. The project also needs to be assessed as it progresses to its finish, to ensure that targets are met, such as deadlines, budgets and quality.

Assessing in project management can be broken down into a process. For an item to be assessed:

• identify a target to be met
• determine how the target will be met
• identify priorities and risks
• check that resources are sufficient
• if not, determine what is needed to meet the target
• if not, adjust the plan – for example, extending the deadline or increasing the budget.

Particular aspects of a project need special attention from the project manager, and these are discussed below.

Unit 5 gives some tips on communicating well in the ‘Initial assessment’ section.

Goals

The overall goals for an editorial project will be set out in the client’s brief to the project manager, and involve a combination of aims set out by both the editorial and production departments.

The commissioning department provides the details for a publication (e.g., a book or magazine issue) and sets goals for it, such as design and manufacturing specifications, the budget and the publication date. This information is often set out in a document called the transmittal form, and typical details include

• publication details – title, author’s name, order of the contents, etc.
• typescript details – number of chapters/articles, words, illustrations, etc.
• publication specifications/format – design, page size, colour or black and white, hard or soft cover, etc.
• manufacturing specifications – print run, target costs, publication date, etc.

as well as anything else relevant, such as outstanding material, use of copyrighted material or a firm publication date to coincide with an event.

The transmittal form accompanies the typescript when it is handed over to the production department for its manufacture.

The production department then draws up a brief for the project manager, taking the transmittal form into consideration. The brief includes information such as the following: the deadline (e.g., for delivery of the print-ready files to the printer), the budget and anything else of relevance (e.g., that an author will be away at a certain time, or that there are missing illustrations).

The project manager will need to assess the brief and other documentation on their receipt, to draw up a set of project goals. Some goals will be obvious, such as not exceeding the deadline and budget; the main tasks will also be clear, such as the need for copy-editing, typesetting and proofreading. However, other goals may be less obvious, such as the need to build the author’s holiday into the schedule when they will be unavailable; that copyrighted material is being included, so it is necessary to confirm that permissions for use have been obtained; or that the brief requires a colour plate section and that the colours must be accurate – which will entail colour proofs.

Project briefs are discussed further in Unit 4, and an example of a brief for a book is provided here:

Download 

An example transmittal form for the same book is also provided:

Download 

Additionally, the typescript needs to be assessed by the project manager, to set or fine-tune goals. For example, it may be a series of articles on general topics and well written, and thus needs only a light edit by a non-specialist copy-editor, or it could be a poorly organised book on, say, quantum mechanics that requires heavy editing by someone with a degree in physics.

Feasibility

When assessing the typescript, illustrations and accompanying documentation, the project manager will need to assure themselves that the goals as set out in the brief are achievable – that they have the resources to meet the goals. They will also need to examine the material for possible problems. For example:

• Is the deadline long enough?
• Is the budget sufficient?
• Is anything missing?
• Do the typescript and illustrations match the brief?

Common problems are out-of-date information, such as the actual word or illustration count being significantly more than that in the transmittal form or brief; an insufficient budget; and incomplete material, such as missing text, illustrations or permissions to use copyrighted material. The project manager will need to decide on what action to take to resolve a problem: for example,

• if the word count is higher than stated in the brief, then the deadline may need extending and the budget increasing
• if material is missing, then the goal of obtaining this for the copy-editor may need to be set, and time for this built into the schedule.

The project manager should therefore plan the schedule and allocate costs (including their own fee, if relevant) as a priority, as this will indicate whether the publisher’s deadline and budget are appropriate.

Resources are not only time and money but also people – the various suppliers required for a project such as the copy-editor and printer. Suppliers may have limited availability and be more expensive than expected.

Risk

The project manager needs to assess and mitigate risks.

Risks need to be identified as early in a project as possible – assessing the material and documentation to spot problems and to confirm the feasibility of the project goals is the first step in risk management. Involving others can help to identify risks, for example the copy-editor may be better positioned than the project manager to appraise the typescript, and the same for the artist with illustrations. All the identified risks need to be fully understood: What would cause a risk? And what would its impact be on the project?

The risks then need to be prioritised, as some will have a greater detrimental effect than others. This will allow the project manager to manage risks more effectively, so they can concentrate on those most critical to a project – possibly by setting aside resources or building in contingency.

Communication is important in risk management, too. The publisher needs to be made aware of major risks, and also of risks that fall outside the remit of the project manager. An example of the former might be the possibility of the author going on holiday and being unavailable, requiring the schedule to be amended but without affecting the publication date. An example of the latter might be the copy-editor warning that the edit may take longer than expected, which would exceed the budget allocated by the publisher.

Risks also need to be communicated to the person responsible for or best able to identify them if they occur. For example, if risks have been identified for copy-editing, such as the possibility of plagiarised material or missing a tight editing deadline, then it should be made clear to the copy-editor that they need to inform the project manager immediately either problem occurs.

Preventative measures to eliminate or mitigate risks should be developed. For example, the project manager needs to draw up a schedule and commission suppliers – adjusting the schedule and budget accordingly depending on their availability and agreed fees; or assessing a typescript with possible problems more thoroughly than usual prior to copy-editing. Contingency can also be built into the project, such as allowing more time than necessary for a task, to reduce the chance of a missed deadline, or part of the budget held back in case of cost overruns.

Risks should be documented by the project manager, so that they can track their progress and also ensure that none are forgotten or ignored.

Terms and conditions

Project managers who are not employees need to agree terms and conditions (T&Cs) with the publisher. This is essential to avoid misunderstandings, and possible legal or financial consequences if things go awry. The aim is to have a set of T&Cs that outline the responsibilities and duties of both parties.

The publisher may have their own T&Cs that they require the project manager to agree to – the project manager should read these carefully and negotiate about any clauses that they are unhappy with. Alternatively, the project manager should present their own T&Cs to the publisher.

Remember that T&Cs are legally binding documents.

T&Cs are discussed further in Unit 4.

Quality control

As well as ensuring that a publication is delivered on time and within budget, the project manager needs to make sure that a project meets and maintains the standard that the publisher expects, both in the quality of the work (e.g., of copy-editing) and of materials and processes (e.g., paper choice or offset versus laser printing). The publisher rather than the editorial project manager usually selects materials and processes, so we will concentrate on suppliers here.

It is important to define what is meant by ‘quality’ at the outset of a project – what is expected for the project by the publisher, and how this translates into expectations by the project manager of suppliers.

Clearly, suppliers must be competent, both in their standard of work and reliability. However, the budget may affect the choice of suppliers. Many areas of work have professional associations that set and maintain standards expected of their members: for example, the UK-based Chartered Institute of Editing and Proofreading and Society of Indexers. It can be useful to see samples of work, and the project manager could request these – possibly a test on part of the project material (if this does not conflict with confidentiality requirements of the project).

The project manager can put procedures in place to help maintain quality. For example, a clear brief is necessary so that a supplier is aware of the project manager’s expectations. The project manager could also provide a checklist of tasks – a simple thing, but one which has been proven to increase efficiency.

Tests of quality are also useful. For example, spot checks by the project manager on work returned by a supplier will provide a guide to performance, and allows constructive feedback to be given to the supplier.

Change

Projects invariably evolve and deviate from the initial plan, so project managers need to assess changes and their impact. Not all change is bad – a task in a project may cost less or be completed sooner than expected. Ideally, change that has negative implications for a project, such as increased cost or a delay, needs preventing (e.g., by managing risk), but that is not always possible. If an undesirable change cannot be prevented, the project manager must adapt to it.

The project manager will need to identify how a change will affect a project, and how best to adapt to it. Some examples of managing change are:

• altering deadlines or contingency in the schedule to compensate for a missed deadline
• doing less work (e.g., redrawing fewer illustrations) to compensate for a higher-than-expected supplier fee
• replacing a supplier who cannot meet a deadline or whose work is not to the expected quality.

Good communication is vital when adapting to change in a project: everyone affected must be made aware of the situation and kept informed – and they need to be included in discussions to solve the problem.

Software tools for scheduling and planning – especially those using Kanban boards and the agile approach – can make managing change easier. These tools are explored in detail in Unit 5, and the agile approach is discussed below, in the section titled ‘The agile way’.

Scheduling

The project manager is responsible for creating the schedule – a timetable of activities and their progress – that guides a publication through its production process. It should be drawn up as early as possible after the initial assessment of a project. There are various approaches to scheduling, and the most widely used are introduced in this section.

The schedule is the project manager’s principal tool, allowing them to, for example,

• share the schedule with others
• refer to and update the schedule with ease
• see activities and their dates
• see holidays
• see conflicts
• spot delays.

Unit 5 gives some suggestions on creating a schedule.

Milestones

The first thing the project manager needs to do is identify milestones, marking significant points in a schedule. They can be broken down into three types:

• key dates – significant events in the project such as meetings or when an activity starts, reminding the project manager of the activities in a project

• key deadlines – dates when an activity ends, allowing the project manager to see when an event associated with a key date is complete

• delivery dates – when something is due to arrive (e.g., proofs or redrawn illustrations), and which the project manager needs to track because late delivery will affect a key date.

After identifying milestones, the project manager determines the order in which the activities must be carried out and their timescales. This information then needs to be displayed as a table or chart.

The critical path

The critical path method is the most commonly used method for scheduling a project. It is the longest path of all the necessary activities in a project to finish the project on time, from its start to its finish, placed in their order of completion. The important word here is ‘necessary’: we are only concerned with critical events – those that must be completed to allow the next critical event to start, and have no leeway (or float) for the end date (discussed later in this section), so any delay will affect all subsequent activities. Also, note that the events in a project do not usually form a linear chain but a network – see for example the production-process flowchart in Unit 2.

Critical events are the danger points in a project, and any slippage in their deadlines will result in missing the project’s completion date.

There will be events that are not on the critical path because they are subsumed within a critical event. For example, addressing author queries is often lumped in with copy-editing, and ‘proofreading’ could encompass the entire proofreading process (e.g., first proofs, collation, revised proofs, final proofs). Other events may be separate from the critical path, for example, creating the cover does not directly affect a critical event, and, in fact, has its own critical path. A project will often have subsidiary critical paths such as this: for example, for the cover, for illustrations to go to the artist and for the index. Finally, there are activities with float – which excludes them from the critical path because the leeway for the end date means that the start date of the next activity may not be delayed.

Although an activity may not be on the critical path, it must not be forgotten and should appear in the project manager’s schedule.

A project’s pathways and events with the critical path identified might look something like the following:

To determine the timescale for a project, it is usually more convenient to work backwards from the publisher’s final deadline (e.g., the publication date). Durations for events using the critical path method are allocated using the earliest start date and the latest finish date.

A schedule created in this way therefore shows the maximum time allowable as well as the earliest and latest dates on which each activity can start and finish without missing the project’s final deadline. The project manager can use this type of schedule to easily see the impact of delays that will be fatal to the project.

The agile way

The agile method to project management is relatively recent, being created in 2001, and takes a different approach to scheduling. A problem with the usual critical path method is its rigidness, with all events viewed as being connected together in a chain and progressing in a single direction.

The aim of the agile method is to make project management more flexible and responsive, and it does this by embracing change and emphasising collaboration through team-working.

Agile working splits a project into independent parts, and those involved in each part are encouraged to be proactive and give feedback among themselves – for example, using collaborative means of communication and scheduling such as cloud-based software rather than, say, passive spreadsheets.

Applying it to publications, the publisher would set up teams for activities, such as designing the publication: the project manager, designer, typesetter and copy-editor could comprise the design team, with each member giving input into the design and responding to suggestions and changes arising from members’ contributions. In this way, the design evolves quickly, and pitfalls are avoided – such as conflict between the design and the actual content of the typescript. Compiling the index could be approached similarly, arranging for the project manager, author and indexer to collaborate as a team.

Contingency and float

One way to cope with risk and change in a project – for example, if the cost or timescale of an activity is not known precisely, or there is a likelihood of it being exceeded – is to use contingency: that is, money or time set aside in case it is needed. The project manager should identify activities most at risk, and assign contingency as needed.

The project manager will need to some contingency planning: estimating the amount of contingency for an activity based on the likely additional money or time required and the chance of the overrun occurring. They should also take account of the overall schedule and budget: if contingency is used, it should not make the project late or over budget.

Float in a schedule is the amount of time that an event can be delayed without affecting the project’s final deadline. If, for example, copy-editing has been allocated 21 days but only takes 24 days, then the float is 3 days. If a project activity with float is delayed, the project manager has the option of using float from an activity with float later in the schedule to compensate (as the float from the latter activity is reduced, that activity becomes closer to becoming a critical event).

Scheduling tools

A schedule can be presented as text, such as a table of dates in a Microsoft Word document, or visually, such as a calendar with coloured bars, perhaps on a paper wall planner or online in Microsoft Outlook. Dedicated project management software such as Microsoft Project is also available that allows the project manager to customise the view to their preferences.

Displaying the schedule visually makes it easier to comprehend, allowing the project manager to more easily gain an overview of the project and an understanding of how the activities interrelate.

Project-management tools are discussed more fully in Unit 5.

Budgeting

The editorial department sets the budget for a project, which may be modified by the production department. Occasionally, the publisher may ask the project manager to help set the budget, perhaps by estimating the costs of certain activities.

An area of concern for freelance project managers is paying suppliers, as this can be very costly. However, publishers are often amenable to suppliers sending invoices to them and paying themselves.

Determining the costs

It is helpful for the project manager to understand how the production budget is arrived at.

The commissioning department will set a maximum price for the publication that it considers reasonable: the recommended retail price (RRP). A discount is applied to the RRP, depending on a particular market: for example, an overseas market may have a greater discount than the home market. The discounted prices are then multiplied by the number of copies expected to sell in each market. This revenue from direct sales of the publication is the turnover.

Additional sources of revenue, such as translation rights from another publisher, are added to the turnover, to give the income.

The manufacturing costs of the publication are the sum of the direct costs (money spent on items specific to the project, such as printing or the author’s royalties – or the project manager’s fee) and a share of the overheads (expenditure for a publication that is not directly attributable to it, such as for heating and office rent). A direct cost may be fixed (e.g., a set fee for doing a task, such as designing a book cover) or variable (e.g., an hourly fee for cover design).

The net profit = total income – (direct costs + overheads).

Publishers often use a target unit cost, which is the manufacturing costs divided by the print run (the total number of copies printed).

Project managers are sometimes asked to suggest ways in which direct costs for a publication can be reduced.

Keeping to budget

The project manager is expected to stay within the budget and should, as a priority, check that it is adequate, assessing the material and documentation for a project on receipt and ensuring that there are no oversights, errors or other problems.

The budget needs to be adequate for the quality and amount of work needed. For example:

• A typescript from an author whose first language is not English will typically take longer to copy-edit than one from a native English speaker, so the budget needs to account for this.

• If the original illustrations supplied are rather plain and boring, this may be acceptable to the alternative of spending money on redrawing them attractively.

The second point highlights the expectation that the project manager should minimise expenditure whenever possible: do not require higher quality or more work than necessary. At the same time, they need to ensure that standards are adequate: a poorly edited typescript will result in heavily corrected proofs, quite likely increasing the proofreading cost and maybe also the typesetting fee (not to mention increasing the possibility of errors slipping through).

The project manager needs to check and confirm the budgeted costs with all suppliers. This may involve negotiation.

Slippage of the schedule can also increase costs, for example by necessitating a supplier to work outside normal office hours or to prioritise the job – which they quite reasonably will charge extra for.

Contingency and float

Contingency was mentioned earlier, when discussing the schedule and time. However, it relates to cost in exactly the same way. Budgets are nearly always estimates, so the project manager should ensure that part of the money allocated to a project is set aside from the budget as a contingency fund, available if needed for cost overruns.

A rule of thumb for contingency is to set aside about 5–10% of the overall budget. If the budget is tight, it is not a good idea to decide on a smaller contingency fund, as that increases the chance of the project going over the budget.

Risk assessment by the project manager will give a better idea of the amount of contingency and also of which activities are most likely to cost more than expected.

Estimates versus quotes

The fee for a job may be provided as an estimate or a quote. Knowing the difference is crucial:

• An estimate is essentially an educated guess at what a job may cost – it is not legally binding and can change dramatically. Suppliers usually provide an estimate if circumstances may change or they do not know all the details about the job.

• A quote is a fixed price for a job – it is a contract and thus legally binding, and cannot change without mutual agreement. Suppliers usually provide a quote if they are confident that they have full information on a job and have established exactly what it entails.

Establishing a team

The project manager is just one member of the team involved in seeing an editorial project through to its publication. Some will be stakeholders, other suppliers:

• a stakeholder is someone who has an interest in the project or is affected by it – for example, the publisher, the author or, eventually, a customer

• a supplier is someone commissioned to work directly on the project – for example, the copy-editor or printer, and in very large projects an office administrator.

There is overlap between the two categories – a supplier will naturally have a vested interest in the project – but it is useful see team members as being in one group or the other.

The project manager interacts with stakeholders and suppliers differently. Stakeholders are typically concerned with the progress and success of the entire project, such as whether it is on schedule or on budget; they are less interested in day-to-day matters. The project manager will need to communicate effectively and regularly with stakeholders, prioritising the needs of each and tailoring the information provided. Depending on the stakeholder, keeping them informed may simply involve occasional short emails or perhaps regular video conferences or face-to-face meetings.

Communication with suppliers, by contrast, tends to revolve around their roles and what may affect them. However, the style of the project manager affects how suppliers interact with the project: the agile approach sees all editorial team members as stakeholders who engage proactively to ensure a successful project.

Team members

A typical team involved in producing a publication is shown below. The members in green are stakeholders, those in blue are suppliers. The lines show the usual channels of communication.

There may more suppliers, depending on the project: for example, an indexer, picture researcher or photographer may be needed. Similarly, there may be additional stakeholders: for example, the publisher’s marketing manager, or the editor of a multi-author book or a magazine. There may also be fewer members, as the publication may not require an indexer or have any illustrations, or a designer may be unnecessary because the publication follows an existing design.

The channels of communication can also vary: for example, the commissioning or production editor at the publisher may liaise with the designer, not the project manager, or the copy-editor may be asked to deal with the author regarding queries on the typescript.

Creating an effective team

The project manager has no control over the stakeholders involved in a project. Some publishers also select some or all of the suppliers for the project. However, when the project manager does have a say in selecting suppliers, they need to assess the project to decide not only what kind of suppliers are needed but also their appropriateness.

The two initial areas to look at are specialisms and expertise needed by suppliers in a project. Specialism in this context means being skilled in a particular area. For example,

• a book on advanced physics will need suppliers familiar with maths

• a publication with complex tables or academic references will need suppliers experienced in working with this type of material.

By expertise we mean the level of skill. For example,

• if the project is a physics book, the required copy-editor may be a generalist (i.e., without a scientific background), an area specialist (has a scientific background but not necessarily physics) or a subject specialist (familiar with the book’s specific subject) – depending on the level of writing (e.g., a popular science title aimed at everyone versus a postgraduate book on cutting-edge research)

• if the publication is very straightforward on a general subject written in very good English, with a simple design and layout, and no tables or illustrations, then suppliers competent in only basic skills are needed – a copy-editor able to restructure complex material written by non-native English speakers is not needed

• if simple graphs need redrawing, there is no need to commission an expensive artist who can draw, say, anatomical figures freehand

Personal qualities matter, too, such as reliability and communication: the project manager needs to be able to trust suppliers to do what they say; and if, say, the author is known to be ‘difficult’ and the copy-editor is to liaise with them, the editor will need to have standout communication skills.

Specialist and expert suppliers are aware of their skills, and will charge a premium.

A more general consideration is the competence of a supplier to do their job. The project manager can check this in various ways: the supplier may have appropriate qualifications or belong to a trade organisation: for example, certificates from the Publishing Training Centre, or being a member of the Chartered Institute of Editors and Proofreaders. They may be able to supply testimonials, perhaps with contact details, or the project manager could request a supplier to do a test, e.g., on a sample from the project.

Publishers often have a pool of regular, trusted suppliers, so that may be a source of competent suppliers. A bonus is that such suppliers will be familiar with the publisher’s way of working and material. Suppliers are also listed in online trade directories. Finally, there is networking: asking associates and colleagues for recommendations.

It is useful to build up a list of trusted suppliers. Not only will this make commissioning easier on future projects, but occasionally a supplier in an ongoing project may need to be replaced – perhaps unexpectedly and at short notice through, say, illness.

Negotiating

Before the project manager starts to negotiate the fee and deadline for a job with a supplier, they need to plan. First, they need to prepare themselves with basic information on the task:

• the hours needed

• the time allowed by the schedule

• the money permitted by the budget

• expenses that might arise

• the market rate.

The project manager also needs to know their goals: for example, how much of the total time and money allocated to the whole job are they prepared to allow?

Suppliers should be approached as far in advance in possible and provided with all the information they need to decide whether they are interested in the job. This information is not just about the material itself (extent, subject matter, complexity, etc.) and project parameters (schedule, fee, etc.) but also how the work will be carried out (necessary software, team-working, etc.).

The project manager also needs to agree a contract with each supplier.

The process of negotiating can be summarised as below, in the order in which the stages take place:

• Discuss. The project manager should lead the discussion, keeping things on track. The negotiations are opened by setting the scene and introducing the key points. The project manager should take care to listen, and paraphrase important issues to ensure common understanding.

• Propose. If there are disagreements or problems arise, the project manager should suggest solutions and ask the supplier to propose solutions. The project manager should be flexible and be prepared for give and take – the aim is to reach agreements. The project manager should not offer the full amount of time or expenditure allowed but hold some in reserve to bargain with.

• Agree. Once an agreement has been reached, the project manager should summarise it to avoid misunderstandings. The supplier is then asked to send the agreement to the project manager in writing.

• Review. Following up on an agreement is essential. The project manager will need to ensure that any team members who need to know about the outcome of the negotiation are informed, and project documents updated as necessary.

Creating briefs

Itis essential that the project manager provides a clear, concise and complete brief to each supplier, to ensure that the supplier knows what is expected of them and that work is delivered that meets all the project manager’s expectations. The qualities required by a brief are encapsulated by the acronym SMART:

• S – specific. The objectives set out in the brief must be clear, so that the supplier knows exactly what to do, how to do it and the resources needed to achieve the objectives.

• M – measurable. It is important that end points are clear, so that the supplier can track their progress and know when the job is finished.

• A – attainable. The objectives must be realistic and attainable, i.e., within time, the budget and the supplier’s skills.

• R – relevant. The objectives must be relevant to the supplier’s skills and the aims of the project.

• T – time-bound. Deadlines must be specified for the supplier to focus on and work toward.

Stakeholders as well as suppliers require briefs. For example, the author needs to know what to do and when – such as the dates to expect and return proofs and what to correct, plus perhaps a clarification about whom to contact (e.g., production matters to the project manager, other matters such as a question about royalties to the commissioning editor).

Unit 4 examines the project manager’s brief from the publisher in detail. Although the discussion is about receiving, not sending, briefs, the principles remain the same: a brief is a brief.

Supervising the team

The project manager needs to supervise the team members, so as to spot and resolve problems and minimise their impact on the project. The bottom line is that the project manager needs to know – not assume – that jobs are on track and problem free.

Managing activities

If the project manager delegates work, then it is a waste of everyone’s time if they overly interfere, and can introduce other problems such as alienating the supplier or introducing mistakes: let the supplier get on with their job. The project manager will already have minimised the likelihood of problems by choosing a competent supplier with the appropriate skills, and providing a clear and comprehensive yet concise brief.

However, one of the project manager’s roles is to maintain quality, so they will need to check suppliers’ work and their adherence to objectives such as keeping on schedule and within budget. The project manager must not forget that stakeholders such as the author also need supervising.

Regular progress reports to the project manager from suppliers may be useful for large or long jobs so that progress can be monitored – if progress reports are required, this should be noted in the brief. For shorter jobs, an occasional email or phone call to suppliers from the project manager asking about progress may be sufficient.

An especially complex project may require video conferencing or face-to-face meetings.

If problems do occur, the project manager will need to ascertain their cause and extent, and fix them. Some ways of addressing problems have already been discussed, such identifying whether they affect the critical path, and using contingency and float (see the scheduling and budgeting sections above). Other possible resolutions may to use other or additional people or equipment. A solution should avoid affecting the overall project budget and the final project deadline, if possible; if the deadline or budget will be affected, then the project manager should assess which is the least desirable, and adjust the solution accordingly (in discussion with the publisher – since they will need to be involved).

As already mentioned, the project manager is responsible for maintaining quality throughout a project. In addition to choosing the right people and providing good briefs, the project manager will need to monitor the quality of work done by suppliers through regular checks. The frequency and extent of monitoring will depend on various factors, such as the size and complexity of the job, the schedule, the familiarity of the project manager with the supplier and the reliability of the supplier.

Feedback to suppliers will thus need to be provided: how to do this is discussed at the end of this section.

Communicating effectively

As mentioned at the start of this course, communication is at the heart of project management, and is what a project manager spends most of their time doing. It is therefore important that they are good communicators. So, what constitutes effective communication?

• Listen. Effective communication is two-way: if you ask a question, listen to the reply and give it your full attention – do not switch off and start thinking about what you want to say next.

• Trust. If your actions do not match your words, people will lose confidence in you if you do not correct this swiftly. Sometimes it is better to say nothing until you are certain that you can deliver what you say.

• Clarity. Simplicity is key – say what you mean in as few words as possible, and avoid jargon. Avoid emails or phone calls that go on and on – there is usually no need.

• Your own voice. Let your natural self come through and avoid stiff, formal language and ‘business speak’ – concentrate on being real and genuine.

• Visibility. It is easy today to hide behind a computer and communicate without being seen or heard. Phoning or meeting face to face improves engagement, and shows that you value people and their work.

This applies to all forms of communication, whether speech, email or any other means.

Also, when someone contacts you, it is essential to reply in a timely way. That does not mean you have to always respond immediately – but if there will be a delay, do send an acknowledgement to confirm receipt.

The SMART principle (see the creating briefs section above) can be applied to things other than the brief, such as meetings. Another acronym is ASAP, which is useful to remember for defusing difficult situations and avoiding conflicts:

• A – apologise. Acknowledge and apologise for the problem.

• S – sympathise. Show sympathy and empathise with the person.

• A – accept. Take responsibility.

• P – prepare. Decide on a plan – and act on it.

A no-blame approach is always to be preferred – blaming is always negative.

Effective communication also means having procedures in place that facilitate this. Asking suppliers to contact the project manager if they wish to discuss anything is too vague: if the project manager wants regular reports or email updates from them, then they need to formally request this in the brief.

The project manager should also have an organised system for filing communications, and keep written records of meetings and phone calls.

Unit 5 gives some tips on communicating well in the ‘Stakeholders and suppliers’ section.

Giving feedback

Feedback can be often overlooked by project managers but providing it is key to engaging team members and keeping them on track by informing them what they are doing well and not so well. When done right, feedback is not only appreciated but improves future performance.

Receiving feedback should be seen as a positive experience – the project manager should remember that the aim is to improve a situation, which will not be accomplished if the recipient finds the comments harsh or offensive. Although the project manager may be concerned with poor performance, they need to pay equal attention to and praise tasks done well; in fact, starting with something positive puts the recipient at ease, so the feedback overall is more likely to be received favourably. Feedback must be fair and balanced.

Feedback should also be timely – if it is in response to a problem, provide it as soon as possible after the issue has come to light. Regular feedback is especially useful: suppliers know to expect it, and comments are acted on as part of an ongoing process, so unexpected shocks to either the supplier or the project manager are far less likely than with infrequent feedback.

When writing feedback, be specific: for example, what exactly does ‘some errors were missed during proofreading’ mean? Language needs to be used carefully, so avoid words that exaggerate, criticise or make the recipient feel that they are being preached at, such as ‘never’, ‘always’, ‘bad’ and ‘need to’; and put the emphasis on yourself, not the recipient, by using ‘I’ not ‘you’. The feedback should cover only a few points – too many can come over as aggressive, and demoralise the recipient. Finally, the feedback should not simply be a list of problems: suggest ways to improve performance, and ask the recipient for their opinions.

Reporting

As well as requiring reports, the project manager needs to provide regular progress reports to the publisher, and possibly other occasional reports (e.g., on a meeting). Writing a report can be broken down into three stages:

• Consider the recipient. Think about whom you are reporting to: What kind of information do they need? How do they want the information presented? What do you want them to do with the information?

• Plan the report. A clear structure makes the report easier to read: plan the layout, such headings, and tables. Does it need particular sections, such as an introduction or recommendations? Keep the report as concise as possible – no one has time to read through a mass of material.

• Write the report. Reports vary widely in content, but typically need to include findings on outcomes, outputs and procedures.

For simple, straightforward projects, sending regular emails summarising progress may suffice.

Introduction

The previous units of this course have dealt with defining what editorial project management is and the principles and methods involved in carrying it out. In this and later units we turn to the more practical aspects of being an editorial project manager. This unit looks at defining the scope of a project – which the project manager needs to clarify at the outset.

The project brief

The project manager requires a brief from the publisher that is clear and complete – it is crucial that they understand exactly what they are required to do and the resources available. Unit 3 outlined the qualities of a good brief using the acronym SMART, and as a reminder these are summarised below:

• S – specific. The objectives set out in the brief must be clear.

• M – measurable. The end points must be specific.

• A – attainable. The objectives must be realistic and attainable.

• R – relevant. The objectives must be relevant to the person and the project.

• T – time-bound. Deadlines must be specific.

A well-written brief thus succinctly sets out clear expectations and goals for everyone involved – in this case, the publisher and the project manager. The project brief will be a point of reference for the project at all stages of its production. It will clarify what the publisher wants to achieve, what it expects from the relationship with the project manager and any constraints.

The project brief should include the following:

• Publisher details. The publisher’s name and contact details.

• Project background. A summary of the publication and the project should be provided, avoiding unnecessary detail. For example, the market for the publication, the strategic objectives (e.g., competing publications), the publication details (e.g., title, extent, binding and print run) and other items of relevance (e.g., a colour-plate section, or soft and hard cover editions both required). Note that full specifications for the publication will be in the transmittal form, which the project manager should also receive.

• Objectives. The requirements of the publisher should be set out, listing the aims and objectives that the project manager must meet.

• Budget. The expenditure for the project should be provided. It needs to be made clear whether this is a set budget or an estimate, and, if the latter, whether the publisher will revise it or expects the project manager to provide their own estimate or quote.

• Timescale. It should be stated whether the project is to follow a plan or milestones provided by the publisher, or if the project manager is to follow their own schedule to meet a final deadline for delivery.

• Management. Details should be provided of the internal teams and personnel that the project manager will liaise with. The project manager will also need to know who is responsible for the project, including the approval process (e.g., what needs to be signed off, and when). Communication should also be described, such as the format and frequency of progress reports.

• Constraints. Any limitations should also be listed, such as firm deadlines, holidays of key people (e.g., the author), the need to use the publisher’s branding in the publication or a requirement to use certain suppliers (e.g., a typesetter or printer).

On receiving the brief, the project manager should read it carefully, and ensure that they understand precisely what is required of them and whether they can meet the objectives: for example, that they have the necessary expertise and time, and that the budget is sufficient. They should raise any points that cause concern with the publisher, which may require face-to-face meetings to resolve.

An example of a project brief for a book is provided here:

Download 

An example of a transmittal form for the same book is provided here:

Download

Terms and conditions

As well as obtaining clear instructions on what a job entails, a project manager who is not an employee (e.g., a freelance) needs to agree to terms and conditions (T&Cs) with the publisher. T&Cs set out the rules that both parties have agreed to follow for the duration of a project – which are legally binding even if not signed, providing both parties are aware of them.

T&Cs protect both the project manager and the publisher, setting boundaries, bonuses and penalties, and provide written proof of verbal agreements that is accepted by the courts in the event of a dispute. Well-drafted T&Cs should act like a manual for doing business and have absolute clarity on what happens in a given situation – especially when something goes wrong.

As an example, consider the payment of suppliers, which typically run into several thousands of pounds on a book project. If there are no T&Cs, how suppliers are to be paid may be overlooked, with the project manager being sent invoices that put them in a financially difficult position. However, publishers are often amenable to paying suppliers directly, and, if they agree to do so, this should be stated in the T&Cs.

T&Cs for project management might include:

• the services to be provided

• the responsibilities of the project manager and the publisher

• confidentiality and data protection (note that sole traders are subject to the UK General Data Protection Regulations [GDPR] regardless of whether these are mentioned in the T&Cs)

• the payment terms

• deadlines

• how disputes are to be handled

• the term of the agreement

• which laws will govern the contract (e.g., the Late Payment of Commercial debts [Interest] Act).

The project manager may write out their own T&Cs and send them to the publisher. Alternatively, the publisher may supply their own T&Cs to the project manager. After checking the T&Cs, the recipient may find them entirely acceptable. However, if there are clauses that cause concern, there needs to be negotiation on amending these or striking them out. A project can only be governed by one set of T&Cs, which will need to be mutually agreed to.

Basic T&Cs suitable for editorial work are provided here:

Download 

Introduction

This unit discusses how a project manager can get a project off to a flying start. However, to get off the ground they will need a set of tools.

Tools

Everyday tools

Microsoft Office is essential, and the project manager will need to know the ins and outs of Word, Excel and, sometimes, PowerPoint. Crucially, for typical publications such as books and magazines (whether for print or e-publication), the project manager should arrange for the typescript text files be supplied to them as Word files, or to be converted to Word files (with checks to ensure no loss of formatting, etc.), and the typescript should be copy-edited and sent to the typesetter as Word files. Project managers may be tempted by other office suites (increasingly Google Docs) – but Microsoft Office is the industry standard within publishing, and should be used to ensure full compatibility with files from stakeholders and suppliers. Google Docs is convenient for fast, convenient online collaboration, but, for example, copy-editing in Google Docs is slow, awkward, and problematic if files need exchanging between it and Word.

All that said, using Google Docs can simplify administration for project managers and other stakeholders, allowing everyone to share and update files easily (e.g., style guides and schedules) – but avoid it for editorial use in most projects. Similarly, Google Sheets is a convenient and viable online alternative to Excel for administration.

Project managers will find themselves sending and receiving a lot of emails, and an email client with a built-in calendar, such as Microsoft Outlook or Mozilla Thunderbird, will prove invaluable. Business communication platforms have become popular in recent years: Microsoft Teams is probably the best known, but Slack is also very widely used, especially by smaller organisations and individuals. Messaging services such as WhatsApp have also seen a widespread rise in use. However, using a business communication platform means that all the stakeholders in a project who needs to contact each regularly must sign up to the platform or system and familiarise themselves with it – which may be difficult or even impossible. The advantage of email is that all stakeholders use it. So, because of its ubiquity, project managers should consider staying with email unless there are good reasons not to.

Project managers will also find themselves frequently dealing with PDF files. The industry standard program for PDF files is Adobe Acrobat (either the free Reader or the paid-for Pro version), and it is strongly recommended that project managers use this rather than an alternative PDF viewer, to ensure compatibility of mark-up in PDF proofs.

Scheduling and planning

The project manager needs to be able to see the schedule. It can be displayed very simply, such as a table of dates in a Microsoft Word document:

However, this can be difficult to comprehend, so a more visual way of presenting the schedule will be more informative: the traditional wall planner. This allows the project manager to easily see and plan activities against a time, showing the past and future using coloured lines for different activities, and to add notes to activities. This makes a complex plan visually simple, and critical events, say, can easily be seen. The modern counterpart of the wall planner is an online calendar, such as Google Calendar, or those in email clients such as Microsoft Outlook or Mozilla Thunderbird:

An online calendar is flexible: it can show different calendar views, is easy to update and can be shared with other people. However, the drawback of this ‘diary view’ is that activities are not shown as clearly as they could be: more emphasis is placed on the calendar than on the event. This was addressed by the invention of the Gantt chart, which has a single horizontal timeline, with activities shown vertically.

The image below shows Microsoft Excel, using a Gantt chart template:

Dedicated software for displaying schedules as Gantt charts is available, ranging in price from free to hundreds of pounds, and adds sophistication such as showing critical paths, costs and float. The following is Microsoft Project:

This way of viewing a project is sometimes called the waterfall approach, as events cascade downwards.

An alternative way of showing projects is the board approach, of which the best known is Kanban. In Kanban, each activity in the schedule is treated as an individual unit of workflow. Each unit has a number of sections indicating status, starting with ‘To do’ and finishing with ‘Done’, with further statuses in between that suit the project; all workflow units in the project have the same structure. As an activity progresses, it moves from one status to the next. An activity can be broken down into multiple workflow units, if it is clearer to view an activity as a collection of tasks.

As an example of the Kanban approach, consider the proofreading stage and its tasks:

• page proofs to the proofreader, author and publisher

• corrected page proofs from the proofreader, author and publisher

• proof collation.

Assuming that the proofs all go out on the same day, there are still five events to keep track of (not to mention other ongoing tasks, such as dealing with the index being compiled from the proofs). If the proofs have gone out and the project manager is waiting for the corrected proofs so they can collate them, then the Kanban board looks like:

It is remarkably clear what the situation is. It can be seen at a glance that

• the proofreading stage is ongoing and that everything is on schedule

• the status of each task has been confirmed by all team members that week – excepting the publisher

• there are no delays

• there is one task to do – and its to-do date is in the future, and will be carried out by the project manager.

Compare this to the text-only view of the Word document shown at the start of this section, where understanding situations is not so immediate.

The advantages of the Kanban approach is that it is very visual: it places the focus on individual activities; how well or poorly an activity is progressing is obvious by the number units piling up at one end of the board or the other, and where in the activity a bottleneck occurs; encourages teamwork; and drives completion of activities. It is at its best when all the people involved can see and use the board.

Kanban’s strength of placing the spotlight on activities is also its weakness: it can be difficult to review the overall project timeline and to predict future events. However, there is nothing to prevent the project manager from using a combined Gantt–Kanban approach

There are various programs created specifically for project managers that can display projects as Kanban boards. Many, such as Trello, Todoist, Jira, Basecamp and Zenkit, are new with a modern take on productivity – cross-platform, cloud based, highly customisable, and promoting agile working, collaboration and virtual teams. Some, such as Trello, can also show waterfall views.

However, if you prefer the ubiquity of spreadsheets, a web search will turn up Gantt, waterfall and Kanban templates for Microsoft Excel and Google Sheets: editorial project management is straightforward, so you may find the extra functionality of Trello and their ilk unnecessary.

Project managers may find other software tools useful such as a time-tracking tool (e.g., Toggl): project management often occurs in fits and starts, so it is easy to lose track of how long has been spent doing something. Mind-mapping software may also be of benefit: a mind map is a visual way of organising information as an interrelated network, and is especially productive when thinking through ideas and problem-solving.

Tools all have their pros and cons, so project managers often use a combination: perhaps an old-fashioned wall planner for quick overview and on which to scribble notes; an online diary for daily action and cross-device convenience (phone, PC, laptop, etc.); and a project management app for its flexibility, multiple display options and ease of sharing information via the cloud.

Note. The names of software are mentioned for information only; it does not imply recommendation or endorsement by the PTC.

Initial assessment

Assessing the project material, including the schedule, the budget, and the brief and other documentation, has already been discussed in Units 3 and 4. So, we will cover a few practical points here.

From experience, details in the documentation supplied by the publisher are often out of date or incomplete, so this information needs to be checked thoroughly by the project manager. There can be major discrepancies that affect the project’s deadline and budget, such as the actual word count of the typescript being significantly larger than the word count given by the publisher in their documentation.

The typescript and illustrations also require thorough examination by the project manager. First, check for structural problems, for example

• Is there anything missing (e.g., illustrations or tables)?

• Has the author met the publisher’s requirements (e.g., name–date references required but numbered references are used – time-consuming to convert)?

• Is the text well written?

• Is the text suitable for its audience?

• Will illustrations need redrawing or amending?

The typescript should then be assessed for complexity, for example:

• Is it on a general subject or an advanced topic needing a specialist copy-editor and proofreader?

• Is there a significant amount of maths or chemistry, which will require specialist suppliers, including a typesetter?

• Is there complex material such as large tables, or awkward illustrations requiring bleeds and splitting across double-page spreads?

If the typescript has been used by the designer to create the design, the design should be problem free. However, if the design is a standard template, reused from another publication or created without using the typescript, the project manager needs to check that it is suitable for the typescript.

Permissions for use of copyrighted material such as illustrations will need to be checked to ensure that they have all been received, in writing. Obtaining permissions can be a long process, so it is not uncommon for them to be incomplete. Also, the project manager should not assume that permission for use will always be given – sometimes it is not, and the material will then have to replaced or deleted.

If the project manager finds any omissions or deviations from the agreed project brief or other problems during the initial assessment, they need to discuss them with publisher – ideally with recommended action.

Creating the schedule

As with assessment, scheduling has already been discussed (see Unit 3), so only practical advice will be provided here.

Draw up the schedule based on the publisher’s final deadline, as it is easier to work backwards from that date; it also gives the project manager a clear idea of slack time in the schedule. The start date can then be changed to a more appropriate one, and the dates shifted accordingly. The project manager must not forget to take account of weekends, bank and other holidays (including your own), and other breaks, and to include events that are not directly part of the production schedule (e.g., ad hoc meetings).

Check the schedule carefully: a poorly timed critical event can throw out the entire schedule. And build some slack into deadlines, to account for possible delays.

Publications can have a production schedule lasting many months, and it is tempting to set aside small additional jobs (e.g., publicity material) rather than include them in the schedule – do not do this: it easy to either forget about them or run out of time! It is better for tasks to be done as soon as possible – without causing bottlenecks of work for the project manager or anyone else involved in the project – so there is plenty of time in hand.

Stakeholders and suppliers

The project manager should ensure that the publisher has provided a list of all the stakeholders in a project, including their contact details and other relevant details – and the same for suppliers they wish the project to manager use. The project manager then needs to create a stakeholder–supplier database (e.g., using Microsoft Access) for the project, so all this information is in a single location.

At the outset of a project the project manager needs to introduce themselves to the project’s stakeholders (usually just the author). Using email is normal today, but the project manager may wish to phone first, as that can help establish a relationship.

It is best to be fairly formal in this initial communication, for example not addressing the recipient by their first name, to avoid causing irritation – although business is done more informally today, not everyone appreciates this. The email should:

• state who the project manager is and their relationship to the publisher

• explain what the project manager will be doing

• explain the task required of the recipient

• provide the scheduled dates for the task (e.g., when the author will receive proofs to correct and when these are to be returned to the project manager)

• request confirmation that the scheduled dates are acceptable and can be met (e.g., that they will not be on holiday)

• ask for confirmation of the recipient’s contact details.

The project manager will probably need to commission some suppliers. Unit 3 discusses how to do this. Their details too need adding to the database.

The initial communication to suppliers will cover similar points to those listed above, but will additionally need to discuss fees.

The supplier should be asked to confirm costs, and if an estimate is being provided rather than a quote (recall that the former may change, unlike the latter). Cost estimates need to be accurate, so suppliers may need to assess the material prior to commencing work (not all suppliers will be willing to supply quotes). The project manager should ensure that suppliers alert them as soon as a problem is discovered, to avoid unpleasant shocks – this may do as part of a formal reporting procedure that the project manager sets up.

Suppliers also need to know who will pay their invoices: the project manager or the publisher?

Lastly, good supervision and organisation are key, so the project manager needs to carefully assess a project to head off potential problems. As an example, consider a book with five authors who will all receive proofs to correct. If the proofs are simply sent out and corrected proofs returned to the project manager, then:

• the project manager will need to go through five sets of proofs during collation, transferring corrections from each to the proofread set
• proof corrections from different authors may contradict each other.

Not only is collating five sets of proofs time-consuming, but the project manager may need to contact the authors to sort out conflicting changes. In a worst-case scenario, so much time may be needed that the project is delayed. A solution could be to get the authors to collaborate as a team and to send the project manager a single set of proofs containing corrections that they have all agreed upon.

Running the project - a few pointers

Once the project is underway, the project manager should:

• regularly update the schedule, costs and other documentation

• build and nurture relationships, including providing constructive feedback

• report to the publisher at the agreed intervals (e.g., weekly)

• regularly check with suppliers and other stakeholders to ensure that there are no problems that might affect the project (e.g., increasing schedule and budget)

• remind affected stakeholders in advance when a task is imminent (people have been known to forget about booked-in jobs!).

All these aspects have been discussed in the course (notably in Unit 3).

The project manager will inevitably meet problems along the way. Hopefully, these will be minor and straightforward to deal with. However, more intractable difficulties do arise, and a few of the more common ones in publishing are:

• the typescript turns out to be more difficult and time consuming than anticipated to copy-edit – perhaps due to unforeseen problems or poor assessment, or late delivery of missing material by the publisher or author

• the proofs contain a lot of errors, due to either poor copy-editing or typesetting

• the author fails to return their corrected proofs on time, or makes extensive changes.

All of these can affect the schedule and/or budget. Ideally, the time and monetary contingency that the project manager has allowed for in the project will be sufficient to counter these problems. If not, the project manager will need to make more intrusive changes, perhaps reducing the time between milestones in the schedule, or redistributing the budget: this will require liaison, and sometimes negotiation, with the affected stakeholders.

It is crucial for the project manager to keep the publisher appraised so they always know how things are panning out and progressing. They should always be up front and honest – difficulties should never be downplayed, as that inevitably makes the situation worse and can sour relationships.

A project manager tends to concentrate – not unnaturally – on the main task of overseeing the production of a publication through all of its stages, and key dates not directly connected with production can be overlooked if the project manager is not alert. These may be things like sending material to the publisher’s marketing department, or final proofs to a magazine that will be writing a review of the new publication.

Introduction

Unit 5 discussed starting a project, with earlier units exploring how to manage and ongoing one. This unit is about how to finish it – final delivery.

Handover

When an editorial project is drawing to a close – the end point being typically being delivery of press-ready (print) or device-ready (e-publication) files to the publisher, printer or other recipient, or as printed and bound copies to a warehouse – the project manager should give the publisher prior warning of completion, and confirm the completion date. The project manager should also inform the author and other stakeholders that their involvement is ending on the completion date, and that they should contact the publisher regarding the project after that date, not the publishing manager.

The project manager should know at completion of the project – if they’ve been carrying out their responsibilities properly – whether the project requirements have all been met, such as the final costs being within budget, the quality of work by suppliers to the standard expected and the specifications met (e.g., the page extent).

The project should, though, be checked to ensure that nothing is missing, and that any documentation required by the publisher at handover is provided, such as a final report. Even if the publisher has not requested a final report, it is a good idea to provide one as the publisher will find it useful. The report should cover aspects such as:

• a summary of the project objectives and confirmation that they have been met

• changes to the project specifications (e.g., the budget or page extent) agreed with the publisher

• what is being delivered, and when

• any activities still to be completed.

Some project material may need to be sent to the publisher, such as photographic prints or the author’s hard-copy corrected proofs (paper proofs are still used on occasion). Other items may need returning to their owners, for example a book loaned by the author. These items should also be noted in the final report.

The final step in any project should be an evaluation review by the project manager, for their own use. It is a look back over the entire project to see what went well and what not so well, to learn what could contribute to better, more efficient future projects.

Archiving the project

After completion, the project manager should archive the project in a systematic and comprehensible manner, so that they can retrieve the material easily for future reference – months or even years hence.

The archive should be regularly backed up and stored outside the computer with the original files – as all responsible computer users should do as a matter of course. Although it may seem old fashioned, a document box with computer files on archival-quality DVDs is safe and secure; alternatively, files can be stored on an external drive or (as increasingly common) online using a cloud service such as Google Cloud. Multiple back-ups are recommended – each on a different medium – for redundancy in case of failure.

Insecure ways of backing up data are:

• keeping it in the same location as the original files (a drive can fail and a computer can be stolen)

• on non-archival DVDs (these can degrade within months, becoming unusable).

Hard drives, SSD drives and USB sticks cannot store data permanently: if used regularly, they will eventually fail; if not used, their data gradually degrades (which could be months to decades, depending on the storage conditions and the device itself). If using these media for back-up, they should be powered up occasionally to maximise date retention.

Documents and correspondence need particular care, and should be kept in a form that can be recovered easily. If the documents are stored electronically, use standard naming conventions so that they can be sorted and grouped by name. Emails are especially hard to keep track of: they should not be left in the project manager’s email client but exported as EML files, or copy and pasted into Word files. There will inevitably be a lot of emails over the lifetime of a project, so winnow them, keeping only the important ones.

The project manager should consider future needs: will material be needed for the next edition, for example? If so, this material needs to be accessible. Software evolves and programs disappear, so computer files need to be in a universal standard format when possible: for example, image files should be in EPS, PDF, TIFF or JPEG format. The typesetter’s files may not be usable in the future, so the text may need to be exported by the typesetter to, say, Microsoft Word files.

Archiving, converting and exporting computer files costs time and, often, money (e.g., the typesetter may require a fee), so the project manager should discuss the publisher’s needs, if not covered by the brief, at the outset of the project.