There was a post on the OmniPlan 2 private beta forum that might be enlightening, too. I hope Tom doesn't mind my taking the liberty of reposting his message!
Quote:
Originally Posted by Tom Bunch
The "grey-box-extensions", don't indicate any kind of conflict. Think of them like a trough. If you set both a start and end constraint on a task, OmniPlan can feel free to slide the task anywhere within the trough without causing a violation. Leveling and explicit dependencies are two things that will go ahead and do that.
In 1.x, when you moved a task, group or milestone start date, you are changing the scheduling method of the item to "On specified date". Thereafter leveling will not move the task. We found that when people start with OmniPlan they create tasks, start dragging them around to get a sense of the project, do some resource assignments, and then try leveling, which they very reasonably assumed was completely broken when it didn't move tasks.
That informed our thinking that when they start dragging tasks like that, they're really saying, "don't start that until somewhere over here" and what they really want is a start constraint.
To that end, I think we really need to support start constraints on groups and implicitly set them if the project date is earlier than today. Group start constraints do constrain the child tasks, and you can add an empty group at any time.
I think your use of the term "split" may be confusing me, given that we now support true split tasks. If you take a project starting some days ago, add a task (automatically constrained to start today) drag it to tomorrow, and add a child task to it (automatically constrained to start today), the first task will be constrained to start at whatever point you dragged it to, and the child task will have an earlier constraint that busts right out of the group's bounding rectangle (see View -> Gantt -> Group Shading). Is there a specific part of those results that is troubling?
-Tom
|
A comment about dragging things around: in my opinion, it is best to express the structure of your plan with dependencies, lead times, and constraints as needed, trying to do as little fixed assignment of what happens when as possible (in other words, "this needs to happen after this task finishes" is good, and "this needs to happen on Tuesday" is not good, unless it really has to happen on Tuesday, and you aren't just saying that because you expect the previous thing will take all of Monday). This gives OmniPlan the most flexibility to find good solutions when leveling, and also helps you if you decide to move the whole project.