Author: Neville Turbit

Overview

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.

• In an IT project, you might want to know how much was spent on servers and how much on switches and routers.
• In a construction project you might want to know how much was spent on air conditioning plant and how much on ducting.

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:

• We have a total budget of 135k.
• The initial allocation is made to spend 10k to kick off the project.
• Once a plan is developed for Analysis, a request is made to fund Analysis to the tune of $30k.
• If the Analysis becomes much more complex than anticipated, and it suddenly looks like it will cost $50k, the team has to ask for an additional $20k.

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:

• A two month delay to the project
• Time spent refining and arguing one small part of the project
• A budget with one component that the team believed was, and proved to be, unrealistic

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

• A project is agreed by the Senior Approval Authority. It has an approved budget of $100k and a variation of $20k (20%)
• The first chunk of work is $20k and is approved by the Sponsor
• The work is completed for $20k
• A new estimate is done based on the work in stage 1 and the overall budget is now $110k
• The next piece of work is estimated at 30k
• The Sponsor agrees to release the $30k and advises the Senior Approval Authority that the project is now expected to cost $110k (now 10% over the approved $100k)
• As the work progresses, the team realize the estimate is too low. The 2nd piece of work estimated at $30k will now cost $45k to complete. They advise the Sponsor that the cost is now likely to be $125k for the whole project. This assumes the subsequent phases are correctly estimated.
• A revised business case now needs to be re-submitted to the Senior Approval Authority

Benefits

The benefits of this approach are:

• The business case approval is done on a high level estimate without becoming bogged down in the detail. The focus is on the big picture.
• There is a recognition that an early estimate is likely to be rubbery
• The Sponsor is given authority and accountability for how the money is spent.
• A chunked approach ensures more attention to the cost to complete
• The Senior Approval Authority does not have to approve small increases hence the project can keep moving without becoming frozen awaiting approval

In parallel with this approach to funding should be a parallel approach to benefits. If estimated benefits change, they should also trigger a review.

Consolidated Reporting

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:

• The original quotation broken down by component (perhaps account code, or stage, or deliverables)
• The schedule to support that plan
• The latest schedule to complete the project including resource projections
• The time spent against the schedule and the cost of those resources
• Capitol expenditure incurred to date (both actual and accrued) and projected expenditure
• Performance against budget on a projected cash flow basis

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:

• Actual expenditure is what shows up in the general ledger as the cost of the project
• Real expenditure is the costs that get absorbed elsewhere. For example the cost of using internal resources to provide requirements.

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 cost of building an internal system is estimated at $100k.
• Buying an external system is estimated at $150k.

The organisation decides to build on financial grounds. Here are the potential flaws in their logic.

• No consideration of the additional demands on internal resources in designing and testing the internal solution
• No consideration of TCO (Total Cost of Ownership). What will it cost to support and maintain the application if it is built internally versus the support costs from a vendor for an external solution.
• No consideration of upgrade costs. Requirements for additional features are bound to arise. What is the projected cost to add features versus upgrading top a new version of a commercial solution?
• No consideration of business impacts. What is the cost of changing business processes to fit both new solutions? This may in fact work in the favour of the in-house solution

Benefit Reporting

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.

Summary

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.

Copyright Project Perfect