The world of technical book publishing is going through a transformation. More information is available than ever before online; software and hardware products evolve faster; people demand up to date knowledge that is also insightful and in-depth. These factors create enormous difficulties for the way that technical books were written, edited, and published in the past. Simply put, it is no longer acceptable for an outdated technical book to appear.

I’ve been immersed in the traditional approach since 1991 and have written fifteen books in that time. The usual approach is:

• Identify a need: “Let’s write a book about Product A”.
• Create book proposal: Outline the structure of the book – how many chapters, what each chapter will cover, the overall length – and perhaps write the first chapter to demonstrate the kind of coverage you want to give to a subject.
• Sign with a publisher: Agree a contract outlining when the book will be delivered and the commercial terms that apply, including the royalty rate paid for book sales, translations, and electronic copies.
• Write the book: Depending on the length, this can take months. Modern software is complex and has many twists and turns.
• Technical edit: Have the book reviewed by an acknowledged expert in the space who will helpfully point out all the places where mistakes are made, omissions occur, and an author’s opinion on a matter if is just plain wrong.
• Copy edit: Correct the content by applying a “house style” to the text. Some authors need a lot more work than others (even up to and including a complete rewrite of text) and some of the changes that are made can seem bizarre. Publishers might not like particular phrases, for instance, because they make the book harder to translate for different markets, and some look for additional input by the author to make the book more accessible. And then you have the “commercial” side where a publisher might not like the author to use particular examples. Microsoft Press, for instance, doesn’t like screen captures of the Chrome browser.
• Editing: Constant effort is required from an editor to keep the workflow going from initial creation to publication. Details like creating an index, book layout and styles, and so on are discussed and implemented.
• Preparation: The final text is given to a desktop publishing expert who takes Word documents, bitmap graphics, and anything else that’s needed and composes a good-looking book that meets the layout and graphic requirements of the publisher.
• Printing: The desktop publishing output (usually high-quality PDF or PostScript files) are generated in the format required by the printer. The printer then prints, binds, and ships the books to wherever they are to be sold. If required, electronic copies are produced in the formats required by the various readers.

Phew! That’s a lot of work by a lot of people and it takes place over a long time. A book about a new version of Exchange would be usually agreed some months before the software is available but writing can’t start until the software is in reasonable shape, normally well on in the beta cycle. I’ve found that it is worthless to write about the software that is shipped to customers as the RTM (Release to Manufacturing) version because very few companies ever install the RTM version. It is better to base a book on software that has matured a little and the obvious bugs have been fixed.

Writing the text of a book might not finish until six months after RTM. During this time it is relatively easy for the author to keep up with new developments as people discuss the software, encounter bugs and workarounds, or find new ways to use it. That knowledge can be incorporated into the text as it arises.

The technical edit phase probably lasts two months, depending on the length of the book, and will overlap the writing phase somewhat. The author has to provide finished chapters to the editor, who checks them and then releases the chapters to the technical editor. Reviewed chapters flow back to the editor after a couple of weeks and are sent on to the author. The comments usually result in a set of updates to the chapters. Any new information that has come to hand about the software can be incorporated into the text at this point.

The copy editing phase kicks in as fully edited (through technical review and author update) chapters become available and the interaction between copy editor, editor, and author takes another four to six weeks.

Chapters are also being worked on by the desktop publishing expert to create the final form of the book. From this point on it becomes more difficult to accommodate new information because the page count is being finalized and insertion (or deletion) of material will affect page flow, indexing, and so on. It’s still possible to make changes, but the changes tend to be relatively minor. There’s no way that a section of a chapter will be rewritten at this point unless it is badly flawed and absolutely needs the work to be done.

A final round of reviews occurs after all the chapters are in their almost final form to identify any issues – code extracts are often problematic as pouring text from Word documents into desktop publishing packages can affect their formatting and meaning. The last few patches are made to the text, but now it’s really only done on a must-need basis.

The book now goes to the publisher and appears four to six weeks later. Noticing a mistake at this point produces real heartburn for all concerned, but it happens. That frustration continues as time goes by and new updates appear but the printed copies stay the same. I would very much like to have an update for my Exchange 2013 Inside Out: Mailbox and High Availability book, but that’s not going to happen anytime soon, despite the multitudinous updates that have appeared since the book was published in September 2013.

Everyone involved in moving a book from text to print attempts to work as efficiently as possible, but even so the entire process can take between nine and fifteen months. And it’s terribly difficult to accommodate changes due to software updates during the last three months.

Extended as it was, the process has worked for years. But that’s because a products like Exchange, SharePoint, Outlook, or Windows have been engineered in three or four year cycles, leading to releases like Exchange 2000, Exchange 2003, Exchange 2007. Exchange 2010, and Exchange 2013. It worked, but it’s been getting harder and harder as Microsoft has changed its engineering cadence in response to the faster release cycles of competitors and customer demands for new functionality sooner.

It’s crazy to think about using traditional publishing methods to produce a book about Office 365. Too many changes happen too quickly for the old approach to work. Anyone who stays abreast of the constant flow of announcements on the Office Blogs knows this. Any administrator responsible for an Office 365 tenant realizes that things are different in the cloud and that software can change daily. At the time of writing, Microsoft’s Office 365 Roadmap lists 46 engineering developments under way. That list is incomplete because it only includes the major efforts; bug fixes and adjustments to features happen all the time.

The work necessary to keep text up to date about Office 365 is enough to make an experienced author cry. It’s time for a new approach. That’s why Paul Cunningham (ExchangeServerPro.com), Michael Van Horenbeeck (nicknamed Van Hybrid for good reason), and myself will publish “Office 365 for Exchange Professionals” on May 3. The book is designed to explain Office 365 to experienced Exchange on-premises administrators, but I think it will be valuable to anyone who wants to learn more about Office 365.

We’ve been writing since last December and underestimated the effort necessary to stay abreast of new developments inside Office 365. But the work has justified our belief that this book would be impossible to do using traditional methods.

“Office 365 for Exchange Professionals” will be available for purchase as an eBook from ExchangeServerPro.com. We plan to update the book regularly, so the version you download from the site will be the latest text. We’ll probably take a bit of a rest after the first version appears, but you can expect regular updates from September onwards.

We’re still working on the text and won’t finalize it until April 15. I can tell you that the book currently spans some 600 pages divided into 18 chapters.

“Office 365 for Exchange Professionals” has been a fantastic project. Apart from learning a ton of stuff, we have received terrific support from the Exchange product development group and the MVP community. Jeff Guillet is the overall technical editor and he’s being helped by other MVPs who are reviewing individual chapters. And we have the pleasure of a foreword written by Microsoft Vice President Perry Clarke, who has led the development effort to take Exchange from being software designed for deployment inside corporate datacenters to cloud software that supports tens of millions of mailboxes with a very substantial record of meeting SLAs.

Hopefully you’ll like the book. And hopefully we will receive lots of ideas and suggestions that we can incorporate into the second edition, and the third edition, and so on. I suspect that this project might turn into an ongoing effort, but we’ll see how the first edition turns out and decide what happens then.

Now we had better get on and finish the book else it won’t be at Ignite.

– Tony (with a lot of help from his friends)

Follow Tony @12Knocksinna

PS. The book is available (PDF and MOBI) at ExchangeServerPro.com or (Kindle format) at Amazon.com and its country-level stores.