The Money Files

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?

As a project manager, there’s one big problem on projects – you are right in the middle of it. You have tight deadlines, unforgiving stakeholders and detailed plans. It is very hard to lift yourself up out of this and see the bigger corporate picture – many project managers can’t do this at all.

You should try.

Being able to see the bigger picture puts your project in context. It helps you operate more effectively. It helps you see what is important to your project and business customers. It makes you a better member of the company, as well as a better project manager.

Here are 5 ways to ensure that you can see the big picture.

Go to internal networking events.

Every company has them. And if, for some reason, yours doesn’t, start one. Got to lunch and learn events. Go to afternoon briefings, or drinks after work, or corporate team building days. Don’t opt out of anything. You never know who you might meet, but more importantly, what you might learn about the company’s focus. You can use this to sharpen your project’s focus to deliver what is really important to the business.

Read the annual report.

Yes, it’s boring. But it is also a great source of information about how the company operates. How does your company make money? If you sell shoes, it’s pretty obvious, but many firms have more complex ways of bringing in the cash. How will your project contribute to this? Is there a strategic thread where your project fits (or is it clear that your project is now irrelevant to the new corporate strategy?).

Read the business pages.

Follow your industry. Not project management, but the industry your company operates in – IT, construction, engineering, retail etc. What’s happening there? What are your competitors up to? Set up a Google alert for the name of your company and your CEO. How does your project fit with what your CEO talks about in the media?

Join an industry body.

In the UK, BCS, The Chartered Institute for IT, represents the interests of the IT arena. It’s not the only IT industry body, but it actually doesn’t matter which one you join. The point is to have another way to find out what’s happening in the big wide world. Read their magazines. Go to their events. Join their LinkedIn discussion groups.

Ask questions.

If you don’t know what terms like ROI, IRR, BCR and payback period, ask (or watch my videos). Talk to your managers, customers and suppliers. What is important to them? How is your project helping?

Being able to see the bigger picture lifts you out of the detail and helps you operate in a project leadership role. How do you make sure that you know what’s going on outside of your project?