Project Management Software
Specialists in Project Infrastructure
This white paper is an attempt to think outside the box and look at some non-standard accounting practices that might make project accounting more effective. If someone would like to take some of these ideas, and incorporate them into an accounting package please do so. Just let me know so that I can buy and use the package afterwards.
Granularity of Project Accounts
One ongoing problem is in the analysis of accounts. You might have one account for equipment.
That may be the way your budget was developed and you want to track the estimates at that level.
If there was some way to tag expenditure that could provide the required groupings, it would make the life of a project manager much simpler. You probably need multiple tags as you might want to know if it was air conditioning ducting, and also who bought it, and who installed it. What is needed is a series of tags that can be attached to any expenditure item. Reporting on a particular tag would be available to the project manager as well as the ability to select a number of tags and report against those.
Release of Funds for Projects
On day one of a project, the total funding is never clear. Very often when a project achieves budget it is because the scope was trimmed to suit the budget. It may have been presented as a timeboxed project where we deliver what we can within the time available, but in effect, it is scope trimming. Depending on the nature of the project, the variation to the first estimate may be anywhere up to hundreds of percent out. I was recently looking at a project where the initial estimate in 2000 was $170k and it was stopped in 2005 after $7m had been spent.
If you want to be creative, what if the only funds granted were for chunks of work where the estimate was permitted to be within 10%. For example, an amount of money is made available to undertake analysis. The deliverables are defined, and the cost is determined. Once the analysis is complete, another funding allocation is requested to do the proof of concept.
Of course many would cringe that you have to go back to a funding authority to get the next chunk of money. There is certainly an overhead. It does however change the mentality of the team to plan and cost each piece of work in a lot more detail. If there is an initial estimate which is structured around each piece of work, it also provides an early warning system that the project is off track.
For example, suppose we have the following first cut estimate:
If the request comes mid way through the analysis, it gives the approving body the option to say
“We have spent 15k. What have we learned and is it worth continuing?”
If they decide to cut their losses and abandon the project, they have burnt the initial $10K and possibly another $15k. In a normal project, the team might keep going hoping to recoup part of the over expenditure later in the project. The approving body may never know that the project is now looking like it will overspend.
Project Funding Approval Body
Another concept worth considering is the actual Approving Body. I have seen teams spend weeks to put together a business case or funding request then sit around for weeks waiting approval. Surely there is a simpler way? In the interest of creative project accounting, let me offer another approach.
Approval of a business case is based around the total cost, and the benefits it can deliver. It is an essential part of a project, and cannot be ignored. There is often however, myriad detail in the costing that is not particularly relevant. Approval of a business case should be a big picture activity. If it starts to focus on the detail, it is probably missing the point.
For example I have seen a $400k request to a capitol approval committee spend hours reviewing the money allocated to training. It was argued that there was not the need to spend $20k. It should be more like $10k to $15k. The submission went back and forth to the committee over 3 monthly meetings and was eventually approved after a delay of 2 months. When the project came to develop the training, they ended up spending over $20k and came in over budget. What was achieved was:
Even if the amount was too high, was it worth delaying the project for two months? The point of all this is that a budget is subjective in many cases. Unless it looks wildly inaccurate, if the numbers make sense, it should go ahead.
Another Approval Approach
A better approach is to have levels of approval. A senior approval authority give first approval with parameters. For example, for the first approval, the project budget is approved but there is a 20% variation before it comes back to the senior approval authority. The percentage can be set by the approval authority.
The next level is the actual allocation of real money. In line with a chunking approach, the Sponsor has authority to release chunks of money for specific pieces of work within the approved budget. At the end of each piece of work, a forward estimate is provided for the remaining work. Provided it is within the approved budget, and the Sponsor agrees to the next stage, the money is released.
The 20% variation comes into play in that the Sponsor can agree to continue if the budget estimate goes over 10% of the agreed budget but must advise the Senior Approving Authority that the project is expected to exceed the budget and the reason why. If the estimate exceeds 20% of the approved budget, the project needs to go back with a revised funding request.
Example Project Budget Approval Approach
The benefits of this approach are:
In parallel with this approach to funding should be a parallel approach to benefits. If estimated benefits change, they should also trigger a review.
I recently visited a smallish client who was undertaking around 400 projects a year. They had a timesheeting program which did some nice workflow things such as forwarding for approval and triggering emails if the sheet was not completed. They also had Microsoft Project for some projects. In addition, they put capitol purchases through their accounting system. The also had an estimating package, and their quotes were in the estimating package.
In a nutshell, the estimates were in their estimating package, the plan was in Project (sometimes), the time spent was in a worksheet package, and the capitol expenditure was in their accounting system.
They were considering a Crystal report to pull information from the four sources to get a picture of each job. Now I am sure there are packages out there that will do the whole end to end job, but does it need to be that complex? Without going to an ERP type package, is there something that will pull all the information out of the various packages and present a consolidated report? I know Project Server goes part of the way however it seems that there is an opportunity to have an accounting system that links to a number of project related tools.
What I want to see is:
Real versus Actual Project Expenditure
Accountants cringe when I talk of running two sets of books. In projects there is a need to do so to differentiate between real and actual expenditure:
If the project is being approved on the basis of actual expenditure, the organisation is fooling itself. This is not a valid cost benefit analysis. I have heard people say
“Well, we pay for the people anyway so why charge them to the project?”
If the people have time to spend on the project it either indicates they have too much free time on their hands, or other work is not being done. In the end, looking at the general ledger and believing that you are looking at the real cost of the project is usually a fallacy.
You might say
“So what? What harm does it do?”
The harm comes in the cost benefit analysis as mentioned above. It also comes in the misguided view that an externally sourced solution is more expensive.
Take the following example.
The organisation decides to build on financial grounds. Here are the potential flaws in their logic.
We have raised another financial issue here in the estimation and tracking of future costs. It would be a nice feature if a financial package was able to set an estimate for future cost of a system and report on a regular basis against that estimate. Perhaps this is getting more into financial modeling, but because there is no facility to track the estimated cost over a long period, it is generally forgotten as soon as the project is complete – that is assuming it was considered in the first place.
Above are a few of the frustrations that project managers face when dealing with financials. Typically there is no integration between the corporate GL and what the project manager uses for tracking. Surprises are a regular occurrence, and management information is usually hard to extract.
What is required is a re-think in how we manage the money. This white paper is an attempt to “stir the pot” and drive out some creative solutions to financial management. It has tried to look at both processes and tools, and suggest some different ways of doing things. Hopefully it will result in a few ideas being tried and those experiences will make projects both easier to manage financially, and more accountable. Let me know your thoughts.