[frankrei]

I'm fairly new to OmniPlan and I bought it to plan and keep track of a one-man development effort; a bit of overkill perhaps but also a simplest-possible usage scenario.

Many things in OmniPlan work in unexpected ways, but something that baffles me completely is the leveling button..

I have created a baseline schedule for the project and I'm now updating the task completion as I proceed. I'm well ahead of my development schedule and I have completed many tasks that are not yet supposed to even start. I have put those tasks on a completion percentage of 100%.

What I'd expect would happen when I press the leveling button, would be for those tasks to be scheduled in the past (before the current day) and my work schedule to be adjusted to feature only incomplete tasks. I would also expect the project end-date to shift to show me when I can expect to ship the product.

Instead the leveling (with the Don't schedule any tasks before {now} checkbox ticked) puts the completed tasks in my work schedule as if they were 0% completed. In other words, my work schedule is full of gaps where I will not actually be doing anything since the task I'm supposed to working on is already completed?

How can I get OmniPlan to honor the completion level of the tasks when leveling?

[Lizard]

Leveling won't move completed tasks around. This is intended, but we are pondering how to do something closer to what you're expecting.

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.

[Lizard]

I think the theory is that you would adjust task actual end dates as you complete the tasks. Then leveling would behave as you expect.

We do have a feature request open for "move task end dates to now when you mark them completed".

[Brian]

I *think* that leveling actually ignores tasks that are 100% complete: we only care about re-arranging tasks that you can actually still do work on.

We don't want to alter history, in other words - just the present and the future. ;-)

[Brian]

Also, if you open up a bunch of threads in tabs, you should probably reload them before responding, in case someone beats you to the punch. :)

[frankrei]

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".

[Lizard]

Obviously, this needs some careful design discussion for how we want to do it in the future. However, for working with OmniPlan as it is now, I'd encourage users to behave as if (1) were true. That is, if you're going to change the completion status of a bug, check to make sure the start and end dates are current also.

I don't know that we can have OmniPlan just auto-move a 2-day task starting tomorrow back to start yesterday if you say it's half done. Maybe it's half-done because you worked on it all day yesterday. Maybe you worked on it this morning for 2 hours and made way more progress than you expected. If OmniPlan tried to guess what happened and moved things around, I think it would be wrong enough to scare users.

"Rules":
1) If you're changing a task's completion percentage from 0 to anything else, double-check the start date and make sure it's accurate.
2) If you're changing a task's completion percentage to 100%, double-check the end date is accurate.
3) If you've got a task that needs to be mostly done before another task can start, you've got 3 options
a) Create the Finish->Start dependency and realize this is a sub-optimal schedule and you'll probably deviate from it.
b) Create a Start->Start dependency instead of a Finish->Start. Also not completely accurate, but depending on how you're looking at the data, might be closer.
c) Break the first task into two separate tasks, such as "roughly plan user interface" and "fine-tune user interface". (Or explicit separate tasks like "layout UI elements" and "design icons") Then make "roughly plan user interface" a F->S pre-requisite for both "fine-tune user interface" and "implement user interface". This not only makes your schedule more accurate, but might help you plan better. For example, you might realize that the fine-tuning will be much more productive after the UI is implemented, when you can actually test drive it.
So you might change your schedule more to look like
Rough design -> Implementation -> Fine-Tuning

[frankrei]

Thanks for the detailed reply. Sorry I didn't reply any quicker; I was on holiday abroad.

You're right of course about the magical moving around of tasks; probably not so intuitive.

I wasn't aware of the start -> start dependencies. Those are probably much better for my purposes and will solve many of my problems.

I have already broken down the tasks into lots of micro tasks, but that doesn't really solve the time estimation problem.

My basic problem is that it's very hard to accurately judge how long a task will actually take to accomplish.

I'm sure as a developer you have run into the same problem: you need a nice calendar control but you don't know whether the built-in Mac OS X control is up to the job or not. If it is the effort is half a day, if it isn't you're heading for custom developing the control (40 man days?).

Breaking the task down into "evaluate standard control" and "develop custom control" is better planning but does not provide you with a more accurate estimate of when you'll be shipping your product.

I guess what I really want is something that lets me capture my tasks, define basic dependencies and then work out what I should/ could start working on today AND when I'll be shipping the product based on the current task progress and estimates (e.g. is a september release still realistic?).

OmniPlan isn't really the right product to do that with. OmniFocus is great, but as far as I can see it doesn't really fit the bill either..

I'll see how far I get with the start/start dependencies.

Thanks for your time and thanks for listening.

[tburton]

Reading through this thread makes my head hurt. I empathize all around. No scheduler I've seen satisfies everyone in the area under discussion.

Regardless of leveling behavior, I wonder if the following change would meet with everyone's approval and not be too difficult to make: Include the completed portions of tasks in the calculation of resource allocation. I am looking now at a construction schedule. I work continually to keep everyone busy. Every time I (a) mark a task partially or fully complete, I (b) see gaps open in the allocations of affected resources. Because I must do (a) in task view and (b) in resource view, (b) often comes as a surprise. I waste time reassuring myself that the gaps are not real.

If this happened only in the past, I could more easily ignore it. Because constructions tasks frequently get stuck (lack of proper fasteners, etc.), however, tasks are often performed out of order, so that future allocations also can show gaps owing to tasks completed ahead of schedule.

This is a nuisance. Can OmniPlan be changed to compute and show allocations for both incomplete and complete tasks without messing up something else?

[EDIT:] Counterargument: Suppose I paste an 80%-complete task from another plan into my current plan. I want to allocate resources only to the unfinished 20%. I don't want the completed portion to generate warnings of over-allocation. My solution to that issue would be to redefine the task to include only the 20%.