On Fri, May 8, 2009 at 11:10 AM, Greg Troxel <[email protected]> wrote: > > > I would say that A does not get allocated resources, just AA and AB, and > > A's planned start time is the earlier of AA and AB, and planned end the > > later, and that's that. > > In your example AA will be done in 4 days and > > AB 7.5 so that's A's finish time. > > > > I m not sure about how other PMS handle this, but it seems that > distinguishing between simple (atomic) tasks and composite tasks / > activities should be considered ... the limit between what's atomic > and what's not should be left to the project manager or somebody else > in the dev team, enterprise, etc (I mean not to enforce a policy ;) > > I don't understand what you mean here. With a WBS organization, tasks > are either leaves (no children)
simple (atomic) in what I said ... > or not. composite ... > I am proposing to have a rule > that non-leaf tasks only hold leaf tasks and don't have associated work. that's the distinction I was talking about ... ;o) > One can always add a subtask to hold the work. Oh! yea ... > It would be reasonable > to make that configurable, ... at least I didnt say anything about this, and I dont want configs for that. IMHO this is an extra and unnecessary overhead ... > but I think it's easier to just have the rule > and doesn't hurt much. > What I was trying to say is that people may like to omit some details when they actually do the WBS. For example sometimes it happens that enterprise `A` carry out something by itself and this represent a minimal overhead, so they dont include it as a task, but as a necessary step needed to accomplish a task. But sometimes it also happens in some specific cases, that the same «thing that needs to be done» is more complex or needs to be outsourced, or whatever, and (in the overall picture) other tasks still need all this be finished in order to be started. Thus WBS in the later case gets deeper (and is more complex) than the former (even if both are about the same «thing that needs to be done» ;). The fact is that sometimes such situations also happen as projects move on ... Your proposal looks good ... and was like the idea I had in my mind (but possibly wasnt clearly enough after I wrote it ... ;) > ... but I am not sure about the conflict ... IMHO (now) it's just > about the way scheduling's carried out. WBS is only about tasks, > activities (compound) and relationships | constraints (e.g. available > resources & allocation, dependencies ...) . > > OTH, scheduling is about (planning | estimating) the tasks to do at a > specific time (date) ... I think there's something like this in the > wiki ... isn't it ? Or am I missing something ? > > > In classic earned value, a WBS is a hiararchical description of all > tasks, and usually those tasks all have estimated costs. Then there are > the start/finish dependencies. Then one can have available resources > and construct a plan for what gets done when. ok > With actual cost data, > one can compute Cost Performance Factor. So this is all related, but I > think one can set up to express a WBS and task estimates, and even > compute earned value and CPF with no scheduling. And none of this will > make sceheduling harder. > I mostly agree, even when there might be some special cases ... but anyway ... «let the child start walking first, and then, be concerned about the reason why he's been falling » -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Here comes the Sun ... turu ruru. It's Oracle's ! - http://feedproxy.google.com/~r/simelo-es/~3/EMxV1KHhl60/here-comes-sun-turu-ruru-its-oracles.html --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
