Stakeholder Communication ... A "Pattern Language"

Stakeholder relationships are shaped by communications ... and these are shaped by cultural patterns with the organization. That can be positive ... or not.

Our discussion of how we communicate with our fellow stakeholders has brought to mind a presentation based on ideas from Christopher Alexander’s books, A Pattern Language and The Timeless Way of Building. (In the spirit of full disclosure, I must tell you that the speaker is my oldest son, John.  With a master’s degree in architecture--the building kind--he has spent much of his career in web design, user experience, and related project management.)

Many of Alexander’s concepts regarding building design apply to most of the non-construction projects that I’ve worked on.  While he discusses the importance of experience and competence with the processes and concepts to be applied in a project, a couple of his points clearly tie to stakeholder management. 

1.    The power of mastery of the steps in a process. The project process is a powerful tool for arriving at the desired outcome with optimal efficiency.  All team members need to understand and follow the process.  IBM made this one focus of their Project Management Center of Excellence transformation strategy over 20 years ago.

2.    Stakeholders sharing a common project language. As part of following the process, all stakeholders need to be able to communicate their wants and needs, and to report status with a consistent terminology.  The most successful projects that I have seen met those criteria.   Some stakeholders had worked together so much that their approaches and language were standardized, but others relied on the documented project processes and a project glossary to uphold standard phrasing and meanings.  Where formal glossaries existed, they were living documents, and stakeholders held each other accountable to note any non-standard usage.  We assumed standard meanings unless otherwise noted.

The most successful teams also shared some other traits.   They didn’t leave to chance that they shared the same assumptions.  They discussed, documented, and periodically reviewed them to ensure common ground.  Similarly, expectations were documented regarding the desired project outcome and how the outcome would be achieved.   “SMART” criteria were used to define acceptable outcomes and how project success would be measured.  Even expectations regarding how and when stakeholders were required to communicate were documented as part of the processes to ensure that risks resulting from communication failures were minimized.

As I thought about it, those project successes seemed to nest perfectly in Christopher Alexander’s theory.  His approach included four basic elements.  Below I’ve listed those elements and how I saw them applying to project management and managing the stakeholders in a project:  

• Pattern name: What do we call the project approach, process, or tool?
• Problem:  When do we apply that “pattern” in our organization?
• Solution: What elements make up the “pattern”?
• Consequences: What results/impacts can we anticipate from the use of the “pattern”?

The “patterns” that we have developed in project management are concepts or principles, usually learned from past successes and failures.  For project managers, they can help us reduce uncertainty, and assist us in finding the best alternative in the face of often incomplete knowledge.  The “pattern” could be using a project charter, conducting a risk workshop, holding a stage gate review, or establishing a clear definition for a business term used in the project documents.  Whatever the “pattern”, it would help add a degree of certainty, and create a common understanding in the project “community,” which includes all project stakeholders.

One reality of specifying a pattern is that novices often use the pattern as an absolute and do not understand that there are many variations and applications of a pattern.  I remember attending a meeting many years ago, when Total Quality Management had recently been adopted by the hosting organization.  We had a very complete discussion of a matter, and the experienced people around the table were ready to make a decision.  When a vote was called for, a recent graduate of the organization’s TQM training said “we can’t vote yet, we haven’t had three meetings to discuss the matter!”  (We voted!)  Patterns are wonderful, but we must guard against valuing the form over the substance.  Virtually every tool and process in project management is scalable; it’s not a one-size-fits-all approach.  Knowing what’s right for the circumstance is part of competence with the process.

What have been your experiences with “patterns”?  What has worked and what has not met your expectations or needs?  How can one move their team to mastery of the processes? Please share your ideas in the comments.  

Next time, I’d like to continue along this line and share some thoughts about how we talk about time, and its role in stakeholder management.