Should I include the developers in the official email communication with clients?

Question

Currently I am a Project Manager of the following team:

• 3 Android Developers
• 2 Web Developers
• 2 iOS Developers

and we are currently between the project initiation and development stages since the client has not yet clearly identified all the exact details of the system but we know the basics.

Every now and then I need to contact the client and ask them for more information regarding the project (documentation acceptance, asking questions).

Should I include the developers in these emails or not? The good thing is this way they are able to see the answers of all technical questions themselves but once I was told the less the developers are exposed to the clients the better.

What is the best practice in this case for projects which contain up to 10 developers in them and are for small to medium size projects (1-6 months in length)

Answer 1

TL;DR

Should I include the developers in these emails or not?

Increased direct communications, if done effectively, can improve the viability of a project. However, there are often pros and cons that must be considered. A lot depends on your project management framework, your project communications plan, and on the type of relationship you have with your client. In short, your mileage may vary.

Direct Contact with Agile Frameworks

The Agile Manifesto recommends direct interactions and customer collaboration whenever possible. This often stands in contrast to more traditional project management frameworks that value formal communications plans and carefully-managed client communications.

In the XP framework, direct contact between the development team and customers is both expected and required for success. Consider the following excerpt:

One of the few requirements of extreme programming (XP) is to have the customer available. Not only to help the development team, but to be a part of it as well. All phases of an XP project require communication with the customer, preferably face to face, on site.

In Scrum, sometimes the Product Owner proxies for the customer, while at other times the Product Owner facilitates appropriate interactions between the customer and the Development Team. Both proxy and direct communication methods have their pros and cons, and neither approach is actually mandated by the Scrum framework.

There Are Always Downsides

An unmediated interface between customers (or end users) and the Development Team is generally The Right Thing™ for mature agile teams, but there can certainly be counter-indications. For example:

1. Teams or customers with low process maturity often need a mediator.
2. Development teams with poor communications skills, or team members with significant personality deficits, should not be client-facing.
3. Customers who are not on-board with a cooperative, negotiation-based, or back-and-forth approach to product delivery should be insulated from the Development Team.
4. Projects based around "big up-front design" or that rely on detailed specification documents are often designed to minimize ongoing communications.

Whether or not the benefits of increased direct communications outweigh the potential social, political, or contractual consequences is something that each project must determine for itself. There simply is no universal answer to this complex consideration.

Answer 2

Email as a medium for capturing, documenting and disseminating requirements is a bad idea

1. Developers are not trained in the art of handling clients diplomatically. If you include them in the email, they will respond as they see fit and you may be left handling the damage control.
2. The assumption that the entire development team will somehow absorb all the requirements based on emails back and forth is naive.
3. You may be setting yourself up for nasty disputes with your clients as to what exactly you committed to deliver.

You need a better way to capture requirements. If you are following the Waterfall process, use the email communication with the clients as a source of information for what goes into the requirements document that you will get the client to approve. After that any changes should be handled through change control.

However, I strongly recommend that you follow the Scrum process. Designate a Product Owner (PO) on your side to engage in this communication with the client to understand their business goal and what would constitute success in what you all are setting out to build. Then this PO should be able to work with the dev team to write user stories in the form of

As a [type of user], I want [some goal] so that [some reason].

And also write testable acceptance criteria for each such user story.

Here is the opinion of Roman Pichler, author of Agile Product Management with Scrum, on the PO role in small teams. You will see it in the Q&A below the blog post: "I have worked with a few teams where one of the team members played the product owner role successfully. Generally speaking, I find combining the roles challenging."

Answer 3

The roles are irrelevant. What is important is who benefits and what the benefits are from receiving the message as compared to its costs, risks, and penalties.

You should be able to articulate that, if the developers are in the communication loop, the receipt of a message has specific benefits for their work. The benefit can even be indirect and intangible such as the feelings of being involved, being in the know, and transparency. However, including the developers can raise costs, risks, and penalties, such as actual increase in dollars to include them, the risk that some type of misunderstanding or disagreement can occur that really did not need to, or that the information is really not that beneficial and you are slowly training your developers to ignore e-mails, causing them to ignore something they should not have.

If you want thoughtful communication practices, you need to think about these things. Don't just adopt an easy include or exclude policy--as likely most of us do--as the damages could be very high.

EDIT: Based on the bolded question on best practice, you are clearly looking for the one size fits all answer...do so at your detriment. There is NO SUCH THING. Google a bit on audience analysis. It works both ways, one to define the message in content and abstraction based on who the audience is as well as defining who the audience needs to be based on the message to be delivered or messages you need to extract.

Your best practice will work some of the time and will yield varying degrees of adverse consequences the rest of the time. Communications are hard. It requires some thought. The best practice answer you need is, analyze the audience and message and make them consistent.

Answer 4

Even more - you should get your client and dev team on a regular requirements call.

It's your client who knows what should be done and it's your team who knows how to do that and what time it will take. Facilitating a regular requrements clarification call with the team is the best option.

You can use the following call agenda:

1. PM gets the client and the team on the call.
2. PM shares the screen with the backlog of requirements, mockups and other details.
3. Client goes through what should be done. Team provides feedback.
4. PM updates requirements on the fly right on the shared screen.
5. PM sets up next requirements clarification call as needed.

Answer 5

It really depends on your team, but here are a few thoughts:

Having all your developers on all email chains is probably not a good idea as it can't all be relevant to the work they do. Too much data is just noise and slows teams down.

Beware of loosing requirements in email chains. An email is not the right place to define a story or be the source of record for a scope change.

Consider appointing a tech lead or equivalent to screen emails for the first iteration and have them discuss with other devs as necessary to get feedback on if the team wants to undertake this practice. Go from there and decide if you really wish to involve all your technical resources in customer facing emails.

During retro or informally, make sure you occasionally ask the participants something like "was this useful, were all the RIGHT people in on the communication?" Be willing to adjust accordingly based on your dev and customer feedback. There are devs that are business savy and there are devs that should be kept as far away from customers as possible. Figure out where your devs lie on this scale before creating the direct customer-dev link.

Think about the benefits of having a dev on the chain vs the cons. Think about devs and customers as distinct audiences. Can their needs be met through this form of collaboration?

Answer 6

The good thing is this way they are able to see the answers of all technical questions themselves

If this is your goal, then you can accomplish this goal without risk of client-dev email interactions going south by forwarding the emails to your devs.

(I will also pause here to agree with those who caution against using emails to capture requirements. They can provide useful background and context info tho.)

My team's situation is different (my "clients" are not external), but I've found that productive client-dev working relationships usually take some time to develop. For short 1-6 month projects, I would avoid it.

(Unless of course you're taking an agile customer-embedded approach.)