The Money Files

Whether it’s raised eyebrows and eyerolling or a full-on shouting match, projects are a conflict-inflicted environment!

You could be on the receiving end of the conflict because team members or stakeholders have fallen out over something. Or you could be contributing to it, having to address an issue such as not having enough money to complete the work.

As a self-confessed conflict avoider, I have always wanted to get conflict dealt with and out the way as soon as possible, so we can all get back to work. Here are 3 options for diffusing conflict situations on a project.

1. Take the heat out of the situation

One option – one of my favourites because it’s not confrontational – is to help everyone calm down a bit.

Oftentimes, a problem doesn’t look so bad with a bit of distance, and the heat disappears from the conflict.

The simplest thing to do here is to draw a line under the conversation, take a pause, and say you’ll come back to the conflict-causing topic at another time.

Remember to actually address the topic at that time, though, otherwise you just cause seething resentment in the team members who want to air their views and haven’t had the opportunity to.

If you are one of those people who can diffuse tension in a room with a joke, go for it. I’m not, so I wouldn’t risk saying something not very funny and making the situation worse, so I opt for calm voices, and a short pause in proceedings.

2. Agree

It’s so difficult to be rude or argumentative to someone who agrees with you. I don’t remember who I learned this from as a retail assistant in a busy shop while I was at college, but it certainly works with angry customers.

If you aren’t defensive, they stop fighting. It’s no fun arguing with someone who isn’t arguing back and who appears to actually be on your side.

Obviously, this isn’t going to work in every scenario. You can’t agree with a construction worker who is choosing not to wear protective gear on a building site and causing a fuss about it.

But in some situations, this is a good technique to try. You can always move the discussion along and use other techniques if necessary.

3. Say you are sorry

Again, this isn’t a solution appropriate for every project conflict situation. However, you shouldn’t be above saying sorry. If the mistake is yours, own it. Sometimes that’s all people want – for someone else to accept the issue happened and to own up to it.

I’ve been in meetings where I’ve taken the blame for something the project team did (collectively) as I’m the one who is responsible for the successful delivery. And we didn’t deliver. That’s on me. The body language of the person with the complaint changed significantly after I said sorry. The discussion moved on.

These 3 techniques aren’t going to win you any peace treaty awards, but for day-to-day small gripes and grumbles on a team, they are easy things to try. What’s your best tip for keeping the peace on a project?

Pin for later reading:

Payback period is a term that you’ll seen on business cases and in other project selection documentation. It’s a criteria that helps organisations decide if they want to go ahead with a project or not.

But what is it? And how can we use it to our advantage?

Payback period refers to the amount of time required for your investment to pay back. In other words, it’s the time taken to ‘earn’ the amount of the original investment.

Let’s say you own a hotel. You build a penthouse room on the top. It costs £100,000 to build (you get the materials very cheaply! Go with me, this amount makes the maths easier).

The price for one night’s accommodation in the penthouse is £100.

Therefore, you need to sell 1,000 nights of accommodation to break even.

 100,000 / 100 = 1,000.

The payback period for this room is 1,000 nights.

That example is SO simplistic but hopefully you get the idea. Payback period measures how long something takes to pay for itself.

What kind of payback period is best?

The best kind of payback period is the shortest!

The faster something can pay back, and start bringing in profit, the better in business terms. Once you have broken even, payback period has been completed and any money earned after that is extra – the benefits you were hoping to see.

I love using payback period because it’s easy to understand and easy to work out. If you are comparing projects, when everything else is equal, the project with the shortest payback period should be the one you do first.

Of course, in real life projects aren’t equal in all other respects. You will be juggling a range of other selection criteria, of which, payback period is only one. However, it is a useful measure to look at first, to give you an idea of the effort involved in earning anything from this project. Something that has a payback period of over 10 years might not be worth doing at all and can be eliminated from project selection.

Depending on your industry, payback periods could be short or long. Any type of large-scale construction project will necessarily have a longer payback period than launching a fast-to-market consumer app. Some projects may not pay back for years, and still be worth doing. You know your industry and projects better than I ever will, so apply your professional judgement and consider what the ‘appropriate’ kind of payback period is for your organisation.

Pin for later reading:

Project managers often get concerned about project cost control. This video talks about what project cost control actually is and why you shouldn’t be worried about getting to grips with your budget. Most of what you have to do is the same type of ‘monitoring and controlling’ you do on other areas of the project, so it isn’t really that different… just with large amounts of cash attached!

This video aims to demystify project cost control and share some thoughts about just getting started.

Pin for later reading:

Thinking about doing some project management training this year? Here are some things to consider to help you choose the right vendor for you.

You know I’m interested in the financial aspects of project management – I’m even thinking of teaching a workshop on project budgeting and accounting later this year. I feel like I’ve got quite a good understanding of the topic, but I’m constantly learning.

Having only done a very small amount of work in a team I would say is using agile practices, I am by no means an expert in the practical ways of making agile approaches work on project teams. However, there is a lot of guidance out there for people like me who want to learn more.

The Agile Practice Guide, in particular, has some interesting information about how to apply information from the PMBOK® Guide Knowledge Areas to agile work processes. From a financial perspective, here’s my interpretation of how this would work.

Project Cost Management in Agile Environments

Typically, on predictive projects you would do a lot of costing and estimating in advance. For projects with a high degree of uncertainty, or those where you don’t have a fully-fleshed out scope (hello, agile projects), then obviously you don’t have the data to do this level of cost analysis.

Instead, the recommendation is to use “lightweight estimation methods” (although no detail is given as to what these might be) to come up with fast, high level cost forecasts for resource costs. I can see this working when you are forecasting the general length of a particular engagement – even if you simply plan out the resource costs for the next financial period as a basic benchmark.

Detailed costs for things that aren’t people costs do still need to be done. You can’t run a successful business if you aren’t aware of what project work is costing you. It is OK, however, to do those detailed analyses on a more just-in-time and rolling basis.

To be honest, on some of the long programmes I’ve been involved with we’ve taken the same approach. The business case costs might have been fixed from the start, but frankly they were only ever our best estimate at the time. I then worked out detailed forecasts for the actual year we were in, so the Finance team could manage cash flow and we could accurately account for the capital outlay in the current financial year.

Where your budget is fixed, but you still need to be agile in other respects, then your choice is simply to flex scope and schedule to stay within the cost constraints.

Project Procurement Management in Agile Environments

Procurement management is another area where we incur costs, and as project managers, we need to be aware of how to manage that – in all environments.

Typically, procurements I have been involved with have had a protracted contract negotiation at the beginning to come up with a Master Services Agreement, and then you define the current engagement with a Statement of Work. As we needed suppliers to do extra things, we created new SoWs detailing that engagement. This is also how change control worked: the change control process generated either a credit note (when something was being changed and the end result was the development cost less) or a purchase order and an addendum to the current SoW.

It turns out that, according to the Agile Practice Guide, this is a pretty agile way of working.

There probably are projects where it is prudent and necessary to sign a massive contract upfront (ERP deployments spring to mind, from experience!) but generally, staying small with the engagement and working in a flexible way will suit both parties on the majority of projects.

Either way, something that is the same regardless of the project management approach you are taking is the need to document contractual arrangements and file them somewhere you can easily find them again. I have had a few moments in my career where I have sheepishly rung a vendor and asked for a copy of the executed contracts because – whisper it – it wasn’t possible to find our version of the same document.

Don’t make that mistake! Be agile. Be tidy!

Pin for later reading: