Timeline for Number of people in a team that need to communicate with the client?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 7, 2011 at 21:59 | comment | added | PhD | 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 :) | |
| Apr 18, 2011 at 4:26 | vote | accept | TehBoyan | ||
| Apr 18, 2011 at 4:10 | comment | added | jmort253 | @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. | |
| Apr 14, 2011 at 21:20 | comment | added | Lee Kowalkowski | 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. | |
| Apr 14, 2011 at 16:11 | history | answered | Piotr Leszczyński | CC BY-SA 3.0 |