Problem with dates/durations on a plan containing imported data

[Peter Rooney]

I have a problem with a large plan I'm working on.

It contains task data that has been copied in from other plans and I am
finding a lot of summary times that DON'T equal the sum of the tasks that
they're supposed to be summarising - they show fractional decimal numbers
much higher than they should be - I don't have ANY fractional durations -
they are all be whole numbers of days. I read that it's something to do with
the way in which Project 98 stores data (I'm using 2000 9.0.2000.0224), and
as a lot of the data that was fed into my plan historically may have come
from Project 98 users, i suspect that this may be the cause of the problem.

I don't suppose that there's a quick and easy way to correct this, is there?

Also, is there a way to format the duration and work columns so that all
entries show the same number of decimal places?


Yours hopefully

Pete


Start

 

[Steve House [MVP]]

It's hard to say what the exact cause is without more information but
realize that the duration of a summary task does not, in fact, always equal
the arithmetic sum of the durations of its subtasks so your results may or
may not indicate a problem. A summary's duration extends from when the
earliest starting subtask begins until the latest finishing subtask ends.
If there are gaps for lag time or leveling delays where some tasks start
later than they otherwise might, if tasks are split in progress, or if there
is overlap where several tasks are going on at the same time, the true
duration of the summary can be very different from the sum of the subtask
durations.

Here's a simple example - we have a summary task with 2 1-day subtasks.
Sub1 starts Monday at 8am and finishes at 5pm. Sub2 is linked FS from 1 but
with a lead time of 50%. Sub2 starts Mon at 1pm and finishes Tue at 12:00
noon. Both subs are 1 day and their sum is 2 days, but the duration of the
summary task is 1.5 days - Mon 8am to Tue 12 noon.

Or ... as before but Sub2 is assigned to a resource who has Tue and Wed off.
Now even though the total of the subtasks is still 2 days, Sub2 doesn't
finish until Thur 12 noon. The summary duration becomes 3.5 days for those
same 2 1-day tasks.

 

[John]

I have a problem with a large plan I'm working on.

It contains task data that has been copied in from other plans and I am
finding a lot of summary times that DON'T equal the sum of the tasks that
they're supposed to be summarising - they show fractional decimal numbers
much higher than they should be - I don't have ANY fractional durations -
they are all be whole numbers of days. I read that it's something to do with
the way in which Project 98 stores data (I'm using 2000 9.0.2000.0224), and
as a lot of the data that was fed into my plan historically may have come
from Project 98 users, i suspect that this may be the cause of the problem.

I don't suppose that there's a quick and easy way to correct this, is there?

Also, is there a way to format the duration and work columns so that all
entries show the same number of decimal places?


Yours hopefully

Pete

Pete,
I'm not aware of any issues that would cause the problem you are seeing,
particularly with Summary Lines since Project will calculate the values
based on the subtasks. However if there is some residual corruption as
the result of all the cutting and pasting, you might try clearing the
corruption. For some methods, go to the MVP website at:
http://www.mvps.org/project/faqs.htm
and look at FAQ 43 - File boat? - Might be corruption.

If the above doesn't help, let us know. We'll come up with more ideas.

The number of decimal places for Duration and Work cannot be formatted
to be consistent. There are three choices, 1) live with it, 2) Make sure
all tasks are full days and all work is full hours, or 3) replicate the
normal Duration and Work fields with custom columns where the formatting
can be controlled.

Hope this helps.
John
Project MVP

 

[Mike Glen]

Hi Peter,

Welcome to this Microsoft Project newsgroup

On another tack, decimal durations often spring from a mis-match between
workin hours set in your calendars and those imposed by settings in
Tools/Options.../Calendar tab. You might like to see FAQ Item: 5. Default
Working Hours

FAQs, companion products and other useful Project information can be seen at
this web address: http://www.mvps.org/project/

Hope this helps - please let us know how you get on

Mike Glen
Project MVP

 

[Peter Rooney]

Thanks for all your help, chaps.
I've done some more investigation into Resource calendars which has gone
some way toward explaining some of my problems, but, to give you an example,
I still have a summary duration for four tasks which start between 18/10/04
and 26/11/04, showing a total of 35 days, which I can't for the life of me
understand, as if you add up all the working days from my calendar (Mondays
to Fridays), this comes to 30 days, and if you add up ALL the days, this
comes to 40!

Start
Finish
Task 1 Mon
18/10/04 Wed 03/11/04
shows a duration of 13 days which is correct
Task 2 Thu 11/11/04
Wed 17/11/04
shows a duration of 7 days which isn't (it should be 5 by my reckoning -
Thu, Fri,
Mon, Tue & Wed)
Task 3 Fri
19/11/04 Tue 23/11/04
shows a duration of 5 days which it isn't (it should be 3, I think, Fri, Mon
& Tue)

Can ANYONE tell me what's going on - and explain properly where the decimal
summary durations come from if my tasks are all measured in whole numbers of
days?

Incidentally, I tried opening the file, saving it immediately and reclosing
it.
I also tried saving it as a database file then saving it back. Apart from
giving me a 10% saving on my file size, neither operation solved any of my
problems.

Could repeated application errors occurring whenever I open the plan be
indicative of a corruption which could be causing my other problems too?

Yours in cheerful desperation

Pete

 

[Steve House [MVP]]

To track down the decimals, first go to the Tools Options menu, View tab and
select a date format that includes the time as well as the date. The start
and finish fields are really date/time fields and while your tasks are
presently showing whole days, something showing a start of today 14/01/05
might really be 14/01/05 10:00 or 14/01/05 14:00 or some such. If the
subtasks don't start and end exactly at the beginning and ending of your
workday, summaries can end up with fractional days in the durations.

You saif you looked at the resource calendars but have you looked at the
Project Calendar to see what the master hours of work are? For instance,
your Task 2 should be 5 days duration IF your Project Calendar is the
default Standard Calendar but if the Project Calendar has been modified to
show, say, work going on 0800-1700 7-days a week then those dates will give
you 7 days duration, not 5.

Also check the Tools Options Calendar page and see what the hours per day
and hours per week setting say. If it's 8 hour per day and you enter a
1-day duration task, then go and change it to 7 hours per day, the next time
you look at your task list you'll find the 1 day tasks have become 1.12 day
tasks even though their start and end dates and times haven't changed at
all.

 

[Peter Rooney]

Steve.

You are a hero!

This is EXACTLY what was happening.

Although I changed the default working times to be 09:00-13:00 and
14:00-17:30, and made sure that my standard calendar matched this, any dates
that had been entered prior to my changing the defaults kept their original
start and end times. As these periods of time didn't match the default times,
I had decimal days, which I couldn't see until I changed the display date
format and amended the times!

Mind you, that's a L-O-T of tasks to change, especially as you can't do a
search and replace on the time element of a date - unless there's some way to
do it in VBA..?

In any case, it's Friday afternoon, and now I don't have any worries about
going to our exec next week and having him ask me "why is Bob working 1.05 of
a day when that task starts and ends on the same day?" I just got my weekend
back!

You're a life saver - thank you VERY much indeed! MVP payrises all round!

Pete

 

[Steve House [MVP]]

Hang on - be careful and ask yourself if those task start and end times
really should changed? Consider - my calendar says we work an 8 hour day
and I look at a task that says we must produce 80 fids. We said "Well, Fred
Fidmaker creates 10 fids an hour so that task will have a duration of 8
hours or 1 day" and we enter it as "Make 80 fids, duration 1 day, resource
Fred 100%." Now we look at our calendars and notice our settings aren't
right, we don't work 0800-1200 and 12:00-17:00 with an 8 hour day. We
really work 09:00-13:00 and 14:00-17:30 for a 7 1/2 hour work day. Does
that realization mean that Fred now does 11 fids an hour? Nope, he makes
fids at the rate he makes fids, regardless of the length of our workday.
What it means is that if he starts making fids when he comes in to work on
Monday, when it comes time to go home he'll still have a few fids to go to
finish the 80 that the project requires and he'll have to continue on them
Tuesday morning for a little while. The task duration will no longer be
exactly 1 workday, it will, in fact, require 1 day plus 30 minutes of a
second day to get them all finished. It's still 8 work hours and the
duration actually hasn't changed at all, but that now translates to 1.05 or
so days, starting Monday 09:00 and ending Tuesday 09:30.

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

 

[Peter Rooney]

Steve,

Although this won't apply in this case as we work on a "stay until it's done
basis", I appreciate what you're saying. We don't do piecework here, as we're
an I.T. outfit, so "1 day"s work could be 1/2 a day or a full day. What I'm
really trying to do is make sure that my dates and durations match those of
the project plans that I've imported from other areas of the business - we
all work on the same basis, so there's no problem.
Incidentally, I still have a few funnies here: STILL wondering what the rule
is in terms of what you're supposed to overtype to get your
Start/End/Durations to be what you want. It doesn't seem to be the case that
if you fix your Start Date and enter your Duration that you always get your
End Date worked out, or if you enter your Start and End Dates, that you
always get your Duration calculated. It feels a bit like working with Excel
and working out the answers on a calculator and typing the answers in, as
against entering a formula!

Nevertheless, I'm sure it'll sort itself out. At least I know how to get rid
of the wretched decimals, which I couldn't before your answer, so once again,
thanks!

It's 16:04 and time to go home for the weekend, so if you answer this and I
don't reply, please don't be offended! Brits on the starting blocks, and all
that!

Cheers

Pete

 

[Steve House [MVP]]

Actually you normally shouldn't be entering or overtyping the start OR the
finish dates directly for your tasks at all. Except in certain
circumstances the task start and finish should be calculated by Project, the
start being determined by the project start date, the schedule of the tasks
that must precede this one by virtue of the logic of the process itself, and
the availability of the resources with the required skills to do the work.
The finish date of the task should be calculated, again by Project, not you,
from the calculated task start plus the estimated length of time, the
duration, that you expect your resources will require to complete the work.
So in terms of the fields where you should be entering/editing data, that
would mean you supply the task name, the duration, the predecessor link(s),
and the resource assignment but NO dates at all (other than the single entry
for the Project Start Date). As I view it, the fundamental reason to bother
with using Project in the first place is as a tool to figure out what the
task schedule dates should be in an optimized plan, not just to illustrate
schedule dates you have already worked out by some other method.

If you do fix a start date, a Start No Earlier Than constraint is applied to
the task and it will never be scheduled starting any earlier than that date
in your project, even if it otherwise could or should happen earlier. If
you enter a finish date, you'll get a Finish No Earlier Than constraint and
it will be placed so that is the earliest it would ever be allowed to
finish. A task can have only one governing constraint so if you manually
enter BOTH fields, the end result will depend on the order you edit them,
the last one entered determining the constraint you end up with. Whatever
the end result, though, it's probably going to be wrong because constraints
have a specific meaning and purpose and anything other than ASAP would be
inappropriate for most tasks.

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

 

[Peter Rooney]

Steve,

Actually you normally shouldn't be entering or overtyping the start OR the
finish dates directly for your tasks at all. Except in certain
circumstances the task start and finish should be calculated by Project, the
start being determined by the project start date, the schedule of the tasks
that must precede this one by virtue of the logic of the process itself, and
the availability of the resources with the required skills to do the work.
The finish date of the task should be calculated, again by Project, not you,
from the calculated task start plus the estimated length of time, the
duration, that you expect your resources will require to complete the work.
So in terms of the fields where you should be entering/editing data, that
would mean you supply the task name, the duration, the predecessor link(s),
and the resource assignment but NO dates at all (other than the single entry
for the Project Start Date). As I view it, the fundamental reason to bother
with using Project in the first place is as a tool to figure out what the
task schedule dates should be in an optimized plan, not just to illustrate
schedule dates you have already worked out by some other method.

If you do fix a start date, a Start No Earlier Than constraint is applied to
the task and it will never be scheduled starting any earlier than that date
in your project, even if it otherwise could or should happen earlier. If
you enter a finish date, you'll get a Finish No Earlier Than constraint and
it will be placed so that is the earliest it would ever be allowed to
finish. A task can have only one governing constraint so if you manually
enter BOTH fields, the end result will depend on the order you edit them,
the last one entered determining the constraint you end up with. Whatever
the end result, though, it's probably going to be wrong because constraints
have a specific meaning and purpose and anything other than ASAP would be
inappropriate for most tasks.

 

[Peter Rooney]

Steve,

The reason why I've been typing i my own start dates is that the data that
I've been importing from external sources contains tasks for resources in
other parts of the business, as well as my area - they see my area as an
external resource.
However, if I was to import everything, my plan would be huge, as my area's
activities only accout for about 15-10% of the tasks as a whole.
So, I've eliminated everything from my plan that isn't an activity for one
of my teams. This means that, for example, my team might have a task starting
on the 1st and ending on the 5th, then, somebody from another team might have
a task starting on the 6th and ending on the 10th and my team's next task
might start on the 11th.
I would need a "Start no earlier than" constriction on this task, as we
can't start it until the previous task (which isn't on my plan as it isn't my
team who carries it out)
is complete. If I had an ASAP on it, it would start on the 6th, which would
be incorrect.

I do agree with you that I shouldn't be changing finish dates, though!

Anyway, once again, thanks for your help - at least now I understand why the
problem's occurred. I wish I knew enough to be an MVP!

Cheers

Pete

 

[Steve House [MVP]]

I have to disagree with your logic. You cite your team having a task
running the 1st thru the 5th, another team has a task from the 6th thru the
10th, and then your team again picks up with a task running from the 11th
until sometime. But for a plan to be a useful model, there needs to be
mechanisms in place that will tell you that if that outside team finishes
their task on the 8th instead of the 10th, you can go ahead and start the
task for the 11th 2 days earlier, on the 9th. Or conversely, if your team
runs late and isn't finished by the 5th as they are supposed to be, there
needs to be a mechanism to inform team 2 that they need to delay their task
until your guys are ready to hand it off to them. Without links, those
mechanisms don't exist. Not only that, if you have set the start date for
task 3 to the 11th by entering that date thus setting it as a SNET
constraint, not only is there no way to let you know you can start it
earlier than originally expected, even if you put links in place the
existence of the constraint is an instruction to Project that under no
circumstances can that task *ever* start earlier than the 11th and it will
*never* move it earlier until you manualy edit the file.

Your Excel analogy is right on the money - what you are doing is akin to
building a spreadsheet by entering in all the data but then instead of using
formulas for the calculations, you get out your paper and pencil and do all
the calculations by hand, typing the results into the cells where you should
be using formulas. Yes, you can get the same appearing hard-copy output
with that method as you would with a properly done worksheet. But the
resulting product is useless for what-if kinds of modeling and decision
making - you've taken a marvelous number-crunching tool and turned it into
nothing more than a glorified typewriter. Using Project as you are, because
you have disabled a good portion of its calculation ability, it is no longer
a tool to create and manage project plans but now is simply a typewriter to
print kewl Gantt charts. Pretty cosmetics, but not much of a management
tool.


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

 

[Peter Rooney]

Steve,

I consider myself well and truly rapped on the knuckes!
I know what you're saying is correct, but sadly, we don't have centrally
held project plans that more that one person can access or amed (I assume,
from reading other posts on here that this is what "Project Server" is
for..?) - otherwise, projects for more than one team would be a doddle (I
never know what colloquailisms to use on here, but I'm guessing you're not
from the UK, in which case, a "doddle" is something easy).

It gets more complicated in that some of "my" resource is actually managed
by an external business project manager, so, "my" resource reports to him and
he reports progress to me (even though "my" resource sits two desks away..!).

The BPM would then tell me if a task was started early or late, and I'd
amend the start date accordingly.

It's not a very good way of using Project, I grant you, (I expect you'd be
spinning in your grave, if you had one) but thankfully this sub team only
form a small part of the overall work carried out my my department (20
resources, divided up into 4 teams), most of which is carried out between
them all, with no external dependencies.

Once again thanks for your help. You'd probably be scared to death if you
knew who I worked for, with planning like this!

Cheers

Pete