Why projects fail (part two) – the matter of communication

It is better to keep your mouth closed and let people think you are a fool than to open it and remove all doubt. — Mark Twain



f you read the first article of this series (you can find it here), I promised to deepen the matter of communication that is considered the first cause of failure in IT projects.

At the end of that article I asked: “What tools have we to demand to afford these barriers? What skills have we to improve?”

In this article, I’d like to try to answer those questions giving you some tricks that may help to eliminate misunderstandings and miscommunications.

The first advice I could give to you is: Plan, Plan, Plan!

We are used to talk about the need to communicate. However, most project teams do not take the time to plan the who, what, when and how of their project communications.

Why Plan is so valuable?

A lot of Junior Project Managers think that communications is meetings, memos, emails and such kind of stuff; it’s not so simple.

As project leaders, a project manager has to provide and promote an open and two-way information flow, planning his/her project communications.

Planning communications will facilitate problem identification and resolution, will ensure an effective decision-making, will improve the involvement of key stakeholders and will promote teamwork.

What is a Project Communication Plan?

A project communication plan is a written strategy for getting the right information to the right people at the right time.

A typical project communication plan has the following basic components:

  • What – the event triggering the communication (e.g. Initiation Meeting, Status Report, Sponsor Meeting, and so on)
  • Who/Target – The target of the communication (e.g. All stakeholders, PMO, Project Team, and so on)
  • Purpose — the goals and objectives of the project communication process
  • When/Frequency — the timing and frequency requirements for all formal and informal communication activities
  • Type/Methods — the mechanisms and formats for the elements of the project communication process

I prepared a template (I personally use it in my projects); you can find it here

Of course, the first thing that you have to do is to identify your project stakeholders (all people involved in the project, affected by the project, or affected by the outcome of the project).

After this, you have to analyze the stakeholders’ needs and expectations.

Then, you have to identify all the vehicles and opportunities for the communications (pay attention to the fact that every stakeholder might have a preferred vehicle for communications).

At least, you have to collect all the informations mentioned above and set up a project communication plan; of course, the document has to be a live document; you must develop and maintain your communication plan, otherwise it’ll be only an administrative burden.


How Much is Too Much Communication?

It depends on the project size and complexity.

In theory, you can never have too much communication.

When misapplied, even the most well intentioned communications strategy can backfire.
On a small project, overly formal communication practices can quickly become an administrative burden, interfering with productivity and schedule progression.

On a large project, informal, ad-hoc communication practices can quickly turn success into disaster as important issues and opportunities are missed through lax procedures.

The amount of communications planning and formality increases directly in proportion to the size and complexity of the project.


And now?

And now, try to implement the advices and let me know if you had success!


Donate € 5,00

Help the growth of this blog

Latest Tweets

%d bloggers like this: