Think about a typical project. In my experience, they start with planning and prototyping, then go into production, then as production ends all the bits and pieces are sent out for printing or conversion for electronic use, and eventually archiving. At the beginning of a project, there’s a small staff doing the market research and planning, then a little more staff for prototyping, then the whole Machinery of Progress gets thrown at it for the production and post-production phases. Lovely.
Except during the production and post-production phases (or really any of the phases), things happen, schedules get strained or broken, and more and more people and effort are required to keep the whole thing going. People start working overtime, temps might need to be brought in, or parts of the project might need to be sent out. Typical.
And since you don’t just make one product then close for a six-month tropical vacation (and if you do, are you hiring?), the next project has to start during the Crazy Time of the current project. So the planning and prototyping get fewer staff. The next project isn’t as well-planned or developed when production needs to start. More things happen that require rework and more help. And on it goes forever.
I drew a chart of this once (nerd!), with time on the bottom and effort on the vertical axis. As time goes on, effort goes up. The highest effort of one project overlaps with the beginning effort of the next, shortchanging the next project. These curves keep overlapping as projects go on. It’s an endless cycle of sadness.
The use of XML can, in fact, reverse those curves. Throw the effort at the start of a project, and as time goes on, effort goes down, freeing up people to start the next project. If the effort is expended up front, you still have time to make adjustments without blowing up the whole project.
How does that work? Theoretically, XML should help with planning and prototyping, since you have access to all your stuff in an easy-to-reuse format. It should help with production, especially if you’re using it to facilitate page comp activity. It will definitely help with delivery to other departments, vendors, or the archives. Theoretically.
So what’s the up-front effort? Design and templating, which should be part of that up-front work anyway. Content and metadata tagging, which usually isn’t.
In introducing an XML-based workflow, we’re really talking about changing more than just the tools. We also have to change the whole idea of how a project gets done. We’re asking authors, editors and designers to trade up-front effort for a smoother project down the road. We’re asking them to do more work than they might be responsible for now. And it’s not work they signed up to do. This might be the most difficult part of getting an XML workflow up and running. If they’re not 100% on board, and, dare to dream, enthusiastic, then you’ll end up with an expensive system with nothing in it. Or you’ll end up spending time and money getting stuff ready to put in it, which adds steps to the project, and might end up putting you right back in that old way of working, but now with even more work to do in the middle of the project.
Filed under: XML |