Don't Protect Your Team!

I was involved in a project which had not gone as smooth as we'd hoped. By the end of the project we had a chat about tying up the pieces, so I asked the project manager how she felt we could do better next time. I explained that looking back at the project to see what we can do better next time is a way to avoid repeating the same mistakes again.

One problem with this project was that the team had to work extra to correct and implement things too late in the project time frame. The reason was poor planning, which in turn was a natural consequence of the team not having enough information available. It's worth noting that there had been enough time for them to do everything, but they thought they were finished and had started to work on other things.

Why did that happen? Well, it turned out the developers had no contact with the customer and was left in a vacuum once the initial sale was completed. Promises where made and then shifted over to the team to "make it happen". The customer had absolutely no idea who was on the team, and the team had no idea who the customer was (apart from the company name). Not a single time during the project did any of the team members talk to the customer.

I asked why the developers were kept out out the loop like that. The response I got from the project manager was that "shielding the team from the customer is a way to save them from having the customer calling all the time and disrupting their work". In other words, don't give them your phone number.

It turned out the project manager had been in a situation once where one customer had been a real pain, constantly disturbing the team. This can happen in a maintenance/support situation, but it was not an issue in this case. I said that I thought the developers were professional enough to deal with such issues if they popped up and that is was no big deal.

I honestly don't believe this was the real cause for blocking the teams communication. I'd rather think the project manager didn't want to give up control. Loosing control can be frightening, and the only way to deal with that is to have a bit of confidence in the developers ability to do their job. Or it may  be that the project manager was so used to doing things that way that it didn't even occur to her that letting go of the reins might be a valid approach.

In the end, the project manager dismissed this idea and said her approach was preferred: is is better to shield them from their customer and instead channel all communication through her. (Side note: the project manager had been absent for most of the project, increasing communication problems even further. From that point of view she did trust the team... to fend for themselves.)

Here is what I think. Allowing the team to interact with their users during development makes it much more likely that problems are dealt with and helps make adjustments quickly and timely. It also increases trust between the two parts which allows for more ideas and better creativity, not to mention improving chances of doing business with the customer again.

Another important factor is that the team, through direct communication, feels more responsible and committed to the tasks: "I'm doing this because I want to make a great job delivering as I've promised." as opposed to "The project manager wants me to do this, because she says so." What do you think is more likely to produce great results?