Task Hopping

[Sinister]

I have a two software developers that want to hammer out a schedule for a
design project they are working on. We have gone through and identified 31
tasks. Each is Fixed work. We have assigned both of them on each task.
Developer 1 puts 75% on every task and Developer 2 puts 50% on every task.

The problem begins when we try to identify the dependencies. According to
them there are none. Their rational is that they go back and forth between
tasks all the time. So, they all start at the same time. Obviously this wont
due considering on the first day Developer 1 has to work 88 hours while
Developer 2 works 72.

So, how do you schedule tasks that a resources bounces around on on any
given day?

Thank you in advance.

 

[Jack Dahlgren]

Consider modeling at a higher level. In other words bundle a number of tasks
into a larger task and use some other method to track how they are doing on
the 31 individual items.
Or have all tasks the length of the project and have the resources assigned
at an appropriate proportional rate to each (ie: 75% / 31).
Or have them tell you which ones are highest priority and use leveling to
schedule them.

There are a number of ways to do this. You need to decide which one gives
you the information you need to manage the project. Do you really care about
each of the 31 tasks? How do you know when they are through? How do you know
if you are behind? I'd also say some amount of hoping around is reasonable,
but if they hop all the time they are probably not as effective as if they
had some organized way to handle the work.

-Jack

 

[Steve House]

Taks dependencies are not created by sequencing, they are the cause of
sequencing. In Project they describe a physical relationship between the
tasks such that the timing of the predecessor task either drives or controls
the timing of the successor task. Erecting the walls of a building before
installing the roof are a FS relationship because Mother Nature doesn't
permit us to install the roof in midair and come back later to stuff the
walls in underneath it. The time sequence in the schedule is caused by that
physical requirement. Project's links model those requirements. While your
software developers may jump back and forth between tasks, there surely are
some of those dependencies in the Project - you have to write a program
module before you can test it, for example. Think not about how they want
to sequence their work, instead approach it from the way they HAVE to
sequence their work according to the project process itself - if you
flowchart the process, diagramming the flow of materials and information
through the project from start to end, the result will be a network diagram
where each arrow represents a dependency link.

Good planning practices say that EVERY task has at least one predecessor and
one successor. IF no other activity is the task's predecessor, the start
milestone is. If no other activity is the task's successor, the finish
milestone is. There may be multiple pathways between start and finish but
every task will lie on at least one of them.

 

[davegb]

I have a two software developers that want to hammer out a schedule for a
design project they are working on. We have gone through and identified 31
tasks. Each is Fixed work. We have assigned both of them on each task.
Developer 1 puts 75% on every task and Developer 2 puts 50% on every task.

The problem begins when we try to identify the dependencies. According to
them there are none. Their rational is that they go back and forth between
tasks all the time. So, they all start at the same time. Obviously this wont
due considering on the first day Developer 1 has to work 88 hours while
Developer 2 works 72.

So, how do you schedule tasks that a resources bounces around on on any
given day?

Thank you in advance.

This is a real problem in scheduling software projects. There aren't
clear FS relationships like in construction where you can't put on the
roof until the walls are up.
What I've done in a similar situation is to estimate the time for each
"chunk" of code to be developed, and the time estimate for testing that
code. Then, set the start of test to be a the requisite amount of time
after the start of code on a task by task basis using a SS relationship
with the appropriate lag. Then set the finish of test to be a day or two
after the finish of develop via a link between the two. These do need a
fair amount of adjustment, but it's not undoable. We did it on a $40mm
development project with 250 developers and 250 testers. Worked fine.
We also put in a lot of schedule buffers to account for the inevitable
low confidence level in the original estimates. We all know that in
software development, there's going to be that occasional code/test
cycle that takes way longer than normal. We just never know which one.
Buffers placed at the end of each major module completion take care of
this.
Hope this helps in your world.