The big reason to make 112 projects is IF you choose to track the work on each page in that way. Yeah... it can make everyone look overallocated especially if all the projects are running at the same time, and that's really the intent. If you allocated a designer 15 minutes per page, for example, they would have to spend 28 hours working on the 112 pages. If these were all due on the same day, well, then they are overallocated. You often choose to track this work in this way if you have multiple designers. This way project tasks can be assigned to different people. If I had 4 designers, and everything was due on the same day, I'd assume everyone was taking 28 tasks each, and noses to the grindstone for 7 hours. As each designer finishes each task, that project can move to the next task. So I assume that you specifically had some sort of process where the reviewers (for example) are waiting for the designers. As each page is completed, the reviewer is notified that that page review task is "ready to start". This definitely gets annoying to get a ping every 15 minutes that something is ready to review, but again--this is based on your choice. If you want the reviewer to get started as every page rolls out, this is the way to do it. I think what people sometimes don't keep in mind is that there are interdependencies in the way people work. For example, if your designer actually wants to work on a set of 20 pages to develop a cohesive design that spans that whole category, then it might make more sense to bulk the design tasks so that there aren't 112 design tasks: there are ... 6, and the designer holds on to the task until the whole set of pages are done. Same thing with your reviewers. If they wanted to review the 20 pages in Section A and check links between the pages, then getting a ping on every single page is pretty useless. So if your project team is more geared to working in this way, 112 projects can feel like an imposition and unhelpful. -skye
