How communication determines project outcomes
A project’s outcome is directly determined by the design of the communication environment of the project. This theory was proposed by Melvin Conway in 1968 in a Datamation magazine article entitled ‘How Do Committees Invent?’ In it, he put forth an idea that has come to be known as Conway’s Law. It says that “organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.”
In other words, the solutions that teams come up with mirror the structure of those teams. There is a structure-preserving relationship between the team that works on a project and the project itself. Their shapes match, they mirror each other—or, in technical terms used by Conway, “there is a homomorphism [mirroring] from the linear graph of a system to the linear graph of its design organization.”
Conway’s Law
What this means is that the design of the project’s communication environment will be mirrored in the project outcome. For example, a government agency has requirements for a new product. To develop the product, it works with its contracting department and hires a large contractor. The large contractor has two internal development teams and also has relationships with three other subcontractors which it will work with on this project.
Conway’s Law suggests that the final product will consist of at least five subsystems, reflecting the two internal development teams and the three subcontractors. Further, the interface between the subsystems and the nature of the final product will reflect the effectiveness and quality of the interpersonal communication between all parties including the subcontractors, the internal development teams, the program manager at the large contractor, the government agency and the contracting department.
The mirroring effect described by Conway is supported by empirical research from a Harvard Business School Working Paper. In it, the authors state:
Specifically, products tend to “mirror” the architectures of the organizations in which they are developed. This dynamic occurs because the organization’s governance structures, problem solving routines and communication patterns constrain the space in which it searches for new solutions. Such a relationship is important, given that product architecture has been shown to be an important predictor of product performance, product variety, process flexibility and even the path of industry evolution.
The decisions we make about the communication environment of our teams and the communication processes determine project performance. These decisions are expressed in the communication design. Communication design is how we design the communication environment on our projects. It is the flow of the communication on a project and is the system design of how people communicate and interact. Communication design, as a separate field of study, is based on the awareness that communication is not about reporting on data from a project; rather, it is about shaping reality on a project.
This is a fundamentally different view of communication from that discussed in standard project management texts such as A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (4th edition) from the Project Management Institute. This view is radically different from the traditional definition of the role of communication in project management. The traditional approach to a communication plan views the project as an independent endeavour, working on its own, and ignores the impact of system design.
In the traditional view, communication is a necessary fluid that runs through the system to keep the wheels turning. The content of communication is determined by the project. People use whatever tools they like, in whatever way they like, to pass along information when they feel they have to. Rather than being a tool for shaping reality and improving project outcomes, communication becomes a burden.
Reluctant project managers and team members ask: what information do I have to send out or pass along now? To me, this explains emails forwarded to everyone or a ‘reply all’ with five pages of email back and forth quoted within the email. The sender doesn’t realise the power of communication; s/he is just concerned with getting another task off their plate. Email sent. Communication happened. Check.
Changing the communication environment
Conway’s Law has significant implications. It means that the solution that our teams come up with depends on how we structure the communications on the team. It means that part of our role involves designing the communication environment on a project. We are communication designers.
As managers, the way we design and create the communication environment directly impacts the project. To quote Conway: “We have found a criterion for the structuring of design organisations: a design effort should be organised according to the need for communication.” We can optimise the project environment to meet the project’s goals by changing the communication environment of the project.
Even in cases where we don’t have full control over the project’s communication environment, being aware of it adds to the list of places where we should look for the root cause of problems on a project and where we can look to find solutions. If we ignore the communication environment, we are making a choice to accept it for what it is and are agreeing to manage the project under constraints that may or may not help it.
If we pay attention to the communication environment, even if we cannot change it, we can consciously manage the project within the constraints, tweaking the items we do have control over so that we can meet our goals while working within the constraints. We can tailor our communication and what we communicate to increase its effectiveness within the communication environment, and we can improve our ability to contribute to the project and increase our value to project participants.
This is an extract of Mark Phillips’ book Reinventing Communication: How to design, lead and manage high performing projects (Gower, 2014), published with permission.