What is the best mechanism for tracking costs associated with the development of IP products? We've got a number of projects that we're working on internally in hopes of turning them into publications and taking them to market. They cut across departments. My CEO thinks each project should be a cost center in our budget tracking but that seems to conflate projects with departments. I'm interested in hearing about tools and processes people have used to track costs associated with this sort of product.
Tracking costs of product development
Answers
Anon
You are on to the right thing...projects are different dimensions than cost centers.
Project numbers help gather costs for specific purposes (e.g. each internal IP project should have a budget); Cost centers help identify WHO spent the money.
They can, and should, co-exist in the situation you describe.
There is also a difference between a cost center budget (which normally rolls up to a company budget) and project budgets (which are often cross accounts and cost centers and do not represent ALL of the company's activities/costs). GL systems generally are good at company-division/region-account-cost center budgets.
For project budgeting however, actual time/cost tracking and reporting, you need to be able to add another dimension of budgets. Some GL systems do this via concepts like Project ID, Project
If your internal projects consume labor resources, you may need to consider a time/effort recording process as well as an AP process, to ensure you capture your IP project costs.
If you have any further questions, let me know.
We often use the Customer and Job/Projects concepts in this scenario. The Customer could be IP Projects, R&D. etc. Then the Jobs are the individual projects on which you are working. In this way, the costs can then be charged to both the project and the department as these are separate database fields.
I have seen cost centers used to track projects. I disagree from a G/L purist stand point as I don't like to use the G/L as a cost accounting/project system, However it can work. I have seen adding a digit or a suffix to the cost center to track projects. I think the method you use is also dependant on the costs you are tracking. If it's labor, do you have labor tracking within your financial system? If you do, you should also have project capturing capabilities and you don't have to use cost centers.
2
Patrick- I agree with your purist principle, as this is really a "poor man's response" but not really a solution. At some stage, reporting can become tricky.
Anon- while your question may be around IP projects, remember the principles can also apply to any other major discretionary spend, e.g.
Hi Patrick
Why don't you like to use the G/l as a cost accounting system?
Many of the newer accounting systems have the ability to track projects, departments or any other division you arbitrarily decide is important.
The actual expense (or transaction amount) ends up in the G/L account specified, but using the packages report writer, you can sort on those specific elements. Thus you can get a I/S for project X without an extra 6,000 G/L accounts.
An example of doing it the wrong way was a consulting job I did way back for MONY. They had a G/L that was 24 characters long (to the 36th power) and the Actuary who created the G/L was determine to use every conceivable possibility. I was of course overruled, but then again, MONY didn't survie and I'm sure those systems ultimately didn't work properly.
Projects should be tracked in a dedicated project accounting module, and integrated to the G/L via designated control accounts. All project(s) detail will accumulate in the project accounting module, with specific reporting capabilities built-in or user configured. The G/L will only "see" either summary or detail postings into the pre-defined control accounts. Using an additional G/L segment to track projects is generally not a good idea as it adds unnecessary detail to the G/L, complicates financial reporting and usually adds many G/L account combinations that can be easily avoided with a dedicated project module.
You should also use a budgeting system that can mimic these project G/L control accounts and have all relevant forecasted project activity assigned to these "Budget G/L Control Accounts". When you perform your periodic (e.g., monthly) actuals vs. budget analysis, you will see immediately how your foretasted project expenses compare with your actual project costs.
Another question to add on to this. Do you accumulate these project expenses on the balance sheet or expense them to the income statement as you go.
I worked for a company that had product development costs for software that they sold. The developers tracked their time in IBM Rational Rational ClearQuest, and then it was costed out in
To answer Steven's question, we were required by U.S. GAAP to capitalize those development costs that added functionality to the software or extended its useful life. They were added to the balance sheet as L/T assets, and amortized over the estimated useful life once released into production. R&D costs, bug fixes,
1
This is interesting. They way I read GAAP, development costs such as these are to be expensed. How do you distinguish which costs are expensed and which are amortized?
Accounting for software for sale to external users is governed by ASC 985-20 and is a fairly complex subject. Essentially, all costs in the preliminary project phase are to be expensed as incurred. Once technological feasibility has been established (i.e. a working model) costs are capitalized until the product is released. The development costs that I mentioned above were either new products prior to release or enhancements to existing products that added functionality or extended the useful life.
The determination as to which costs fit into this category and which ones were to be expensed were determined by the development team and their supervisors. They were given guidance by accounting personnel, but ultimately they had the technical knowledge to make the correct determination.
Filed Under:
FP&A