The Money Files

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

Many companies use a balanced scorecard to monitor progress against a number of key business strategies or objectives. Areas on a balanced scorecard are typically things like shareholder value or growth measures, quality of service and engagement measures for both staff and customers. The scorecard could look something like this:

Each month the key measures will be rated so that the company’s performance can be measured month by month. A popular way to do this is with the red/amber/green colour coding.

Could you adapt the principle of a balanced scorecard for your project? You can change the quadrants to match the things that are important on your project, for example your key success criteria. Your project scorecard could look something like this:

The idea is to have metrics that you can measure monthly for your project. Choose metrics that you can measure easily and that won’t take you too much time to gather – you don’t want to be spending all month pulling together statistics. Ideally they metrics should mean something to the project team and your sponsor as well. The balanced scorecard layout is just an alternative way to display the information graphically.

Appropriate Contracting is a term used by Michael Cavanagh in his book Second Order Project Management (Gower, 2012). He defines it as “the application of common sense to a commercial relationship”. In other words, it’s not really about money, but it is about making sure that the contracts you enter into with suppliers are fit for purpose and will help you achieve your objectives.

Consider a project where you buy software from a vendor. You go out to tender and you receive pitches from a number of companies. You choose the cheapest. The contract is tied up, with tight clauses around payment terms and schedules. You shake hands, everyone is pleased, and the project starts.

Six months in, you realise that the project scope needs a significant change in order to be able to accommodate the needs of the users. At the time of signing the contract with the software supplier, you hadn’t finished the requirements analysis and were not exactly sure how they would be using the project’s deliverables. Now you know, and you want to change the scope.

The vendor says no.

This is an example of inappropriate contracting – where the money side of things takes so much emphasis over a trusting, working relationship where both parties are working successfully together to achieve the end goal.

A trusting relationship does not mean that you don’t have a contract at all. Of course not. You should always enter a legally binding contract with suppliers on projects, as this gives you both additional protection should the worst happen. But as Cavanagh says in his book, “major contractual issues rarely occur between parties who have long experience in dealing with each other”. Trust is built up over a long time (and this goes for project managers with their teams too – in fact trust is one of the major attributes of a good project leader).

The better your relationship with the vendor, the more likely it is that you can work effectively together. This starts with the bid process. How the vendor operates at this point will give you an insight into what they will be like to work with when the real work starts.

So what is an appropriate contract?

Cavanagh says that an appropriate contract has the following attributes:

• It establishes consensus between both parties
• It establishes consent between both parties
• It provides clarity about the intent of the project/work and reduces ambiguity
• It defines and allocates roles and responsibilities relating to the work and performance
• It agrees how the parties will work together to create trust and confidence
• It documents any processes and principles related to managing success or failure.

For this last point, any processes can be included as a contract schedule.

“First and foremost,” writes Cavanagh, “the contract should be establishing a framework for success.” He says that in order to achieve this the contract should cover these four areas:

1.      Scope and goals (what the contract is about)

2.      Responsibilities

3.      Performance indicators

4.      Rights and remedies (what happens when things go wrong and what options both parties have if performance targets are not met).

Cavanagh says that the ‘meat’ of the contract is in the first three points, but project managers (when they are involved in negotiations) and legal teams spend a lot longer on negotiating point 4. This is counter-productive. If you skip over the scope and goals, who does what, and how success will be measured, you have every chance of needing those rights and remedies because it won’t be at all clear about what the vendor is supposed to actually do. “Rather than managing the risk,” Cavanagh says, “the contracting process itself becomes a source of risk.”

How appropriate are your contracts?