When you are project manager, you are like the conductor of an orchestra. You must have talent yourself and you need the talent of others. But to make a success, you not only need everyone to have the same score sheet, you also need everyone to share the vision of what the group is trying to achieve. This Vision might very well not be coming from you. You can have been hired to implement someone else’s vision, but in all cases everyone needs to understand the goal. You can be producing Liszt’s Hungarian Rhapsodies, but there is quite a gap between a version for a cartoon and a version for illustrating the way it could have been played at the time of Liszt. Still the same score and the same artists in the orchestra, though.

Sometimes, sharing a Vision sounds trivial but it is not always. The reasons can be numerous. Here is one of those situations…

The context

I once was working on a pretty big software project for a customer that had some of these communication illnesses I like to cure (I mean the project has illnesses, not the customer ;-) ). Let me tell you about the symptoms and how they exemplify some of the language challenges topics I have presented in this blog.

The IT project team has over 20 people. This project is absolutely key to the business and there is no question about the status of “flagship project”. The project is presenting a double challenge to the organisation, not only they are starting one of the biggest project they ever had, but they have also decided to adopt a new software development process. They have decided to adopt Scrum when they have used Waterfall so far. In a sense, I respect this bold approach very much, but I also believe that if you are doing that, you should prepare for the worst. They were actually rather lucky as they were not in front of the worst per se. They were in front of enough troubles but not the worst.

The Audit

Communication and Sharing a VisionI had been conducting an audit that had allowed me to talk to almost all members of the team. And something was very puzzling me: every single person I was talking to, genuinely seem to do the best they could on the project. They actually delivered parts of the projects under tremendous pressure and I heard nobody complain. But there were always some recurring themes, which were taking me toward some communication issues. The biggest problem was the lack of shared vision on the project. Not that there was no Vision, not that people were not sharing the objective of being successful, not that people were not talking to each other, but for some reasons the existing Vision never got passed the mind of its inventors.
So, I started to investigate who was holding this Vision and how it was captured when I discovered that the Vision of the future was all captured in a Database Entity relationship model.
For those of you who are not too technical about software project, let me try to give you a flavour of what this representation means for the team. For the developers (rather technical people we may say) it is like a Frenchman trying to read an Italian newspaper without speaking Italian. You have some guesses, maybe a rough idea but surely not confidence in your understanding.
For the staff acting more on the business side like the Business Analysts, it is like a Frenchman trying to make sense of a Latin text without having studied Latin. You keep hope for about 1 line of text and give up at the second line.
For the management, I mean the people who have very little or no technical knowledge of how software is actually implemented, it is like …well “life is too short, isn’t it?”
Just to illustrate what such a diagram is looking like, I am putting one below.

Entity relationship diagram

Entity relationship diagram

Fascinating isn’t it? Of course, it was making a lot of sense for the database technician. I would even concede that it could have been acceptable for conveying the Vision of the project between such technicians.

A Basic Communication Rule Broken

Now, guess what? Well yes indeed the project was actually led and paid for by …non technical top level managers. And for them, everyone knows that life is far too short to dare presenting to them this document and hope they’ll make sense out of it. So, nobody did. But in fact, to make a long story short, nobody out of the creators and maybe one member of staff was making any sense out of that document. As meaningful and accurate as it could be it remained meaningless to almost everyone.

Why was that? Because an essential rule of communication had been broken: when you communicate with someone, you have to use the “receiver’s language”. And by language I do not mean French or English or Chinese, I mean a vehicle that is understandable by the receiver. I mean concepts, images, analogies, and definitions that belong to the receiver’s world. If you use your own language, it creates two contradictory effects:
In the one hand the “sender” is satisfied with himself and knowingly or not feels superior by using a language hardly understood. This is how the computer scientists inside organisations have mastered the last decades. They have made sure to use a language nobody understands, keep the knowledge between them and make the others look like fools. Knowledge is power and power is money.
In the other hand you have a receiver that is highly frustrated, does his best to create a picture of what is said, necessarily creates a fuzzy picture if any and ultimately looses any confidence in what is said.

Pick the right language to communicate with the teamWhat I eventually did with this customer was build a set of documents that were telling the story of the project, where it stands and where it was going. I did this in such a way that everyone in the team, and in fact in the company, could actually share that Vision. The results demonstrated the importance of understanding the mechanics of communication. The best intention in the world can hardly overcome the challenges of communication between people coming from different “worlds”. What is true for national cultures (see other articles in this blog), is also true at a lower level inside a nation, between people not sharing the same background. It creates the same barriers with the same effects. In this case though, misunderstanding would not be called racism. But how do you call it when the developers of a team are saying “Oh, the business? They don’t understand a thing. They don’t even understand their own needs!” while the business people will say in the corridors “bah, these techies, they are just a bunch of hopeless geeks anyway, they will never have an ounce of common sense!” …

The rule of the day will be: whatever it takes, make sure when you communicate with someone that you are actually using his or her “language”. Doing differently is wasting time and maybe even more damaging than no communication at all.

International and offshore projects

In the case of communication inside an international project or a software project outsourced offshore, this situation can be very dangerous for the project, indeed. Not only you have to integrate the business or technical world of the receiver; you also have to take into account the culture of this person. See my other blogs for more examples of this question; Category: Cross-Cultural Communication.

Let’s think about IT!

If you like this article, what about sharing it on Twitter, Google+, FaceBook, or whatever you like?