Problem. Inconsistency between PWA and Project.

[Jose]

I din't found the exact solution to our problem.

People always put their time in PWA. This is correct. Real time here is ok.

The problem is that in real time in Project is wrong. There are few hours
than correct, few days and less time than the same day in PWA.

I tried the function Synchronize with Real Data but is doesn't work. I nedd
to "re-send" the data in PWA to Project. Is it possible?

Thanks.

 

[Gary L. Chefetz [MVP]]

Jose:

The way PWA and Project handle actual work is different. PWA records what
the user inputs, Project applies it according to the algorithm it uses for
applying actual work to tasks based on task type and other task
characteristics. Are you collecting time by week or by day? What task types
do you use? Are your tasks effort driven? For instance, Fixed Duration tasks
get work spread against them like cream cheese on a bagel.

--


Gary L. Chefetz, MVP
"We wrote the books on Project Server"
http://www.msprojectexperts.com

For Project Server FAQs visit
http://www.projectserverexperts.com

For Project FAQs visit
http://www.mvps.org/project

 

[Jose]

The problem is REAL work. It is correct in PWA, but data is different in
Project.

Actual work is not important for me now. I just want real work in PWA be
equal than real work in project.

 

[Jose]

Bug found.

Our project was in Automatic Resource Redistribution. When the project
leader was updating received transactions in Project it showed a
"redistribution problem". The problem was ignored with buttons in the
interfaz "continue and ignore". The project seemed to be ok and PWA showed no
problem. But... many real work in many tasks disappeared.

We tested and when we set "redistribution to manual" it worked.

 

[Gary L. Chefetz [MVP]]

Jose:

Just to be clear, unless you're translating from another language other than
English, there's no such thing as "real work," this is called "actual work"
in Project and Project Server.

--


Gary L. Chefetz, MVP
"We wrote the books on Project Server"
http://www.msprojectexperts.com

For Project Server FAQs visit
http://www.projectserverexperts.com

For Project FAQs visit
http://www.mvps.org/project

 

[Jose]

Yes. In Spanish it is called "real work".

The problem now is how to put all "actual work" from PWA to Project again,
to correct the bugs.

Is it possible?

 

[Gary L. Chefetz [MVP]]

Jose:

I can't think of a way to force this through the interface, but I suppose it
could be done in SQL.

--


Gary L. Chefetz, MVP
"We wrote the books on Project Server"
http://www.msprojectexperts.com

For Project Server FAQs visit
http://www.projectserverexperts.com

For Project FAQs visit
http://www.mvps.org/project

 

[Steve Adams, PMP]

Gary,

If I have a FD task that spans 4 days and is 8 hours, MSP will spread the 8
hours to 2 hours per day. If a resource reports 8 hours on a single day via
PWA, will project spread those hours across the four days or simply leave the
hours on the day reported and indicate the task is complete? Have you seen
an explanation of how actuals effect each tasks type anywhere? Our PMs
struggle with this concept.

Thanks as always for the help.

 

[Gary L. Chefetz [MVP]]

Steve:

You've hit the heart of the actual work conundrum in Project and Project
Server that trips people up time and again. If only folks would take the
time to master the scheduling algorithm and its programming bias. Whose
actual work is it anyway? You can think of fixed-duration task planning as
"tasks with a schmear." The misuse of fixed-duration tasks is probably at
the crux of what most users consider to be Project's bizarre and
unpredictable behaviors.

Here are some simple rules:

If a task is effort-driven, it is not a candidate for Fixed Duration
If your task is effort-driven, and your resource availability for the task
is a known quantity, use Fixed Units
If your task is effort-driven and your work value is an unvarying known
quantity, you have permission to consider Fixed Work, but only if you can
truly justify it.<g>
If your task's most known quantity is duration, and no increase or decrease
in resource effort or availability has any affect on duration, you're clear
to use a Fixed Duration task knowing full well that any actual effort you
captured in the Project side of the equation, will be spread across the
duration.

You also need to understand the techniques and tools available to you to
successfully manipulate the scheduling engine behaviors to use Project as a
scheduling tool.

 

[Steve Adams, PMP]

Hi Gary,

Thanks for the information. I wholly concur with your statememts. I'd make
the argument that Fixed Units should probably be used 90% of the time. In our
business the only factor we can reliably estimate is resource availability.
Furthermore, it would be hard to convince me that the estimated work for a
Fixed Work task is consistently accurate and that a task truly has a Fixed
Duration.

With regard to the scheduling engine/algorithm I've see many discussions on
task types and what happends to Work, Duration and Units as changes occur. Is
this what you're referring to? What material would you reccomend for
ingraining this knowledge into the brains of my PMs?

Many, many thanks!

 

[Gary L. Chefetz [MVP]]

Steve:

I'd like to think we do a good job in our training sessions.