Planned, not worked hours prior to "today"

[G Lykos]

Greetings! What mechanisms are available to pull a report from Project of
planned hours by task which have not been worked before the status date?
Would look something like Work has a value but corresponding Actual Hours
does not. Am looking for total such hours by task.

Thanks,
George

 

[Steve House [Project MVP]]

First save a baseline before starting to post in any progress. Then as you
enter progress the schedule shows actuals for what has happened and
forecasts based on those actuals for what is yet to come, and the baseline
preserves the original planned values.

 

[G Lykos]

Steve, thanks for your reply. I follow using baselines as a basis for
comparison, but the question here is different.

We're looking for current Work and Actual Work between two timelines (i.e.
how much work you were planning to do, and how much work you have actually
done). Right now, the first timeline of interest is the beginning of the
project, and the second timeline is "now" (as determined via the Status
date). We'd like the two numbers for each task, and rollups through
summaries.

A brute-force approach is possible, namely to export the data to Excel and
then do a lot of manipulation (in particular since cumulative work is
available as an export parameter but cumulative actual work is not). I was
hoping that someone had come up with a simpler and more elegant solution
making use of standard Project data and functions.

Put differently, data of interest is Work To Date and Actual Work To Date.
Does a calculated field provide the computational capability to do this with
some sort of date function?

Further thoughts?
Thanks,
George

First save a baseline before starting to post in any progress. Then as you
enter progress the schedule shows actuals for what has happened and
forecasts based on those actuals for what is yet to come, and the baseline
preserves the original planned values.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Greetings! What mechanisms are available to pull a report from Project of
planned hours by task which have not been worked before the status date?
Would look something like Work has a value but corresponding Actual Hours
does not. Am looking for total such hours by task.

Thanks,
George

 

[Steve House [Project MVP]]

This calculation is exactly what Earned Value is all about. EV expresses it
in dollars instead of man-hours but it's the same metric and if you're not
tracking resource costs you can set the resource rates to $1.00/hour and the
EV number will then represent man-hours. EV uses three measures - Budgeted
Cost of Work Scheduled, Budgeted Cost of Work Performed, and Actual Cost of
Work Performed, all cumulative to date for whatever status date you select.
The BCWS is a measure of the amount of work scheduled since the start of the
project, the BCWP is a measure of the amount of work done. The ACWP is a
measure of the accuracy of your planning, among other things - if I'd
expected it to take 40 man-hours to do something and it actually required
twice that to finish that component, the BCWP would be 40 hours while the
ACWP would 80 hours.

The baseline still figures into it because the BCWS is the baseline work
prorated over time. If our project required 100 man-hours total, if our
status date is between the beginning and the end, the BCWS as of that date
would be 50 man-hours while the Baseline Work is 100.

Take a look in help under Earned Value - there's a pretty good discussion of
it there.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Steve, thanks for your reply. I follow using baselines as a basis for
comparison, but the question here is different.

We're looking for current Work and Actual Work between two timelines (i.e.
how much work you were planning to do, and how much work you have actually
done). Right now, the first timeline of interest is the beginning of the
project, and the second timeline is "now" (as determined via the Status
date). We'd like the two numbers for each task, and rollups through
summaries.

A brute-force approach is possible, namely to export the data to Excel and
then do a lot of manipulation (in particular since cumulative work is
available as an export parameter but cumulative actual work is not). I
was
hoping that someone had come up with a simpler and more elegant solution
making use of standard Project data and functions.

Put differently, data of interest is Work To Date and Actual Work To Date.
Does a calculated field provide the computational capability to do this
with
some sort of date function?

Further thoughts?
Thanks,
George

First save a baseline before starting to post in any progress. Then as you
enter progress the schedule shows actuals for what has happened and
forecasts based on those actuals for what is yet to come, and the
baseline
preserves the original planned values.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Greetings! What mechanisms are available to pull a report from Project of
planned hours by task which have not been worked before the status
date?
Would look something like Work has a value but corresponding Actual Hours
does not. Am looking for total such hours by task.

Thanks,
George

 

[G Lykos]

Steve, I hear what you're saying about BCWS, but that's not what's of
interest here. We do use resource rates with real dollar values, so setting
them to $1 is not an option. The interest here in a software development is
truly planned hours vs. actual hours, both to (some) date.

I've put together the following as a first cut. It's crude but at I least I
have a path forward. It also suggests that:
1. The return of TimeScaleValue Method is inconsistent - in the case of
Work, empty strings rather than zeros when no work in a period, a number
when there is.
2. A Work custom field would make unnecessary having to scale Work-related
numbers, which would need to be scaled back if ever used in Work-related
data manipulations.
3. A Sum method for values in a collection (unless it's there and I couldn't
find it) would make unnecessary having to manually do so, with the extra
testing needed due to inconsistent value-type returns from the method.

I guess the good news is that at least the data is accessible. Thanks for
having shared your thoughts on this.

Regards,
George


Sub WorkToDate()

Dim AnyTask As Task
Dim i As Integer

Dim TSVs As TimeScaleValues
Dim WorkToDate As Single
Dim ActualWorkToDate As Single
Dim TimeScale As Single

Select Case ActiveProject.DefaultWorkUnits
Case pjMinute
TimeScale = 1
Case pjHour
TimeScale = 1 / 60
Case pjDay
TimeScale = 1 / (60 * ActiveProject.HoursPerDay)
Case pjWeek
TimeScale = 1 / (60 * ActiveProject.HoursPerWeek)
End Select

For Each AnyTask In ActiveProject.Tasks
If Not (AnyTask Is Nothing Or AnyTask.Summary = True) Then
Set TSVs = AnyTask.TimeScaleData(ActiveProject.ProjectStart, _
ActiveProject.StatusDate, _
pjTaskTimescaledWork, _
pjTimescaleWeeks)
For i = 1 To TSV_WorkToDate.Count
If IsNumeric(TSV_WorkToDate(i).Value) Then
WorkToDate = WorkToDate + TSVs(i).Value * TimeScale
End If
Next i
AnyTask.Number2 = WorkToDate

Set TSVs = AnyTask.TimeScaleData(ActiveProject.ProjectStart, _
ActiveProject.StatusDate, _
pjTaskTimescaledActualWork, _
pjTimescaleWeeks)
ActualWorkToDate = 0
For i = 1 To TSV_ActualWorkToDate.Count
If IsNumeric(TSV_ActualWorkToDate(i).Value) Then
ActualWorkToDate = ActualWorkToDate + TSVs(i).Value * TimeScale
End If
Next i
AnyTask.Number3 = ActualWorkToDate
End If
Next AnyTask

End Sub

This calculation is exactly what Earned Value is all about. EV expresses it
in dollars instead of man-hours but it's the same metric and if you're not
tracking resource costs you can set the resource rates to $1.00/hour and the
EV number will then represent man-hours. EV uses three measures - Budgeted
Cost of Work Scheduled, Budgeted Cost of Work Performed, and Actual Cost of
Work Performed, all cumulative to date for whatever status date you select.
The BCWS is a measure of the amount of work scheduled since the start of the
project, the BCWP is a measure of the amount of work done. The ACWP is a
measure of the accuracy of your planning, among other things - if I'd
expected it to take 40 man-hours to do something and it actually required
twice that to finish that component, the BCWP would be 40 hours while the
ACWP would 80 hours.

The baseline still figures into it because the BCWS is the baseline work
prorated over time. If our project required 100 man-hours total, if our
status date is between the beginning and the end, the BCWS as of that date
would be 50 man-hours while the Baseline Work is 100.

Take a look in help under Earned Value - there's a pretty good discussion of
it there.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Steve, thanks for your reply. I follow using baselines as a basis for
comparison, but the question here is different.

We're looking for current Work and Actual Work between two timelines (i.e.
how much work you were planning to do, and how much work you have actually
done). Right now, the first timeline of interest is the beginning of the
project, and the second timeline is "now" (as determined via the Status
date). We'd like the two numbers for each task, and rollups through
summaries.

A brute-force approach is possible, namely to export the data to Excel and
then do a lot of manipulation (in particular since cumulative work is
available as an export parameter but cumulative actual work is not). I
was
hoping that someone had come up with a simpler and more elegant solution
making use of standard Project data and functions.

Put differently, data of interest is Work To Date and Actual Work To Date.
Does a calculated field provide the computational capability to do this
with
some sort of date function?

Further thoughts?
Thanks,
George

First save a baseline before starting to post in any progress. Then as you
enter progress the schedule shows actuals for what has happened and
forecasts based on those actuals for what is yet to come, and the
baseline
preserves the original planned values.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Greetings! What mechanisms are available to pull a report from

Project
of

planned hours by task which have not been worked before the status
date?
Would look something like Work has a value but corresponding Actual Hours
does not. Am looking for total such hours by task.

Thanks,
George

 

[G Lykos]

And here's cleaned-up code after an incomplete variable name-change before:

Sub WorkToDate()

Dim AnyTask As Task
Dim i As Integer

Dim TSVs As TimeScaleValues
Dim WorkToDate As Single
Dim ActualWorkToDate As Single
Dim TimeScale As Single

Select Case ActiveProject.DefaultWorkUnits
Case pjMinute
TimeScale = 1
Case pjHour
TimeScale = 1 / 60
Case pjDay
TimeScale = 1 / (60 * ActiveProject.HoursPerDay)
Case pjWeek
TimeScale = 1 / (60 * ActiveProject.HoursPerWeek)
End Select

For Each AnyTask In ActiveProject.Tasks
If Not (AnyTask Is Nothing Or AnyTask.Summary = True) Then
Set TSVs = AnyTask.TimeScaleData(ActiveProject.ProjectStart, _
ActiveProject.StatusDate, _
pjTaskTimescaledWork, _
pjTimescaleWeeks)
For i = 1 To TSVs.Count
If IsNumeric(TSVs(i).Value) Then
WorkToDate = WorkToDate + TSVs(i).Value * TimeScale
End If
Next i
AnyTask.Number2 = WorkToDate

Set TSVs = AnyTask.TimeScaleData(ActiveProject.ProjectStart, _
ActiveProject.StatusDate, _
pjTaskTimescaledActualWork, _
pjTimescaleWeeks)
ActualWorkToDate = 0
For i = 1 To TSVs.Count
If IsNumeric(TSVs(i).Value) Then
ActualWorkToDate = ActualWorkToDate + TSVs(i).Value * TimeScale
End If
Next i
AnyTask.Number3 = ActualWorkToDate
End If
Next AnyTask

End Sub

Steve, I hear what you're saying about BCWS, but that's not what's of
interest here. We do use resource rates with real dollar values, so setting
them to $1 is not an option. The interest here in a software development is
truly planned hours vs. actual hours, both to (some) date.

I've put together the following as a first cut. It's crude but at I least I
have a path forward. It also suggests that:
1. The return of TimeScaleValue Method is inconsistent - in the case of
Work, empty strings rather than zeros when no work in a period, a number
when there is.
2. A Work custom field would make unnecessary having to scale Work-related
numbers, which would need to be scaled back if ever used in Work-related
data manipulations.
3. A Sum method for values in a collection (unless it's there and I couldn't
find it) would make unnecessary having to manually do so, with the extra
testing needed due to inconsistent value-type returns from the method.

I guess the good news is that at least the data is accessible. Thanks for
having shared your thoughts on this.

Regards,
George


Sub WorkToDate()

Dim AnyTask As Task
Dim i As Integer

Dim TSVs As TimeScaleValues
Dim WorkToDate As Single
Dim ActualWorkToDate As Single
Dim TimeScale As Single

Select Case ActiveProject.DefaultWorkUnits
Case pjMinute
TimeScale = 1
Case pjHour
TimeScale = 1 / 60
Case pjDay
TimeScale = 1 / (60 * ActiveProject.HoursPerDay)
Case pjWeek
TimeScale = 1 / (60 * ActiveProject.HoursPerWeek)
End Select

For Each AnyTask In ActiveProject.Tasks
If Not (AnyTask Is Nothing Or AnyTask.Summary = True) Then
Set TSVs = AnyTask.TimeScaleData(ActiveProject.ProjectStart, _
ActiveProject.StatusDate, _
pjTaskTimescaledWork, _
pjTimescaleWeeks)
For i = 1 To TSV_WorkToDate.Count
If IsNumeric(TSV_WorkToDate(i).Value) Then
WorkToDate = WorkToDate + TSVs(i).Value * TimeScale
End If
Next i
AnyTask.Number2 = WorkToDate

Set TSVs = AnyTask.TimeScaleData(ActiveProject.ProjectStart, _
ActiveProject.StatusDate, _
pjTaskTimescaledActualWork, _
pjTimescaleWeeks)
ActualWorkToDate = 0
For i = 1 To TSV_ActualWorkToDate.Count
If IsNumeric(TSV_ActualWorkToDate(i).Value) Then
ActualWorkToDate = ActualWorkToDate + TSVs(i).Value * TimeScale
End If
Next i
AnyTask.Number3 = ActualWorkToDate
End If
Next AnyTask

End Sub

This calculation is exactly what Earned Value is all about. EV

expresses

it
in dollars instead of man-hours but it's the same metric and if you're not
tracking resource costs you can set the resource rates to $1.00/hour and the
EV number will then represent man-hours. EV uses three measures - Budgeted
Cost of Work Scheduled, Budgeted Cost of Work Performed, and Actual Cost of
Work Performed, all cumulative to date for whatever status date you select.
The BCWS is a measure of the amount of work scheduled since the start of the
project, the BCWP is a measure of the amount of work done. The ACWP is a
measure of the accuracy of your planning, among other things - if I'd
expected it to take 40 man-hours to do something and it actually required
twice that to finish that component, the BCWP would be 40 hours while the
ACWP would 80 hours.

The baseline still figures into it because the BCWS is the baseline work
prorated over time. If our project required 100 man-hours total, if our
status date is between the beginning and the end, the BCWS as of that date
would be 50 man-hours while the Baseline Work is 100.

Take a look in help under Earned Value - there's a pretty good

discussion

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

Steve, thanks for your reply. I follow using baselines as a basis for
comparison, but the question here is different.

We're looking for current Work and Actual Work between two timelines (i.e.
how much work you were planning to do, and how much work you have actually
done). Right now, the first timeline of interest is the beginning of the
project, and the second timeline is "now" (as determined via the Status
date). We'd like the two numbers for each task, and rollups through
summaries.

A brute-force approach is possible, namely to export the data to Excel and
then do a lot of manipulation (in particular since cumulative work is
available as an export parameter but cumulative actual work is not). I
was
hoping that someone had come up with a simpler and more elegant solution
making use of standard Project data and functions.

Put differently, data of interest is Work To Date and Actual Work To Date.
Does a calculated field provide the computational capability to do this
with
some sort of date function?

Further thoughts?
Thanks,
George


message First save a baseline before starting to post in any progress. Then as
you
enter progress the schedule shows actuals for what has happened and
forecasts based on those actuals for what is yet to come, and the
baseline
preserves the original planned values.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Greetings! What mechanisms are available to pull a report from Project
of
planned hours by task which have not been worked before the status
date?
Would look something like Work has a value but corresponding Actual
Hours
does not. Am looking for total such hours by task.

Thanks,
George

 

[G Lykos]

And here's cleaned-up code after an incomplete variable name-change version
sent a little while ago:

Sub WorkToDate()

Dim AnyTask As Task
Dim i As Integer

Dim TSVs As TimeScaleValues
Dim WorkToDate As Single
Dim ActualWorkToDate As Single
Dim TimeScale As Single

Select Case ActiveProject.DefaultWorkUnits
Case pjMinute
TimeScale = 1
Case pjHour
TimeScale = 1 / 60
Case pjDay
TimeScale = 1 / (60 * ActiveProject.HoursPerDay)
Case pjWeek
TimeScale = 1 / (60 * ActiveProject.HoursPerWeek)
End Select

For Each AnyTask In ActiveProject.Tasks
If Not (AnyTask Is Nothing Or AnyTask.Summary = True) Then
Set TSVs = AnyTask.TimeScaleData(ActiveProject.ProjectStart, _
ActiveProject.StatusDate, _
pjTaskTimescaledWork, _
pjTimescaleWeeks)
For i = 1 To TSVs.Count
If IsNumeric(TSVs(i).Value) Then
WorkToDate = WorkToDate + TSVs(i).Value * TimeScale
End If
Next i
AnyTask.Number2 = WorkToDate

Set TSVs = AnyTask.TimeScaleData(ActiveProject.ProjectStart, _
ActiveProject.StatusDate, _
pjTaskTimescaledActualWork, _
pjTimescaleWeeks)
ActualWorkToDate = 0
For i = 1 To TSVs.Count
If IsNumeric(TSVs(i).Value) Then
ActualWorkToDate = ActualWorkToDate + TSVs(i).Value * TimeScale
End If
Next i
AnyTask.Number3 = ActualWorkToDate
End If
Next AnyTask

End Sub

Steve, I hear what you're saying about BCWS, but that's not what's of
interest here. We do use resource rates with real dollar values, so setting
them to $1 is not an option. The interest here in a software development is
truly planned hours vs. actual hours, both to (some) date.

I've put together the following as a first cut. It's crude but at I least I
have a path forward. It also suggests that:
1. The return of TimeScaleValue Method is inconsistent - in the case of
Work, empty strings rather than zeros when no work in a period, a number
when there is.
2. A Work custom field would make unnecessary having to scale Work-related
numbers, which would need to be scaled back if ever used in Work-related
data manipulations.
3. A Sum method for values in a collection (unless it's there and I couldn't
find it) would make unnecessary having to manually do so, with the extra
testing needed due to inconsistent value-type returns from the method.

I guess the good news is that at least the data is accessible. Thanks for
having shared your thoughts on this.

Regards,
George


Sub WorkToDate()

Dim AnyTask As Task
Dim i As Integer

Dim TSVs As TimeScaleValues
Dim WorkToDate As Single
Dim ActualWorkToDate As Single
Dim TimeScale As Single

Select Case ActiveProject.DefaultWorkUnits
Case pjMinute
TimeScale = 1
Case pjHour
TimeScale = 1 / 60
Case pjDay
TimeScale = 1 / (60 * ActiveProject.HoursPerDay)
Case pjWeek
TimeScale = 1 / (60 * ActiveProject.HoursPerWeek)
End Select

For Each AnyTask In ActiveProject.Tasks
If Not (AnyTask Is Nothing Or AnyTask.Summary = True) Then
Set TSVs = AnyTask.TimeScaleData(ActiveProject.ProjectStart, _
ActiveProject.StatusDate, _
pjTaskTimescaledWork, _
pjTimescaleWeeks)
For i = 1 To TSV_WorkToDate.Count
If IsNumeric(TSV_WorkToDate(i).Value) Then
WorkToDate = WorkToDate + TSVs(i).Value * TimeScale
End If
Next i
AnyTask.Number2 = WorkToDate

Set TSVs = AnyTask.TimeScaleData(ActiveProject.ProjectStart, _
ActiveProject.StatusDate, _
pjTaskTimescaledActualWork, _
pjTimescaleWeeks)
ActualWorkToDate = 0
For i = 1 To TSV_ActualWorkToDate.Count
If IsNumeric(TSV_ActualWorkToDate(i).Value) Then
ActualWorkToDate = ActualWorkToDate + TSVs(i).Value * TimeScale
End If
Next i
AnyTask.Number3 = ActualWorkToDate
End If
Next AnyTask

End Sub

This calculation is exactly what Earned Value is all about. EV

expresses

it
in dollars instead of man-hours but it's the same metric and if you're not
tracking resource costs you can set the resource rates to $1.00/hour and the
EV number will then represent man-hours. EV uses three measures - Budgeted
Cost of Work Scheduled, Budgeted Cost of Work Performed, and Actual Cost of
Work Performed, all cumulative to date for whatever status date you select.
The BCWS is a measure of the amount of work scheduled since the start of the
project, the BCWP is a measure of the amount of work done. The ACWP is a
measure of the accuracy of your planning, among other things - if I'd
expected it to take 40 man-hours to do something and it actually required
twice that to finish that component, the BCWP would be 40 hours while the
ACWP would 80 hours.

The baseline still figures into it because the BCWS is the baseline work
prorated over time. If our project required 100 man-hours total, if our
status date is between the beginning and the end, the BCWS as of that date
would be 50 man-hours while the Baseline Work is 100.

Take a look in help under Earned Value - there's a pretty good

discussion

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

Steve, thanks for your reply. I follow using baselines as a basis for
comparison, but the question here is different.

We're looking for current Work and Actual Work between two timelines (i.e.
how much work you were planning to do, and how much work you have actually
done). Right now, the first timeline of interest is the beginning of the
project, and the second timeline is "now" (as determined via the Status
date). We'd like the two numbers for each task, and rollups through
summaries.

A brute-force approach is possible, namely to export the data to Excel and
then do a lot of manipulation (in particular since cumulative work is
available as an export parameter but cumulative actual work is not). I
was
hoping that someone had come up with a simpler and more elegant solution
making use of standard Project data and functions.

Put differently, data of interest is Work To Date and Actual Work To Date.
Does a calculated field provide the computational capability to do this
with
some sort of date function?

Further thoughts?
Thanks,
George


message First save a baseline before starting to post in any progress. Then as
you
enter progress the schedule shows actuals for what has happened and
forecasts based on those actuals for what is yet to come, and the
baseline
preserves the original planned values.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Greetings! What mechanisms are available to pull a report from Project
of
planned hours by task which have not been worked before the status
date?
Would look something like Work has a value but corresponding Actual
Hours
does not. Am looking for total such hours by task.

Thanks,
George

 

[G Lykos]

And here's further-cleaned-up code (argh) after an incomplete variable
name-change version
sent a little while ago (wish I were able to delete a bad post):

Sub WorkToDate()

Dim AnyTask As Task
Dim i As Integer

Dim TSVs As TimeScaleValues
Dim WorkToDate As Single
Dim ActualWorkToDate As Single
Dim TimeScale As Single

Select Case ActiveProject.DefaultWorkUnits
Case pjMinute
TimeScale = 1
Case pjHour
TimeScale = 1 / 60
Case pjDay
TimeScale = 1 / (60 * ActiveProject.HoursPerDay)
Case pjWeek
TimeScale = 1 / (60 * ActiveProject.HoursPerWeek)
End Select

For Each AnyTask In ActiveProject.Tasks
If Not (AnyTask Is Nothing Or AnyTask.Summary = True) Then
Set TSVs = AnyTask.TimeScaleData(ActiveProject.ProjectStart, _
ActiveProject.StatusDate, _
pjTaskTimescaledWork, _
pjTimescaleWeeks)
WorkToDate = 0
For i = 1 To TSVs.Count
If IsNumeric(TSVs(i).Value) Then
WorkToDate = WorkToDate + TSVs(i).Value * TimeScale
End If
Next i
AnyTask.Number2 = WorkToDate

Set TSVs = AnyTask.TimeScaleData(ActiveProject.ProjectStart, _
ActiveProject.StatusDate, _
pjTaskTimescaledActualWork, _
pjTimescaleWeeks)
ActualWorkToDate = 0
For i = 1 To TSVs.Count
If IsNumeric(TSVs(i).Value) Then
ActualWorkToDate = ActualWorkToDate + TSVs(i).Value * TimeScale
End If
Next i
AnyTask.Number3 = ActualWorkToDate
End If
Next AnyTask

End Sub

This calculation is exactly what Earned Value is all about. EV expresses it
in dollars instead of man-hours but it's the same metric and if you're not
tracking resource costs you can set the resource rates to $1.00/hour and the
EV number will then represent man-hours. EV uses three measures - Budgeted
Cost of Work Scheduled, Budgeted Cost of Work Performed, and Actual Cost of
Work Performed, all cumulative to date for whatever status date you select.
The BCWS is a measure of the amount of work scheduled since the start of the
project, the BCWP is a measure of the amount of work done. The ACWP is a
measure of the accuracy of your planning, among other things - if I'd
expected it to take 40 man-hours to do something and it actually required
twice that to finish that component, the BCWP would be 40 hours while the
ACWP would 80 hours.

The baseline still figures into it because the BCWS is the baseline work
prorated over time. If our project required 100 man-hours total, if our
status date is between the beginning and the end, the BCWS as of that date
would be 50 man-hours while the Baseline Work is 100.

Take a look in help under Earned Value - there's a pretty good discussion of
it there.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Steve, thanks for your reply. I follow using baselines as a basis for
comparison, but the question here is different.

We're looking for current Work and Actual Work between two timelines (i.e.
how much work you were planning to do, and how much work you have actually
done). Right now, the first timeline of interest is the beginning of the
project, and the second timeline is "now" (as determined via the Status
date). We'd like the two numbers for each task, and rollups through
summaries.

A brute-force approach is possible, namely to export the data to Excel and
then do a lot of manipulation (in particular since cumulative work is
available as an export parameter but cumulative actual work is not). I
was
hoping that someone had come up with a simpler and more elegant solution
making use of standard Project data and functions.

Put differently, data of interest is Work To Date and Actual Work To Date.
Does a calculated field provide the computational capability to do this
with
some sort of date function?

Further thoughts?
Thanks,
George

First save a baseline before starting to post in any progress. Then as you
enter progress the schedule shows actuals for what has happened and
forecasts based on those actuals for what is yet to come, and the
baseline
preserves the original planned values.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Greetings! What mechanisms are available to pull a report from

Project
of

planned hours by task which have not been worked before the status
date?
Would look something like Work has a value but corresponding Actual Hours
does not. Am looking for total such hours by task.

Thanks,
George

 

[Steve House [Project MVP]]

"Planned Hours" to a status date would be the cummulative total of the
baseline hours between the project start and the status date - BCWS
expressed in hours instead of dollars. It represents the planned hours your
original schedule called for you to work between the two dates.

"Actual Hours" to the same status date would be the ACWP, again in units of
hours instead of dollars, and represents the hours you actually did work
between the same two dates.

Isn't that what you're looking for?

 

[Steve House [Project MVP]]

No offense, but it sure seems to me you're going to an awfully lot of
trouble to reinvent the wheel <grin>


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

And here's cleaned-up code after an incomplete variable name-change
version

.... snip ...

 

[G Lykos]

Steve, I now have what I need. There are some nuances, I did some further
thinking, and made a partial change in direction.

1. We're looking for planned work to date. Not baseline, but rather current
plan. Not BCWS (i.e. baseline cost), but rather work (man-hours). The
question it is answering is, "How many man-hours were to have been expended
by today on the current plan?"

2. For us, "actual hours" are earned hours. Also, we are not on Project
Server, and do not apply timesheet hours to Project tasks. The task work is
based on a man-hour estimate (actually a mix of different skill types), and
there is a performance measurement process external to Project which yields
a task "percent work complete" (effectively a physical percent complete)
that is applied to the task and generates "actual [earned] hours". "Actual
Hours" as recognized by Project against the task does not necessarily have
an exact relation to the time period where it occurs upon posting of
"percent work complete" since Project just fills actual work from the start
of the task as the percent work complete increases. For this reason, I
realized that calculating an Actual Work to Date based on Status date is not
meaningful - the standard Actual Work is in fact what is needed, regardless
of its relation to the Status date.

3. However, a companion statistic to 1. above is current cost to date. The
question is, "How much were we planning to have spent by today on the
current plan?" This like 1. above requires a manual accumulation drawing
upon TimeScaleValues.

So I'm ending up with calculated man-hours to date and actual (earned)
man-hours, calculated cost to date and actual (earned) cost, all based on
current plan. And no, using the built-in EV parameters doesn't provide that
same information. We do an earned value assessment outside of Project using
real actual costs from our accounting system, with the project baseline as
the standard for comparison.

Having worked now with Project a bit on this and an earlier exercise
involving custom fields, some things become clear.
1. The Project implementation of custom field names is very poorly
conceived. You outta be able to read or write a field value using a syntax
as exists everywhere else with collections along the lines of
TaskCustomField("Textn" or "My Name", interchangeably).Value = desired
value, or vice versa.
2. The lack of a collection Sum method is a nuisance.
3. The lack of a Work custom field causes constant non-value-added
bookkeeping in the in-and-out scaling caused by having to use a custom
Number field as a proxy, and yields inconsistent data displays (comma
separators of 000's, unit designator).
4. Ideally, such a basic data manipulation (current planned work to date,
current planned cost to date) would be able to be handled via a formula in a
calculated field.

Brings to mind the question - is there a published list of enhancements for
the next version of Project?

Cheers!
George

"Planned Hours" to a status date would be the cummulative total of the
baseline hours between the project start and the status date - BCWS
expressed in hours instead of dollars. It represents the planned hours your
original schedule called for you to work between the two dates.

"Actual Hours" to the same status date would be the ACWP, again in units of
hours instead of dollars, and represents the hours you actually did work
between the same two dates.

Isn't that what you're looking for?

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

Steve, I hear what you're saying about BCWS, but that's not what's of
interest here. We do use resource rates with real dollar values, so
setting
them to $1 is not an option. The interest here in a software development
is
truly planned hours vs. actual hours, both to (some) date.

 

[Steve House [Project MVP]]

See embedded ...Can't address your specifc VBA issues because I view Project
as a management tool with programming allowed for flexibility and to extend
its utility, not a development environment.

Steve, I now have what I need. There are some nuances, I did some further
thinking, and made a partial change in direction.

1. We're looking for planned work to date. Not baseline, but rather
current
plan. Not BCWS (i.e. baseline cost), but rather work (man-hours). The
question it is answering is, "How many man-hours were to have been
expended
by today on the current plan?"

Planned work is what the baseline represents. It is saved after the plan is
finalized and before work begun and once created should never change except
when the project itself is redefined. Once work begins, the schedule
represented by the Start, Finish, Duration, and Work fields is automatically
set equal to the data entered into the Actual Start, Actual Finish, Actual
Duration+Remaining Duration, and Actual Work+Remaining Work. ISo what you
are calling "planned work" is not even close to planned work at all - it is
Actual Work for work done + Forecast Work (if I can invent a name) for work
not yet performed. The "current plan" - the schedule you see when you
display the basic default Gantt chart - is not the plan at all once work is
underway - at least for work that as been done the plan is the baseline
while the "plan" is actuals. That sum may be quite different from what was
planned, ie, what your original estimates entailed.

2. For us, "actual hours" are earned hours. Also, we are not on Project
Server, and do not apply timesheet hours to Project tasks. The task work
is
based on a man-hour estimate (actually a mix of different skill types),
and
there is a performance measurement process external to Project which
yields
a task "percent work complete" (effectively a physical percent complete)
that is applied to the task and generates "actual [earned] hours".
"Actual
Hours" as recognized by Project against the task does not necessarily have
an exact relation to the time period where it occurs upon posting of
"percent work complete" since Project just fills actual work from the
start
of the task as the percent work complete increases. For this reason, I
realized that calculating an Actual Work to Date based on Status date is
not
meaningful - the standard Actual Work is in fact what is needed,
regardless
of its relation to the Status date.

So you're measuring progress not by what actually happened in the physical
universe but rather some abstract accounting principle that has no bearing
on the real progress to achieving the goal of the project????? The bottom
line needs to be something that when your client sticks his head in the door
and asks "When will it be done?" you have a better answer than "When it is
finished." I don't see how the "earned hours" pseudo-progress metric you
describe helps you come up with an accurate projected completion date and an
accurate real cost at completion estimate (which, IMHO is the whole reason
for bothering with such issues in the first place - if you're not aiming at
that it has no point).

Project fills in the % Work Complete that is the equivalent to the %
(duration) Complete only by default. If you wish disconnect the two,
turning off the "Updating Task Status Updates Resource Status" option
setting.

% Work complete is not an equivalent to % Physical Complete - If you like I
can give some concrete examples where the three completion percentages are
wildly different from each other for the same in-progress task.

Your last sentence is very confusing. Actual work to status date is VERY
meaningful - actual work to date is simply work to yet another status date
that just happens to also coincide the current date. Comparing where you
were at various status dates is extremely useful because it can give you
indicators whether you're progressing according to plan or are losing
ground, and if you're losing ground is it at a constant or an accelerating
rate going from bas to worse.

3. However, a companion statistic to 1. above is current cost to date.
The
question is, "How much were we planning to have spent by today on the
current plan?" This like 1. above requires a manual accumulation drawing
upon TimeScaleValues.

This is absolutely what the stock BCWS measures. What you're insisting is
the plan, ain't.

So I'm ending up with calculated man-hours to date and actual (earned)
man-hours, calculated cost to date and actual (earned) cost, all based on
current plan. And no, using the built-in EV parameters doesn't provide
that
same information. We do an earned value assessment outside of Project
using
real actual costs from our accounting system, with the project baseline as
the standard for comparison.

See above - as I've said several times now, that is because what you are
calling the "plan" isn't the plan - for work that has been performed what
you are calling the "plan" is numerically equal to the actual because
posting progress updates the schedule fields to be equal to the actual
fields.

Having worked now with Project a bit on this and an earlier exercise
involving custom fields, some things become clear.
1. The Project implementation of custom field names is very poorly
conceived. You outta be able to read or write a field value using a
syntax
as exists everywhere else with collections along the lines of
TaskCustomField("Textn" or "My Name", interchangeably).Value = desired
value, or vice versa.
2. The lack of a collection Sum method is a nuisance.
3. The lack of a Work custom field causes constant non-value-added
bookkeeping in the in-and-out scaling caused by having to use a custom
Number field as a proxy, and yields inconsistent data displays (comma
separators of 000's, unit designator).
4. Ideally, such a basic data manipulation (current planned work to date,
current planned cost to date) would be able to be handled via a formula in
a
calculated field.

It is handled already in the EV fields. For sum to-date, you just need to
set appropriate status date for your reports of interest.

Brings to mind the question - is there a published list of enhancements
for
the next version of Project?

I'm not aware of such a list having been published yet.