[whpalmer4]

I agree that Greg's theory is probably correct here. To expand on what he said, start dates, due dates, and flags all pass their characteristics down to any children of their row. If you have a project with a start date, all the children will be treated as if having that same start date, if they don't have a later one of their own. Similarly, a project with a due date will cause all the children to be treated as if they are due on the project's due date if they don't have an earlier one explicitly set. Flagging a project will cause its actions to be treated as if flagged. The same thing happens with action groups (or sub-projects as some like to call them).

For the most part, this behavior is what you want, but it can complicate life a little bit at times. For example, if you want to bring up a view that shows all of the actions which do not have their own due or start dates set, you can't use the group by due or group by start options in the view bar, because they are treated as if the parent's due or start date is present.

The project's start date should be the earliest that anything in the project can be worked, and the due date should be the date at which the job is finally done. There's nothing preventing you from having intermediate start and due dates for the various components of the project, and if the project is set to sequential execution, you won't see subsequent actions ("send proofs to client for approval") on your available actions list in context view until the necessary prerequisite(s) ("process images from shoot") have been completed.