Is this critical path correct?

[Rick Anderson]

This question is not specific to Project 2003 (same behavior in 2000 and
2007). Let's say I have a project that starts on Monday, 1/28/2008 and
consists of four 5 day tasks (task #1, task #2, task #3 and task #4). Each
task is assigned to the same person, and they are each successors of the
other. So one would expect the critical path to be task #1 for 5d, task #2
for 5d, task #3 for 5d and task #4 for 5d. If we review the critical path,
that's what it shows us.

Now, instead of working on task #1 on 1/28/08, I complete 1 day of work on
task #2. At this point, my critical path becomes task #2 -> #3 -> #4 and #1
drops off the critical path. I can't convince myself this is correct. I
still have 5d to do on that task and it's clearly part of the critical path
chain. Project says task #1 has 1d of slack, which is why it is not showing
up.

What is the best way to get around this? We often have tasks that start out
of order. I suppose we could break them up into smaller parts (the part that
started and the part that is left), or we could re-organize predecessors and
successors, but it seems like there must be some better way.

If I change task #1 to start on 1/22, it shows back up in the critical path.
That seems simple enough, but a more complex example of where task #1 has 1d
complete and task #2 has 1d complete makes this less desireable (so start
task #1 on 1/22, mark task #1 as 1d complete and mark task #2 as 2d complete
and #1 is back off the critical path and interestingly task #1 has no slack
in it).

If you play with this simple example, there is all kinds of interesting
things that happen if you change start dates and so on.

I appreciate any help. It's driving me a bit nuts.

Rick Anderson (rick dot d dot anderson at tektronix dot com)

 

[Jim Aksel]

Project is pretty literal and relys on algorithms, not judgement. So your
patyh is correctly deteremined mathmatically.

The real problem is your predecessors. If you were able to accomplish 20%
of Task 2 prior to completing Task1 then you didn't really have a 1 -->2 FS
relationship did you? This implies there are missing tasks and that Task 1
or 2 could have been further broken down.
--
If this post was helpful, please consider rating it.

Jim

Visit http://project.mvps.org/ for FAQs and more information
about Microsoft Project

 

[Rick Anderson]

Thanks for the reply, Jim.

Let's assume there are no missing tasks and that they cannot be broken down
further (I believe this is a real world assumption for our simple example).
I will agree that maybe the predecessor connection is incorrect as FS. But
what is the better way to represent this so that you get all four tasks (all
20d, or the 19d left anyway) into the critical path properly. This seems to
be the struggle.

I guess I could move the start date of task #1 every day that I work on task
#2. That seems to keep it in the critical path. But if you are working on
two tasks in parallel, this become more of a challenge. And I don't like
changing the start date of a task once it has started, because it did start
on the date in the schedule.

Maybe the best answer is to move the start date if the task hasn't started,
and if it has, move the end date. Let's take an example. All tasks are 0d
actual duration (the start condition presented above). Now complete 1d of
task #2. Task #1 is not critical path now. So adjust the start date of task
#1 by 1d. It's now back in the critical path. Now let's say I start task #1
on the next day, so I mark it 1d complete and adjust the end date by one day.
It's back in the critical path. I guess that works.

Seems like there should be some way to count the number of days of work left
to be done for the resources and show you an expected completion date. Maybe
some of the resource graphs show you that. I haven't played with those much.

 

[Dave]

Thanks for the reply, Jim.

Let's assume there are no missing tasks and that they cannot be broken down
further (I believe this is a real world assumption for our simple example).
I will agree that maybe the predecessor connection is incorrect as FS. But
what is the better way to represent this so that you get all four tasks (all
20d, or the 19d left anyway) into the critical path properly. This seems to
be the struggle.

I guess I could move the start date of task #1 every day that I work on task
#2. That seems to keep it in the critical path. But if you are working on
two tasks in parallel, this become more of a challenge. And I don't like
changing the start date of a task once it has started, because it did start
on the date in the schedule.

Maybe the best answer is to move the start date if the task hasn't started,
and if it has, move the end date. Let's take an example. All tasks are 0d
actual duration (the start condition presented above). Now complete 1d of
task #2. Task #1 is not critical path now. So adjust the start date of task
#1 by 1d. It's now back in the critical path. Now let's say I start task #1
on the next day, so I mark it 1d complete and adjust the end date by one day.
It's back in the critical path. I guess that works.

Seems like there should be some way to count the number of days of work left
to be done for the resources and show you an expected completion date. Maybe
some of the resource graphs show you that. I haven't played with those much.

The trouble is, task #1 isn't part of the critical path or at least it
is not decidable whether it is or not.

If task #1 cannot be completed before task #2 then it is on the path but
now it is being worked on before task #2 so it might not be.

Criticality is defined as the amount of slip that a task can enjoy
before it affects the end of the project. Now that your logic is not
being respected, how can the application be expected to calculate the
amount of slip that task #1 could be subjected to?

You need to get an accurate plan which models your work and your
approach to it. You can't really ask "I know my plan is wrong, but why
doesn't the application give the right results?".

Hope this helps.

 

[Rick Anderson]

I would argue my plan is not wrong. Let me ask the question another way:

I have one resource who must work on two 5d tasks. The resource can work on
the tasks in any order, including working on task #1 for a day then task #2
for a day and then back to task #1.

How should you model a relationship (i.e. - my plan like this in
MS-Project?

This is a real world situation, at least in our shop.

Thanks,
Rick

 

[Dave]

Your plan is wrong in the sense that (as I understand it anyway) that
you have linked your tasks and that implies that they have to be carried
out in that order yet you are saying they can be worked on in any order.

My model would first of all link the tasks in a way which truly modelled
the dependencies. In other words there would be a FS link from Task A
to Task B if and only if Task B could not be started until Task A was
complete (give or take small tolerances).

I would then decide how I wanted my resources to work on them (or find
out how they wanted to work on them) and model according to that.

One model would be that they worked on each of them flat out until they
were complete. So in that scenario each 5 day task would have a
duration of 5 days. Then I would level (using priority to set the order).

Another model would be that they worked on the two 5 day tasks
side-by-side with equal priority so each 5 day task took 10 days in
duration.

The plan you had was not actually a plan because your resource did not
work to it from day 1 and so it did not model what was going to take place.

I understand what you are saying about criticality because if any of the
early tasks overrun then they will cause an overrun in the overall
project, but they are not critical in that they don't have 0 slack so
you have time to take remedial action.

It is anomalous and counter-intuitive that if you level you have the
same plan for work as if you had linked them all FS yet the critical
path changes and it is a very interesting exercise to think about.