The Money Files

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).

When do you really know how much a project will cost? At the beginning, when you work out the business case? During the project start up phase, where you prepare your budget and establish the processes to track spending? While you are using Earned Value Management and can forecast forward predicted spend? After you have spent your contingency budget? When you do the close out report?

There are so many moments where you can calculate your project’s cost. Michael Cavanagh, in his book Second Order Project Management (Gower, 2012), argues that none of the points I have mentioned are right.

He believes that you don’t find out how much your project is going to cost until after the project is complete – a long time after.

“Although it has been said often that the only time you know the cost and duration of a project is when it has been delivered, in truth, you don’t,” he writes. “Post-delivery costs including fault correction, maintenance, support and disposal are all subject to the vagaries of implementation in the real world and should be addressed and included in the estimation process.”

In other words, you’ll never know during the project implementation what the overall cost of your project will be. This is perhaps less of a problem for the project manager. I think you can justifiably say that we are only responsible for managing the budget up until the point the project is closed. That’s what we plan for and budget for, and manage towards. Any costs that are incurred after this are not part of the project and therefore Not Our Problem. Project managers manage project costs, and as soon as it stops being a project cost it is hard to consider it our responsibility.

However, this is a problem for the contracting process. You can’t have a project that enters into a contract where the contract is only fit for the project stage. Unless your contract is with a vendor who will only be around during the project implementation, like a hired-help contractor. If you are buying software or a service, or equipment, you want the contract to include maintenance and support. Those are after-the-project costs.

So while you might not know how much your project will cost overall, you can do something about helping the operational team who come after you to manage their costs. Get them involved in the contracting. Ask them how they manage ongoing costs and how you should be factoring this in. What is the lifespan of the product or equipment you are buying? What decommissioning costs should you factor in? Ideally get the project sponsor or the operational team representative to represent themselves during the contract discussions. You’ll get a better result, even if it does mean sitting in the room with lawyers for several days.

Do operational teams get involved with preparing the cost predictions for projects in your company? And when do you think the responsibility of the project manager ends when it comes to managing the budget?