none
Cost Resources RRS feed

  • Question

  • We want to introduce the use of Cost Resources in MS Project Server 2010 and would like to enter in Cost and Actual Cost information at a monthly level.  One resource we’ve consistently used tells us that we should not enter actual costs at a monthly level but should instead use daily/weekly – the resource does not tell us why.  Can anyone provide clarification and/or advice on this topic?

    Thanks

    Tasha Holland

    Wednesday, April 17, 2013 7:33 PM

All replies

  • Tasha --
     
    Have you actually experimented with the scenario you describe with Expense Cost resources?  I created a simple project with one task and assigned a Work resource and a Cost resource to the task.  I applied a planned Cost amount to the resource assignment for the Cost resource as well.  However, when I tried typing the Actual Cost amount on a weekly basis in the timephased grid, all heck broke loose.  I was caught off guard by what I saw, but it was enough to convince me NOT to enter Actual Cost amounts in the timephased grid.  My personal habit, which will now remain unchanged, is to enter the actual cost for the Cost resource in the Actual Cost column for the resource assignments of the Cost resource.  Try the simple experiment that I did, and see what happens.  I think you will talk yourself out of entering Actual Costs for the Cost resource at any level in the timephased grid.  Hope this helps.
     

    Dale A. Howard [MVP]

    Thursday, April 18, 2013 12:12 PM
    Moderator
  • Tasha,

    We do cost entry using the timephased grid. Cost resources are a bit touchy and you need to be aware of the following. This was all vetted with Microsoft Support, FYI.

    In Project Pro, under File, Options, Schedule, your Week starts on value should match the start day of your timesheet periods. This is for display consistence between server and client for timephased entries.

    When editing timephased costs, you should not edit the finish date of the assignment. Instead, enter your costs where they will occur and let Project extend the tasks. If you mess with the finish date, you may see behavior where you enter cost and actual cost will get filled in.

    Don't use fixed duration for cost tracking tasks. Odd behavior will occur when you don't spend as you planned. Fixed work seems to work much better.

    Don't put work and cost resources on the same task. You may hit a situation where the cost moves since the work moved.

    If you need to look at costs by fiscal period, you are out of luck. Project Pro only uses calendar periods.

    Lastly, I would patch to the latest CU on both Server and Client. There were some cost related fixes which may make your life easier.

    In our instance, we've modified the Task Usage view to manage costs and this seems to work the best for the need.

    Hope this helps.

    Treb Gatte | @tgatte |http://AboutMSProject.com

    Thursday, April 18, 2013 8:48 PM
    Moderator
  • Hi Dale!  Thank you for your response (your book is affectionately referred to as our 'bible' and has kept us out of more than a few issues and is the 'resource' I referred to in my question).  We did experiment with the scenario - however, we made certain not to add cost resources to a task that had work resources assigned (per the advice in your book) to avoid some of the issues you mentioned.  We have found that if you enter in your forecasts and your actuals on the timephased grid using the same timephase to enter both (in our case, we prefer to use Months) that the durations/start/finish dates remain unaffected.  If you try to do it any other way it is crazy (months to weeks, or using the column and then using the grid - any combination other than 'like entries').  The only issues we've seens to far (we're still testing this in QA) is that once you enter in your actuals, you lose your original planned amount - it does not recalculate or reforecast over the remainder of the task - so we are using baselines to capture original forecasts at specific phase gates throughout the lifecycle of the project and historical reporting to capture the detailed monthly forecasts so that we can compare month to month actuals vs planned. 

    Am I missing something that will create problems down the line?  I just want to make sure I'm testing out all possible scenarios before we roll out this functionality.  Thank you! 

    Monday, April 22, 2013 4:38 PM
  • Thank you for the tips!  Especially the start dates - I would've missed that.  We have a number of best practices that we've hammered in to the user groups here - no hard finish dates is one of our biggest no-no's but I will make sure to highlight that in our user guides when we train users on this functionality.

    You mention not using fixed duration for tracking cost resources - what odd behavior have you noticed?  We're using that currently in our QA environment and have noticed any difference between that calculation and fixed work or fixed units.

    Thanks for the heads up on the CU - I will look into that today, we need to update our patches so we may look at waiting to release this until our servers are updated. 

    I appreciate your comprehensive response!

    Tasha

    Monday, April 22, 2013 4:44 PM
  • Tasha,

    Long running tasks set to fixed duration will sometimes yield the finish date moving out for no particular reason. Changing to Fixed Work resolves the issue. Therefore, we simply use Fixed Work.

    Treb Gatte | @tgatte |http://AboutMSProject.com

    Monday, April 22, 2013 7:05 PM
    Moderator