Guest Blogger – Project Failure is Also Due to Poor Communication

Earlier this year Arras People launched their Project Management Benchmark Report and an article followed from Kareem Shaker* on project failure. Looking at the reasons for project failure suggested by the Survey, and by David Pitchford, the common thread is a failure of communication. That’s a dreadful generalization, so let me be specific, looking at some of the examples in Kareem’s article.

  • The people in charge of the project do not communicate its scope or sell it to the people most likely to be affected by it – and then bury their heads in the sand when it starts to go wrong.
  • No one listens to the stakeholders – or if they do, no-one does anything about it. (Did anyone ask the stakeholders in the first place?).
  • In other words, no-one monitors or manages stakeholder expectations.
  • Implementation teams make assumptions about the end user climate which is not borne out by the facts.
  • The requirement analysis is insufficient.
  • The implementation teams frustrate their customers by duplicating requests for information and co-operation.
  • Too much indigestible project information, not enough targeted, focused, clear communication.
  • Relationship failures/turf wars/ silo culture frustrate the project, or divert it into a cul-de –sac.

I spent a number of years working as a communications director for a major international business integration project. The experience demonstrated that a good comms person reporting at a senior level, with some freedom and creativity can make a huge difference, avoiding some of the pitfalls above, shortening the project acceptance timescale and cost, and increasing buy-in and acceptance.

It also led to the development of Benchpoint, which was originally conceived as a project management tool. Simply, we were spending a lot of money communicating with thousands of people all over the globe, in three different languages. Was anyone listening? Did anyone care? What was working? What was not working? And where?

Unable at the time to find suitable software, I developed my own, one of the first interactive, all singing, all dancing on line polling systems, which eventually became Benchpoint. The results of that first survey were ground breaking, hailed by the client CEO as Best Practice, and providing a huge amount of data to guide future projects.

As a senior member of the project team, I began to appreciate how a  system like this could be used to provide a dramatic improvement in  2-way communication and transparency, without taking up internal resources and wasting either client or project manager time.

You can avoid email and information overload by collecting responses to common information requests on line. Such systems will also handle routine status reports, “dipstick” surveys, even training course requirements.

Typically, busy line managers are inundated with requests for information, often the same information, from different project managers. Why not collect key information on line? Benchmarking and survey software sorts and analyses the answers, and the results can be shared with everyone who needs to know.

A key part of a project is testing the readiness, skill and knowledge base, and attitudes of the project stakeholders, and getting an early warning of problems.

Some of the subjects which could be covered:

  • Understanding and acceptance of scope
  • Current skills and knowledge
  • Future skills and knowledge
  • Training requirements
  • Availability for key meetings and training sessions
  • Readiness and acceptance of change
  • Effectiveness of project processes and communications
  • Monitoring and management of stakeholder expectation
  • Satisfaction with current progress

The concept works equally well within the project, particularly when teams are dispersed across geographic or cultural borders. Who wants to read 50 status reports from subordinates before the Monday morning meeting? Using a system like Benchpoint, you can ask the right questions on Friday, with the consolidated results aggregated and presented in a concise format first thing on Monday, and distributed back to the field by lunchtime. No paper, no supernumeraries, no wasted time.

Richard Gaunt is CEO of Benchpoint Ltd, which provides the annual Arras People Project Management survey. The company also specializes in employee surveys and recently developed an all-embracing organization effectiveness diagnostic tool called “Management Probe”. He is also a professional communicator, and has worked on a number of major re-organisation, integration and change projects.

See and www.

* To take a look at Kareem Shaker’s blog


Image © Mike Licht and used with permission.

Share: Linkedin Logo Facebook Logo Twitter Logo


  1. I love tools, but sometimes simple things work well.

    If we know how to measure what we are doing (features completed, defect found/resolved, milestones achieved, funds expended, etc.) then reporting is straight forward, it just has to get out to everyone who needs to know.

    1. Keep databases/status reports/dashboards available on line and open (read only if necessary) to everyone – where possible.

    2. Have one place to go or to monitor to get the most recent updates. No more hip pocket status reports “held” back for the select few.

    It is better to show a time based trend – compared to a plan line – then to provide one data point at a time (such as the 50 status reports).

    1. Show where we are versus where we should be. Make it real, often by using past historical trends as control lines, rather than “gee, this is a nice chart we came up with using this slick new tool.”

    2. Report the data with brutal honesty, leave off the “filtering” and “adjusting” of data. Get folks use to what the real data looks like.

    The common thread of failure I’ve seen in my experience and practice usually centered around poor up front estimating and commitments based upon those estimates. If these are not done reasonably well, then as everything goes wrong, the apparent “need” to communicate goes way up. It becomes easy to highlight “communication” as the problem, when in fact it is just all the normal yelling one would expect after the ship hits the iceberg.

    Good article. Hope your tool helps.


Leave your thoughts