The Money Files

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?

Transcript

As a project manager you are not the only person in your company who is interested in tracking where the organisation’s money goes. As well as the project expenses the Finance team will also track all company expenditure but they can be a great ally when you are looking at project costs.

If your project costs include more than just staff time you could potentially be buying goods and services as part of your project. Your role will include authorising purchase orders, raising them and checking when the invoices come in and processing the invoices. Your role could also include working with suppliers when they don’t get paid on time to try to resolve any payment queries. Now the team in your company’s Finance department who will be the most help to you with all that is the Accounts Payable team.

In a large company you may have an Accounts Payable team made up of a number of different people but you could also have a multi-functional Finance person who provides Accounts Payable services, if you like, as part of their role. So the first step is to find out who deals with Accounts Payable.

An account payable is something where you have received an invoice and the company needs to pay it. As a project manager the things that you are most likely to be buying are goods and services. There is normally – well, there should be – a wall between people who can approve invoices and people who can actually press the button to pay the money that goes out the door of the company. That’s so that people can’t raise invoices to themselves and then process the invoice and pay themselves. So it’s a security feature and it’s quite an important thing.

So you may well be able to submit the invoice for payment but you won’t ever see anything to do with the bank accounts. That’s what the Accounts Payable team will do on your behalf. The most useful thing that they can do apart from that general administration and processing of invoices is helping you resolve queries with suppliers. If suppliers come back to you and say that they haven’t been paid on time, it is that person that you will need to ring to find out how you need to get the invoice processed, if there is a problem with the invoice, why it’s got stuck, maybe they didn’t receive it, maybe the money has been paid but it’s gone to potentially a different account, and they can deal with all those things for you.

That’s a really good relationship to have as a project manager as it can smooth out queries with suppliers. So if you know who to talk to in Finance for invoicing queries you can build better relationships with the people who are working with you on your project.