C
carey
Is there a way to expressed percent complete in decimal format such as 25.4%
complete?
complete?
B
Brian K - Project MVP
carey said:
Only if you use this VBA code to place a formatted expression of Percent
Complete into a Text field.
Sub DecPercent()
Dim t As Task
For Each t In ActiveProject.Tasks
If Not (t Is Nothing) Then
t.Text1 = Format((t.ActualDuration / t.Duration), "0.0000%")
End If
Next t
End Sub
If you want it to be fewer decimals then remove one or more of the zeros.
B
Brian K - Project MVP
Brian said:
Actually, use this code instead:
Private Sub Project_Change(ByVal pj As Project)
Dim t As Task
For Each t In ActiveProject.Tasks
If Not (t Is Nothing) Then
t.Text1 = Format((t.ActualDuration / t.Duration), "0.0000%")
End If
Next t
End Sub
it will run everytime a change is made to your project so that the Text1
field will always have the current % Complete.
And another thing: you might rethink the whole process of being so
concerned with percent complete that you need to know it down to the 2nd
and 3rd decimal place. Ask yourself what you would do differently if the
task was 3.425% complete vs. it being 3.815% complete. Unless you are
talking about a task that is years long it would not make very much
difference. And if your task is years long it should be broken down into
smaller tasks!
C
carey
Thanks Brian.
It is not so much a concern for me when a percentage is expressed in
decimals as it is the remaining duration. I have a non-resource loaded
schedule where the remaining durations are required to be expressed as whole
numbers.
However, to achieve a remaining duration whole number is virtually
impossible if the percent complete can only be expressed as a whole number.
Again, thanks alot.
BTW, I apologize for the three postings. For some reason I was getting a
page fault the first two times I posted it -- and wasn't sure if the first
two went through. I guess it did.
It is not so much a concern for me when a percentage is expressed in
decimals as it is the remaining duration. I have a non-resource loaded
schedule where the remaining durations are required to be expressed as whole
numbers.
However, to achieve a remaining duration whole number is virtually
impossible if the percent complete can only be expressed as a whole number.
Again, thanks alot.
BTW, I apologize for the three postings. For some reason I was getting a
page fault the first two times I posted it -- and wasn't sure if the first
two went through. I guess it did.
S
Steve House [Project MVP]
Expressing remaining durations as whole numbers ... just don't calculate
remainng duration by multiplying percentages. Instead simply subtract the
actual duration from the total (and remember that "% Complete" is NOT based
on work performed but rather duration, though the two are often the same
value). I have a task that is 10 days in duration. Up till now we have
worked on it for 4 days. That makes it 40% complete. The remaining duration
is 10-4 or 6 days. Easy, peasy.
remainng duration by multiplying percentages. Instead simply subtract the
actual duration from the total (and remember that "% Complete" is NOT based
on work performed but rather duration, though the two are often the same
value). I have a task that is 10 days in duration. Up till now we have
worked on it for 4 days. That makes it 40% complete. The remaining duration
is 10-4 or 6 days. Easy, peasy.
B
Brian K - Project MVP
carey said:
The same code can be used witth some modifications to express a
calculation of remaining duration but again I would ask what difference it
would make on your decision making process if the remaining duration was
25.456 days versus 25.46 days? Remaining Duration already shows down to
the 100th. Why would you need 1000th?
C
carey
Steve:
The original duration should always remain the same as originally designed
in your baseline -- unless there is a change order that requires you to
change it. However, even change orders should be expressed as a separate
activity when you are presenting a claims clase.
The primary issue here is that MSP is designed to not change the original
calculated early finish date until the activity is 100% completed. The
remaining duration should change if, lets say, a 2 day activity is 50%
complete. The remaining being 1 day should change the early finish date to
tell you if you are ahead, on, or behind your baseline schedule. But, this,
of course, depends on your data date (status date). However, in my case, the
early finish (forward pass) does not change regardless what the DD is. This
is a falacy and does not properly represent the true nature of that activity.
Regarding the remainining duration: I personally need it to be expressed as
a whole number because and since the % complete is linked to the remaining
duration, I get fractions of duration that are sometimes less or more than
the number of remaining days I know is correct.
For instance, when if I have a 3 day duration and I know 1 day of those has
been worked, then two days is remaining. Therefore, the activity is 33.3%
complete. But, since MSP does not utilize fractional percent complete, the RD
in this case is 2.01. (33% x 3 days = .99 3days - .99 days = 2.01 days. This
is incorrect Because now the task sheet adds another day to reflect the .01
days and changes the actual duration to reflect this. This is totally wrong.
Therefore, the algorithim is incorrect.
One should be able to insert a remaining duration to calculate the percent
complete, or, insert a percent complete to obtain a remaining duration.
However, MSP is not designed to manually change the remaining duration or the
original duration will change and your whole baseline claims case is out of
sync.
That is why I need remaining duration expressed as a whole number. Not a
fraction below or above the true remaining duration.
I hope his explains my question. It is very late and I just came back from a
two river trip. So, I am a little sun burned right now.
Carey
The original duration should always remain the same as originally designed
in your baseline -- unless there is a change order that requires you to
change it. However, even change orders should be expressed as a separate
activity when you are presenting a claims clase.
The primary issue here is that MSP is designed to not change the original
calculated early finish date until the activity is 100% completed. The
remaining duration should change if, lets say, a 2 day activity is 50%
complete. The remaining being 1 day should change the early finish date to
tell you if you are ahead, on, or behind your baseline schedule. But, this,
of course, depends on your data date (status date). However, in my case, the
early finish (forward pass) does not change regardless what the DD is. This
is a falacy and does not properly represent the true nature of that activity.
Regarding the remainining duration: I personally need it to be expressed as
a whole number because and since the % complete is linked to the remaining
duration, I get fractions of duration that are sometimes less or more than
the number of remaining days I know is correct.
For instance, when if I have a 3 day duration and I know 1 day of those has
been worked, then two days is remaining. Therefore, the activity is 33.3%
complete. But, since MSP does not utilize fractional percent complete, the RD
in this case is 2.01. (33% x 3 days = .99 3days - .99 days = 2.01 days. This
is incorrect Because now the task sheet adds another day to reflect the .01
days and changes the actual duration to reflect this. This is totally wrong.
Therefore, the algorithim is incorrect.
One should be able to insert a remaining duration to calculate the percent
complete, or, insert a percent complete to obtain a remaining duration.
However, MSP is not designed to manually change the remaining duration or the
original duration will change and your whole baseline claims case is out of
sync.
That is why I need remaining duration expressed as a whole number. Not a
fraction below or above the true remaining duration.
I hope his explains my question. It is very late and I just came back from a
two river trip. So, I am a little sun burned right now.
Carey
C
carey
Brain:
Please review my response to Steve. The fractional percent complete does not
mean a darn thing to me. However, in order to achieve a whole number for the
remaining duration, I need the ability to this through the percent complete.
Carey
Please review my response to Steve. The fractional percent complete does not
mean a darn thing to me. However, in order to achieve a whole number for the
remaining duration, I need the ability to this through the percent complete.
Carey
B
Brian K - Project MVP
carey said:
OK. I will start this with the full admission of the fact that I am no
great EV expert. BUT my understanding is that the simple act of the
forward and backard pass should not change your Early Finish. The whole
"ahead or behind schedule" does not come from reading the Early Finish. It
comes from the derived EV metrics (BCWP, BCWS, etc, etc)
However... What I think you are asking is for Project to automatically
reschedule incomplete work that falls before the Status Date to after the
status date. This would indeed move work into the future and thereby
adjust the Early Finish.
There are two ways to do this (assuming you are using Project 2002 or
2003). The first is manual and it is the reschedule button on the Tracking
Toolbar. it will move any incomplete parts of a task prior to the status
date to start after the status date.
There is also a set of options on the Calculation tab of the Tools |
Options dialog. "Move Start of remaining parts before status date forward
to status date" This is basically the automatic way to have project hit
the reschedule button for you.
S
Steve House [Project MVP]
The remaining duration IS NOT the baseline (ie, original) duration minus the
actual duration (except by pure coincidence). It is the CURRENTLY ESTIMATED
duration minus the actual duration. True, the original duration shouldn't
change as the project progresses but the Gantt chart timeline doesn't show
the original duration once work begins, it shows the actual duration of
tasks that have been completed and the forecast duration of tasks in
progress or still to begin, which is something quite different. You are
confusing the baseline, which is static, with the working schedule which is
dynamic and is the schedule that is expressed by the Gantt chart. Before
work commences the plan shows your estimated durations and the
MSP-calculated planned start and finish dates. After work commences the
Gantt shows actual performance for tasks that have been completed or are in
progress. Actual progress means it shows the date the task actually began
(and finished once completed) along with the portion of the duration that
has been worked to the status date and the estimated remaining duration. If
those actual performance metrics are the same as your original estimates,
the Gantt chart of the project schedule doesn't change. But if the actual
performance is different from what was planned, the Gantt reflects actual
history of what transpired and the forecast of what changes that implies for
the future schedule. It''s entirely possible for a task to be estimated at,
say, 10 days, but once work commences it becomes apparent that the work
required was under- or over-estimated. In fact, that will happen more often
than not in many industries. IF a predecessor's total duration estimate
changes halfway through the task, it's finish date will change and the start
of a subsequent successor task will also change by a like amount, driven by
the dependency link. Only the baseline does not change and if you need to
view the original schedule the only place you can see it is by making the
baseline visible - the standard Gantt does not show it nor should it.
The durations entered during planning are NOT an allowance the PM gives to
the resource to do the work. A task produces a concrete deliverable. The
deliverable in turn requires an exact, finite, measurable, amount of work to
produce. The duration of a task is the best guess on the part of the
planner in consultation with subject matter experts and the resources
involved of the number of work periods that will be required to generate
that work. It's only an estimate and is subject to revision at any time as
experience is gained once work begins. Because planned duration is only an
estimate, a change order should not be required merely to revise it. A
change order is triggered by the need to change the project *scope* adding
or deleting deliverables and tasks.
To prevent fractional remaining durations, do not actually enter the %
Complete field at all. Don't ask your resources to estimate percentages -
that's usually an extremely unreliable estimate anyway - and instead ask
them how many hours or days they worked on the task and how many they expect
it to take them before it's done. On the tracking table, enter the Actual
Duration and the Remaining Duration and let Project calculate the % Complete
for you. If you only enter integer values for the durations and don't ask
MSP to calculate actual and remaining durations based on a user-supplied
percentage, Project won't put decimals there. If I have a 5 day task and
enter that it's 30% complete, Project will calculate Actual Duration of 1.5
days and Remaining Duration of 3.5 days. If those decimals are unacceptable
and you want round to whole days, enter Actual of 1 day, enter Remaining of
4 days, and let Project calculate on its own that the task is 20% complete.
And remember, the definition of "% Complete" is the amount of time during
which work has physically taken place compared to the total duration that is
required. If we are halfway though a 10 day task and work took place as
scheduled we are 50% complete. But if only 2 days of the 5 that should have
been done by now actually had work taking place, the task is only 20% done
at the point where we should be 50% done. All calculations in Project are
carried out using time slices consisting of 1/10 minute "ticks" of a master
clock. If you enter a percentage that represents a fraction of a day or
hour, what's what you'll see in the calculated result. 30% of 5 days is 1.5
days and 5-1.5 = 3.5 and can't be anything else. If you want it to read 1 &
4 days, don't enter the 30% and instead enter or let it calculate the 20%
which is mathematically accurate. You say you sometimes get remaining
durations that you know are incorrect - it that's true, the % Complete
you're entering is not an accurate value. The answer is not to drive
yourself nuts trying to come up with calculated fields that are only integer
values. The answer is to enter more accurate % Complete estimates to begin
with, best done by letting Project calculate them for you based on your
supplied Actual and Remaining estimates.
You keep saying that the early finish doesn't change, but that's simply not
true. I think you are looking at it before completing the update process,
leaving the work that should have been done prior to the reporting date but
wasn't done still sitting where it was scheduled in the original plan. But
we can't do that because we aren't able to do work retroactively. If work
days were missed they were missed and our only choice is to reschedule that
work into the future. Before writing this answer I set up a trial in Proj
2003 Pro. I entered a task that has 10 days duration and a second task 15
days duration. The tasks are not linked to each other, they both start
today 15 Aug and both tasks are linked to a finish milestone FS so they run
in parallel. Considering just task 1, it's scheduled duration is 10 days,
scheduled finish is 26 Aug, early finish is 26 Aug, late finish is 02 Sep.
Set the status date to Fri, 19 Aug, 5pm. Show task 1 as 20% complete,
reflecting that work was done on that task Mon & Tues, but the work that was
supposed to take place Wed, Thur, and today, Fri, did not happen. ACtual
duration is 2 days, remiaing duration is 8 days. Task 2, OTOH, went
according to plan and as of the moment all 5 days that should have taken
place before and including today did, in fact, happen. Sp far, the early
finish of task 1 hasn'r changed but that's because only we haven't finished
the updating process yet. We had work scheduled for last Wed, Thur, and
today that did not take place - perhaps the resource took sick Tue evening
and we didn't have a replacement. So what happens when he returns to work
Monday and we can pick up the work again? We don't have a time machine that
lets us go back to last Wed and do work on that date that should have been
done but we missed. The only time we can possibly do that work is at some
point in the *future* and we must adjust the remaining schedule accordingly.
We need to reschedule the uncompleted work. When we trigger that tool, task
1 splits at Wed and the second half moves forward to show work resuming this
coming Mon at 8am, the earliest we can possibly do that work. Duration
remains at 10 days (the time in the split doesn't count for duration), the
scheduled finish and the early finish now changes to 31 Aug, the earliest
date that task could possibly finish unless we revise its duration.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs
actual duration (except by pure coincidence). It is the CURRENTLY ESTIMATED
duration minus the actual duration. True, the original duration shouldn't
change as the project progresses but the Gantt chart timeline doesn't show
the original duration once work begins, it shows the actual duration of
tasks that have been completed and the forecast duration of tasks in
progress or still to begin, which is something quite different. You are
confusing the baseline, which is static, with the working schedule which is
dynamic and is the schedule that is expressed by the Gantt chart. Before
work commences the plan shows your estimated durations and the
MSP-calculated planned start and finish dates. After work commences the
Gantt shows actual performance for tasks that have been completed or are in
progress. Actual progress means it shows the date the task actually began
(and finished once completed) along with the portion of the duration that
has been worked to the status date and the estimated remaining duration. If
those actual performance metrics are the same as your original estimates,
the Gantt chart of the project schedule doesn't change. But if the actual
performance is different from what was planned, the Gantt reflects actual
history of what transpired and the forecast of what changes that implies for
the future schedule. It''s entirely possible for a task to be estimated at,
say, 10 days, but once work commences it becomes apparent that the work
required was under- or over-estimated. In fact, that will happen more often
than not in many industries. IF a predecessor's total duration estimate
changes halfway through the task, it's finish date will change and the start
of a subsequent successor task will also change by a like amount, driven by
the dependency link. Only the baseline does not change and if you need to
view the original schedule the only place you can see it is by making the
baseline visible - the standard Gantt does not show it nor should it.
The durations entered during planning are NOT an allowance the PM gives to
the resource to do the work. A task produces a concrete deliverable. The
deliverable in turn requires an exact, finite, measurable, amount of work to
produce. The duration of a task is the best guess on the part of the
planner in consultation with subject matter experts and the resources
involved of the number of work periods that will be required to generate
that work. It's only an estimate and is subject to revision at any time as
experience is gained once work begins. Because planned duration is only an
estimate, a change order should not be required merely to revise it. A
change order is triggered by the need to change the project *scope* adding
or deleting deliverables and tasks.
To prevent fractional remaining durations, do not actually enter the %
Complete field at all. Don't ask your resources to estimate percentages -
that's usually an extremely unreliable estimate anyway - and instead ask
them how many hours or days they worked on the task and how many they expect
it to take them before it's done. On the tracking table, enter the Actual
Duration and the Remaining Duration and let Project calculate the % Complete
for you. If you only enter integer values for the durations and don't ask
MSP to calculate actual and remaining durations based on a user-supplied
percentage, Project won't put decimals there. If I have a 5 day task and
enter that it's 30% complete, Project will calculate Actual Duration of 1.5
days and Remaining Duration of 3.5 days. If those decimals are unacceptable
and you want round to whole days, enter Actual of 1 day, enter Remaining of
4 days, and let Project calculate on its own that the task is 20% complete.
And remember, the definition of "% Complete" is the amount of time during
which work has physically taken place compared to the total duration that is
required. If we are halfway though a 10 day task and work took place as
scheduled we are 50% complete. But if only 2 days of the 5 that should have
been done by now actually had work taking place, the task is only 20% done
at the point where we should be 50% done. All calculations in Project are
carried out using time slices consisting of 1/10 minute "ticks" of a master
clock. If you enter a percentage that represents a fraction of a day or
hour, what's what you'll see in the calculated result. 30% of 5 days is 1.5
days and 5-1.5 = 3.5 and can't be anything else. If you want it to read 1 &
4 days, don't enter the 30% and instead enter or let it calculate the 20%
which is mathematically accurate. You say you sometimes get remaining
durations that you know are incorrect - it that's true, the % Complete
you're entering is not an accurate value. The answer is not to drive
yourself nuts trying to come up with calculated fields that are only integer
values. The answer is to enter more accurate % Complete estimates to begin
with, best done by letting Project calculate them for you based on your
supplied Actual and Remaining estimates.
You keep saying that the early finish doesn't change, but that's simply not
true. I think you are looking at it before completing the update process,
leaving the work that should have been done prior to the reporting date but
wasn't done still sitting where it was scheduled in the original plan. But
we can't do that because we aren't able to do work retroactively. If work
days were missed they were missed and our only choice is to reschedule that
work into the future. Before writing this answer I set up a trial in Proj
2003 Pro. I entered a task that has 10 days duration and a second task 15
days duration. The tasks are not linked to each other, they both start
today 15 Aug and both tasks are linked to a finish milestone FS so they run
in parallel. Considering just task 1, it's scheduled duration is 10 days,
scheduled finish is 26 Aug, early finish is 26 Aug, late finish is 02 Sep.
Set the status date to Fri, 19 Aug, 5pm. Show task 1 as 20% complete,
reflecting that work was done on that task Mon & Tues, but the work that was
supposed to take place Wed, Thur, and today, Fri, did not happen. ACtual
duration is 2 days, remiaing duration is 8 days. Task 2, OTOH, went
according to plan and as of the moment all 5 days that should have taken
place before and including today did, in fact, happen. Sp far, the early
finish of task 1 hasn'r changed but that's because only we haven't finished
the updating process yet. We had work scheduled for last Wed, Thur, and
today that did not take place - perhaps the resource took sick Tue evening
and we didn't have a replacement. So what happens when he returns to work
Monday and we can pick up the work again? We don't have a time machine that
lets us go back to last Wed and do work on that date that should have been
done but we missed. The only time we can possibly do that work is at some
point in the *future* and we must adjust the remaining schedule accordingly.
We need to reschedule the uncompleted work. When we trigger that tool, task
1 splits at Wed and the second half moves forward to show work resuming this
coming Mon at 8am, the earliest we can possibly do that work. Duration
remains at 10 days (the time in the split doesn't count for duration), the
scheduled finish and the early finish now changes to 31 Aug, the earliest
date that task could possibly finish unless we revise its duration.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs
carey said:
C
carey
The primary issue is that the newly calculated early finish is before the
data date (status date). This is what is incorrect. It should be the day
after your data date if the activity has a two day duration and the one day
is complete.
data date (status date). This is what is incorrect. It should be the day
after your data date if the activity has a two day duration and the one day
is complete.
B
Brian K - Project MVP
carey said:
See my response "above". There is an option in Project that will do what
you want. It will automatically move unfinished work prior to the Status
Date to after the status date. I detail it in my reply to you above.
S
Steve House [Project MVP]
We agree that it should be after the status date and if you reschedule the
incomplete work to take place after the status date your early finish will
show as it should. What I'm trying to tell you is updating the project's
progress involves more than merely setting a percent complete. That's only
the first step in a 2 step procedure - and you're leaving out a crucial part
of the process. If I have a 2 day task that was scheduled for last week,
Mon and Tue, and mark it as 50% complete, it will show work took place on
Monday but has not taken place on Tuesday. But as of that moment, Project
doesn't know if it really didn't take place and needs to be moved up into
the future or if we just haven't gotten around to posting the data for last
Tuesday's work yet. If you now reschedule the remaining work, Project will
split the task and move the remaining portion forward, in the process also
changing the early finish date to the day after your status date as it
should. If you don't reschedule uncompleted work, Project doesn't know it's
supposed to recalculate those early finish dates. You have to do both
tasks - post actuals and reschedule remaining.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs
incomplete work to take place after the status date your early finish will
show as it should. What I'm trying to tell you is updating the project's
progress involves more than merely setting a percent complete. That's only
the first step in a 2 step procedure - and you're leaving out a crucial part
of the process. If I have a 2 day task that was scheduled for last week,
Mon and Tue, and mark it as 50% complete, it will show work took place on
Monday but has not taken place on Tuesday. But as of that moment, Project
doesn't know if it really didn't take place and needs to be moved up into
the future or if we just haven't gotten around to posting the data for last
Tuesday's work yet. If you now reschedule the remaining work, Project will
split the task and move the remaining portion forward, in the process also
changing the early finish date to the day after your status date as it
should. If you don't reschedule uncompleted work, Project doesn't know it's
supposed to recalculate those early finish dates. You have to do both
tasks - post actuals and reschedule remaining.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs
carey said:
C
carey
Brian:
My responses.
Regarding your first paragraph:
The forward and backward pass will not change if you are on schedule.
However, if you are ahead or behind your original network design, then, yes,
the early dates and the late dates will change based on the status of the
activities prior to your data date. This will occur whether the activities
are resource loaded or not -- the same is true if the activities are just
cost loaded. The forward pass is calculated from the data date not from the
project start date. And those activities that have not started or are
incomplete will fall downstream of the data date. This has nothing to do with
BCWS, BCWP or any of the EV formulas. These primarily are used when resources
or dollars are loaded. My schedule is just a non-loaded schedule. And, there
is a difference between resource durations and schedule durations (activity
durations).
Regarding your comment that I am searching a way for the forward pass to
calculate dates after the data is is true. This is what I am searching for.
My responses.
Regarding your first paragraph:
The forward and backward pass will not change if you are on schedule.
However, if you are ahead or behind your original network design, then, yes,
the early dates and the late dates will change based on the status of the
activities prior to your data date. This will occur whether the activities
are resource loaded or not -- the same is true if the activities are just
cost loaded. The forward pass is calculated from the data date not from the
project start date. And those activities that have not started or are
incomplete will fall downstream of the data date. This has nothing to do with
BCWS, BCWP or any of the EV formulas. These primarily are used when resources
or dollars are loaded. My schedule is just a non-loaded schedule. And, there
is a difference between resource durations and schedule durations (activity
durations).
Regarding your comment that I am searching a way for the forward pass to
calculate dates after the data is is true. This is what I am searching for.
B
Brian K - Project MVP
carey said:
The answer to your question has been posted in this thread at least 3
times.
It is not the Forward pass that is not working. It is your update process. The forward pass is just fine. It is working with the dates you are giving it. your update process is incomplete since it seems that it is made up on just updating percent complete. It is up to you to move the unfinished portion of incomplete tasks so that they start after your Status Date. There are two very easy ways to do this:
There is a button on the Tracking Toolbar called Reschedule. it will do
exactly what you are looking for. Then there is an option on the
Calculation tab of the Tools | Options dialog that will do this
automatically. "Move start of remaining parts before status date forward
to status date". If you check this box Project will always move the
unfinished portion of your incomplete tasks so that they start after the
status date. This will happen as soon as you edit the task.
Please look into these solutions.
P
Philip
Hi Brian,
I noticed this thread of discussion on expressing % complete in decimals.
Our client has requested for us to report our progress in decimals. I tried
to use your VBA code below but I'm not very experienced with VBA. Could you
help with step by step instructions? I'm using Project2000.
I presume this is a macro, so I tried to create one and typed in your code
in Microsoft Visual Basic Editor. But when I go back to Tool/Macro its not
there for me to run it.
Thanks.
I noticed this thread of discussion on expressing % complete in decimals.
Our client has requested for us to report our progress in decimals. I tried
to use your VBA code below but I'm not very experienced with VBA. Could you
help with step by step instructions? I'm using Project2000.
I presume this is a macro, so I tried to create one and typed in your code
in Microsoft Visual Basic Editor. But when I go back to Tool/Macro its not
there for me to run it.
Thanks.
J
John
Philip said:
Philip,
Brian may or may not be able to address your post immediately so let me
take a shot.
First of all, Brian gave two versions of code. The first you WOULD see
if you entered it into the VB Editor and then looed under
Tools/Macro/Macros. The second you will NOT see because it is a Private
sub. In order to view Private sub, go to the VB Editor and hit
View/Project Explorer. On the right side of the screen you should see
the explorer hierarchy with something that says, "VBAProject (your
project name)". Under that you will see, "Microsoft Project Objects" and
under that you will see, "ThisProject(your project name)". If you double
click the latter, the macro code will appear in the code window on the
left side of the screen.
The second version of Brian's code is designed to run automatically so
you don't have to initiate it. However it does have a potential glitch
that should be addressed. If any tasks in the schedule are milestones
(i.e. "0" duration) an error will be generated because the format
formula is trying to divide by zero and in this galaxy, that's a no-no
although I think it may be OK in the Pegasus galaxy - I'll have to check
with Sam or Rodney. At any rate, the corrected code is shown below.
Private Sub Project_Change(ByVal pj As Project)
Dim t As Task
For Each t In ActiveProject.Tasks
If Not t Is Nothing And t.Duration <> 0 Then
t.Text1 = Format(t.ActualDuration / t.Duration, "#.00%")
End If
Next t
End Sub
However, all of the above may be useful information but there is an
easier approach. VBA is not necessary to do what you want. A simple
formula in a custom field will do the trick whether you simply want a
decimal value or a decimal percent value. To set up a formula, do the
following:
1. Go to Tools/Customize/Fields
2. In the Type selection box, select a spare text field (e.g. Text1)
3. Hit the Formula button
4. Enter the following:
IIf([Duration]<>0,format([Actual Duration]/[Duration],"#.00"),"")
If you want a decimal percent value the formula would be:
IIf([Duration]<>0,format([Actual Duration]/[Duration],"#.00%"),"")
5. If you want the same data to appear on summary lines then hit the
option to "Use Formula" for "calculation for task and group summary rows"
That's it, you should be all set.
Just for reference, I agree 100% with Brian. If someone is trying to
show percent complete to multiple decimal places then they are way too
far into the detail.
Hope this helps.
John
Project MVP
P
Philip
John said:
Hi John,
Inputting the formula in Customize Fields worked wonderfully. Thank you.
Philip.
J
John
Philip said:
Philip,
You're welcome.
John
R
Ryan
I've tried and tried to follow your directions to input the decimals in my
percents, and really this is a case I must follow as its a govt. contract i
really need to do it. I have mp server, and tried it through there, but I
can't seem to do it. Is it possible to try explaining it so my slow self can
understand? Thanks you so much!
percents, and really this is a case I must follow as its a govt. contract i
really need to do it. I have mp server, and tried it through there, but I
can't seem to do it. Is it possible to try explaining it so my slow self can
understand? Thanks you so much!
John said: