Quote:
Originally Posted by Lizard
However, leveling knows the tasks are complete and should be ignoring them and filling in that time with other tasks. I suppose it wouldn't, however, if all your tasks are in a dependency chain.
If you were getting behind schedule, you could use the Reschedule button to move things into the future, but that won't help you here.
|
Thanks for the information. There's lots of things going on behind the scenes that influence how the leveling works and that makes it (probably unavoidably) difficult to grasp.
What I found was that in my work schedule a lot of completed tasks did show up, but other tasks were scheduled for the same period. This is as you described above.
What baffled me was that there were some gaps in the work schedule with completed tasks scheduled for the gap, but no incomplete tasks scheduled.
This, if I understand correctly, must have been a result of the dependencies that I had defined.
Clearly I'm using the software in a way that it was not designed to work.. I've used the dependencies and priorities to influence how the program would schedule the different tasks in sequence (I did not do any manual scheduling) to establish a base line schedule.
The semantics of the dependencies that I've included (I now realize) are more "much of this task must be completed before I can start on this next task" than "this task must be 100% completed before the second task can start".
As an example, "plan user interface" and "implement user interface" are clearly dependent, but the planning of the interface does not need to be 100% complete before the first line of code can be written. It's perfectly fine for planning to be 75% complete and implementation 30% complete.
The semantics of the dependencies in OmniPlan appear to be "task A needs to complete before task B can start". This is probably appropriate for many projects; but I fear it's not generally appropriate.
The problem is that these semantics are not enforced anywhere in the program except in the leveling feature. If you are strict about these semantics, you shouldn't allow any dependent task to be more than 0% complete before the first task was completed. As things stand at the moment, you do in fact have two different semantics for the same dependency concept.
In my usage scenario, it would be more logical if the leveling resulted in no gaps as one could easily describe the current behavior as a "bug" (as I software developer that interpretation makes me cringe, but I'm playing the user).
On the other hand, enforcing the strict dependency semantics by not allowing dependent tasks to be started before the prerequisite task has finished would at least allow the user to build a correct mental model of what's happening (a good thing in this type of program).
The current behavior of the leveling would make much more sense if you could in fact not change the completion status of with starting dates in the future at all. That way in order to start a task you would need to put it in the past which makes a lot more sense than working now on a task that is going to start in 3 months time.. I think this is also the underlying cause for the problems other people on the forum have with accurately tracking, who did what when and how much effort was actually spent on the task. Working now in the future makes no sense.
At the moment, I'm not sure what kind of mental model I'm supposed to have of how OmniPlan works.
On the one hand, there's no problem in working on future tasks and updating the completion status of those tasks. On the other hand the leveling feature that is supposed to help me allocate resources based on task priorities and dependencies can't actually deal with this without (potentially) leaving gaps in the work schedule.
As a result, I don't know when my project is actually going to finish (one of the most important reasons for me to be using a project management package in the first place) and I'm not even certain how much effort I've already expended nor how much effort I still need to expend.
I think the way the "actual schedule" works needs a rethink to make it more graspable. Off the top of my head I could see two ways of doing this:
1) always accurately track when work is performed; disallow any manipulations that would break those semantics (ie. don't allow the completion status of future tasks to be modified or automatically move them into the past by the "right" amount when they are changed)
2) let people work on future tasks, but "correct" this once the leveling feature is invoked.
In both those scenarios I think it would be necessary to break the completion bar into different segments.
You could of course simply add a checkbox "Do not schedule time for any completed tasks".