As digital content becomes the norm, rather than the exception, the expectations of what can be done with it, and hence the processes to create it become more complex. Publishers and information owners need guidance on implementing digital publishing (to websites, ebooks, even to print!). The requirements are different for professional and academic publishers, for trade publishers, and for B2C information providers. How can I help? What is described here is not rocket science. The headings below divide the digital publishing process into twelve distinct but linked stages. I have provided help on each of them at various timesof them (click on each one to learn more):
- To understand how current software tools are used
- To understand how the current production processes work in practice.
- To identify possible areas for improvements.
Deliverable: A summary document that explains in more detail the current publishing infrastructure, in sufficient detail to be able to recommend specific improvements.
- Where and how content is held
- An accurate estimate of repository size requirements and likely growth.
- Representative samples of content.
- Details of content structure that the content owners may not be aware of.
- Where content has multiple uses.
- List of inputs and outputs (e.g. to third-party delivery platforms, e-book platforms, customer interfaces).
- Where metadata originates or is amended.
The content audit makes possible the task of making content searchable across different types, for example books as well as journals. Deliverable: a spreadsheet and explanatory document.
- Suggested content structure
- Benefits and drawbacks of potential structures.
- Implications for workflow
- Extent to which standard solutions or customised solutions need be found.
- Suggestions for phased implementation
- Skills required to manage the new structure
- Outline budget to carry out changes
It is possible to create proposals without first gathering information or auditing the content, but this process is inevitably less precise.
- Suggested tools for validating content.
- Ways of linking content internally.
- How to linking data to the outside world.
- Reusing content in different formats.
- Outline costs and idea of phased development.
- A suggested proof of concept.
- Identifying suitable suppliers that have the capability to meet the requirements.
- Taking up customer references and reference site visits.
- Scoring vendor proposals and presentations to an agreed set of criteria.
- Ensuring a level playing field for all vendors: clarification of questions and running an FAQ list to ensure no vendor receives privileged information exclusively.
- Face-to-face presentations by proposed suppliers, who will be asked to carry out an agreed list of tasks.
- Risk analysis of suppliers.
This phase ends with an agreed supplier who will deliver the solution that best meets the requirements, to an agreed cost and timescale.
- Checking the vendor and system integrator credit status.
- Negotiating the contract with the vendor to protect the publisher.
- Reviewing statements of work from the system supplier.
- Ensuring any custom work that is commissioned is ring-fenced to ensure the deliverables are clearly stated and demonstrable.
Deliverable: agreed contract and statement of work for signature.
- Identifying appropriate tests to demonstrate fitness for purpose.
- Managing the transfer of technical skills to the in-house users.
- Ensuring that the organisation understands what the system can do, by providing demonstrations and workshops.
- Ensuring any training by the system integrator or vendor meets user needs.
- Ensuring hosting is set up in a cost-effective way that is commensurate with the system requirements.
- Identifying and recommending external expertise as required (e.g. if changes to a schema or DTD are envisaged).
It is highly recommended that an external project manager with publishing knowledge acts for the publisher. This is because:
- The project manager should have sufficient technical knowledge to understand what is being discussed in the project communication.
- The project manager is familiar with the software development process.
- The project manager is external to the organisation and so can provide objectivity: he is outside the existing business processes.
- The project manager provides a single point of contact with the system integrator.
Any project management methodology can of course be aligned to the publisher’s existing systems: project style can be waterfall or Agile, but whichever methodology is implemented the overall goal is the same: to ensure that requirements are captured accurately, costed clearly, and implemented in a clear order of priority. Agile does not mean less specification; it may mean more. Whichever methodology is adopted, I provide the following methodology:
- A way of ensuring senior management know what is happening.
- No use of technical terminology that obfuscates understanding.
- Single-page reports to the project board every two weeks, including budget updates.
- Genuine and regularly updated risk assessment and mitigation.
- And, at the end, a set of lessons learned.
If you are a content owner, I can manage the whole process for you, whether directly or by recommending specialist solution providers. ConsultMU Ltd was founded in 2002 by Michael Upshall. You can contact me at michael [at] consultmu.co.uk.