Critical Path Analysis

[daniel smatt]

Hi Guys

I need an answer to a Question that someone asked me at an interview

I have a task that has 100days duration. when i filter for tasks on
the
Critical path this particular task shows up on the critical path.
The
reason why the task is 100days is because it's some thing that's
repetitive on a weekly basis and i don't want to break teh Task into
Sub Task
How can i ensure that this Task is not reflected as been critical when
i filter on activities on the critical
path.

 

[Rob Schneider]

If the task is on the critical path, then when you filter to see tasks
that are on the critical path, Project will display that task. To not
show that task, you need to make your filter (edit it) to be a little
more complex to say something like "show all tasks on critical path
except for []" and [] would be whatever it is you use as a test to
detect it. Lots of ways to do that. First would be use use on of those
custom flag fields, and "flag" it. Remove flagged fields from the filter.

--rms

 

[Jim Aksel]

If the task is repetitive, it is more than likely "Level of Effort" such as
staff meetings, etc. In cases like these, we do not put Level of Effort into
a schedule, we hold a separate schedule with LOE activity. A task on the
critical path is still on the path, even if filtered out. By definition,
critical path is determined by 0 total slack.

If the task is not LOE, and still runs 100 days... shame on them. Best
scheduling practices dictate the length of a task should not be longer than
about twice the reporting period. So, if you take progress every week, your
maximum task length would be about 10 business days.

Further, if the task is 100 days and actually consists of several smaller
components, it is best to break it down. You have much more accuracy in your
schedule by saying a 5 day task is 20% complete than estimating a 100 day
task to be 1% complete (they are both 8 hours of success).

A 100 day task is obscuring other tasks that really should be monitored.
That would have been my interview answer.
--
If this post was helpful, please consider rating it.

Jim Aksel, MVP

Check out my blog for more information:
http://www.msprojectblog.com

 

[Hardip]

Jim makes a valid point.

Both the PMI and OGC make recommendations on the minimum duration of a work
/ prudct breakdown structure. From memory the PMI suggest no more than 100
hrs for a work packages or WBS element. Whilst I don't subscribe to this it
makes sense.

I'd recommend that the organisation has a standard for scheduling that
prevents a 100 day task. Its not an MS Project issue, rather how people are
project managing and breaking apart scopes / products.

And like Rob says I make sure all my repetitive tasks are off the critical
path and I either have a separate schedule or simply include them at the
moment of the schedule as unconnected tasks such as reoccurring reviews for
executive, managers and support staff.

Cheers, H

 

[Projectability]

Jim & Hardip make good points - whilst the OGC/PMI suggestions provide some
guidance can I offer a truism.

"If you cannot measure something you cannot hope to control it"

A 100 day task is so large that accurately gauging progress on it can be
subjective and open to abuse.

--
Dominic Moss

Projectability - Helping People achieve more with Microsoft Project

Check the Downloads section on our Website for useful documents on both
Project Management and Microsoft Project

www.projectability.co.uk

Why not subscribe to our monthly newsletter for hints tips and views

http://visitor.constantcontact.com/manage/optin/ea?v=001WVdpo956d6lHqIISFtfgVw==

 

[gugliupj]

While everyone gave good answers... after doing this for more years than I
want to admit, and having been asked this question several times; because
some Cost Analyst has to lower the amount of LOE hrs and decided this had to
be a discreet task... shorten the task by 1 day and it will not show up on
the critical path.