In a previous article I spoke to the notion of how important it is to translate our project management language and our customer’s domain language into a common language. We do this so we can better manage our project and ensure it accomplishes what is expected.

Build Tools Your Customer Can Relate To

In an article entitled “Industry-Focused Development” Information Week, October 11, 2010, Jon Barcellona talked about a software intensive effort where they first created their own software programming language that spoke the language of the business they were supporting. Having the actual programming language “know” medical concepts, in this case, helped them to be able to work with their customers without having to translate or “hide” their code. Instead they could often talk to their customers in a structured programming language that “Clinicians [found] intuitive.”

This turns out to be a great concept that works across time and technologies.

Incrementally Build Those Tools As We Learn

Take for example my time as a young lieutenant in the Air Force. As we came to learn and understand the aerospace domain we built software functions that mimicked what we needed to do (e.g., point a sensor, detect a sensor event, send a sensor command, etc.). Pretty soon, even though we were using arcane tools such as FORTRAN, assembler and COBOL, we had a set of primitives that the experts in this aerospace field readily understood (as opposed to For loops, function calls, data declarations and the like). Once we had a sufficient (but always increasing) set of basic function, we found that programming the functionality became a simple discussion and “composition” of the basic functions we already had. As the engineers and scientists we worked with came to understand our “limited” vocabulary they could literally describe what they needed us to do in our shared vocabulary. We could quickly then program the functionality and demonstrate it so they could see it work.

Even Failures Become Useful

One really interesting part was when we implemented something exactly as they asked for it, and it didn’t work as expected, and they thanked us! They thanked us for making it easy to test out and prove — or disprove — new approaches much more rapidly than they had been able to do in the past. As we produced working code and demonstrated it on a daily basis (and it was put into use on a daily basis) we could claim to be fairly “agile” decades before it became a defined and increasingly popular approach!

Use Their Terminology, Not Ours

While this has been a software intensive example, the lessons learned can be applied to many projects. Project management, often in terms of tasks, risks, critical path, resources, etc. can benefit from being translated into the technical language of the project being done. In fact, the artifacts of project management are often best left “behind the scene” and the discussion on progress centered on the functional area being managed. Talking about being short two resources for task number 352 might be better stated as “we still need to free up two mechanical engineers to be able to start work on the latches by the end of next week.” I’ve seen too many project managers (PMs) who didn’t take the time to find out what something really meant in the language of the customer.

Experience Directly What Our Customer Sees

I had PMs managing defects in products — ensuring they were prioritized correctly and that someone was assigned to work on them — where my PMs rarely understood the defects they were managing. I encouraged them to personally reproduce the defect on the product (which was a handheld consumer mass market device) so they could manage with authority and understanding. I found my PMs were much better managers of the defect repair process, and added considerable value, when they understood the defects by directly experiencing them, rather than by just reading what was often no more than an unclear description of the defect.

As project managers, we need to strive to understand the specific language of our customer and be able to translate and speak in the domain of the project rather than in our project-speak. We benefit by better communicating with our customer without losing the advantages of the project management discipline.

Are you able to communicate comfortably with your customers in the language of their expertise?