Communication within your Project Team

I saw some things today that really threw me a curveball. Let me explain:
I sank my claws into a new project today. It's basically a collection of 'tickets' that got lumped together and got called a project and prioritized. Each ticket goes through a cycle of requirements -> design -> coding -> QA -> UAT -> Release.

I started investigating one ticket in depth and talked to the architect reviewing the design to see if the suggested approach was feasible. After 15 minutes, I knew that what was being asked in the requirements was too big and that the best way to proceed forward was to descope some things. I called over the Business Analyst who wrote the requirements spec (and who luckily sits a few aisles over) to clarify. The architect went over his concerns and the BA understood and we quickly honed in on a much more tractable solution. The whole thing took about an hour. And furthermore, the solution was so simple, that the architect simply coded it himself! Now we can actually go ahead and test it!

However, it wasn't completely as smooth and easy as I described above. There were some valuable insights I gained from facilitating the interaction.

Some of the highlights are:
1. The architect thought the writer of the requirements document was in London because he assumed the person who created the ticket (who is in London) also had written the requirements; this was not the case. The author of the document was in NY but the architect never even looked at the cover page of the document! There would have been a lot of time wasted going back and forth with the person in London trying to get clarification on requirements when the 2 people who needed to talk most were both in the same location! It's really mind-boggling how something so simple can become so convoluted. We easily could have lost 2 or 3 days if the person in London got involved and tried to be the go-between.

2. We all know one of the functions of the BA is to translate business requirements into technical specs; basically being the go-between for business & IT. One doesn't think there needs to be any kind of translation within IT itself. It's easy to assume IT staff can all talk to one another and understand each other. In yet another twist of events, this assumption has also proven not to be true. In this particular case, the architect is very technical, repeats himself, and elaborates on points to an extreme degree. He is also a non-native speaker of English and speaks haltingly. It does take some effort to really listen and draw out the salient points. The BA isn't very technical and wanted things explained at a higher level. I facilitated the conversation between them. Where the BA didn't understand things, I stepped in to explain. In some cases I would cut off the long-winded explanations of the architect and other times I would ask him pointed, leading questions so he would emphasize something important.
It dawned on me that even within IT, it's dangerous to assume we all are on the same page. Miscommunication can easily happen between 2 co-located colleagues. (Note that this is the most ideal form of collaboration: a face-to-face meeting; yet it can still go horribly wrong!)

The larger lesson here is that a Project Manager with great listening skills can make a huge difference by facilitating interactions between the various members of the team and making sure everyone is clear on next steps. Many PMs just want to stay above the action and merely delegate the tasks to the team members and collect status items to report. They can add so much more value by delving into the details of the project alongside their teammates.