Cost and Fixed cost Project std 2010 RRS feed

  • Question

  • I have a problem using [cost] in a formula in a custom field (say cost2)

    This is easily demonstrated by setting cost2 as [Cost] and set to roll up to sum.

    so cost2 should always equal cost?

    however I am using fixed costs, and whilst I only add a fixed cost to a task all is fine but when I add one to a summary task (perfectly legitimate use of fixed cost) then cost2 no longer equals cost being short by the amount entered in the summary task.

    any suggestions?

    The overall aim is to produce a simple template for estimating use where non-proficient users (like me) plan costs and time-scales given a pre-set resource sheet for labour and by entering fixed costs for bought in parts.  

    The cost output from this three figures: total cost, labour cost, fixed cost,     both fixed and labour costs have to be derived by formula.  We cannot have the situation where this fails if a user enters a fixed cost in a summary task.

    Thursday, July 30, 2015 5:40 PM

All replies

  • anotherPaul,

    Suggestion, yes. If you have summary level calculation set for roll-up then you can not also have it use the formula (i.e. Cost2=[Cost]). I suggest you do not set any fixed costs at summary level. Instead, create a separate task line for "bought in parts" and set the fixed cost at that level. Now your formulas will work as desired.

    Bear in mind that summary lines are not tasks, even though they are called that. Rather, they represent a summary of subtasks under them. So, even though Project will allow you to add costs to summary lines and/or assign resources to summary lines, it is not a good practice.

    As far as new users doing something "bad", the best approach for avoiding that is through training. Project is not an intuitive application and it is easy to go astray. It is far better to train users both on how to use Project as designed/intended and also to include any corporate requirements that impact scheduling (e.g. work calendars, statusing periods, etc.)

    Hope this helps.


    Thursday, July 30, 2015 6:00 PM
  • I don't agree that assigning fixed costs to summaries is "legitimate".
    As you can see, it causes problems such as the one you have discovered.

    Assigning anything to summaries (except perhaps a calendar) is best avoided altogether, and if you adopt this rule, and no exceptions, it is easy to instruct and easy to check and fix, say with a filter.

    There are many things which MSP allows you to do, which may have some rare specific purpose, but are generally a bad idea, either on principle but mainly because they cause problems, eg assigning fixed costs to summaries, assigning resources to summaries, linking summaries as predecessor/successor, negative lag etc).

    Friday, July 31, 2015 12:19 AM
  • Hi Trevor,

    my use of the word 'legitimate' was carefully chosen based on the content of MS websites such as here:

    and explanation as to why the fixed cost doesn't  sum up like cost etc.

    if a user is able to follow the software vendors instructions and then get a wrong answer who's fault is that?

    The fixed cost was the method of assigning cost to external POs, applied as a task 'pay invoice' that was used by the company I worked for ~20 years ago. I remember using Project was difficult then,  but the company employed experts to support the engineers. Now I'm on my tod.

    Friday, July 31, 2015 7:57 AM
  • Hi John,

    thank you for your prompt answer I can't disagree with anything you say. Unfortunately any allowed training time/budget is easily swallowed up by the effort required to get back up to speed  after having been 'ribboned' by MS

    Are you implying that I shouldn't be using fixed costs at all for recording  e.g. purchase orders or just using them more carefully? 

    Friday, July 31, 2015 8:07 AM
  • anotherPaul,

    Yes I hear you about the training but as you stated in you response back to Trevor about the difficulty in using Project "back in the day", it only gets more challenging as the application is upgraded to do more stuff. Project never was very intuitive and it still isn't so a good training initiative is pretty much imperative if you wish to use the application to its greatest potential. So, bite the bullet, get yourself trained, and train those who will be working with you.

    Using fixed costs is fine but Project 2010 introduced a new type of resource called a Cost resource. You may find the following site helpful and sorting out the various ways of assigning costs in Project 2010 and up:

    Hope this helps.


    Friday, July 31, 2015 3:42 PM
  • I followed the link and read it. It shows how to assign a fixed cost to a summary task, but does not say whether it should be done or not, or whether it is a good idea. That's a matter for user judgement.

    There is also an error in the instruction at point 5 where it says that the fixed cost will accrue at the start or end of the project, when it should say at the start or end of the task.

    I take the instructions at with a grain of salt.

    Saturday, August 1, 2015 12:36 AM
  • John and Trevor,

    Thanks for your inputs, I am presently working on a Sunday to meet a deadline, for which I am late and over-budget partially due to the assumption that upgrading from what ever version I was using last time to 2010 would not require this level of effort.

    Holiday booked for next week  so the link will have to wait until I'm back.


    Sunday, August 2, 2015 3:49 PM