Communication Failure means Project Failure
Communication is the foundation building block of every project. How so? Although poorly represented in most project management literature about project success and failure, the logic is simple. A project only exists when there is an objective and an intent to get there. You can only get a project to its objective by doing work. Work requires people. But those people can only progress the project if they know what to do. Knowing what to do requires some sort of a plan. And a plan requires communicating. Ergo,
Communication is the foundation of every project!
However, communication must be done right! The goal of project communication is to turn data into useful information that can be understood and translated into actionable work. Along the way, whether on the part of the Giver or the Receiver, a number of attributes are requires by both parties. These include: The ability to assemble clear, precise and concise, unambiguous, relevant and succinct messages delivered to the right people on the one hand. And there must be active listening (a very different skill, and perhaps the hardest part) by the recipient(s) with the necessary training, experience, and abilities on the other.
With all these requirements, no wonder:
So many messages fail in their intent,
with consequent adverse affects on project progress!
There's a lot to learn about effective communication and a good place to start
is with the Issacons listed here: maxwideman.com/sitemap/info.htm.
There are also valuable and insightful papers by knowledgeable authors listed
on the same page.
But let's just start with the requirements to be "clear, precise and concise, unambiguous". Not only must you choose the right words, but those words must also qualify with the right meanings. So, any competent project manager on a new project should first establish a "Project Reference Bible". In this folder, will be names of participants their contact information, and perhaps key policies and procedures relating to the management and performance of the project. No doubt the name of the project will be on the cover of the folder. But how many of such "Bibles" set out the objectives of the project and a list of key definitions in the first place?
If you don't know where you are going, you will never get
there!
But what if the terminology we use is not that precise in the first place? A lot of people shrug that off with a response like: "You can tell the meaning by the context." The trouble with that reply, is that project management instructions should not be fogged up with a lot of circumstantial verbiage since that subverts the first requirement to be clear, precise and concise.
This is where our Wideman Comparative Glossary of Project Management terms
comes in very handy. You can find it here: maxwideman.com/pmglossary/index.htm.
The beauty of this document is that it is not so much a dictionary of terms about
what various term names should mean, but what various sources have
actually used them to mean. In many cases you will see significant differences.
Moreover, the Glossary's contents are extensively linked to related terms used in the various definitions. By following these links you, the reader, can learn a lot more about the subject area. Hence, for anyone involved in managing projects, or programs or that matter, the Glossary is an important resource to:
Selectively pick out key terminology for the project at hand,
and quote the most relevant definition.
What's all the fuss about? Well, here's a good example.
A vital part of Project Management success is the careful management of time, or rather how time is used to progress through the work involved in the project. That means doing the right things in the right sequential order through the project's life span. To this end, major time intervals along that path may be seen as existing on two distinct levels.
At the top level, such time intervals may be described as "Phases". In PRINCE2[1] for example, a project is divided into "Phases" to define Project Management decision points. These are called the "Management Phases".
It is generally agreed, by members of PMI[2] at least, that in a generic Project Life Span there are four such Major Phases consisting of "Conceive", "Develop", "Execute" and "Finish", or labels to that effect. Other labels used to imply the same sequence of phases include: "Concept, Definition & Planning, Execution, and Transfer" (of the product to operations); or "Initiation, Definition, Implementation, and Completion" and so on. Or again the PMI PMBOK® Guide describes the life span of a project as: "Starting the project, Organizing and preparing, Carrying out the work, and Closing the project".[3] As the PMBOK® Guide points out, these so-called Management Phases are representative of most projects most of the time.
At the second level, however, there are generally shorter time intervals representing the actual technological development of the project's Product. These are mostly, but not always entirely, a part of the Project's Execution or Implementation. This, too, means doing the right things in the right sequential order. Because these intervals are shorter, they are typically referred as "Stages".
Of course, they should be referred to as "Technological Stages" but that is a terrible mouthful so the label most often used is "Technical Stages" of the project.
In the past, however, the term "technical" has been used to refer to one of the numeric functions of project management, such as Cost Management or Schedule Management. So now we have two quite different meanings for the word "Technical". That is to say, in many of the more recent definitions to be added to our Glossary, the term "Technical" refers to the work of creating the project's product and not to one of the project management functions noted above.
By the way, in practice these two distinct sets of time intervals do not necessarily overlap or conflict but rather the Stages of Technical Product Management are contained within one or more of the relevant Phases of Project Management. But in examples like this, do be clear because in this case, when you use the term "technical", are you referring to project management or are you referring to technology management?
1. PRINCE2® is a registered trademark of AXELOS Limited, and represents a project management methodology developed and used extensively in the UK and other parts of the world.
2. Project Management Institute
3. PMBOK® Guide, 5th Edition Figure 2-8, p39
|
