You may want to create more milestones of the same type, and to chain them together. This allows you to control how long an element may stay in certain status, and to prevent bottlenecks from the very beginning of the work flow. The solution, of course, depends on your organization. For an efficient milestones chaining, you should write down the work phases for stories, images, and pages, and define the allowed range of time for them. You start with the last work flow step, i.e. the page closing time, and then go to the beginning, step-by-step.
Important: there must not be two milestones with the same time set!
For example:
Description of the operation |
Duration (minutes) |
Must begin before deadline (minutes) |
Must finish before deadline (minutes) |
Milestone name |
Milestone properties |
Sending page to type setter and setting workstate to "Closed" |
~2:00 |
2:00 |
0:00 |
Page closed |
•Workstate: Closed (page) •Printed on some: - •Printed everywhere: - •Before deadline: 0 |
Final proof reading and changing workstate to "Approved".page |
~2.00 |
4:00 |
2:00 |
Page approved |
•Workstate: Approved (page) •Printed on some: - •Printed everywhere: - •Before deadline: 2 |
Printing page on proofer and handing it to the section head |
~3:00 |
7:00 |
4:00 |
Final proof |
•Workstate: - •Printed on some:selected, and all proofers listed •Printed everywhere: - •Before deadline: 4 |
Completing the page when the last image or text is in the "Page" workstate |
~6:00 |
13:00 |
7:00 |
Page complete |
•Workstate: Complete (page) •Printed on some: - •Printed everywhere: - •Before deadline: 7 |
Subbing of stories for one page |
~15:00 |
23:00 |
13:00 |
Subbing complete |
•Workstate: Page (file) •Before deadline: 13 |
Editing of stories for one page |
~35:00 |
58:00 |
23:00 |
Editing complete |
•Workstate: Sub (file) •Before deadline: 23 |