![]() |
|||||||||||||
|
Schedule Specificity BY KATIE MULDOON The catalog coordinator was close to pulling her hair out as she had repeatedly downloaded the layouts and they kept coming up the same unsatisfactory way. Worse, her boss was moving into a position where she could see over her shoulder. Time to fess up. “For some reason the layouts aren't downloading properly. Every spread is just a big black and white grid with nothing in it,” the coordinator said. Expressionless, her boss said, “That's what it's supposed to look like.” “Ahhhh, but the schedule says we receive layouts today.” “These are the layouts. Well, the layout grids anyway.” “Oh,” the coordinator said, as she wondered what she was supposed to be doing with a layout version she had never seen before. Another case of poor catalog creative and production schedule specificity. Nothing keeps a project on time and on budget like a detailed, overly specific schedule that has five major columns of information: * Function or activity name. * Date started. * Date ended/due. * Days allocated per function. * Person responsible. There are several software tools that aid in the development of schedules; my favorite is simple, intuitive FastTrack Schedule from AEC Software. It has a quick learning curve, works effectively even at the initial learning stages and can be imported into Palm. If you have used the more popular Microsoft Project, FastTrack does data exchange with Project, so any work previously done in Project would not be lost. Whatever software you choose, absolutely, positively have a beginning and end date for each step of the project. The No. 1 misunderstanding in scheduling occurs when, as with most schedules, there is only one date per function. The assumption is that everyone agrees that this is the finish date. Trust me. They don't. Some think this is when the task starts, others think this is when someone, not necessarily them, should complete the task. Even if the function is something like a one-day meeting, show the same date for the meeting. As most software programs allow you to enter the actual hour that you start and end, this might be the right approach for a really tight schedule. Showing the number of days allocated per function helps those who will be responsible for getting that part completed on time to spot timing errors immediately, not once they are into the project. For some reason, seeing a date range such as “starts May 9, ends May 16” doesn't mentally translate into the five working days it actually is. Showing days allocated avoids the “I didn't realize it was only (fill in any number) days I can't possibly do it in that time!” situation. The person responsible should, if at all possible, be one person by name, not a company or a group of people. If only one person is listed, no one can say, “But I thought John was handling that.” If there really does need to be more than one responsible person, list the one who has the ultimate responsibility first. Make sure that all understand what the first listing represents, then include that information on every page of the schedule. Always, always date each version of every schedule. There is never just one version and relying on the date-modified information on your computer is a certain way to get the latest one confused with a prior version. Numbering versions also can be effective. Number every sheet of the schedule, not just the first page. You would think that the “function” part would be self-evident. Believe me, it is anything but. Only actually going through the process with all team members will refine it to the point where it is a truly useful tool. And then it will only have real meaning if you revisit it each and every time you have completed a project, editing function names and days allocated per function. As in our original example, be specific about what the layouts you are reviewing will contain. Will they be grids for position only, type in place, partial photos in place, color, black and white? What will you be providing to the creative team, and when? Will you be giving them all copy and photo data at the handoff meeting or are these elements coming at different times? How complete will they be? Say exactly what the creatives will be getting (half the catalog, all but 10% whatever it is, to the best of your knowledge). Did you allow time for reshots and enough revisions? Interviewing models and finding locations? Only you know how many revisions you'll really need. Don't be optimistic; be realistic. What about prep work like checking on paper changes, the number of covers per drop and to whom, any format changes or testing considerations? All of these should be in the schedule. Most of us work backward from the in-mail date, noting days allocated per function and allowing the software to work out the actual dates through its linking process. First we start with the ideal days allocated. Then, when we find that we should have begun that particular catalog many months ago, we can go back to the scheduling software and make adjustments. The last, and sometimes hardest, step before actually starting to use the schedule is getting the sign-off from all the players. Circulate the schedule, discuss it, adapt and hold folks to their commitments. |
||||||||||||