Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

Earned Value Reporting - Historical Values

6 replies [Last post]
Alan Smith
User offline. Last seen 13 years 42 weeks ago. Offline
Joined: 13 Oct 2005
Posts: 9
Groups: None
Thanks for reading this folks, but I need some information or help in attemtpting to resolve a bit of a glitch with our EV reporting.
Essentially we notice that when we look back at last weeks or last months recorded values they have in fact changed somewhat substantially to those which we had graphically recorded.
We get the scenario whereby we can record for instance last week a value of 8230 Earned Value hours, whereas after updating this week and re-scheduleing with this weeks date the figures for last week are now indicating an EV of some 5436 Hrs.
I have always laboured under the simple logic that historical values are cast in stone and would not change following routine weekly updating of progress.
I can send pdf representaion of our values should anybody want to see exactly where we are coming from.

Any help advice would be appreciated.
Regards
Alan

Replies

Alex Wong
User offline. Last seen 11 years 4 weeks ago. Offline
Joined: 12 Feb 2003
Posts: 874
Groups: TILOS
Hi

Since your EV(hrs) is dropping substaintially, I suggest you get your previous schedule and run a simple report of

Act id | Description | Budgeted Hr | % Complete |EVhr

Compare the two plan and identify which one is droping in value

I supspect that it might be your budgeted value where when you update you might zero some of your budgeted value

Cheers

Alex
Alan Smith
User offline. Last seen 13 years 42 weeks ago. Offline
Joined: 13 Oct 2005
Posts: 9
Groups: None
Store Period Performance was the right answer, silly thing is I used to do this on a previous contract. Mind must be going. Thanks lads I am indebted.

Regards

Alan
Brennan Westworth
User offline. Last seen 6 years 51 weeks ago. Offline
Joined: 23 Feb 2003
Posts: 150
Groups: None
Errors in period performance can also be caused by trying to save "0" periods.

P3 does not close off periods with "0" performance and instead spreads this into the following period as if the period wasnt closed off at all.

As a work around, you need to record something (0.01) for each resource that has recorded 0 for the period but is still in progress.

A real pain in the A$$ :)

Alan Smith
User offline. Last seen 13 years 42 weeks ago. Offline
Joined: 13 Oct 2005
Posts: 9
Groups: None
Joao,

Of course, what a simple thing to forget. guess that comes from too many contracts on differnt sites with different operating systems.
Guess we should try that and see how it goes.

Regards

Alan
Joao Ribeiro
User offline. Last seen 5 years 34 weeks ago. Offline
Joined: 21 Mar 2003
Posts: 64
If you are using P3, that may come from not closing out the period before updating.
HTH
Anoon Iimos
User offline. Last seen 2 years 14 weeks ago. Offline
Joined: 22 Sep 2006
Posts: 1422
i don’t exactly understand what you’re saying but i got a guess something like this:

perhaps you got some corrective works carried out, which means that you have taken out some pieces and you need to reinstall it again; this shall only apply to your Current Project.

whereas, your baseline/target schedule will tell you exactly where you’re supposed to be at a certain time (this you need to cast in stone); while your Current Project may become erratic, you’ll need to get exactly (actual) what you have at a certain time (data/status date); from there you can make the comparison...