While some developers are learning the language of basic design concepts through osmosis, it is nevertheless helpful to have a common vocabulary as long as the definitions are consistent and mutually understood by developers and designers.  “When you have two people talking about the same thing in a different way, you have chaos pre-programmed,” said Microsoft’s Schormann.  Development and design converge … but not completely, Software Development Times, July 2012.

Speaking the same language is a key project management tool. I’m of course not talking about a national language, but a technical or domain language.  We not only need to talk the domain language of our customer but we have to work at ensuring our teams can talk to each other in a way that is productive.

Compare with Quit Talking Jargon To Our Customers

The first step by the project manager is often just the awareness that this can be an issue.  I recall trying to explain to software development managers the notion of how many days it was taking to fix our defects in terms of averages and percentile distributions.  It was clear my comments had very little meaning to them (“but some defects are big and some are small!”).   I was rescued by a hardware manager who jumped in to help me explain it (“Huh? What do hardware folks know about software defects?”).  I came to realize that my hardware team was well versed in quantitative methods as they were essential to hardware quality and manufacturing.

For more see Defect Reports Are Your Best Friend

This also reminds me of the Mars space probe, the $125 million Climate Orbiter, that failed because one team was talking in metrics and the other was talking in English measurements.  Not all projects fail this catastrophically due to one mis-communicated specification, but many projects struggle because of a continual disconnect between the concepts and notions of the individual teams.

As much as I campaign against too many meetings, one good reason to get teams together periodically is to speed the process by which they come to understand the key elements of each other’s discipline.  I would have project kickoff meetings where each team would present what they were doing and why to the other teams.  This provided both an introduction to the project and a learning session for teams about what other teams were doing and why they were doing it.

Also see Meeting Madness, Don’t Do It!

When I first started working in the mobile phone industry, I took a series of courses on mobile phone technology (e.g., CDMA, TDMA, GSM, 3G, 4G etc.). While this didn’t make me an expert it did give me the basic concepts and vocabulary I needed to talk to project teams and customers.  Later I discovered I knew more than many folks who had been in the industry a lot longer than I, because I took the time to take a comprehensive course.  They had great specific knowledge, but they had not had the advantage of rounding out that knowledge by updating themselves on what else had been going on in the field.

See also Why We Don’t Really Need All Those Experts

As  project managers we need to be aware of the differences in technical language and concepts spoken between our teams.  If necessary we need to take action to update ourselves and to get our teams together to accelerate them learning a common set of terms and concepts that allow them to communicate effectively.  Meetings and training courses can facilitate this learning and we may need to employ these project management tools to avoid chaos in our projects.

How well do you and your team communicate with teams outside of your expertise?