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

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Whoops!

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


"Trevor Rabey" <trabey@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:4463e8af@xxxxxxxxxxxxxxxxxxx
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.


"Pinkman Tintwhistle" <dave@xxxxxxxx> wrote in message
news:toc662pug4duoj5uf8sjsk1a83ahda3pea@xxxxxxxxxx

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!


On Wed, 10 May 2006 19:52:37 +0800, "Trevor Rabey"
<trabey@xxxxxxxxxxxxxxxxxxxxx> wrote:

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.



"Pinkman Tintwhistle" <dave@xxxxxxxx> wrote in message
news:0m8362hrvco1q3p02pge181d5183i88u3l@xxxxxxxxxx
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!





.

Quantcast