An SDLC project when executed with distributed teams needs attention in many areas involving processes in addition to technologies. The maturity of the processes and the sincerity of the team following them, goes a long way in deciding the fate of the project. One such area of concern for almost all projects is the management of Issues (till testing phase) and defects (there after).
Issues can be of any type, ie it may be requests for clarifications of any requirements, setting up of customer specified environments or any other thing that needs a clarification from a geographically distributed team. As the number of issues grow, it necessitates a consolidation, tracking mechanism and process for followup & closure. Traditionally people resort to xls sheets. They create an xls sheet (mostly issue-log.xls 😉 ) with numbers of columns varying according to the experience of the person creating the sheet, consolidate the issues in it and put a process in place for shuttling the xls sheet between onsite and offshore in a specified frequency with updates happenning on either side.
There are a lot of problems with this approach. Namely,
>1> It needs single point of contact on either side. It creates a dependency on those persons. God forbid, if any one of them falls sick, your project falls sick.
2> More often than not the team runs into version issues of the sheet, ie different teams working with different versions of the sheet. Some people go to the extent of attaching version numbers with each xls, only making matters worse.
>3> Managing the file becomes difficult once the number of issues grow beyond 100s.
>4> A lot of issues need discussions. It can happen over phone or in a mail chain. In either case the information related to the issue gets scattered into various media. So the xls sheet alone doesn’t provide complete picture on the issue at any time.
>5> At least one resource each side is wasted for handling the file. If you don’t dedicate a person to handle the issue log on each side then you are bound to get into a version issue, loss of issues or orphan issues.
>6> Situation is much more complicated if you have to manage defects. Because defects usually have a work-flow and need to exchange multiple hands during its lifecycle. Using xls sheet to manage the life cycle is hell of a task.
If your issue/defect management is not correct, you are bound to fail to close many issues which only gets highlighted during UAT phase of the project and becomes a reason for spoiled relationship between you and your customer.
My experience says, these tasks should be automated through introduction of appropriate tools. There are quite a lot of commercial as well as open source tools in market today that help in issue and defect management. Commercial tools tend to become complicated in their effort to provide maximum features, thus increasing the learning curve and reducing the ease of use. We have used open source tools effectively for this purpose and they provide the bare minimum features required to do the task in hand effectively.