In many companies, a classic situation exists between project management and the finance department: both contribute to and need access to up-to-date project financial figures, but neither usually has a system that can provide all the information the other party requires in a timely, accurate and sufficiently detailed format. How can this be addressed?

 

Projects can play a big role in company finances, particularly if the majority of activity in a company is about the execution of projects. Financial managers and project managers alike will be concerned about whether the projects generate the expected profits and deliver at the right time, but the angle at which either party is looking at the project financials is different.

 

In order to keep control over a project, the project manager needs to have a detailed breakdown of all the project work and its associated budgets and expenses; while the financial manager will be more concerned if the project as a whole is within budget.

 

The problem becomes more complex if the number of project team members that can order non-labour items is large and there are many sub-budgets within the project associated with different levels in the work breakdown structure. If the financial system then, in addition to this, does not carry information to this level of detail, some or other project management support system is required.

 Projects are only a part of the total information in the financial system of the financial manager while it represents the majority of information that concerns the project manager. It is, therefore, inevitable that if the project manager cannot gain all the project information to the level of detail necessary to manage the project from the financial system, a separate project management system will be created to serve this purpose.

 This project management system usually also fulfils roles such as, for example, those of schedule and resource planning tools, which are closely related subjects for the project manager. Once a financial and a project management system exist, they need to represent the same truths about the project e.g. the total expenses reported by the one cannot be different from those reported by the other, or the project manager will soon lose control (and his job!) over the project.

 The project management system also can carry information that is required by the financial system e.g. total labour expenses per cost centre per month, and cash flow forecasts for the project. The financial system, in return, will have information that could be required by the project management system e.g. the actual value (influenced by, for example, the exchange rate) and other updated information about orders and sales.

 

Synchronisation challenges

 There can be many reasons why these two systems do not correspond at a given time – particularly while the project is running.

 

Manual transfer of data between the systems

 If data is transferred manually between the two systems, data could be entered incorrectly. Not only could values be transferred incorrectly, but actual expenses could be entered against the wrong project in the financial system.

 Transferred data that could be incorrect also can include fundamental information which is used to calculate other values e.g. exchange rates, cost centre or job classification or salary labour tariffs, etc.

 

Invoice vs. committed basis of accounting

 The financial system does accounting on an invoice basis i.e. the actual value of an expense is not recorded until an invoice and the goods ordered
are received.

 The project manager, on the other hand, needs to keep track of expenses within the project on a committed basis i.e. the moment the project manager (or his team members who have delegated authority) approves an expense, it should be subtracted from one of the budgets even though the order may not have been placed in the financial system yet. This is to prevent overspending on lower level budgets of the work breakdown structure, which is usually not detected by the financial system.

 The mechanism to apply for and approve of committed expenses can be implemented through the use of purchase requisition documents. There can be long delays between approval of the purchase requisition and delivery of the order, also known as “open purchase orders”, thus increasing the discrepancy between the value of actual expenses reported by the financial system and that of the project management system.

 Due to the fact that committed expenses lead their invoices in time, the former will usually reflect a larger value than the latter until the order is fully delivered. The project management system needs to keep track of both actual expenses (as defined by the financial system as goods received) and committed expenses (as defined by the project management system as goods approved for ordering) in order to be able to reconcile the two systems at regular intervals.

 

The effect of the exchange rate

 Sometimes, due to exchange rate fluctuations or other reasons, the invoiced value of orders can be different from the original quote by the supplier, and thus also be different from the associated purchase requisition document or committed values entered into the project management system.

 

Ad hoc and special project expenses

 There are sometimes certain expenses that are booked directly by finance to the project which are not necessarily taken into account by the purchase requisition or project management system. Examples could be courier costs and travel and subsistence expenses. These expenses need to be updated from the financial system to the project management system for the latter to be accurate.

 

The solution

 It is clear that in order to enable the project manager to manage his projects properly, he needs to be able to plan and monitor his project finances to a level of detail for which the information is usually not available in the financial system. He will then need to manage this information in a project management system. To address this, one of three approaches could be taken:

 

Conventional approach

 Here, the project managers and the financial managers each choose their own tools and these systems are
manually interfaced. This situation implies that each party can use its system of choice that (hopefully) will provide all the functionality that they each require within their specific discipline.

 Although this gives the project manager much better visibility into and control of his project rather than to obtain financial data directly from the financial system, the burden and risk of keeping the financial information in the project management system up to date with the financial system can
be prohibitive.

 The challenges mentioned earlier all need to be taken into account every time synchronisation between the two systems is required (e.g. at month end). Because the synchronisation does not occur in real time, the project management system will only be accurate immediately after an update, and the project manager will have to work with estimates for the remainder of the month until the next update.

 

All-in-one approach

 The company could deploy an all-in-one system that is capable of providing both financial and project management functionality (this article concerns itself only with these two disciplines, but the same applies to any other involved discipline and its associated management system e.g. human resources). Such an all-in-one system tries to be everything to everyone and usually excels in some of the areas while other areas are less mature.

 Many times, the core of the system originates as a financial system that is then extended to add, for example, project management functionality. The software companies that create these products seldom have expertise in all the disciplines they are integrating into their product.

 Due to the fact that a company usually first selects its financial system, by the time project management starts to look for a project management system, they find it difficult to motivate a project management system of their choice which is not already part of the existing financial system. These systems are usually expensive and do not always provide all the functionality that all involved parties require.

 

Integrating best-of-breed

 The third alternative is for financial management and project management to each choose its own system and to integrate them loosely. This can provide the best of the two previously mentioned approaches – each party has the best-of-breed system for its own use as well as automatic transfer of the relevant data between the systems.

 Only the data that the one system is dependent on the other system is transferred, and apart from that, the systems are not necessarily sharing anything else. This can imply that they could be running on different hardware, operating systems or database platforms mostly independent from each other.

 It also has the advantage that in the event that one of the systems is not available or offline, the other can still fulfil its functions – synchronisation between them will take place as soon as both are available again. This mode of operation is similar to the conventional approach discussed earlier, with the advantage that it will revert to the integrated approach once the other system is available again.

 The disadvantage of this approach is that if an out-of-the-box integration between your financial system and project management systems of choice does not already exist, you will have to pay for a custom integration of the systems.

 Additional expenses also could follow in future if either of the systems is upgraded and is no longer entirely compatible with the integration design (this can occur because the two systems are most likely independently designed and maintained by different software companies). In the case of a custom integration, the integration itself will have to be updated as well.

 The ideal answer will be to find a solution where your choice of best-of-breed systems is already integrated by a party that continues to support the integration because they have other clients who are using the same solution. In this way, you have, in effect, bought a ‘new’ product, offering the advantages of the all-in-one approach, but without the disadvantage of being forced to use those components that would not have been your first choice as a project management professional.

 Additional advantages of this approach can include:

 If one of the systems that are part of the integrated approach has functionality which is very powerful, it can be put to good use by users of one of the other integrated systems on any of the data shared between the systems. For example, if the project management system has powerful reporting or dashboard capabilities, and the financial system is less powerful or flexible in this regard, financial managers can use the project management system for such reporting requirements.

This ‘new’ integrated product can be extended indefinitely by adding more systems to it e.g. human resources, payroll, document, risk/issue, portfolio, configuration and other management systems. As long as the integration is supported and sustainable in the
long term.

Conclusion

 Financial management and project management (just to mention two management disciplines) each needs its own specialised systems. Although there is more than one approach to this, the ideal solution is to be able to use the best-of-breed system on both sides which are already integrated with the other by a party that supports their continued integration in the event of future upgrades to either of the systems.

 In this way, both financial and project management enjoy the best that technology can offer them, without being forced to use a system which would not have been their first choice. 

 

Chris Laker