Communication Excellence in Project Management

(Excerpt from my latest book)

Understanding is a topic in epistemology which is the study of knowledge. Don’t worry; I will keep the philosophy brief and to the point. Even though the study of knowledge is ancient, the study of understanding is relatively new (just like the study of project management communication). According to philosophers, there three main ways of understanding.

There is know-what in which I have an understanding of some concept, physical object, or process. For example, I know what a work-breakdown-structure (WBS) is in the sense of it being a tool in project management. I may have a simple understanding of what a WBS is because I recognize a WBS when I see it. Or my know-what may be that I know WBS exist but, that is all I know. In contrast, I may thoroughly understand WBS including the history of the concept. Know-what is often the first step in creating understanding.

When I can construct a WBS, I have know-how. As you can see, know-how is more involved than know-what. For me to have know-how, I must possess these six attributes:

1. Ability to follow the explanation of the concept, physical object, or process.

2. Ability to explain the concept, physical object, or process.

3. Ability to draw conclusions from the concept, physical object, or process.

4. Ability to conclude opposing conclusions from the opposite of the concept, physical object, or process.

5. Ability to conclude the correct ideas when given the concept, physical object, or process.

6. Ability to conclude the correct opposite ideas when given the opposite of the concept, physical object, or process.

The third way of understanding is know-why. You may know what a WBS is and how to construct the WBS. However, your understanding is incomplete if you don’t know why you need to use a WBS. Know-why may seem the same as know-what, but there is a significant difference. For example, I may be an expert on Monte Carlo simulations in risk management. I can explain the concept and even create a spreadsheet that uses Monte Carlo simulations for risk management. However, I may not be able to explain why you need a Monte Carlo simulation in your project. I just want to use a Monte Carlo simulation in your simple weekend project to build a deck just because I like building Monte Carlo simulations. I know-what and I know-how but I don’t know-why we shouldn’t use the Monte Carlo simulation in your particular project.

It is unnecessary to have three ways of understanding to be effective. For example, your senior sponsor may only need to know why your project needs a risk register but, has only a partial understanding of what a risk register is. The senior sponsor doesn’t need to understand how to create a risk register. And the senior sponsor needs only a cursory understanding of why a risk register is needed. Just enough know-what and know-why to reassure the sponsor that the project’s chances for success will increase if you use a risk register.

An important decision for a communicator is to determine the level of understanding that his or her audience needs for successful communication. That is why communication is more than information transfer. The communicator and the receiver must use feedback to determine how the message was received and if the communicator created the intended level of understanding in the receiver for the communication to succeed.

In the last three years, I have undertaken an intensive study of project management communication as it is portrayed in academic research. Using two complementary research methods, deductive qualitative analysis and qualitative content analysis, I examined 272 journal articles published between 1970 and 2016 to determine how academic researchers defined and investigated project management communication.

I found that many researchers conceived of project management communication as "information transfer" (the "transmission model"). The transmission model was and is still the dominant perspective. However, since 2010, there have arisen new project management communication models that build upon the transmission model by adding the emergent dimension of understanding (the "emergent model").

In the research, my research partner and I have demonstrated how deductive qualitative analysis paired with qualitative content analysis can cast new light on the academic research into project management communication that indicates how the evolution of project management can influence the evolution of communication practices in managing projects. It is our hope that our research will inform and benefit both the project management academics and practitioners.

Our next research project is to study practitioner-initiated research into project management communication. We hypothesize that practitioners will have adopted the emergent model of project management communication to help them to better manage today's projects.

"What does research reveal about how project managers can communicate with their teams more effectively?" My latest work is a feature article in The Public Manager.

One-hundred and forty-one years ago, a charismatic but, vain leader made a bad decision that cost him his life and (almost) all the lives of the people who served under him. General Armstrong Custer decided to fight a force of 2,500+ Indian warriors with only 210 men under his command. John Hollon, well-known HR guru, has argued that we should memorialize June 25th as a cautionary warning of the perils of bad management.

What made Custer's decision so wrong? According to Hollon, five factors:

1. Refusing to listen to others.
2. Arrogance.
3. Didn't focus on the goal.
4. His opponent had a better strategy AND people that could be trusted to execute the strategy.
5. Bad luck.

Personally, I am not sure that the fifth factor wasn't just a natural result of the first four factors. Even so, when I've seen projects go off track and even ultimately fail, I bet you could trace one or more reasons back to one or more these factors.

As a project manager, take time on Saturday to reflect on Custer's Last Stand and think of how you can prevent your current project from being your last stand.

Good article in HuffPost Business about beating task saturation with operational elasticity. I didn't know the actual names of these two terms but, I certainly know feeling of being overwhelmed with tasks and not having the organizational resources to lighten the load of too many tasks.

Task saturation can lead to employees shutting down or hyper-focusing on a single task. Task saturation can not only harm employees, it can destroy organizations.

"Task saturated employees may often start to shut down and channelize on one problem. . . . Some channelize to a point where they are dropping some of the most important elements that can keep your jet in the air or in business, keep your business alive. Agility is lost and if an issue comes up and is not in the channel they are dealing with at that point in time, they are going to ignore it. . . . With zero to minimal operational elasticity you often find teams having high stress levels, pushing back, starting to take more time off, basically - shutting down. As operational elasticity decreases, performance decreases and executional errors increase."

There are five ways to increase operational elasticity and prevent task saturation:

1. Build a pipeline of talent.

2. Set clear expectations and have frequent performance debriefs.

3. Establish agility in the organization.

4. Recognize employees for their work and contributions.

5. A coherent, consistent, and communicated strategic narrative.

Task elasticity may be more of a problem for project teams because of the heavy schedule and resource constraints. In the above list, there are three methods in which communication helps to build operational elasticity. Good project managers already know to set clear expectations, recognize project team members, and deliver a compelling [project] strategy narrative.

So, what does operational elasticity look like in project teams?