Because yes, they are different. Let’s dive in!
1. The Dates are Different
Project accounting has start and end dates. Your project budget starts when the project starts. The accounting work ends when your project moves through closure and ties up all the contracts and you’re done.
Financial accounting is different. It is based on periods in a financial year. Your financial year will be different in different businesses. Mine starts in May, because that’s when my company was created. For ease, some businesses align their financial years to the tax year (that’s April to April in the UK) or the calendar year (January to December). Whatever works best for you and your team of accountants is OK.
Unfortunately this means that project accounting timetables and financial accounting timetables – what the rest of the business is doing beyond your project – rarely, if ever, align.
2. Reporting Is Based on Different Elements
Reporting in project accounting is based on deliverables. This won’t be news to you. In your project reports you’ll be tracking spend against a certain milestone or a product that you had to buy.
You could also track in a cost breakdown structure against the various deliverables or products that you are creating. Your costs are tied back to the things you are doing, the work you are producing and the output you are creating. It’s very easy to see that buying software licences is linked to the delivery of a new piece of software for the business.
In financial accounting reports, they don’t relate to deliverables. Financial accounting looks at other aspects of running a business, like profit and loss, something that projects don’t much have to worry about.
There’s another difference in the reporting and that’s depreciation. If you are installing assets over a long period of time, as I did on a 18-month software rollout project, your financial accountants will be depreciating the assets behind the scenes. You probably never have to know that this is happening, but it is, based on your company’s defined policy.
On a project, the costs are calculated when invoices are received. If you should be depreciating those assets to spread the cost, it’s done by financial accountants afterwards. I have never met anyone or come across any policy that says this is an expected part of project accounting, so you shouldn’t have to deal with it in your project reports.
3. The Cost Hierarchies are Different
Project accounting hierarchies are based on tasks and projects. Your project costs relate to costs generated by deliverables and project activities.
Rolled up, you can see the costs per project.
Rolled up even further, your programme office can see costs for the programme.
Rolled up even further, your portfolio office can see costs for the business projects overall. They can see which departments have the most project-related spend and cut the project cost data in any way they like.
Financial accounting hierarchies are based on departments and cost centres. You might need to know the cost centres for your work so that you can bill your project costs to the right place. I have worked on a big project with its own cost centre.
But generally the approach financial accounting takes to drilling down or rolling up is different to how you would look at project-related spend.
4. Comparative Analysis Is Different
Comparing project costs across projects is hard. How is it possible to compare the relative costs of a multi-million pound project with huge benefits to the relatively small costs of upgrading a server for one of your offices? And what would the value in that comparison even be?
It’s possible to compare costs against projects in a meaningful way only if the projects are similar. There needs to be a consistent structure for coding the costs on the project, for example, standard cost codes for expense items.
And it’s important to look at why you would want to do that. It can be interesting to do a comparison across projects if you think you’ll be able to find out more about the financial exposure for the business. It might help you understand what is going on across the business at portfolio level if you are able to split and compare costs like this. And it’s helpful for comparing benefits, where it makes sense for projects to compare their benefits.
Comparative analysis in financial accounting is comparatively easy (see what I did there?). You look back at costs for the previous period or the same period in the previous year. Then spot the differences. Simple, and a lot more meaningful.
5. Level of Understanding is Different
Stakeholders don’t always understand project accounting. Your project sponsor probably has some idea of the fact that you shouldn’t be spending it all in one go, but they probably don’t understand the way that you have to process invoices or the quirks of assigning money to capital. Or perhaps they do. You are bound, however, to come across some project stakeholders who don’t get how to spend money on a project in a way that fits with the rules. These ar the people who want changes done but don’t want to pay for them!
On the other hand, most leaders understand financial accounting principles. These are the things taught on MBAs and on the Finance for Non-Financial Managers courses.
In this video I share 5 differences between what it means to do accounting on your project (and manage the financials/budget) and how financial accounting can work. Understanding these differences makes it easier for you to work with your Finance teams and run your project budgeting processes.
5 Facts from Project Management Accounting
In this video I talk about 4 pitfalls of project estimating.
OK, so we all know budgets change from time to time (normally being reduced unless you’ve got a great reason for your sponsor to give you more, like a change). But aside from office politics and the change control process, there are other things that can affect your project budget. Here are 4 risks to consider when both putting your risk log together and your budget.
1. Gold plating
Gold plating is where the project team adds stuff into the project scope without the customers asking for it. It often happens on software design projects, where the developers know they can add extra functionality to improve the product, so they do. Even if the customer didn’t want it, and didn’t know they could ask for it, the team do it.
You’d be forgiven for thinking that gold plating is a good thing. After all, what project customer isn’t going to want more for their money? It’s the bells and whistles that set your project team aside from any other project team.
However, if your team is working on tasks that are not on the project schedule, that costs you money. It takes time to do extra work, so whether they realise or not, they are helping the project go over budget through their enthusiasm. Talk to the team about the proper change control process and make sure that they are only working on what is approved.
2. Scope creep
Scope creep is something that all project managers have come across at some time in their career. You start off with a narrow, well-defined scope and by the end of the project it’s become a rambling monster of requirements. This is different from gold plating – the team are working on things that are approved, it’s just that the approved work stretches the scope way beyond what was originally agreed.
Scope creep takes many forms, and can be through a poor change control process. If everything gets approved, then you know that your change process is not rigorous enough! While many changes put forward will be good, useful suggestions, some will take the project outside of its original goals and objectives. Should they really be included in this project or would it be better to manage those requirements in another way?
Scope creep adds time to your project, and therefore cost.
3. Failed QA systems
Quality Assurance (QA) makes sure that your deliverables are fit for purpose. Whether your QA system is peer reviewing lines of code or stress testing bricks off a production line, you should have some method of checking your work before you give it to the client.
Poor QA means that deliverables will make it through to the customer only to be rejected. The customer will not sign off on poor quality work, so it is far more beneficial for you to catch mistakes early on. This will reduce the amount of testing required and also give you more of a chance of your deliverables being approved by your client.
Deliverables that are rejected will have to be done again, and by the time the work has got into the client’s hands for approval, it is likely to be costly to make changes and complete rework. It is far better to catch poor quality early so that you can rectify it while it’s still cheap enough to do so.
4. Currency fluctuation
Not all projects will suffer from currency fluctuation, but if you are working with an international team, this could happen to your project. The problem comes when you budget at a certain exchange rate but of course are charged the exchange rate of the day when the invoices come in. In some cases the discrepancy between what you had planned to pay and what you actually pay can be hundreds of dollars (or euro, or yen etc).
It’s hard to plan for this, but you can make your budget a bit more robust by including a percentage contingency to cope with currency fluctuations. Only you will know what seems appropriate given the overall spend of your project and the amount to be spent in foreign currency. Talk to your accounting department as they may be able to advise on how best to manage this.
You can probably think of many more risks to your budget, but these 4 make a good starting point for budget risk planning with your team. What else do you normally include on your risk register when it comes to money?