Communication is key in software projects. I do not have to elaborate on that. There are enough and more examples on that. Having said the above, I have come across many instances during my career managing software projects, where communication actually came in the way of the project’s success. Here is on such case and how it was handled.
A Case Study
A few years ago, one of our program managers was assigned to a software development project that was supposedly in RED status and tasked with pulling it out of the mess. The project was a high visibility one with a large team, dragging on for over 3 years with the costs running into millions of dollars (and counting). The development was more or less done but the software was in the testing phase for many months. The testing teams were reporting issues in a never-ending stream. With all the quality, timeline and performance issues it was just not moving to customer user acceptance testing. The team was very tired with the late nights and weekend workings, the senior management was concerned that there seemed no light at the end of the tunnel, the customer was getting jittery about the success of the project. Frustration all around.
During the first couple of weeks, as the program manager talked to the teams to get a handle on the issues and bottlenecks, one thing that struck him was that the team was providing daily status updates to many stakeholders. Sometimes more than once a day. As stated above, this being a high-profile engagement, everyone concerned wanted to know what was happening. The Account Manager who was stationed at the customer location, the Delivery Director of the project, the Quality Assurance Team, the Senior Management, The Customer etc. The intentions of the stakeholders were noble as they wanted to provide support/help to the team. But it was back firing. The project’s leadership team was preparing daily reports, defect analysis, revised schedules, presentations and so on and sitting on conference calls and meetings most of the day. They were not able to spend enough time on the actual bottlenecks and fixing them. Time was being spent more on talking about the issues and less on doing anything about them. (Many of you who have been part of projects that had escalations all around can relate to this!).
So, one of the things that the program manager did, was to ring fence the team. He informed all the stakeholders that no one would talk to the team directly. All communications and status updates would be channeled through him only. He would provide the details to all the stakeholders. He would attend the meetings and conference calls. No one from the team was to be disturbed. It was a small change to the way everyone functioned but had a big impact on the project. The team on the ground was freed up to focus on the issues. And in a couple of months the project moved to User Acceptance Testing and soon went live.
It would be unfair to say that just a change in the line of communication, magically solved all the issues in the project. There were other initiatives that were undertaken with the help of the above stakeholders that also helped remove the bottlenecks. But freeing up the team from daily reporting of work done, had a significant impact on the scheme of things.
As a manager, when you are concerned about the project, you want to know what is happening and you end up asking for all sorts of data and reports from the team. But sometimes providing status becomes more of a nuisance to the team slogging it out. You got to resist the temptation and back off and give space to the teams (who know exactly what is wrong and how to fix it) to work things out. Easier said than done.