Dynamic Tasks

[jnickel]

Hi,

I like what is happening with the Project Management - I think it is on the right track!

However, I have two questions/concerns:

1) There needs to be not just a man-hours duration, but also a time-frame duration - one is the estimate time of how long the work will take, the other is over what period of time will those hours will be worked: For example you might have a task that will take 12 hours, but will take 1 week to complete as there are other things to do so only a few hours will be put in each day.

Can this already be accomplished?

2) When I played with the demo site, I couldn't get a task that was dependant on another task to automatically slide forward when the first tasks time duration was edited. Also, it wouldn't seem to accept any changes to the 2nd tasks time duration - I would save, but it wouldn't keep my changes.

Just one other thing I noticed is that the start and end dates for a task have different date formats: one is month/day/year, the other is day/month/year.

Lastly,

I understand how the current dynamic tasks work. My suggestion that I think would be more useful is this:

Make another checkbox that allows the child to be dynamic and not the parent. When it goes to figure out it's start date, it goes back to it's parent - if the parent is also a dynamic child, then it goes back till it finds a hard coded start date and uses the elapsed time (from my item 1 above) to calculate each tasks start date. This is not true linking, but would allow a child to change duration and have all other future items that depend on it to slide forward. You also wouldn't enter a end date for the project, instead that would be calculated and could slide.

IE a static start date for the first task and have all other tasks in the project be dynamic so that a shift/move in one will automatically shift/move all the others?

If I was programming it, I would leave the interface the same (except for the addition of the elapsed time field beside the estimated hours), and just add a configuration checkbox for the project that reads: "Duration based time tracking?" If this was checked, then the project would function as described above....otherwise it would work the way you already have it.


If anyone has time to reply I would appreciate it!

Thanks,

Jim Nickel
jim@lfchosting.com

[dcordes]

#1)

The start and end dates for a task handle this well. You might have a start and end dates 7 days apart, but the actual task duration might only be 2 hours.

#2) Again, the start and end dates are what should push out the dependant tasks, not the duration.

The date formats and those duration buttons do seem a little buggy.

[jnickel]

#1) That doesn't work if you don't have start and end dates for a task. In fact, that is the whole point. I don't want to setup each task with a start and end date. I just want to specify the number of man hours and the period of time those hours will occur.

If I do it the way you suggest, and I end up changing the end date for a task in the middle (extending it for example), then I must go to all the other tasks and adjust their start and end dates - this could take quite some time if you had a lot of tasks in a big project. This is the problem I already have.


2) Again, I disagree - like I said, I don't want to have to set start and end dates for each task. Just a start date for the project and everything else is calculated from the duration.

Jim

[kclawson]

If I understand correctly, we are talking about feature request 900036 - Propagate date changes to dependent tasks on the SourceForge pages (http://sourceforge.net/tracker/index.php?func=detail&aid=900036&group_id=21656&at id=372486)

While I really love the program and design, I think this one feature request would make the system much more usable for projects of medium to large size and complexity. (I would offer my service to help if I know how to write good code.)

Has there been a decision on this request? Is there any ETA?

Kurtis

[jnickel]

Yup...I would say that I agree with that. I would hope that it was done using the duration method I was talking about instead of just by dates.

Jim

[ajdonnison]

I would hope that it was done using the duration method I was talking about instead of just by dates.


Duration should be the default, but you also need to be able to fix dates for other items. E.g. you have a project that has an external input that is a set date (perhaps a contractor is supplying a major piece of equipment). You need to set up for the arrival of the equipment and then you can use the equipment after it has arrived. All the before and after stuff can be juggled around, but the external piece must be at a fixed time as you don't control the date. So you need a combination.

While all of this is possible it is important that it gets coded such that we don't have an n*n performance curve. Otherwise large projects would become impossible to manage.

And yes, I agree that we need this fix, and yes, it is something that will be fixed. Please don't ask me when.

[jnickel]

Excellent! I agree with this totally.

I would ask when, but you told me not to....so I wont.... :)

Jim

[vulzan]

I work for Thomson - Prometric and am trying to be an advocate for this product. The problem is, this product doesn't work like MS Project (whihc has gone through hours and hours of user testing and feedback). Users (thousands and thousands) have dictated that they do NOT want to have to keep adjusting each tasks start and end dates simply because one of the tasks dates have changed. I think, from what I cna tell from the prior posting is that you agree. I'm glad. The problem is in the comment of not to ask when this feature will be addressed. It seems ot me to be the core of using a task based project scheduling system. It must be easy to use and basically map to exsiting user processes and expectations. We want MS Project, but better (like dotproject)... but we want this feature. From my directors perspective, there are two things that make or break this product for our companies needs:

1. The ability to import from MS Project files and possibly export to make using the product easier.

2. The problem discussed in this thread where tasks are not automatically being bumped out to an appropriate date based on the number of days the task will take and the end date of its parent dependency.

I think it is a fair question to ask when this feature (not the first one but the second one) will be addressed. Your roadmap should address when this will be available.

Of course this is just my opinion, but its hard to support the product if we dont even have a clue when a feature will be implemented. From our persepective it is dangerous to begin using this product never knowing when a feature will become available.

What are your comments? Sorry I seem so harsh, but I feel I have a valid consumer perspective.

[ajdonnison]

I thank you for your honesty. There are always competing priorities in an open source project, and this is but one of them. The beauty of open source is that you have the source, and you can make changes yourself if you have a requirement that you need right now. Similarly you can hire someone to do the same if you are not capable yourself. You could even sponsor the development of a feature. There are endless options. Each of these is within your grasp and probably for far less than an MS Project license fee. Any code you contribute would normally be incorporated into the next release, so you have no on-going support issues - it becomes supported by the core team.

If I may say, supporting an open source project goes well beyond the mere use of it. Unlike proprietary models you have the power to influence the development, or even contribute to the development, and still have a supported product at the end of it. This is the difference and a big "selling point" to management. When you see the fastest development of dotProject it is usually because a company wants a feature and is paying one of their employees to work on it. They understand that once completed the code is incorporated into the base product, so they don't have to keep paying the employee to support it. It is a very clear economic benefit.

The development of this feature will happen, and the roadmap will at some stage be updated. I cannot give you a time and date right now as the developers come from a dozen different timezones around the globe and scheduling can be very difficult to get them all together to discuss timelines. Some of the developers are full time for a short period but many are part time. This is not to excuse anything, merely to state the situation.

[vulzan]

Thank you for professionally responding to my post. I partly agree and partly disagree, but that doesn't change how this project is managed, so its no good going further. However, I appreciate your suggestions. The bottom line is I fear taking this point back to my director and having to explain to him that there is no date for this feature. That will most likely shut me and this project down as an alternative to MS Project. As you know, its very hard to get people to change from what they are used to. If the new suggested tool maps to exsiting processes and procedures and possibly even expectations, to sell the product becomes so much easier.

Anyway, I'm blathering again. Thanks for your repsonse.

[penguinparty]

I think that this is the wrong approach.

Our company could really use this feature as well!

Rather then giving up on the release schedule for this feature, I would ask how we could sponsor the development of this feature? What would it take to get it put into the base code of the project?

How long would this take? If we sponsor a feature can we get a time line on delivery?

Would your company Vulzan join us in sponsoring this feature?

[jnickel]

Yes,

I also would be interested in providing sponsorship if we could get a timeframe.

Jim

[ajdonnison]

If you would like to sponsor this, contact one of the people in the Web Links/Commercial Support section of this web page, or me privately at ajdonnison at users dot sourceforge dot net. All of those listed in Commercial Support are core dotProject developers and will give you a quote and a timeframe, and the code will go back into the base product (unless it is truly esoteric).

[hnm]

Hi all together, this feature would be of our interest, too. So probably we would agree in taking part in a sponsoring for this feature as well. But we don't have any idea about the details of such an agreement ...

[ajdonnison]

This is getting a bit tricky. Normally we would simply get you to contract one of the developers, however that works on a one-on-one basis. Here we have a consortium wanting to develop. What about I have a good look at the proposal, and come up with a timeframe, then see what developers have the time on their hands to do the work, and at what cost? Then I can publish the timeframe and total cost and the potential developers can decide how important it is to them and therefore how much of the total they will donate. (Its about this time I am thinking we should put this on one of the bidding sites like OpenSourceExperts.com so we can do it properly.)

[cyberhorse]

* Sorry about the off-topic post, but the site OpenSourceExperts.com shows up with the Fedora Core testing page of Apache ... :)

[ajdonnison]

Hmmm, I get their normal front page, no matter - they are just one site that I am aware of, and not the best. I can't remember the other site but there was a brilliant one that hosted transactions between potential developers and supporters, you could put up a proposal and then let sponsors promise the money, once the bid was covered and the code done, the sponsors would then be charged the amount, the developer gets paid and the site takes a handling fee. The sponsors only cough up the money when the code was delivered, so there was no possibility of rorting. If anyone can remember the site details I'd be grateful as I need to put it in my bookmarks.