Monthly Archives: November 2010

Getting the right budget – its more than just cost cutting

A few days ago, I got a reminder about what seems to be a very useful meeting being run by my engineering institution [Institution of Chemical Engineers] and the Association of Project Managers entitled “Budget, what Budget”[] in London on 10th December. This focuses on the issues around getting the best budget for your project.

Whilst this is critical, I think it only tells part of the story.

I’ve worked on the front end of projects for many years and know that the initial budget is usually considered to be too high – the costs outweigh the benefits.

So it tends to get reviewed downward thorough a cost cutting exercise – Balancing the costs and benefits by reducing the costsI also know that much of the scope removed in this process tends to creep back in during or after the project – suggesting that it was really needed.

This got me thinking about whether projects are too costly or whether there is just not enough effort put into the justification process.

Balancing the costs and benefits by making the benefits more overt.There needs to be a balance between the two. Here are 10 tips to help you get the right budget for your project by paying attention to the justification process.

1.    It’s all about business

However technologically based the company is they only do projects to gain a business advantage. It may be to cope with changes in the business environment, to respond to competitor action or to meet their own objectives. If you are going to win support, it will be because of the strength of your business case, not the technological.

2.    Understand the process

Your business will have a set of policies, rules and procedures to authorise projects. These are designed to make sure that the right projects get approved and the right ones get rejected. If you don’t understand [and are not prepared to criticise] the process then you will struggle to make a winning case.

3.    Yours is not the only view

Projects involve many different groups, operations, maintenance, marketing, engineering etc. Each has a different perspective on what is important. If you are to win the support of others, you need to understand their perspective.

4.    See the big picture

Your project will be designed to contribute to one or more strategic objectives but may also contribute to other objectives. This may be intended or may be unintended. Make sure that all of the benefits of the project are allowed for in the analysis.

5.    Check sensitivity / assumptions

Virtually every project goes through a cost cutting stage in the justification phase but it is important to note that other assumptions contribute to the assessment of the feasibility of the project. Make sure you understand the contribution to each assumption on the feasibility of the project. Then concentrate your efforts on the right parameters.

6.    Understand the risks

Projects convey us from the present to the future; as a consequence they all involve risks. How you allow for the uncertainties has a big bearing on the outcome of the project. What you know is not that important, it is critical to understand what you don’t know and allow for that. Ideally, you should be using a structured risk identification and management technique.

7.     Don’t open the bidding too low

When the opportunity for a project opens up in our area of interest we naturally want to do all we can to ensure that it is approved and the investment comes our way. This tendency can lead us to suggest a low initial figure for the capital cost. The danger is that this will be cast in stone particular as the “± 30%” caveat we add is missed. It would be better to quote a higher figure and point out that there will be opportunities to reduce the costs. That way you are not painted into a corner.

8.     Value not cost

It is easy to focus on the cost of the various features of the proposed future asset and it is very easy to be drawn into drastic cost reductions to meet the approval hurdles. It is however much more important to concentrate on value and using creative approaches to achieve the desired results more economically.

9.    Market your ideas

However good your ideas are, they will only be accepted if you sell them to the other interested parties. This means spelling out the benefits in business terms [Tip 1] and tailoring your message to the audience[s]. You may need to use a different approach for each group. [Tip 3] You need to lobby for your ideas to be adopted; it won’t happen unless you take action.

10.   Don’t forget WIIFM

The easiest way to get people’s attention is to show them what is in it for them, so make sure that your message to each person or group is focused on “What’s in it for me”

Improving Projects – Make sure everyone is doing the same project!

One of the most difficult situations for a project manager to deal with is that point in the implementation stage where one of the future users of the facility realises that what is being delivered is not what they were expecting. Usually, this means that there has been a communication error at some point in the scoping of the project or a lack of involvement of a key stakeholder.

Because problems of this type only come to light during the delivery phase, they can be particularly complex to deal with causing rework with cost and time penalties. So it is desirable to avoid them!


The causes frequently go right back to the project development stages and the processes used to move from each participant’s vague notions of what is required to a structured definition of the project scope.

Key issues include:

1.       Range of participants

2.       Process and Procedure

3.       Thinking processes

4.       Language Issues

5.       Cultural Issues


Most projects involve a wide range of actors with different skills, objectives and levels of involvement with the project and the assets to be delivered. Some are involved with its ultimate use, some with the construction or development and some with its on-going maintenance. Others may only be involved indirectly.

The end users of a project to develop a manufacturing facility:

  • Production
  • Maintenance
  • Marketing
  • QA
  • Logistics

The project team may involve:

  • Design
  • Construction
  • Project Management
  • Architect

This may be the tip of the iceberg: with corporate management and external contractors also having an input. For other types of project, the titles may be different but the complexity remains. Each group is likely to have only a partial understanding of each other’s perspective and ability to contribute.

Process Issues

Many project development frameworks envisage the development of a brief [protocol, mandate, charter etc.] which is intended to encapsulate the requirements of the sponsors and ultimate owners. This document is then used to guide the project team through the development and delivery phases.

This one hit method can cause serious problems as it may take only a slight difference in understanding to send the project team on a different trajectory to that anticipated by the sponsors.

Similarly, if there is not a mechanism to probe the objectives effectively, there is a significant danger that the project will deliver the stated needs but not the real needs. Satisfying the project objectives but not the corporate or strategic ones may result in the creation of a white elephant. This is discussed further in a paper “Integrating strategic and project management” []  and the book “Project Benefits Management” .

Thinking Processes

Each group comes to the project with a different level of understanding based on their knowledge, experience, functional expertise etc. This influences both their perspective on the project and their perceived needs and wants.

This is the essence of what Peter Senge calls Mental Models [See for example ]. Each of us has our own mental model which allows us to interact with and interpret the world – they are all different so failure to recognise this is a recipe for misunderstanding, futile argument and stress.

Gareth Morgan in his excellent book “Imaginization” provides a superb metaphor for how this works – he presents a drawing of a pig surrounded by a number of different observers ranging from a butcher to a small girl to a Muslim. [See slide 15 of ] they all see the same animal but it conjures up different responses for each.

One side effect of these different perspectives is that the different functional groupings each develop their own shorthand and there is a danger that they may well use the same terminology to mean quite different things.

Understanding these different perspectives is crucial to the effective development of a shared understanding of the project scope.

Language Issues

Appropriate use of language is crucial to shared understanding; unfortunately, our meaning is often distorted by what we say and how we say it. The quotation “I know that you believe you understand what you think I said, but I’m not sure you realize that what you heard is not what I meant”; sums it up neatly.

One of the key ideas in the field of knowledge of Neurolinguistic Programming is the concept of the metamodel. This describes how the ways in which we use language can lead to lack of precision in communication. A particular issue is the notion of “nominalisation” where we give a name to an abstract concept and talk about it as if it were real. David Kerr, discussed this recently in his blog

Different groups [and individuals] will use the same word for different purposes with the danger that they will superficially agree with each other whilst disagreeing at a deeper level.  An architect and a laboratory manager may have very different understandings of what is meant by “a state of the art laboratory”.

This may be compounded by national language issues for multinational teams, especially where people are working in their second [or third languages]

Cultural Issues

The way the organisation goes about its work and the behaviours it encourages or discourages may have a significant impact on the ability of the team to define the scope of the project. If the organisation encourages deference to experts and / or discourages questioning of management decisions then there is a significant risk that the proposed scope and implementation method will not be examined critically.

The more diverse the team in areas of expertise, geography and experience, the greater will be the danger of culturally led misunderstandings.


The first step in “solving” these problems is to understand that they are likely to occur; forewarned is forearmed. Specifically, however the following actions seem to be relevant:

1.       Encourage participants to understand the background, needs and contribution of each group.

2.       Use a facilitative approach to encourage effective dialogue. This requires an air of independence, a broader set of skills and techniques such as those outlined in “The Fifth Discipline Fieldbook” and “The Dance of Change” [both P Senge et al]. The methods database of the IAF is also useful.

3.       Use approaches to encourage focused and well directed thinking such as those suggested by Edward de Bono.

4.       Be wary of agreement which seems to have been reached too easily – remember the Alfred Sloan statement to his board ‘Gentlemen, I take it that we are all in complete agreement on the decision here. Then, I propose that we postpone further discussion to give ourselves time to develop disagreement and perhaps gain some understanding of what the decision is all about.’

5.       Put effort into ensuring that all participants are able to understand what is being proposed, don’t exclude them by using a medium they don’t understand – we will return to this in a later post.

6.       Remember the Second Law of Thermodynamics – the universe tends to chaos, effort is needed to create order. So work at it!

We didn’t overspend – really!

I caught a section of one of those property redevelopment programmes on TV today. I always find them interesting as examples of how [not to] do projects but this one was exceptional. It pre-empts some issues on the practical recommendations series so I’ll return to them in detail later but I felt this was worth sharing.

The young couple who had refurbished a terraced house were asked how they had done against their  modest budget of £8000 – the gist of their response was:

  • Quite well really we only spent £10 500
  • Everyone told us it was normal to go over
  • We’re happy with what we’ve got for the money

This illustrates a few useful points:

  1. Your budget has to match the scope and planned method of working
  2. If you believe you are going to overspend – you will, especially if you believe it is “normal” to do so!
  3. £2500 may not sound much but it is over 30% of the original budget.

How do projects get to be 30% over spent? A pound at a time!

And what if you can’t finance the overspend!

Watch out for future posts on this topic – including one on whether your project is overspent or under justified.

Those of you interested in budgeting and cost estimating might find the following seminar useful –

It ain’t what you say … well it is really!

Virtually all projects require some form of team working and efficient communication is vital for success. This is borne out by the emphasis on communication in most books on project management. Unfortunately, many concentrate on the formal elements of communication; reporting channels, report content and format, appropriate procedures, forms etc.

Formal Communication – necessary but not sufficient

Whilst this is all necessary, it is not sufficient for effective project performance; what really matters is the informal communication that fills in any gaps in the formal processes. This provides information which amplifies and illustrates the underlying issues and helps generate a shared sense of responsibility and commitment to the project goals and objectives. It both forms the cultural glue that binds those involved into a team and oils the wheels of information flow.

Much of this informal communication goes on in impromptu meetings over drawings and other documents or in coffee breaks or in the few minutes either side of formal meetings when team members get together. In some cases, there are opportunities for such informal discussions whilst handing over key documents or information but this may become more difficult as greater reliance is placed on electronic systems.

Provide necessary information – don’t just answer the question

The key factor in ensuring success is whether the team members freely provide the necessary information to their colleagues – do they answer the questions asked or provide the information they think the other person needs. Ideally, do they probe the real needs and encourage effective dialogue.

I’m sure many people have suffered from the situation where the question asked is answered but the information provided is useless because the other person didn’t add on secondary information which they had or perhaps didn’t understand the purpose behind the question.

At a trivial level, one might ask for directions to a particular person’s office but not be given the additional information that the person in question only worked part time and was unlikely to be around – even when this information is widely known. The result can be a wasted visit with complaints met with  the response “well, I could have told you that but you didn’t ask”.

On a more serious level, I once was asked to faciliate a value engineering exercise on a manufacturing project which was approaching sanction. Early in the process, I asked about the reliability of the design information only to be told that most of the development trials had been failures and that the design was based on the only successful one.  No one had ever asked this sort of question and the information had not been volunteered.

Importance of trust

This approach often has a significant defensive element and may demonstrate a lack of trust in the organisation or team. It is usually counterproductive and can lead to significant problems, delays and rework when the additional information emerges later. An example would be where participants asked for the standards or regulations applicable to a particular element of the project provide exactly that information but fail to mention new requirements which will come into effect before the project is completed. The information is correct but useless.

Better dialogue in effective teams

In more effective teams, additional support information is provided without prompting; usually by putting the basic information in to context and providing “health warnings” about the validity of the information. Ideally, team members will enter into a discussion about how the information is to be used.

It is far better for information to be qualified with comments such as “this is my best guess at the moment and I’m concerned about X and expect better information by Y, so I’ll confirm it then.”

This is far better than simply filling in the form and allowing the next person in the chain to believe that the information is fixed and final. Even if there is a need to act promptly, it will be done in the knowledge that there is a risk. This will then minimise the chances of ill feeling and will help to build rather than damage trust.

Needs skills, understanding and effort

There  may be as many issues with the person asking for information who might need to develop improved questioning skills. Similarly, there is a need for all participants to have some understanding of each other’s skills, capability and interest in the project to allow them to engage in productive dialogue.

It is vital that project managers are aware of these issues and put effort into building skills, trust and effective informal communciation mechanisms. It is dangerous to rely solely on the formal systems. Putting some effort into promoting informal communication and encouraging effective dialogue will help ensure that there is less rework, fewer delays and that risk is handled more effectively. It should also lead to a less stressful life.

High Stakes – how and why to manage stakeholders

For those at the front line of project management, it can be very tempting to see the project as an end in itself but this can be a dangerous perspective. Projects are always done to meet the needs and expectations of at least one stakeholder group.

Successful projects require effective management of all the stakeholders [anyone who is involved with or affected by the project] and to do this you need to understand all of them: their needs, desires, expectations, contributions and most of all whether they win or lose as a result of the project.

This can be even more critical in “softer” change management situations but attention to stakeholder relationships is crucial in all projects.

Failure to take account of key stakeholders may result in a lack of attention to potential sources of opposition and resistance and may lead to late changes due to lack of consultation or involvement.

Many of the stakeholder groups will be easy to identify: customers, suppliers, regulators, functional departments etc but three additional factors need to be taken into account:

  1. Sometimes your customer’s customers and even their customers can be very important to understanding real needs and wants [you might apply this to suppliers as well]: This can be particularly important if you are part of an external Project Management team or contractor.
  2. Sometimes you need to consider specific individuals as well as the groups they are part of or represent
  3. Sometimes individuals will have different perspectives depending on how they consider the project. A manager might have a completely different view from their personal stance to that expected of his or her department and may not display this openly. These views may even be mutually exclusive!

[Aside: I was speaking to a client who is a director in a family business a couple of weeks back and he noted that business, family and personal issues may each be the top of his priorities on particular days. This suggests that his stance towards a project might vary on a day to day basis.]

You must identify each stakeholder and their aims; it can be very dangerous to uncover an unstated aim of a key stakeholder late in the project delivery process. This invariably leads to additional costs and / or delay.

[Aside: I remember taking the MD of a customer round a food production facility as part of the hand over process. He complained that the “Goods lift” was an inadequate standard for his visiting customers. A moment of panic for both me and my client’s Project Manager: fortunately we were able to show that the Marketing Director had signed off on the specification and had commented that his view was that Passenger standard here would have been seen as excessive by his customers.]

The management literature presents several models / frameworks for analysing stakeholder perspectives; I like to use a combination in a 3D framework covering [See Slide 1]:

Power – does the stakeholder have a source of power to wield over the project? This may be direct power or gained indirectly through influence.

Interest – Is the stakeholder going to be affected by the outcome of the project?

Stance – to what extent is the stakeholder supportive of the project?

These three factors allow you to assess whether they are valuable allies or dangerous enemies. This approach may also allow you to assess who it is worthwhile trying to enrol as a supporter of your proposals.

It can also be useful to examine the relationship between the effort required of an individual or group with their likely rewards [See Slide 2]. It is often the case, particularly in change management situations, that one group will be asked to take on much of the work but has little to gain and potentially much to lose. If their role and rewards are examined in this way, it often becomes very clear why they are less than enthusiastic participants.

It is vital that stakeholders are managed effectively and having a clear view of their perspective on the project is an important factor in your ability to do so. Knowing what is important to each group or individual will allow you to tailor messages to ensure that you get the maximum support through the project scoping, justification and implementation stages. You should also recognise that these messages need to demonstrate the benefits of the project to each stakeholder and need to be adjusted to suit the project stage. It is not sufficient to have one message for all and for that to remain constant throughout the project.

As always, the critical issue is that you have to think about the project from each stakeholder’s perspective – it is usually the things you haven’t thought about that catch you out.

When the going gets slow … its even more important to say no!

We had quite a rainstorm here yesterday and as is usual in these conditions traffic got very slow. The main road near where I live has lots of minor roads joining it – each has a give way sign [equivalent to “Yield” in some countries] what became clear was that as the traffic slowed down – these signs started to work in reverse. Most vehicles on the main road let someone out of one of the side roads – slowing the traffic down even more.

This got me thinking about change control in projects.

The need to focus on avoiding change and in particular late change is well known and often paraded as a major contribution to meeting project goals. Most of the time, the pace of the project helps with this because things move on and overtake the [helpful] suggestions.

But there are times in all projects when the pace of progress drops whilst we wait for particular activities to be completed or there is an unplanned delay. The danger here is that the reduction in the pace allows participants to reconsider options and this can  lead to more opportunities for change to be suggested.

It is even more important that these changes are resisted because they will only lead to further delay and cost. If possible, the proposals should be rejected out of hand because they will consume energy and resources if nothing else.

So just say no!