16

Is it more useful that all the people in a team to communicate with the client or should there be one person - i.e. the project manager that does all the communication and then informs the other members of the team?

Because we have a client, that likes to have his hands on and get informed on everything that is being done and communicate with each member of the team separately. This has caused a lot of problems to us in terms of communicating with each other etc.

Should we restructure the way we communicate with the client? Would we impose more problems if communication is channeled trough only two people?

Improve this question

9 Answers 9

Reset to default
9

In my team it works like this:

When we are facing a problem, something bad has happened, the project is on fire - we usually have contact with the client on Management Level (either PM or TeamLead). The same applies when the client asks how much/long would it take to add a feature X. In such cases developers are told to forward the conversation to Management Level. Client have people on Management Level on his side too.

Then, if developers are working on a specific feature, or there is a bug submitted from a specific user at client side, developers are obliged to contact the person directly.

We came to this approach from trying more restrictive ones:

  • Single Point of Contact - we had problems with distortions of the messages passeed: from the client to the SPoC person, than to developers, and than back the same way
  • Everybody - we had problems that some things were consulted with developers excluding Management Level; another problem was, that developers were directly blamed about something by client

Now we succesfully work with our model for about a year. Developers have less distractions from clients, and on the other side they get specific information on low-level tasks directly from the person interested in it.

Improve this answer
3
  • 2
    This is a great answer. If reducing the people in contact with the client, those people had better have a thorough understanding of the capabilities of the system. If increasing, those people need to have a thorough understanding of the agreed scope of the project. Changes to the capabilities of the system or scope of the project need to be communicated effectively. It's a fine balance.
    – Lee Kowalkowski
    Commented Apr 14, 2011 at 21:20
  • @Lee - Good point! As long as everyone is on the same page in regards to scope, it is possible to have more than one communication path. It actually helps empower everyone on the team to make sure the best decisions are made as everyone will then have the tools they need to get the job done.
    – jmort253
    Commented Apr 18, 2011 at 4:10
  • I'd like to add a point - if there ARE developers who wish to talk to the client or be part of the client meetings to know the "why" behind their work or it's highly recommended to let them be a part of the meetings even if they are going to be mute spectators - of course, you need to explain this to the client as to 'why' it's good to have some interested techies be a part of the business related meetings. That does help cut A LOT of misunderstanding/misinterpretations and does increase the amount of people with tacit knowledge! It DOES work (when controlled wisely :)
    – PhD
    Commented Dec 7, 2011 at 21:59
8

There is a number of factors you should consider why deciding on your communication strategy:

  • Shortening communication paths. Basically the shorter communication path is the better. If information goes from IT guy at client's side, through client's PM, your PM, your tech lead to your developer you're risking misunderstandings. It would be more efficient if the IT guy at client's side could contact the developer directly.

  • Controlling outgoing messages. Leaving all communication paths wide open may result in a situation where your developer is making some unreasonable promises just because from his perspective it seems a good thing to do. It may be about promising some feature on tomorrow but it also may be telling that "this would take me just a couple of days," which may even be true, unless you have to account how it would affect the rest of the project.

  • Controlling incoming messages. Sometimes you deal with one of those difficult clients. They either tend to yell at everyone with no real reason or are changing their mind like twice an hour. In both cases you probably want someone who would isolate the team from such client so you'd have some kind of filter passing to the team only relevant and meaningful messages.

  • Getting right people informed. What you basically want in project is people who know every piece of information they need. Now if you have multiple communication paths you may end up in a situation where the client told a developer something which should be shared with a PM and a tech lead but the developer thought everyone knew that and the message wasn't passed. On the other hand the same situation may happen if you have a single contact person and she sucks at deciding who should know what. In this case the decision is heavily dependent on people in project team.

  • Keeping internal affairs, well, internal. It's not that rare when we deal with some project-related issues and we don't want to share everything with the client. Especially when relations between you and the client are rather far from ideal you might prefer to communicate well-thought messages instead of updating them with every bit of information related to the problem.

  • Taking into consideration overall picture. Most likely a project team isn't the only group which is contacting the client, you likely have other projects done by different teams, salespeople or management contacting the client as well. Since you're the part of the organization you should take into consideration the big picture as well. If the standard approach within the company is to discuss every issue very openly with the client (rather typical case for agile organization) you might want to have more communication paths. On the other hand if you try to play with the client to suck the most out of them (sometimes happens in big corporations) the communication paths should be very limited.

It's all about finding the right balance. I'd say the goal is to communicate efficiently, which means messages are relevant and reach the right addressee as soon as possible, however you can't forget about your environment and its constraints.

In your specific case, since the current situation is a problem, I'd work to change it toward more controlled, but it's hard to say where the balance is. You may want to cut communications paths here and there and see if it helps. If so, go a step further and evaluate the result again and so on and so forth until you find your own equilibrium.

Improve this answer
1
  • All great factors, Pawel! I'd also add only another one: cultural differences (thoroughly discussed on this forum).
    – Tiago Cardoso
    Commented Dec 6, 2011 at 15:28
6

If this client creates conflict by approaching everybody in your team I would recommend you to establish a Single Point of Contact (SPOC) mechanism.

This client will need to go through this allocated person or department in order to seek for info. If the client keeps calling other members of the team you will need to give specific instructions so they immediately forward the call to this SPOC person or group.

Improve this answer
5

In agile methods you get a role of Product Owner or similar, which creates single person responsible for working on the product vision on your side. However I would suggest the following (assuming that your team is <10 people):

  1. I would make one person responsible for the general communication regarding the project/product. This role can be transitive for example each month.

  2. In my opinion it's good to arrange a meeting from time to time where all team members can meet the client or his representative to talk about the next steps in the project. This is the easiest way to take everybody on the same page. Of course you can use variations depending size of the team and size of the project. For example the meeting can be arranged around some working group and a particular part of the system.

  3. To avoid the effect of client loosing his ability to stay informed, you may arrange shorter meeting from time to time. This would use the protocol of a daily stand-up, but it does not need to be daily. The point is to allow team inform everybody else what is happening. It needs to be short and client needs to listen. You may allow him to comment at the end, but the meeting itself cannot be used for discussions. They need to be taken later, preferably by the person assigned in the point 1.

The one thing to avoid for sure is to allow contacting a particular developer ad-hoc. This will lead to misunderstanding and loss of information.

Improve this answer
4

I can unequivocally say there is no right answer to this question. There are benefits and penalties to both extremes and this will become more of a balancing act between the two. You control communication through one or two, you can ensure a consistent message going out and less misunderstanding coming in. Both of those are benefits. However, you will stifle teaming and risk development of mistrust between client and contractor, and inappropriate filtering both outgoing and incoming messages by your POC. Penalties.

You need to feel your way through on this one and find a balance. Tighten some areas and keep others loose, if possible. Whatever you choose, capture your risks and go work them.

Improve this answer
3

As others have said, there's no right answer, in general. In your case, you asked if changing the communication to a one or two channel approach would cause problems. No, because you've already said that the Owner going directly to the team is causing problems, so removing some of those channels can only help control a problem you're already experiencing.

Improve this answer
1

There should be ONE point of truth.

Otherwise, there's way too much politics, misinterpretation and wasted time.

Improve this answer
1
  • I do agree with a single communication-skilled focal point person as long as there's a person for each level of communication. The presented scenario is too vague to understand if it's a 5 or 500 people project. On the latter, I'd say that having a single point of truth to discuss every tiny detail with the client may become almost impossible.
    – Tiago Cardoso
    Commented Dec 7, 2011 at 12:24
1

I agree with Mark Phillips for the most part. Keeping a single point of truth shields you from "He said, She said". When you are really in the think of things, consistent messaging is crucial if you want to maintain credibility and trust.

With that said, if you are getting inconsistent messages across your team, you have a larger problem with internal communication.

Improve this answer
1

Head of PMs that is aware of the customers/projects and known by the customers eases everything for all sides, especially in the case of “emergency situation“.
Also, Head that informs the customer and introduces new PM to the customer in the case of changing/ shifting the PM to another project will prevent weakening the relation with the customer.

Except the above or similiar conditions, the customer’s contact person should be the related PM only in order to complete the project as required without any chaos that is caused by multiple info from multiple sources.

M0N4K0 explained in detail SPOC very well.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.