MSP Randomly Changing Actual Work 1

[WaterGypsy]

Hi guys,

we have recently converted from MSP 2003 to 2007 (some users were later moving than others, but the problem is continuing even though everyone is now on 2007).

Since the conversion we have noticed that on occasion MSP will decide to reallocate Actual Work that has previously been entered.

For example: if we had 3, 4, 5, 3 hours allocated for the previous 4 weeks then went in and put in 4 weeks for this week, MSP could change the prior weeks to something like 3.5, 3.8, 5.2, 3.8 (the total always seems to be correct, just the individual figures change).

Does anyone have any idea what might be causing this?

Thanks

Kevin

 

[PDQBach]

I've never seen anything like that but, then again, although I enter actuals on a weekly basis, I've never gone back and compared them with previous entries. Hmmm, maybe I should write a VBA proc to do just that. (I will ... but not right now.)

Humour me, just for a moment, please.

Open a schedule that has tasks which you believe/know changed.

View > Gantt

Put these six columns next to each other: Start, Finish, Work, Duration, Units, Type.

Go to one of those tasks.

Now, change the type through each of the three possibilities (Fixed Units, Fixed Work and Fixed Duration).

As you change the Type, note if Project changes the displayed value for any of those fields (particularly Duration).

Repeat that sequence for several suspect tasks and let me know what you see.

Thanks.

 

[WaterGypsy]

Hi PDQBach

Sorry for delay in responding, had other things that bosses needed doing.

Firstly, thanks. Secondly, maybe I'm being thick but I can't find a column for Units !!

Anyway with the other columns in place I varied the Type from Fixed Work (which is what we have there) through the other two and back again.

Fixed Units makes no difference, but with Fixed Duration the Work Duration value increases, but the rest remain unchanged.

Was this what you woudl expect ?

Kevin

 

[PDQBach]

My turn to apologise for taking so long to reply!

Units column ... oops ... should have said:
Either:
1. Display the Resource Names column
View > Gantt (or any other task display)
Insert "Resource Names"
if necessary:
Tools > Options > Schedule-tab
In "Show scheduling messages" place a check mark
In "Show assignment units as a" select "Percentage"
You'll see the resource units as a percentage next to the Resource Names.

Or 2. Display the Resource Work form
View > Gantt (or any other task display)
Window > Split
RightMouseButton on the grey area in the bottom
In the popup click on "Resource Work".
You'll see the units there as a separate column

What you saw is what I expected. And it ain't pretty from here on. I believe this is a long-standing bug within MSPrj but since it hasn't been fixed, there must be reasons why MS believes this is correctly working as designed (and, therefore, hasn't fixed the code).

Basically, you're left with two unpallatable choices:

1. Accept the fact that internally MSPrj is going to occasionally "mess up" those values and that you'll simply have to live with the inaccurate results (that's what I do ... :-( )

Or 2. Create from scratch (by typing ... not using copy-and-paste) a duplicate task. So you have to create the task, then you have to go and re-enter the Actual Work for every week. There are two issues (which may or may not affect you).

A. If you are using the Unique ID for any reason to interface with another system, the new task (even though it is a duplicate of your existing task) will have a different Unique ID and there is no easy way to modify the Unique ID.

B. If you baselined the original task then you will need to baseline this one task at the appropriate stage of data entry ... but that will change the date/time stamp on your baseline.

Having said all of that, I suppose it *might* be possible to mess with the UniqueID by exporting the MSPrj file to an MSAccess file, making changes in the MSAccess file and then converting the MSAccess file back to an MSPrj file. But I don't know if the Unique ID field is even exported in a way that makes it accessible. If you take a look at an export from MSPrj to MSAccess then you'll note that the MSAccess file has at least one large "blob" field. There is a serious amount of data in the blob fields but you can't access it to modify it.

So, to answer your original question: the issue happens to others (including me); I've never seen a good explanation for what is happening; I've never seen a reasonable workaround.

To everyone else reading this: if you have seen the explanation or have seen a good, consistent workaround, PLEASE LET ME KNOW. You will earn my undying gratitude.

 

[WaterGypsy]

Thanks for taking the time to look at this, its a relief to know it isn't just us that have the problem

Kevin