parallel tasks

I have 3 things to do that I can do in parallel, but they show up in series.
I already made a subproject, and indented the 3 tasks inside the subproject, but they stay serial.
Is there a way to declare that one task does not depend on the previous task but the one/two/three before?

I (along with others) posted a “need” for explicit dependencies. We’ve had the response that this is coming soon. So Task X can be made dependent on Task A irrespective of the relative postions of the two tasks in the schedule. I guess that’s what you’re asking for – or am I wrong?

100% correct. I need tasks B, C, D to start in parallel after task A completes, and task E to start when B, C, and D are all finished.
A = -xx-—-—-—-—-—-—-—
B = --xxx-—-—-—-—-—-—
C = —-xxxxxx-—-—-—-—-—
D = —-xx-—-—-—-—-—-—-
E = --—-—-xxx-—-—-—-—
Of course the predictive outcome of B,C,D will be the flexible startpoint of E.

@ KayakFun

I just want to check to make sure I understand the issue fully.

Tasks A, B, C, D, and E are all assigned to the same person?

If they are assigned to the same person (e.g. you) then the amount of time it will take to complete all three should be (roughly) the same whether performed in parallel or serially. If this is the case then the priority order you’ve got is just fine and should be accurately predicting the end date for the total project even if the end dates for some of the intermediate steps are not exactly what you would like to see.

I think that while you could do them in parallel, by skipping back and forth from one task to another, you will discover that it is best practice to knock them out serially (see my article on the perils of multi-tasking). In reality those tasks have an implied dependency because they all depend upon the time of the same person (in this case you).

Bruce,
Although I’m not a woman, so in principle not fit for multitasking, these tasks I gave myself are perfect for doing in parallel. My project is the face lift of my 2004 Audi A4 with a single-frame grill of newer models. I need three parts: a new hood, a new bumper and a new grill. I plan to get them second-hand, so this task involves searching the internet for 1 part, mailing someone who might have it, wait for the answer, close the deal, wait for another answer, pay, wait for the money to arrive at the seller, wait for the part to arrive. And that 3 times. In the waiting times for one part I can do the same tasks for the other part.
Your assumption is that throughput time is the same as spent time. To follow your line of thinking, I would need to cut up a conceptually simple step like “obtain part A” into microsteps. That may work for a “Modern Times” Charlie Chaplin factory worker, but higher education people can (and wish to) handle a larger abstraction level. This keeps the planning overseeable too.

To address the matter from a more general viewpoint (mine – I don’t have a car renovation project), the key here for me is that these tasks may be assigned or assignable to members of a team and Task E may really be dependendent upon all of B, C and D finishing – so the logic for explicit dependencies holds whatever your views of multi-tasking.

@ DJB – Yup. We really need to get the dependencies code tested and released. We’re working on it right now.

@ KayakFun – Ah! Now I see what you’re trying to do. I think you’ve hit on the crux of the issue which is duration is not the same as effort. There’s a “cheating option” that you can use.

Build a sub-project called “Get Parts”. Into it put four tasks

1. get hood 0-0 days
2. get bumper 0-0 days
3. get grill 0-0 days
4. get all parts 3-10 days

By putting in zero effort tasks you will remember to do them all and be able to attach notes and URLs and emails and stuff to each one individually. The effort and duration are then entirely determined by the “get all parts” task. The “Get Parts” sub-project won’t be done until all of them are done.

I know it is a bit of a hack. But it does capture the essence of what it is I think you’re trying to do. In the end I think this plan accurately reflects how you think the schedule will play out and helps you remember and organize the tasks and the information associated with those tasks.

I’m currently thinking over how the explicit dependencies features would interact with this and how duration relates to effort. I’m concerned that most users would be confused by the difference between duration and effort. Adding support for both concepts could really make the product much more complicated and harder to use.

Let me know what you think.

As I’m doing all the tasks, the cheat works to create a realistic end date. But as soon as you want to track multiple people doing differently sized tasks, you effectively planning in your head what you want the program to do. But you are going to put it in anyway so I’ll be patient.

Duration and effort
Although a week has 7 days duration, the weekend turns it into a 5 day effort. At my company we have a few people working part-time, their week’s effort is 3 or 4 days. Others have daily support tasks, or weekly team/project meetings so their effort is 5 days of only 60 or 80%. Almost nobody works 100% effort. I think pragmatic users will work around the difference between duration and effort. The simplicity of the program is one of its charms (short ramp-up time), so I would stay with duration and let the planners dilute this in their head. So 4 days effort for a 3-day part-timer is 4 / (3/5) = 20/3 = 6.666 =~ 7 days (with the weekends off already).

It is practical to be able to globally assign non-working days like bank holidays, you could even import a google calendar like “Nederlandse feestdagen” (Dutch bank holidays) in it, which lists all the collectively free days like Easter, Ascencion, the friday after Assencion, the queen’s birthday, Xmas, etc to save us some time. Whether you should be able to assign personal non-working days like personal vacation I don’t know. It makes the product more complicated so I would stick to global bank holidays only for now.

I’m inclined to go along with KayakFun on this. Do not (PLEASE) make it too much more complicated. Certainly everyone who has ever had to deal with PM issues has faced the problem of duration vs effort. Stick with duration – everybody understands it – but help people understand (white papers, blog articles, forum discussions…) that you, the user, translate, in my way of looking at it, effort (man-days) into duration (elapsed time) by factoring in such things as part-time working or holidays. As the product matures, you can have a second bite at this if experience demonstrates that you need to do so. I think that a certain other Seattle software company has confused enough users of PM software with this issue of duration vs effort!

@DJB – We’re with you on simplicity. We think it’s better to create a tool where most everything can be expressed with simple to understand building blocks and concepts so that everyone on the team can make sense of the plan. We’ve seen too many schedules that have been so worked over with dependancies and so called “advanced” features that you could not make heads or tails out of the plan. Basically complexity leads to brittle and then just broken schedules. I look forward to your feedback on the LiquidPlanner version of task-to-task dependancies.