by Howard Boorman and Dr Trevor Bentley

Big projects keep failing. And yet it seems that the same mistakes keep getting made over and over again. And every now and then another project management methodology pops up, requiring yet more detailed documentation. It’s often been said that one definition of madness is doing the same thing over again while expecting a different result every time. And it seems that that is exactly the madness that many organisations are beset by when it comes to project management.

In this article we’ve identified a number of common myths or pitfalls – so common that most project team members simply nod their heads knowingly as we discuss these pitfalls. We also offer what, from our experience, makes a project successful.

The cost of doing projects poorly

So many projects suffer budget blowouts, missed deadlines and poor quality output, that the corporate world and society in general have almost accepted this as just the way it is.

Often these problems cost millions (dollars, pounds, euros, whatever). In many cases the cost in human terms is a lost career or political setback or, tragically, a heart attack. More than once big project failures have brought large organisations to their knees, and cost governments elections.

Even apparently successful projects often have hidden and sometimes devastating costs to the project team members and the organisations they work for.

What can be done to make more projects work, to get more projects coming in on time, under budget and producing what they promised?

We’ve identified 12 of the most common pitfalls that get in the way of projects working well, and ways to avoid each one.

Heading off these pitfalls and developing effective approaches is critical. As long as executives and project managers continue to be spellbound by these practices, or turn a blind eye to them, we’ll continue to see many projects fail.

Pitfall 1: Believing that project owners, senior executives and boards
 actually make the decisions on the projects they sign off

This is not usually the case. This can be tested very quickly in any organisation by counting the number of project proposals that are knocked back at each level. As soon as you get to a level where very few projects are being turned down, you’ve probably reached the point where the real decisions are no longer being made.

At this point it’s much more likely that other things are happening. Project proposals, business cases or cost benefit analyses are probably being massaged (either by underestimating costs or timeframes or by being overly optimistic about the benefits) so projects will be approved. Sydney’s recently opened Cross City Tunnel, where patronage is something like only 30% of the forecasts may well be a classic example of this.

It’s also possible that borderline cases are probably not being put up for consideration – an outcome that management may have produced by not making it ‘safe’ to put up less than rock solid proposals.

The real project approval process occurs in the corridors or behind closed doors through internal politicking, where people who are ‘on side’ are given more weight and those who are less committed are marginalised. This circumvents the formal system and means that the whole project process is less transparent.

The result is that senior people are left to rubber stamp proposals (or they are simply armed with biased and unrealistic estimates to fight the political battle). This means that the strategic thinking skills and well-developed decision-making skills that senior people are supposed to have are not applied.

One of the biggest risks is that ideas that cannot be justified through a cost/benefit analysis, but which might make good sense from a strategic point of view, may never be considered by the people who look after corporate strategy.

Another problem is that the cost of not pursuing an idea knocked back lower down the chain may not be felt or understood by the organisation – until a competitor goes ahead.

Organisations need to make sure that ideas get heard by the people best equipped to evaluate them, and that the real decisions are made by the people best equipped to make them.

Pitfall 2: Focusing too much on scheduling, planning or developing Gantt
            charts

These are only one part of project leadership and certainly not the most crucial functions. Project managers who focus on developing schedules and maintaining their Gantt charts just about guarantee the failure of their project.

At best they may bring something in on time — but there’s little likelihood of it being the thing the organisation really needs. Nor is there much chance that these managers will get the most out of the project team, and the risk to widespread user acceptance of the project output is grave indeed.

Successful project leaders recognise that there are a number of other things that are more important, including:

§         Being clear on why you’re managing this project and who it’s for,

§         Knowing who the other stakeholders are, and how they need to be involved,

§         Keeping stakeholders informed and getting their feedback, and

§         Being a leader to the people on the project team—understanding them and their aspirations, motivations and work preferences.

No matter how complete or detailed a plan is, it’s unlikely that things will unfold exactly as planned. A good plan can help with risk analyses but it will never guarantee the smooth running of a project. Also, plans are based on forecasts and estimates, not facts.

The answer? Ensure project leaders understand what else is important and that they can give real leadership, not just management or supervision.

Pitfall 3:   Rushing into action

This is perhaps the most common of all pitfalls. Action is highly valued in most organisations. As are the people who operate decisively. The result is that many organisations lurch from action to action, and project to project. Often the action required is to fix up the mistakes made last time.

Avoiding this pitfall means taking more care (but not necessarily  a lot more time) to ensure that there is a shared awareness of what is happening, what the options are and what action is appropriate. Of course this is what is behind much of the documentation required at the start of projects. Unfortunately, this documentation is often used to sell an idea rather than as a way of building broad awareness and genuine consensus.

Pitfall 4: Believing that a complex project management methodology
guarantees success

Some of the biggest project stuff-ups around the world were made using well-developed, very sophisticated project management methodologies.

We’re not saying project management methodologies don’t work. What we are saying is that putting your faith in a project management methodology has as many dangers as benefits. They should carry a public health warning that their use can give people a dangerous, false sense of security.

Used well and as intended — with rigour and without shortcuts — most project management methodologies could be very useful. Unfortunately these conditions are rarely met, often because of the apparently onerous workload involved in doing everything the methodology requires. This is a dangerous flaw.

Of even greater concern is the tendency of these tools to be too task-focused. As a result, project leaders often fail to take into account a number of important factors, such as understanding and caring about the people on the project team, regularly checking whether the project is still appropriate, and undertaking two-way communication with all stakeholders.

Also building in lots of project phases and using proprietary jargon just makes project management even more complicated. We’ve found that a simple, and powerfully effective, project management approach can be captured in five key steps:

1. Before the Project

2. At the Start of the Project

3. During the Project

4. At the End of the Project, and

5. After the Project.

Our experience is that people can more readily learn and develop their project management capabilities through these simple, commonsense steps.

Two other problems with many project management methodologies are overly detailed documentation and an emphasis on deadlines; the subject of the next two pitfalls we’ve identified.

Pitfall 5: Believing that detailed project documentation produces
 detailed, quality thinking

It could, but it rarely does. Most project management methodologies require the preparation of a number of documents, including terms of reference, the project brief and a cost/benefit analysis.

Document templates often demand considerable detail. This is apparently based on the notion that writing a lot of stuff about the project will ensure project leaders and teams think about this stuff and that others will read it and think about it too.

Often, thanks to the cut and paste functions in word processors, the opposite happens. Whole chunks are copied from document to document. Even less usefully, whole sections are copied from one project to another.

The effects of this wholesale cutting and pasting are twofold: Less thinking goes into these important project phases and people quickly recognise that they’ve read much of the documentation before and start skip reading. And of course they skip even more when the documentation is two feet thick.

The problem with fixed deadlines (moveable deadlines are not really deadlines) is the way they increase costs and reduce the quality and value of the delivered product. There are five key aspects to this.

First, resources expand to meet the deadline. Additional resources are drafted in to meet the approaching deadline. These resources cost more (in additional salaries or fees, not to mention overtime and training) and achieve less (because of the learning curve).

Second, deliverables are reduced to make the deadline achievable, and the finished product becomes a diminished version of the original plan. It does less, probably less efficiently, and fails to satisfy users’ expectations. It’s a bit like building a two-bedroom house for a family with seven kids just to be on time.

Third, the quality of the product can be diminished in the rush to meet the deadline. Shortcuts are taken and the product quality is compromised. The bugs and faults mean the product costs significantly more to maintain than was expected. Worse, safety is often compromised.

Fourth, the project management process is compromised. Good project management includes careful planning of activities and the arrangement of work according to activity dependencies. When shortcuts are taken, dependencies are ignored or overlooked and chaos ensues.

Lastly, there is the impact on people. This is often not recognised until it is too late for the individuals involved. Stories abound of senior managers on stress leave as a result of tough project deadlines. We know of one project manager, burdened by a series of unreasonable deadlines, who died from a heart attack aged only in his early 40s.

Of course, there are some legitimately deadline driven projects, but these are few and far between.

More often than not, deadlines arise because someone makes a promise – e.g. to the CEO, the board, the financial press or the public – using optimistic estimates. And this is often compounded by gutless executives or project managers who won’t tell the emperor that he has no clothes.

One of the key ways to avoid this pitfall is to avoid giving people optimistic estimates – they will always be used! And if they are, there needs to be a recognition that struggling to meet unrealistic deadlines will not ultimately serve the interests of most people involved, and people need to find the gumption to speak up (where necessary be prepared to rely on external support to help you deliver this message).

Another key answer is to scrap fixed deadlines and work to flexible time scales or target dates. Also build in a reasonable buffer for each task to allow for unexpected delays - they are much more likely to occur if you haven’t allowed for them! Paradoxically, target dates are achieved more often than not.

Pitfall 7: Subscribing to the notion, ‘If we tell people to use it they will’
           (or, ‘If we build it they will come’)

These days, to be really successful, most projects need a high level of commitment from those involved down the line, especially the eventual users.

Simply telling people to use something is unlikely to secure a high level of commitment. At best, you’ll get compliance, not real commitment. People may be quite happy to comply, but are unlikely to go the extra distance to make things work really well, or to help identify improvements (indeed in the case of Sydney’s Cross City Tunnel it seems people are prepared to literally go the extra distance to avoid using the project product!). Even when people don’t make much of a fuss during the project, they’re unlikely to cut the project team any slack when the inevitable hiccups occur.

If things are really bad, you may encounter subversive non-compliance, with people working behind the scenes to sabotage the system at every opportunity. In the worst case, you may even encounter open revolt or public demonstrations. 

Those of you who have been on communication workshops may be familiar with the notion that the message we think we’re sending is frequently misunderstood, or not received at all.

This applies as much to communication produced as a part of a project as it does to communication between two people. In fact, the problems can be even greater because most project communication is not conducted face to face and there is even less opportunity for immediate feedback.

Strangely enough, project managers often work on the basis that every attempt at communication is successful: “How could they not know about it? I sent out a memo detailing the whole thing!”

The job of a project manager is not to send messages. It is to make sure that messages arrive and are understood. Unfortunately, most project management methodologies and managers neglect to develop a communication strategy and plan that includes the step of checking how successful communication have been.

Pitfall 9: Relying on project management courses to develop project
            managers

Let’s be perfectly clear: Nobody can learn to be a fully competent project manager in two days, five days, or even 50 for that matter.

At this point you may be thinking, “Then why the hell am I paying all this money for project management courses?” or something along those lines.

We’re not saying that project management training programs are useless. A well-constructed project management workshop should give people a solid foundation to build on, but the really key project management skills can only be developed over time and with practice.

The answer is in having a program of coaching and mentoring, with access to people who have both highly developed project management skills and coaching and mentoring skills.

This approach is likely to be ineffective unless people have a high level of comfort and experience working as part of self-managed teams, or are given sufficient support.

Often the team will float around aimlessly until management loses patience or someone emerges from within the team to take control. Unfortunately, the leader who emerges from a leaderless team is often the person who most wants structure. They will not necessarily be the most effective leader.

This doesn’t mean that empowering teams to make decisions is inappropriate. Sometimes the best results can be achieved using exactly this approach. The challenge is to get the best balance between giving the team direction and support and leaving them alone.

Give them too much support or direction and they’re likely to feel that their so-called empowerment was a con. Give them too little support and the team is likely to float around endlessly, fall apart or become too rigid to be creative and effective.

It is inappropriate to work this way on important or complex projects when people are not experienced with this model. Complex projects have enough stresses and confusion built in without adding self-management. 

Computer system development methodologies are many and varied and there are lots that do a good job. Unfortunately many people, including some people who sell them, think system development methodologies are complete project management methodologies. They rarely are.

The two most common faults are an inappropriate focus on target dates, leading to de-scoping — reducing system functionality in order to meet a deadline — and a preference for technical rather than leadership skills.

They also tend not to allow sufficiently for reviews of whether the project remains valid, development of things that aren’t directly part of the system, and development of a communication strategy and plan.

System development methodologies can be quite useful, as long as they are used with awareness of their shortcomings and of what needs to be done to plug the gaps.

Pitfall 12: Allowing insufficient time for reflection and learning

This is mostly about making future projects successful – although unfortunately in some cases it’s about knowing what to fix up!. It is true that most methodologies build in a project review phase, but unfortunately this is often only given lip service.

A genuine, open review of what could be done differently next time and what worked well, coupled with a real commitment to change aspects of the system and develop people based on the feedback received, will produce substantial dividends for future projects.

To be done properly, this review should be led or facilitated by someone who was not directly involved (and therefore has no vested interest in the outcome of the review) and involve all project members (especially any who left during the project) and all key stakeholders.

Perhaps most importantly, there needs to be a way of ensuring that the outcome of the review is available to, and accessed by, future project teams. (Unfortunately this is one of the things that is most often neglected.)

Conclusion

It is possible to consistently do projects really well. But it needs courage on the part of leaders and project managers to do things differently. Doing what you’ve always done, or tinkering around the edges with new methodologies, will not lead to sustained success.

Project managers need to be courageous leaders who can listen more than sell, who know when to lead from the front and when to support from behind. They need to be able to inspire by being inspired, and build teams that function at a high level, and they need to be supported to develop the skills required to do these things. They need to be able to say ‘we have to do this differently’ and they need to develop an environment that make s it safe for others to speak up. They need to recognise that success comes from working with people – team members, stakeholders, suppliers and customers. They need to be equipped to know the difference between project planning and project leadership.

Howard’s qualifications include Adult Education and Corporate Management. Trevor has a PhD in organisational development. Both have extensive experience in leading large projects.

You can contact Howard via howard@thespacebetween.com.au and Trevor via Trevor@thespacebetween.com.au

Bsck to Publications

Back to Home