The Money Files

Every so often I’m asked questions about handling project finances. Here is another batch of Q&A. If your question isn’t answered here, drop me a line and I’ll try to include it next time.

Today we are focusing on tolerance.

You've recommended ranges for budgets as well as tolerances - can you recommend whether to combine these or keep them separate?

Estimates are better if they are ranges. You might estimate your budget to be £90-110k, for example. This will become a narrower and narrower estimate as the project progresses. But when you are discussing budgets at the business case stage, a range is a more appropriate response to uncertainty.

Tolerance is the amount by which the project can be delivered over (or under) budget without anyone being concerned.  It’s usually a small amount represented as a percentage. If your tolerance is a percentage, you will express it as something like +/-5% i.e. you can be up to 5% under budget or up to 5% over budget and still be delivering the project appropriately.

I would not combine tolerance and budget estimates. Set your budget. Then agree a tolerance level with your project sponsor. Apply the tolerance to the budget. You will end up with a statement like:

“The budget for Project Banana will be £90-110k with a tolerance of +/-5%.”

Is tolerance the difference between total cost and contingency?

No. Don’t think of tolerance as ‘real money’. It is simply a parameter in which you operate. It’s the same as saying, “I’ll aim to be at the cinema to meet you at 7pm but the trains aren’t running to the timetable because of engineering works so I could be there anytime between 6.45pm and 7.10pm. That should still give us plenty of time to get tickets and sit down for the film.”

Total cost is the amount (in range form if your sponsor will let you) your project will cost. Contingency is a pot of money put aside in case of unforeseen developments. It is not part of your overall budget and with any luck you won’t have to draw on it. It is for managing project risk.

What is the normal level of tolerance as a percent?

That’s a difficult question! It depends on the project. A project that has many elements that have been done before, an experienced team who have put together comprehensive and accurate estimates, with low levels of innovation and without the risk of new technology could easily have very low or no tolerance. This is because you’ll already know enough to ensure that you won’t need the ‘safety blanket’ of tolerance in delivery as you’ll be pretty sure that you will hit the estimates straight on.

The ‘right’ answer is whatever your sponsor says is appropriate. For organizational politics reasons, or financial constraints, the answer might be zero.  Talk to your sponsor about what tolerances they consider acceptable for the budget.

If you are pushing me for an answer I would say +/-5%. That gives you a window of 10%. If you are swinging outside of that window you will either be tying up money that you don’t really need for the project that could be better spent elsewhere, or you’ll need to go back and ask for more money as your project costs have risen.

Is it customary to add % of budget as ‘miscellaneous etc’ to the project budget and is this the tolerance you are talking about?

Yes, it is customary to add a budget line for unforeseen items. But no, it isn’t tolerance. This is your contingency fund.

Is it any different for PRINCE2?

No. PRINCE2 doesn't specify any particular way to manage project finances. You can read more about project tolerances in PRINCE2 here.

Last year I gave a webinar on managing project budgets, which also included the answers to many questions. You can see the whole presentation online here, via a recording of the webinar.  I’ll have some more Q&A for you soon!   Got any questions?  Leave me a comment and I’ll answer them in a future post.

Read Part 1 here
Read Part 2 here
Read Part 3 here
Read Part 4 here
Read Part 5 here

At the PMI Global Congress EMEA in Dublin last month Terry Williams spoke about his research into early warning signs on complex projects. Last week I wrote about what causes problems on projects. One of the things his research team considered was the role that external reviews have to play in uncovering those problems.

External reviews at all points in the project are useful. These provide a sense of legitimacy; comfort that you are doing the right thing. However, they need to be well focused, with guidelines. And of course it is not enough just to do a review and create a list of issues: issues have to be acted on as well.

However in some cases it was the process of doing the review was the most useful. The interview forced the project team to defend what was happening and therefore helped them uncover what was indefensible.

Having to justify the decisions made the project team question them and this process was identified as a good tool for flagging where things were going wrong.

Barriers to identifying early warning signs

You may expect warning signs to be successfully identified and dealt with in an environment where gut feel is taken seriously and reviews are carried out. But it is not like that everywhere.

Terry also shared some of the barriers to identifying early warning signs in projects. Here are some:

• A mismatch between project life cycles and strategic planning cycles; no alignment between annual budgeting and long term projects
• Methods are not well focused
• Effects of politics make you do the wrong thing. internal politics stop you seeing what's happening, and even if you do see it you won't say anything anyway
• Quality of team
• Being too optimistic
• Lack of a good business case
• Sponsors who have set up a project and then moved away leaving the team to get on with it.
• Lack of documentation
• Getting vague answers to critical questions
• When people work too much or too little
• Constant churn of people and those in acting positions (like Acting Marketing Director): they don't have ownership or the history to look out for problems
• Unfulfilled promises
• Frequently changing decisions.

I am not a big fan of organisational politics, and I often wish we could cut through the hidden agendas and just get things done. However, fast tracking projects through politics means you don't have time to assess early warning signs, Terry said.

What are the early warning signs?

As a result of their research the team was able to make lists of typical early warning signs by project stage. These are helpful guidelines for people doing project reviews - pointers for what to be looking for. The lists included:

During project set up

• Poor project definition
• Poorly developed business plan
• Sponsor with unclear expectations
• Inconsistent arguments about agenda
• Vague reasons for undertaking the project
•  

In early stages of project

• Lack of a clear business case
• Deterioration of relationships within the team and with suppliers
• Incomplete docs
• Unwillingness to conclude discussions or make decisions
• Lack of competences in team
• Lack of clear roles and responsibilities

During project execution stage

• Frequently changing decisions
• Uneasy comments
• Strained atmosphere
• Not showing trust in project organisation

Do you do project reviews? If so, have you spotted any of these warning signs or any other signs that things might not be going to plan?

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