% complete of a task moving back to before today's date

[Pinkman Tintwhistle]

Hi guys, i'm running a complex project where tasks are tending to be
done out of order (as most coding tasks tend to) so instead of doing
tasks in order a-b-c they're doing 50% of a then 50% of e then 75% of
c then finishing off a - and so on.

what i'm keen for the mpp to do is take the completed section of the
task on the gantt chart and put that before the progress line
(currently set to display the current date) and leave the remaining
chunk of work where it should be in the gantt chart - thus more
accurately reflecting the end date as it's removing work already done
from the end-date calculation.

At the moment, it's keeping the entire task bar there in the gantt
chart even though 80% of a task might be complete - and calculating
the start and finish dates as though the task hasn't even been
started.

thanks!

 

[Steve House [Project MVP]]

In the Tools/Options menu, calculation tab, turn on the checkbox "Move end
of completed portions back to status date."

 

[Pinkman Tintwhistle]

yeah i've done that - but it's not moving the completed part of the
task - it just sits there in the flow of the project. Do i need to
manually prompt it to actually apply the setting?

 

[Trevor Rabey]

If they are doing part of Tasks out of order, without regard for the
predecessor links, then they can't really be valid links.
Perhaps you need more Tasks to define what is actually being done.
Otherwise you have a plan with no one working to it, so you may as well not
have a plan.

Suggest don't bother with Progress Lines.
Too much zig-zag, not enough meaning.
Preferable, I think, is a straight, vertical Status Date Line in the
Tracking Gantt View.
I would keep the Tracking Gantt View, which does or should include the
Tracking Table, as original as possible except for the addition of the
Status Date line, a straight, vertical line.

You can select each Task and provide an Actual Start, then Actual Duration.
If this does not come up to the Status Date, ie the Task started sometime in
the past of the Status Date and then went on for a while and then stopped
short of the Status Date, you can use the Re-schedule (Remaining) Work
button on the Tracking Toolbar. The remainder of the Task will be pushed to
after the Status Date. Consider revising the Remaining Duration at this
point.

If you provide the Actual Start Date and the Task has been in progress ever
since, ie up to the Status Date, you can use the Update As Scheduled button
on the Tracking Toolbar.

If the Task has finished, provide both Actual Start and Actual Finish Dates.

Do not log completion in the future of the Status Date. eg, if a 10 day Task
started 2 days ago (ie 2 days before the Status Date) it cannot possibly
have more than 2 days actual duration, even if someone says it is "50%
complete".
Do not type anything in the % Complete field, ever. Always allow it to be
calculated by MSP from the other data you provide (AS, AF, AD, RD). Do not
forget that it is % Complete of Duration, not lines of code.

 

[Gérard Ducouret]

Hello,
You have to set this parameter *before* entering any tracking data on the
task.
Gérard Ducouret

 

[Pinkman Tintwhistle]

Thanks very much for this. I do enter some info into the % complete
field as it's as natural for people to talk in terms of % complete as
it is '3 days out of a 5 day task'. I do input days into the Actual
Work field to calculate the % complete too but don't see any problem
with using either (am i wrong here?)

My project also has plain old 'start' and 'finish' dates calculated by
project - and the number of days each task takes is set in the 'work'
field. Each of the tasks are then linked successively to give an
overall duration of a resource's workload.

Now, if someone works on tasks out of sequence, as project manager, i
don't want to end up spending my whole time managing the mpp rather
than the project - shunting tasks around to reflect the order my mpp
says they 'should' have been done in. Rather, i'd prefer to just mark
up a task that's reported as, say, 50% complete, as being 50% complete
- and having project shunt the complete part of the task in the gantt
chart to before the status line and just linking the remining 50% back
into the flow of tasks (by linking the remainding work with it's
predecessor and successor). This will give me the important view of
when a guy will finish all his tasks.

Does that make sense? Is this doable with the current way i'm
inputting data - and do you see any drawbacks with doing things this
way?

thanks!

 

[Pinkman Tintwhistle]

so if i want project to do this, i have to reenter all the data into a
fresh mpp - i can't get project to do this after i've hammered in all
4000 lines of tasks?!?

 

[Steve House [Project MVP]]

FYI - the number of days each task takes is NOT the same as Work except
under very specific circumstances. I have 3 resources working together 8
hours a day for three days. The task takes 3 days to complete, 24 hours,
but the Work is 9 man-days or 72 man-hours.

 

[Steve House [Project MVP]]

No, but you do have to turn on the "move completed work..." setting before
posting in actual performance.

--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

so if i want project to do this, i have to reenter all the data into a
fresh mpp - i can't get project to do this after i've hammered in all
4000 lines of tasks?!?

Hello,
You have to set this parameter *before* entering any tracking data on the
task.
Gérard Ducouret

yeah i've done that - but it's not moving the completed part of the
task - it just sits there in the flow of the project. Do i need to
manually prompt it to actually apply the setting?

On Wed, 10 May 2006 07:09:55 -0400, "Steve House [Project MVP]"

In the Tools/Options menu, calculation tab, turn on the checkbox "Move end
of completed portions back to status date."

 

[Trevor Rabey]

If you know that a 5 day Task has 3 days of actual duration (as at the
Status Date), why not just use that hard data (ie facts). Why do the mental
calculation of 3/5 = 60% when MSP will calculate that for you from the
facts? Doing mental calculations seems to me to be a waste of $1000 worth of
software.

Also, in my experience, many progress tracking problems stem from people
getting confused about the % of the Task that has been achieved and the % of
the Duration that has elapsed.
People tend to report the % of the Task and this gets put into the %
Complete column even though they are completely different, % Complete being
about Duration.

Say the Task is 1000 lines of code in 5 Days, and at the end of Day 3 you
expect to see 666 lines but you only see 333 (or whatever).
% Complete (duration) is 60%
% of Task is 30%

Also:
% Work and % Cost are both in there as quasi-independent quantities.

If you put 30% into the % Complete column (which is wrong but very "natural"
and happens all the time) you will be telling a very strange story about
progress.
You would mark it as 1.5 actual days of progress (contrary to a fact) and
move the remaining 3.5 days to the right of the Status Date as Remaining
Duration.

But actual observed production (ie a fact) is half of your estimate. This
Task duration should have been 10 days, not 5. So if 3 days are gone, RD
should be re-estimated at 7 days. If you don't do this you will never be
getting the benefit of using observed facts for forward projections, then
the Tasks will always take longer than the estimate and the projects will
always be late. Of course, it can go the other way as well, but usually not.

It is useful to maintain a clear distinction between duration and work, and
the easiest way is to use different units, Days for duration and Hours for
work.
Where you use the phrase "overall duration of a resource's workload", I
think I know what you think you mean, but it is about as ambiguous as it can
get. Duration and Work are only ever very loosely connected if at all.

When the project is modeled in the first place it is very important (if you
don't like headaches) to make it as accurate a model as possible.
Defects/flaws in the model (eg Tasks not chopped up enough) will always
surface as problems in progress tracking such as you are experiencing.

From a Project Management point of view, out-of-sequence work is a strong
signal that the plan is not being worked to because the model is wrong, or
because there is no discipline in the execution of the plan (maybe no one
read it), both pretty serious.

But from the point of view of just getting MSP to show it and re-schedule,
no problem. MSP will do that.

 

[Trevor Rabey]

Whoops!

Please apply appropriate correction to my example arithmetic mistake about
666, 333, 60%, 30% etc.