Anibal Has a Related Question
" Thanks Max,
Just one more specific question that will help me to articulate the issue I have.
The way we work here is that we are a standardized central finance team and one of the functions is to support Project Managers, to adhere to the group finance policies and processes.
The PM has been made accountable for accruals in their project portfolio. Recently, the finance team has performed an exercise to evaluate the accuracy of those accruals against invoices paid, and the results were astonishing. You mentioned that accruals should not be part of a project accounting process. So I would like to understand why? And if you can perhaps give me an example to understand and link it to our results.
Thanks.
Regards,
Anibal"
To this we responded
"Hello again Anibal, we are getting into deep water here -- as they say: "The devil is in the details".
I don't think I said anything about "accruals" per se. By "accruals" I assume that you mean: "money added as a result of periodic growth"? If that is true, then I don't expect a project or project portfolio to have any significant return on investment until completed -- it is all on the expense side. It is true that as projects progress they are on their way to an ROI [Return on Investment], but the ROI is notional at that point and any assumptions made in that respect seem to me to be very dangerous, perhaps even misleading.
However, if by "accruals" you are referring to the amount of a commitment actually consumed to a given date, but not yet invoiced, or possibly invoiced but not yet approved, or even invoiced and approved but not yet paid (i.e. check cashed) then that indeed should be included in the project's cost status as of a given date report. And by the same token, the balance of that commitment plus all other now expected expenditures to complete the project should be included in the project's estimated "forecast-to-complete".
The problem with all of this is that the cost-to-date, e.g. how far along we are with the consumption of a commitment is an estimate, and how much is in the future cost is also an estimate. So without a detailed analysis the best we have is a best guess, and by tomorrow the figures will be different anyway. In other words, the value of the answer is questionable. Besides, the primary responsibility of the project manager is to get the job done, not fiddle with finances.
Yet, for a large commitment, like the delivery of a piece of equipment, the sudden appearance of the payment for the item on the ledgers can be a shock for accountants responsible for managing cash flow.
Which is why I advocate for a separate project management accounting system that is designed for the type of project under review and that deals with issues such as I have described. And in particular recognizes that estimates are a necessary part of such a system, and that estimating is not an exact science and should be applied only where necessary with practical common sense."
--- ------ ---
As a point of interest regarding ROI, Figure 1 shows a typical cash flow for a project and its product life span. Note that during the project, the cash flow is all on the expense side. Note also the effect of the quality of project management on the ultimate earning power of the product. That is, skimpy project management may result in a cheaper product, but the product's return may risk a substantially shortfall in the long run.
Figure 1: Project/product cash flow over the entire life span[1]
1. Reproduced with permission from A Management Framework for Project, Program and Portfolio Integration, by R. Max Wideman, Trafford, 2004, Figure 8-9, p114
|
What
can Financial Accounting Do for Projects?
