The Money Files

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.

Do you have contingency on your project? In Eliyahu Goldratt’s book Critical Chain he calls it safety, but whatever name for it you use, most projects have an element of budget provision put aside in case of emergency.

Let’s start with a definition of what management reserves and contingency reserves are, taken from Michel Thiry’s book, Program Management.

Contingency reserve: “a planned amount of money or time which is added to an estimate to address a specific risk.”

Management reserve: “a planned amount of money or time which is added to an estimate to address unforeseeable situations.”

Can you see the difference?

Contingency reserves

When you work out the contingency reserve for a task or project estimate, you do so based on project risk. How do you want to respond to that risk? Most times risk responses require cash or extra time to put a plan in action. The amount of contingency allocated depends on the risk and also on the risk response.

As contingencies are linked to particular risks, if the risk passes and is not realised, the need for the contingency goes away. That means returning the cash, or taking any extra time out of the task schedule. You don’t get to keep the contingency ‘in the bank’. If you feel that you need to, it’s probably because another risk is looming on the horizon. If that is the case, you should increase the contingency related to that risk and make your plans accordingly. It is OK to change your contingency strategies as you go forward with the project – after all, as you get nearer to a particular risk event you find out more about it and have more knowledge about how you would deal with it and that is quite likely to change your response.

Management reserves

Every project could do with one of these! However, in my experience few projects have them. A management reserve is a pot of money of a size that is based on the overall uncertainty of the project. For example, if you are doing an innovative project that your company has little experience of, you would want a big pot of money (or time) as your reserve. If you are working on something relatively straightforward, perhaps something that your company has run several times before, you wouldn’t need such a large amount or in some cases any amount of management reserve at all.

Management reserves are generally calculated using that well-known finger-in-the-air method, although it would be good to think that they are scientifically worked out based on the experience of the company and historical data extrapolated from previous relevant projects both at your company and across your industry. However, it is more likely that you just guess.

Management reserves are only used in emergencies, and that is the reason (in my opinion) that many projects don’t have them. The default for projects without management reserves is to go back to the project sponsor, explain the situation and ask for more cash, or more time. If you can do that anyway, what’s the point in having a management reserve? You still have to ask permission before you dip into the reserve, so the actual process for getting your hands on the money or authority to change the delivery date is the same.

A management reserve means that at least the money is put aside for you, and you avoid the situation where the project sponsor says that there is no additional budget available for your project – in which case you’d be stuck finding a way to deliver what you needed with the available money, which would probably involve changing the timescale or compromising on quality (the classic iron triangle constraint).

You don’t give back what is left of your management reserve when the crisis has passed. The pot stays active until the end of the project, although you may find that towards the end of the project when you have more certainty about how things will unfold, you can give back some of the money or use it for something else.

Now that you know more about management and contingency reserves, do you have these on your projects?

Over at A Girl’s Guide to Project Management we’re running the annual Summer of Books event, so I thought you might like to join in the fun over here.

Turn the Ship Around: How to Create Leadership at Every Level is a leadership book by David Marquet. It’s the story of how he commanded a U.S. nuclear submarine and took it from one of the poor performers to one of the top performers in the fleet. Each chapter includes a story from below deck and also the leadership lesson that non-naval managers can take from this.

"Leadership,” writes Stephen Covey in the Foreword, “is communicating to people their worth and potential so clearly that they are inspired to see it in themselves."

In the naval academy, Marquet learned that leadership is about controlling people. This is the standard ‘leader-follower’ model. What Marquet realised is that this model relies on the leader to be there all the time, setting the direction unfailingly. When the leader leaves (or goes to sleep when off-shift), the followers don’t have that direction any more.

"People who are treated as followers have the expectations of followers and act like followers,” he writes. While that doesn't matter much for many things like sports teams, it does for nuclear submarine. He says that we are taught that empowerment is the answer. "While the message is 'empowerment', the method – it takes me to empower you –fundamentally disempowers employees." Fair point.

On a project, leadership is important. You don’t have to be there 24/7 leading your project team, but you should be concerned about what happens when you are on holiday or out of the office. Can they operate the ship without you? Marquet set about to ensure that everyone could operate without him if necessary, and calls this the ‘leader-leader’ model. It’s also appropriate for keeping a team performing at high levels even after the person at the top is replaced, so it’s a longer term strategy than ‘leader-follower’, and it encourages leaders to be responsible for the performance of their unit long term, even after they have gone.

The book  explains how Marquet got his sub to this level. One of the things I took from this book that is particularly appropriate to project environments is delegating down.

Delegate down

"Don't move information to authority, move authority to the information," Marquet writes. He gives the example of getting leave approved on the sub. The old process had multiple steps, with the person at the top of the chain having little understanding of the impact of that person being away.

Instead, Marquet made the department chiefs responsible for signing leave forms. This eliminated multiple steps in the chain of command, but also cemented their responsibility for having them manage the watch schedule and training schedule.

The three name rule

Another example of encouraging behaviour change comes in the example of the three name rule. Marquet wanted his staff to be polite and interested when visitors came onboard, as they frequently seemed to do.

"When you're trying to change employees' behaviours, you have basically two approaches to choose from: change your own thinking and hope this leads to new behaviour or change your behaviour and hope this leads to new thinking," he writes. They chose the latter, through implementing the three name rule.

The idea was that every time a crew member saw a visitor on board they would address the visitor by name, give their name and give the boat name. So it would sound something like this: “Good morning, Commodore Smith. I’m Petty Officer Jones. Welcome aboard the Sante Fe.”

I’m not suggesting that you adopt this by rote for your project, every time someone comes into your project office. But you could do something similar, by ensuring that everyone on the team knows what is expected of them when new team members join, or when subject matter experts are brought on to the team for a short while.

Control,competence and clarity

Control, competence and clarity are the three things Marquet picks out as essential for organisational excellence. Control can be done in a number of ways, and on a project strong governance principles fall in here. Competence ensures that your team has the skills to effectively carry out their roles. And clarity means they understand why they are doing it and how their part of the project contributes to the whole.

I found this a very enlightening book. It is easy to read with gripping stories that morph into leadership lessons. I really enjoyed it, and found it easy to relate to projects, even though it is not a book about project management. Leadership is something we all need to work at, however good we think we are. As Stephen Covey says in the Foreword: “Remember, leadership is a choice, not a position."