Metrics are invaluable for managing software projects. Anyone who has managed a non-trivial project knows that a software development project comes with many moving parts. Requirements change, timelines change, business priorities change, productivity fluctuates due to team ramp-up/down, the budget gets slashed and so on. In the midst of all these changes, metrics are lodestars that guide the course of the project.
Having said the above, I believe that metrics alone are not enough to successfully manage a software project. As a Delivery Manager responsible for large software product implementation projects, I have had access to various status reports, presentations and graphs/spreadsheets with all sorts of data telling me where a particular project is heading. However, my experience has been that casual water cooler conversations with team members sometimes tend to throw up interesting bits of information. The person providing the information might not know the impact. But someone with access to other project metrics and a higher vantage point, might be able to assess potential project risks from that piece of information.
A Case Study
We had a software product implementation going on for a client in North America. A tester from our Mumbai team went to Chicago for a period of 4 weeks to help the client with the preparation of test cases for User Acceptance Testing. One morning, the Quality Manager (responsible for all the client engagements and not just the one in question) in the Mumbai development center, was filling up his coffee at the pantry vending machine and happened to see a tester waiting for her turn. He started chatting with her and during the conversation asked her “How are your daily status calls with your colleague at the client site (Chicago) going?” She said that they had not been able to speak for the last three days as her onsite colleague was not able to attend the calls due to some personal challenges. As soon as he got back to his desk, the Quality Manager called up the client tester’s home in Mumbai, spoke to his wife and learned that their child was unwell. Sensing a potential leave request, he asked the Project Manager to immediately mobilize a backup tester from his team to travel to Chicago on short notice. It turned out to be a smart move as the client site tester’s child was hospitalized two days before the User Acceptance Testing was to start and he had to rush down to Mumbai. At this crucial juncture, being a tester short at the client site, would have hampered their testing and pushed out the project timelines. The well laid out project plan (with all the dashboards and metrics) would have gone for a toss if not for the casual vending machine conversation.
Senior Managers walking the halls and having casual chats with the development teams on the project status does not imply “overriding” the Project Manager’s status report. These conversations “validate” the status reports and sometimes throw up potential risks not highlighted in the reports.