Which Prepress Workflow to Choose? The Ultimate List

by admin on June 10, 2009

Okay so I was over cruising printplanet and saw this thread. Yes, the question I have seen posted over and over again for the last 10+ years that I have been cruising prepress forums (it feels like an eternity now I have written that). What's the eternal question?

What prepress workflow should I chose? And most usually the poster gives absolutely no information on their shop, the work they do, and the price they want to spend. So the correct answer is "I don't know" when you don't know the parameters that should go into making the decision.

Here you go. Here is a list of factors that should take under consideration when deciding to choose a prepress workflow system. Chose carefully, because if you make a mistake and buy one ill-suited to your needs, you will be stuck in Dante's fifth circle of prepress hell.

By the way, in case you are wondering where the structure for the following list came from, it came from the Volare template guide (short version). This is an extremely useful guide for requirements gathering. If you are REALLY serious about buying a prepress workflow, then you should ante up the $55 and buy the document, as following the guide will mostly likely save you thousands of dollars and hours of your time.

1. Why Do You Want a Prepress Workflow

State Background of the Project Initiative ie where and why this project got started. What are the Goals: How will you define success? Goals must be measurable or else how have you succeeded with the project. The measurement must quantify the advantage gained by the business through doing the project. If the project is worthwhile, there must be some solid business reason for doing it. For example, if the goal of the project is
We want to give immediate and complete response to customers who order our goods over the telephone.
you have to ask what advantage that goal brings to the organization. If immediate response will result in more satisfied customers, then the measurement must quantify that satisfaction. For example, you could measure the increase in repeat business (on the basis that a happy customer comes back for more), the increase in customer approval ratings from surveys, the increase in revenue from returning customers, and so on.
It is crucial to the rest of the development effort that the goal is firmly established, is reasonable, and is measured. It is usually the latter that makes the former possible.
2. The Stakeholders

2a. The Client – this is the guy who will be paying for the software ie not you.
2b. The Customer – This not the same as the owner of the company. Think the manager or supervisor to whom the prepress sys admin reports to.
2c. Other Stakeholders – Anybody, like bindery, sales guys, and pressmen.
2d. The Hands-On Users of the Product – this is you, or the guy that actually has to use the thing.
2e. Maintenance Users and Service Technicians – Self explanatory but you should list them as sometimes it's quite revealing. Like if one prepress workflow has 5 different service techies as a mandatory listing, and the other has zero, then ask the question “why is that?”
3. Mandated Constraints
3a. Solution Constraints
This specifies constraints on the way that the problem must be solved. This is the part of the section to describe limits that are beyond your control to change. For example, you can't buy workflow X because the owner hates that particular vendor (but be diplomatic when you write it, dummy)
3b. Implementation Environment of the Current System – Here you describe your work environment, like your power capabilities and network structure (expect to do upgrades when putting in a workflow system, a $10 hub and a power bar to a standard power outlet won't cut it).

3c. Partner or Collaborative Applications – What other software has to work with the new software (hint CIP3 intergration)

3d. Off-the-Shelf Software (hint: PDF, Quark, and Adobe Creative Suite software)

3f. Schedule Constraints – When do you want the workflow in place by? When you NEED the workflow in place by? (Example, did the company just buy a new press and needs to feed it as quickly as possible?)
3g. Budget Constraints – Yeah, how much is it going to cost, and a better question, what are the financing terms)
4. Naming Conventions and Definitions
4a. Definitions of All Terms, Including Acronyms, Used in the Project
Think about it. Who besides you, know what a three-point trap is? How about FM versus AM screening? You need to carefully define all technical terms so that other people reading the document (like the owner) has the slightest ideas what you are talking about.
5. Relevant Facts and Assumptions
5a. Relevant Facts - Put stuff here that you think is important but you can't think to put anywhere else.
5b. Assumptions - Predictions about the future that you think is going to come true and if they don't come true, could affect the outcome of the project.

I have excerpted about 1/3 of the volare document excerpt and you can see that it's massive. You could easily generate one hundred page business analysis report. Should you? Well, if you are  $2 million a year shop, no. $20 million? Maybe. At least you should print out the excerpt and play the game of fill-in-the-blanks. Note that I haven't even talked about the techincal requirements of the prepress workflow as they are usually the most obvious things that us geeks look for in a system eg, can the imposition package do adjust for creep in  300 saddle-stiched booklet for example. You better be able to nail those requirements with your eyes closed, or you will be for a world of hurt when the system gets dropped in your shop.

{ 3 comments… read them below or add one }