The Money Files

"We should have seen it coming."

Have you ever said that or felt that on a project?

Terry Williams spoke about his research into early warning signs on complex projects at the PMI Global Congress EMEA in Dublin recently. The researchers looked at how successful project assessments are in uncovering the warning signs that something is going wrong on the project.

They set out to discover what the most important early warning signs are, and what to look for in different contexts. Terry specifically focused on complex projects. "A complex project is one where you don't understand how the inputs generate the outputs," he said.

The team went in to 14 organisations and interviewed people about what went wrong in their complex projects. The issues they asked about included:

•  Political processes and reasons for projects

•  Business case

•  Risks and opportunities

•  Stakeholders

•  How you learn lessons from other projects, and the difference between lessons identified and lessons learned.

This last point was interesting. A public sector project lessons learned report included the advice that future projects needed a strong leader. That's not rocket science. But when the researchers dug into the reasons why the lack of leadership had been an issue on this project they found out all the political reasons behind it, which is much more useful. Understanding the context and the narrative around the lessons is helpful, Terry said.

He cited the NASA lessons learned database which I also refer people to when I give talks - it is a great example of managing organisational knowledge.

What causes the problems?

Problems on projects are caused by all kinds of things, and the researchers uncovered some common themes:

•  Overly ambitious plans

•  Development of new technology

•  Difficulty of stopping projects when they have gathered steam.

•  Complexity

•  People in senior roles forgetting what managing projects is like as they have moved to levels in the organisation where they have no recent relevant operational experience

•  Group-think

Then they took a step back and looked at what warning signs came before these problems.

The researchers saw that early warning signs include 'gut feel' and non-verbal, people-related issues. "Early warning signs may be evident from people's behaviour," Terry said.

Unfortunately, project managers and executives don't always pick up on these signs, or know what to do if they notice them. And the more complex the project, the more likely they are to ignore them.

Half of the companies taking part in the research distinguished what a complex project was. They had guidelines set by the company specifying what 'complex' meant for them.

"We got this feeling that people doing complex projects define more things to look at and this takes away reliance on gut feel," Terry explained. "The more complicated guidance distracted you from using gut feel."

The more structured and complicated the organisational structure, the harder it is to allow soft interpretations of concerns.

Next time I’ll be looking at the value of using external reviews to assess early warning signs on complex projects.

Things are always going wrong. No matter how hard we try to keep everything under control, something will always happen to mess up our hard work. Now I’ve read David Hancock’s book, Tame, Messy and Wicked Risk Leadership, I wonder if I shouldn’t be blaming everyone else for messing up, but myself.

Hancock presents the view that actually the world is a lot more complicated than our traditional risk management models can cope with. He argues that we should be looking to the worlds of sociology, philosophy and politics to establish new ways of interacting with risk.

We need to do this because the equation risk = likelihood x consequence only works when the risk is as a result of a knowledge gap. Get more information, analyse it, and you can reduce the risk.

Sometimes all the knowledge in the world won’t help you reduce the risk. He says:

Yesterday’s response to a given set of circumstances is only a hint of what tomorrow’s response to that set of circumstances will be and, in any case, today’s circumstances will never reappear tomorrow precisely as they were today. So we really do not know what the future holds. Risk in our world is nothing more than uncertainty about the decisions that other human beings are going to make and how we can best respond to those decisions.

Much of what Hancock describes is most applicable to large, complex projects with multiple stakeholder groups, like public sector initiatives. He uses examples from transport (he was responsible for the risk management system for the Heathrow Terminal 5 Project) and space exploration to give you an idea of the scale. When you are dealing with projects this big, he says it no longer makes sense to split risk management across different functions or initiatives.

We need to address the total uncertainty facing an organisation, in any instant, and how risks correlate, before we can take responsible action.

He goes on to explain this in action by giving an explanation of the recent financial collapse – with clarity that rivals Robert Peston’s headline-grabbing approach.

Tame, Messy and Wicked

Most of the book is taken up with explaining what tame, messy and wicked problems are all about.  Here’s a summary:

Tame problems: these have “simple, linear causal relationships that have clear beginning and end points.” The traditional approach to risk management works for these. You gather data, analyse the situation, formulate a mitigation plan and then implement your plan.

Messy problems: these are “problems of organised complexity, clusters or interrelated or interdependent problems, or systems of problems.” You can’t solve them in isolation. Systems thinking helps unpack these problems. One example he gives is alleviating traffic congestion. You can’t solve it by widening the motorways or increasing road tax. There are lots of issues at stake, even if we all agree that sitting in traffic jams is bad.

Wicked problems: these are more complicated than messy problems. We can unravel messy problems eventually “as long as most of us share an overriding social theory or overriding social ethic.” If we don’t, we end up with wicked problems. These are where the solution proposed will likely depend less on a probability model and more on your view of the world. Consequently, there is no right answer and five stakeholders will have five different approaches to managing the risk.

Risk leadership

For a book with ‘risk leadership’ in the title, the discussion about this doesn’t start until the book’s conclusion. In fact, there is only about two pages worth of explanation about risk leadership, and I felt short-changed.

Risk leadership is about putting aside traditional linear risk processes and developing relationships with stakeholders, scenario planning, helping others live with uncertainty and facilitating mitigation plans to achieve the best possible compromise, understanding that there is no right answer.

This sounds fascinating, and I wanted to read more about it. Maybe Hancock will write another volume exploring the concept of risk leadership in more depth? As one of the UK’s leading experts on risk I’m sure he’s got more to say on the subject. I would certainly read it.

I was at the PMI Global Congress EMEA in Dublin last this week and I attended a presentation by Dr Penny Pullan about making the best of virtual meetings. In my last article I wrote about why we have so many virtual meetings – some people attending the presentation were spending over 20 hours  per week in virtual meetings – and also the frustrations project team members have when they are participating in virtual meetings.

If virtual meetings are so bad, but we have to do them for cost and other reasons, what can we do t make them better?

“If you put in a little bit of really focused preparation you can improve them,” Penny said. Here are some tips from her presentation to improve your virtual project meetings.

What time is it?

Don’t make project team members in India stay up late for a conference call with the USA contingent unless you really have to. If you do have to, find a way to minimise the impact – do it as early in the day for the USA people as possible. Use this meeting time calculator to find the most convenient time.

Is the technology available?

Penny spoke about working in West Africa when the only technology available to her project team was the phone network. Don’t organise virtual meetings when some participants won’t have the ability to participate because the technical infrastructure isn’t available or reliable.

Can the participants use the technology?

Even in places where the technology is available and reliable, you may have some project team members who are uncomfortable using it. If they don’t know how the web conferencing software works, they will slow down the meeting for everyone else and the project team members who are technically literate will lose interest. Ask a tech-savvy person to sit with anyone who is not comfortable using the computer or the video conferencing suite. It doesn’t have to be a project team member: their PA or a desktop engineer from IT would also be able to ‘drive’ it for them until they are used to it.

What would it cost to fail?

If the meeting is to discuss something critical, what would the impact be if the meeting is not a success? If you are trying to recover a failing project, or discussing bug fixes that will stop the next software release, or gaining agreement on anything that has the ability to have a significant impact on your project, stop and think about whether a virtual meeting is the right way to go. If the cost of failure is more than the cost of travel, bring everyone together and have the meeting face-to-face.

Can you split it?

“You can do short things quickly virtually,” Penny said. But if you have lots to do and meetings that will go on for a while, it is better to meet face-to-face. She recommended an hour and a half as the longest time to spend on a virtual meeting. If you need to meet for longer than that, factor in some breaks. Give people the chance to put down the phone and stretch their legs. It takes a lot of effort to focus in a virtual meeting, and long stretches will impact the productivity and energy levels of the project team.

What else do you do to manage the impact of virtual meetings?

I was at the PMI Global Congress EMEA in Dublin earlier this week and I attended a presentation by Dr Penny Pullan (@pennypullan on Twitter) about making the best of virtual meetings.

Meeting virtually means conference calls, webinars, video calls, and any type of discussion where you are not in the same room as the person or people you are talking to.

Travelling to meet someone face-to-face normally incurs a cost. In several of my previous companies we have had multiple buildings in the same town and the ability to walk between them – but even that takes time. And time is money.

A few years ago, there perhaps wasn’t the driver to cut down on travel, but now there are many reasons why project teams would choose to meet virtually.

Penny listed some drivers for virtual meetings from her research:

• Off-shoring: working with India, China or cross-continent
• Outsourcing
• Saving time
• Cuts in travel and expense budgets
• Flexible working policies and legislation that have meant more people have the choice to work from home
• General cost reduction across the board
• Natural disaster e.g. the ash cloud which stopped many people travelling in Europe last year, and had a major impact on attendees to the London Book Fair (including to my publisher)
• Technology improvements mean that it is possible now at quality that is good enough
• Companies making collaborative products like webinar or project management tools who have to be seen using their own products
• The desire for hiring managers to recruit people with the best skills, not necessarily those who live locally to the office
• Organisations run with volunteer staff finding it necessary to fit meetings around the availability of the people involved
•  

She summarised that more people are working virtually for a number of different reasons. So why do we all still fall asleep on conference calls?

Penny went on to describe the frustrations that project teams had raised with her when asked to attend a virtual meeting. They said:

• There is no clear purpose or agenda for the meeting.
• There are no breaks: we meet for over an hour without stopping.
• The project team members from the USA are alert because it’s morning for them but in Europe we’ve already worked a full day: the energy states of the people on the call are not matched.
• When I ask a question no one answers.
• We always start late because someone has forgotten the code or got the wrong code or the technology isn’t working.
• I can’t hear because there is too much background noise.
• Nothing happens afterwards: we never follow up on any actions.
• There are too many people on the call.
• I get distracted by emails or other project work.
• I don’t know why I’m there.
• Our project conference calls are boring.
• There is no level playing field: I’m on the phone while everyone else is meeting face-to-face.
• Humour backfires without the context.
• People never ‘get’ it: there are lots of misunderstandings.
• There is nothing to look at.
• I can’t get a word in.

With all those issues plaguing project conference calls and virtual meetings, it is a wonder that we get anything done on the phone or via video conference at all. Penny had some suggestions for how to improve virtual project meetings, and I’ll talk about them next time. In the meantime, what other reasons for conference calls or frustrations with virtual meetings do you have to add to these lists?

For those of you who prefer reading or can't see the video, here is the transcript:

Today, I want to talk about capital expenditure which you might know as capex and operating expenditure which you might know as opex. And I want to explain the differences between these two different types of money, the way that the money is categorized which will hopefully give you an idea of what you need to be looking for when you’re preparing project budgets.

So, capital expenditure or capex is money that is allocated for buying things, physical things. So in an IT environment, that could be PCs. It could be servers. It could be the engineering time required to bring an asset into service. So really, capital is about assets, things that company can actually tangibly own and will keep.

Operating expenditure on the other hand is more about labor costs. It’s transient expense that is used to keep the operation running. Hence, its name. So operating expenditure on a project might be things like travel expenses or a training budget or hiring a room for a meeting, or providing sandwiches and a working lunch for your team.

So the way that finance departments categorize money tends to be either as capital or as opex. And you may find that as a project, you end up with two different budgets. So while at the end of the day, it’s all money that leaves our bank accounts or our company’s bank accounts, the way that finance departments need to account for it is different because if you’re buying an asset, assets depreciate in value. So if you’re buying a car for example at home, you might buy a car today for a particular cost and if you sell it again in 3 years, it will actually be worth less. It’s still worth something but it’s worth less than what you paid for it today. And that’s depreciation. So the cost of the asset devalues over time. And accounting departments need to take that into account when they’re looking at what assets a project has purchased.

With operating expenditure though, it’s gone. You hire a room. You eat some sandwiches. You pay for a training course. And at the end of the day, you may have something left in terms of knowledge transfer or a successful outcome but you actually don’t have a tangible asset that adds value to the organization.

So at the end of the day as I say, it’s the same cash that leaves the company but you need to talk to your finance department about how they determine the categorization. Because some companies may decide that certain costs can be capitalized and others may decide that actually that isn’t within their regulations and they want to count that particular expense as an opex charge.

So talk to your finance department when you start working out your budget for your project and see how they determine within finite detail the difference between opex and capex. You’ll then be able to look at your two budgets and you may just find that you end up with two capital budgets and opex is handled somewhere else, perhaps in the running of the department or perhaps in the running of the department that you are delivering a project to.

Once you understand the differences, once you understand what money has been allocated to you as a project manager to manage, you’ll be better placed to start asking intelligent questions around whether a particular piece of equipment you want to buy or a particular thing that you want to do is counted as capital and opex and you’ll know who to ask in order to be able to process those charges effectively.