The Money Files

Project expenses aren’t always spread evenly throughout the life of a project. Understanding how costs are split is one way to make sure that your project budget is appropriately phased. For example, if you will incur more costs at the beginning, then you’ll need to factor that in to the budget. If you will pay out lots of money at the end, you need to factor that in as well, to make sure that you have some money left!

Here are 3 ways that costs can be linked to project activities.

Start of activity

Some projects incur the majority of their costs at the beginning. Examples would be:

• Buying hardware like servers so that the rest of the project can use them for development effort.
• Software licences that are required up front before you can start using the product.
• Buying equipment or heavy machinery that enables you to produce the output of a project, for example if you are making widgets.
• Buying a building for the project team to work in or a building for the project, such as a shop or work facility.

In this case, you’ll want to make sure that your project budget is available to you as soon as you start the project, and isn’t phased by quarter or reliant on some cash flow issue being resolved. You’ll need to spend a large chunk of your budget from day 1, so talk to your project sponsor or your project accountant and make sure that the provisions are available for you.

End of activity

Some projects incur costs at the end of the project. This could be, for example:

• Paying a contractor in one lump sum for the work they have done, on completion of that work.
• Paying for equipment retrospectively, if you have managed to negotiate a period of lease or free use until project completion.

In this situation, you’ll need to make sure that your project funds are still available to you at the end of the project. Finance teams often review budgets and if it looks as if you aren’t spending much of your project budget, they might ask for some of it back! It’s good to be able to justify why you need to hang on to the cash, so that you guarantee it is still available to you when you come to need it at the end.

Uniformly spread across activity

The third way that project costs can be linked to activities is through being spread evenly across the lifecycle of the project. Some examples of this are:

• Paying contractors monthly.
• Paying third parties monthly or regular service fees, such as for the provision of online project management software.
• Subscriptions.
• Property or machinery leases that require a regular payment, such as monthly or quarterly, in advance or in arrears.

This is probably the easiest type of split to manage. Regular payments for regular activities means that your budget will be consumed in an even way across the lifecycle of the project. You can quickly see if you are half way through the project then you should be about half way through your budget too.

Of course, one project could use all of these, as different activities could have different spreads of costs. You’ll have to take that into account when you plan how your budget is phased. If that is the case for you, you’ll also have to consider phasing per task/activity/item as well as what the overall profile looks like. That way you can build up a picture of how much money you’ll need when.

Which is the model that your project uses, or do you phase your project budget in a different way?

In my last video I talked about the role of the Accounts Payable team and how they can help you as a project manager. There’s another team in the Finance department that can also help you, and that is the team that are the general accountants who maintain the books for the company because they will be doing some reports on the finances that you can then compare to your own reports.

Again, in a large company you may well have a team of accountants, capital accountants tend to deal with capital expenditure and the majority of project expenditure, at least under UK regulations, would come under capital expenditure. So you may well have capital accountants and accountants that deal with other things or you may have a multi-functional accountant who does all kinds of expenditure tracking as part of his or her daily role.

As a project manager you’ll be tracking your project expenditure especially for goods and services for the things that you buy for carrying out your project. But you are not the only person in your company who has an interest in how the company’s money is being. The accts will also be looking at overall where the organisation’s money is going. They will then keep a track, and if they can keep a track of the money that is related to your project, perhaps with a particular project code, you can then compare the reports that coming out of the Finance department from the accountants with your own project logs.

That’s really important as it’s quite likely that the company’s senior stakeholders will take what is recorded on the Finance reports as the final state of play. After all, they are the accountants, they know exactly what invoices have been paid and they know everything there is to know about accruals. And your spreadsheet is likely to just be a list of things that the project has spent. So in terms of recognising expenditure in terms of formal accounts, what the accountants have is likely to be the truth, at least in the eyes of the senior stakeholders.

So every so often I would recommend that you find the accountant who is responsible for tracking the area of the company where you project falls and sit down with him or her and compare your reports, your tracking spreadsheet with the data that that person is reporting as part of the overall company expenses.

I have done that recently and it is very interesting to see where there is a discrepancy. And we did find a discrepancy and we then found out what the issue was and why the two sets of reports were different. So it’s important to be able to dig down into the data if you do find problems and make sure you are on the same page as your company Finance team.

Think of your project like a computer.

The culture of your project team is the operating system.

The project objectives are the applications you run on it.

You can set any objectives you want for the team. You can ask them to deliver on time, on budget and on scope. You can ask them to be customer-centric. You can encourage them to schedule their own time effectively, using any number of software products.

But, if the culture doesn’t support it, you will struggle to get your objectives done. Understanding organisational culture will help you manage project risk and get a better outcome for your project!

Risk is inherent to all projects, and you need to know the risk profile of your project in order to be able to budget accordingly and prepare your contingency funds. So what does make a project risky?

In his book, Risk Happens: Managing Risk and Avoiding Failure in Business Projects, Mike Clayton shares some of the typical factors that bump up the risk level on projects. These are categorised into 4 areas.

Strategic

Strategic factors include weaknesses due to operational strategy. For example, if there is a weak link between the objectives of the project and the organisation’s goals, that increases project risk. Poor sponsorship and buy-in at senior levels also increases the risk of a project. This can lead to unrealistic expectations – again, another risk factor. Finally, if you have a poorly defined scope, or project goals that keep changing, you increase the risk of the project.

Capability

Even strong project sponsorship and clear goals won’t help you if you or your project team don’t have the skills to do a good job. Poor processes in place across the project organisation can also increase the risk levels on the project, especially if these are not designed to be scaled up (or down) to fit the size of your project. Finally, if your team is under-resourced this also influences the risk profile.

Process factors

Processes keep projects running. Communication is one process that has a major impact on project risk. Don’t forget communication between the team and any partner organisations, as well as communication between team members and other internal departments. Using technology that doesn’t work because it hasn’t been properly tested, or technology that you don’t really understand are also ways to increase the project risk profile. Inadequate (or non-existent) governance processes including a suitable way to quality assure your project are contributing factors to increasing risk.

Organisational factors

How the organisation works can also influence the risk levels on the project. For example, low morale across the company makes a project more risky, as does resistance to change. If your company is focused on price and cost as the way to determine if something provides good value, that could also introduce more risk to your project. That ties into immature procurement practices – buying stuff is normally a risky area of projects anyway, so a poor organisational approach to procurement can have a detrimental effect on project risk.

Managing risk

You can use these four headings as way to categorise and structure your risk log. I’m sure you’ll also find that there are other risks affecting your project that don’t fit into these headings – there are a number of other ways to structure and organise risk logs, so you should adapt your own to meet the needs of your project and your team.

What additional factors do you consider that increase the risk profile of your project? And how do you manage them?

As this month's theme is project management at the cutting edge, I thought I would share with you this extract from my new book, Customer-Centric Project Management, which gives a new take on the traditional approaches to stakeholder management and post-project reviews.

Putting customers – and by that we mean internal colleagues or third party partners who take a service from another department – at the heart of how we work is a worthy aim. Companies spend a lot of time on focus groups and surveying end customers – consumers who buy products – but not a lot of time looking at how departments within the company serve each other. There might be an annual staff satisfaction survey which is the opportunity to air views on how different teams work together, but this type of conversation is rarely routine. Once you realize that as a team, you have internal customers too, making yourself easy to do business with is the next logical step. Customer centricity is a mindset; a way of working. It is, however, very hard to measure attitudes and behaviours in any unequivocal way.

Exceed was designed to provide an unequivocal way to answer the key question that keeps senior executives in PMOs and other delivery teams awake at night: how good is my organization? To answer that, you need clarity of customer perception, a focus on customer engagement and the deliverables that matter to project customers.

We use a process called Exceed to measure customer satisfaction with the project management process. It was developed to establish the basis of real agreement about the value being provided to stakeholders, and to develop closer engagement with customers using language that everyone could relate to. Here’s how it all began.

A global financial services company successfully implemented a customer-centric approach in its IT department. The IT service delivery function was already highly efficient, having demonstrated continual successes through a number of initiatives. Rationalization, in-sourcing and outsourcing had delivered operational savings of over £1m for three consecutive years. A further project to implement a technical support centre with a 50–strong team in India within nine months of board approval reduced annual spend by a further £1.8m. This project was completed without disruption to service, on time and to budget and proved the ability of IT to successfully deliver complex technical and sensitive projects in a very short timescale.

Shortly after this latest success, the CIO found himself in a frustrating position. The head of the company’s retail division had rung him to complain that the software updates his team desperately needed had not been implemented as promised.

The CIO’s department had a record of regular cost reduction and project delivery. That very week, the retail division had benefited from a further £250,000 cost reduction, delivered directly to this manager’s bottom line as a result of a telecoms contract renegotiation carried out by IT. However, without the software updates, retail branches could not satisfy their customers. The financial results may have been good, but they did nothing to improve customer service or the perception of IT within the retail division.

There are a number of morals to this story. Delivery organizations – and project teams are delivery organizations – need to clearly understand how to fully satisfy all of their customers’ needs at all times and in every situation. There also needs to be an agreed and credible process which proves the quality of the level of service being provided. In this case the IT team was doing a good job. Or were they? Who thought so? In fact, what really defines success for an organization, project or service and how do we measure and quantify it? After all, customers and stakeholders come in all shapes and sizes. They are not only demanding – their requirements are diverse and not always feasible or realistic.

Customer-centric thinking cuts through the confusion by answering a number of key questions:

• How professional is my operation?
• How good are we at delivering services or projects?
• What does good look like for us?

These are the questions that need answering if you are going to truly be customer-centric. Exceed is the process we use to get there.

The Exceed process in his department began with a simple vision: ‘Every customer of IT service delivery will continually rate the services we provide as Good, Very Good or Excellent’. While you might think that this vision could never be achieved, the team achieved rapid results from the first few weeks and they fully achieved this vision in less than six months.

There wasn’t anything special about this particular CIO or his organization. It was just about putting the customer front and centre and working in a customer-centric way.

And that’s how we started to work with project teams and sponsors in a customer-centric way.

This is an edited extract from Customer-Centric Project Managementby Elizabeth Harrin and Phil Peplow (Gower, 2012).