Keeping up with the rapid changes in the publishing technology landscape is a challenge for all publishers. Editorial and production workflows are complex and highly evolved; how can they be updated without breaking them? New standards and new technologies present exciting opportunities; how can they be integrated smoothly and effectively into a publisher’s operations, making it easier for staff to do their jobs and adjust nimbly as technology and user expectations change?

That’s kept Bill Kasdorf, Vice President and Principal Consultant of Apex CoVantage Content and Media Solutions, quite busy helping publishers around the world implement needed change. He sat down to chat about his approach to the consulting process and what publishers who engage with him can expect.

Q: What would you say is the biggest advantage you bring to the table as a consultant?

One big advantage I have as a consultant—for the kinds of modeling, workflow, and content management consulting that I primarily do—is that I have actually been in the shoes of the people I’m working with. I’ve been a copyeditor, a graphic designer, a project manager, a department head, and a business owner. In almost every engagement I have, I can see the sense of relief in the faces of the people I’m working with: This guy isn’t just some wise guy consultant who thinks he knows better than we do. He really gets what we do—he’s one of us.

And it’s true. I am one of them. I know why a copyeditor is so passionate about serial commas and how to use ‘comprise’ correctly (most people get that wrong) because I’m passionate about those things. I understand why that designer is worried that an XML model will cramp her style (it won’t!) because I love great typography and design. I have dealt with that author who changes his mind about too many things at a late proof stage. Your model and your workflow and your content management system will fail if they don’t take these things into account.

Q: How do you begin an engagement?

I don’t camp out at client sites but I usually start with a visit of a day or two. When setting up the meetings for my visit, it’s usually best to have some group meetings and some one-on-one meetings. A group meeting—for example, with the editorial team, or the project managers, or the production staff—is useful not just because everybody has a chance to contribute (which is essential, of course!) but because important information is often revealed. It’s not at all uncommon for somebody in a meeting to explain how they do something, and have somebody else pipe up “Really? That’s what you do? That’s not what I do!”

The reasons for the one-on-one are complementary to that. First of all, people are often inhibited, in a group, from contradicting their peers or making somebody look bad. They are much more likely to be open and honest in a one-on-one meeting, especially after I’ve gained their trust. In that context, it’s not at all uncommon for the individual to say “What you were told in that meeting was how things are supposed to work. But that’s not actually how they do work.” Happens all the time.

Q: What do you do to prepare for that visit?

I like to get as many samples and examples in advance as I can. Especially in the context of modeling and workflow analysis, I like to get what I call a matched set of files—for example, the Word file the author originally submitted, the file after copyediting, the InDesign or XML file used in production, and the PDF and EPUB of the result. It doesn’t have to be whole books or journals, just representative articles or chapters is usually enough.

It’s also important that I get a representative sample with a sense of proportion. On the one hand, I want to get as broad a selection of content as possible, so I know all the things that need to be considered. On the other hand, I also need to know if some features are very common and others seldom occur. For the latter, we need to know how important that outlier is. Sometimes it’s very important; other times it unduly complicates the analysis.

Q: How do you deal with the typical resistance from the client’s staff? Since often you’re going to recommend changing things about what they do, right?

My main strategy is to say, “Don’t just have me meet the enthusiastic people.” I also want to talk to the skeptics, the people who, in a meeting, sit back behind folded arms and never say anything but give off clear “This is never going to work” vibes. I need to know why they think that. Maybe I haven’t been clear enough about what the plans are, and why things are being done, and how things are expected to work. Or maybe they actually know something that will be a problem that the current plans don’t take into account. Either way, I need to know those things.

Q: Not to get too deep into the weeds, but I know you do a lot of markup and model development. Can you say anything about your fundamental strategies?

It’s almost always best to start with a well-known and widely adopted standard as a foundation or framework. But it’s also almost always necessary to build on that framework to add the features that make that model do what that client needs it to do.

Another thing I always stress with people is not to confuse a model with a specification. People get into a lot of trouble when they just tell their vendor “We use JATS or DocBook or EPUB.” I had one client who sent thousands of books out to five different conversion vendors to create the EPUBs of their backlist, only to find that each one of those vendors did it a different way. Were they cheated? Nope. All the vendors did in fact provide EPUBs that conformed to the EPUB model. But because there was no specification of how to apply that model for their books, to do what they needed to do, they had a mess on their hands. Another client spent thousands of dollars getting EPUBs created with the expectation that they then would have XML of all those books—which was, in fact, true: the content documents in EPUB are XML. But because there was no specification of how to do that markup, they literally had to start all over and reconvert all that content to XML for their content repository.

Bottom line: Yes, you need a model, but you also always need a specification for how to apply that model. And you don’t necessarily have to use everything the model enables. You just need to use the things that are useful to you.

Bill has become a critical resource to his clients around the world because of his in-depth knowledge and honest assessments. He always tells them exactly what he believes based on his years of experience and what he knows about their situation, even when it’s not what they were expecting or hoping to hear. And that’s the thing about Bill that his clients have come to know and love.

If you’d like to hear more from Bill, check out his recent webinar on Modern Publishing in Practice, in which he and Greg Suprock, our Head of Solutions Architecture, discuss authoring and editing, production, digital asset management, and more. Or just reach out to start a conversation.