Project management and issue tracking

There are huge number of project management and issue tracking systems available in the market, but users (and vendors) often arbitrarily use these terms, which erodes the difference between these notions. This may give rise to questions like:

• is it possible to use MS Project for managing the software development
• is it possible to use TrackStudio instead of MS Project
• which is better – MS Project or TrackStudio

Basically the domain of these systems is very similar (task and deadline control), but in most of the cases they can’t replace one another.

Therefore, the customer generally wants the programmers to develop a system, which could provide a solution to his business requirements. He doesn’t want a system with lots of functions, but he simply wants the solutions to his problems. Technical task (i.e. description of system components and functions, and not the solutions of its tasks) is generally the maximum level of abstraction which the customer wants to understand the project. Thereafter, the customer wants to split the entire project into understandable stages and control the deadlines, expenditures, and percentage of completion etc.

Project management system is the ideal option to communicate with the customer:

• customer sees the required information in the language he understands. For example, if in MS Project the coding of report generator is one task, then the customer wants to know when this task will be executed, who is responsible for that, how much money has been spent for implementing this task, percentage of completion etc. This information allows the customer to solve his own problems, without scrutinizing the programming process.
• customer doesn’t see the non-essential information. He is interested in the state of the project, and he is least concerned in the process of coding. Therefore, in project management system it is not required to divide “report generator’ into 100 sub-tasks, describe the state of each sub-task, and correspondence etc. All this information is useless for the customer.

But for programmers, the level of project management is a continuous abstraction.

• programmers don’t want to know what should be the end result, but they must know what has to be done at the given moment. Programmers need the description of process (make the dialog box like this, do the debugging, move the button by 5 pixels rightwards), and not the description of result.
• programmers can not say how much percent of report generator is ready, they can more or less exactly say how many hours it will take them to implement the current change (move the button right), however without taking into account the testing and debugging.
• programmer can not say what is the relation between report generator and import module, each of these components can have hundreds of tasks, and it is not he who will do all of them. Even if he can write the generator without import module, it doesn’t mean that tester can test it.

It means that there must be a particular person (project manager), which will translate from the language “what must be” to the language “what needs to be done” and vice versa. He must first split the task “write report generator” into 20-30 sub-tasks, assign the assignees (different people can do different parts of the generator), periodically check the state of the work, create news tasks as per requirement etc. Particularly for this purpose “Issue Tracking System” is required.

Periodically he must evaluate the number of unfinished tasks, for which feature “change requests” have not been written, what has already been tested, how frequently the new problems are detected, how many users worked on the system etc., prepare his own estimate about percentage of completion and inform this to the client (e.g. feed in the MS Project report).

TrackStudio allows integration of issue tracking and project management, for this purpose “project tree’ needs to be created in TrackStudio, thereafter in each of these projects the manager assigns specific tasks for the programmers. On the basis of programmers’ data TrackStudio allows to calculate the time spent on any part of the project, to set the deadlines and budgets, and control their implementation.

TrackStudio even allows to export the data to MS Project, at the same time it allows to specify which particular categories of tasks must be included for export (e.g., notifications about errors are not included). But there is hardly any benefit of using the export for automatic reports to MS Project because of following reasons:

• the tasks are created step by step as per the implementation of work, issue tracker does not know which tasks have not been included in the system, how thoroughly the application has been tested, how frequently the testers detect the problems, whether the system has been shown to the users etc.
• tasks on different sub-projects are practically executed continuously from the start of project till its completion. In MS Project this looks like fractional-piecewise plan, where each job is executed during the entire duration of working over the project (if looked from programmer’s point of view)./li>

Answers to questions given in the beginning of the article:

• MS Project can be used for managing the software development if customer and programmers speak in the same language: customer is ready to put forward specific tasks to the programmers or programmers are ready to put the tasks before themselves on the basis of customer’s requirements.
• TrackStudio can be used for preparing/correcting the plans for the customer. Features for processing the basic information (how much time does it take to solve the task, which type of clients’ tasks we are not able to solve most of the times and so on) are significantly better than most of the products by our competitors, but automatic generation of reports for client on the basis of any issue tracking system is a very bad idea. For the same reasons, it is also not a good idea to generate “user manual” on the basis of source code, comments and correspondence between programmers.
• In the project if customers can not allocate 100-200 sub-projects, state of which they are ready to control, then usage of MS Project will be extravagant, then Excel is certainly better. If internal organization of developers’ team is simple (few programmers, every one has his clearly assigned part of work, programmers themselves communicate with the customer) – usage of issue tracking system will also be unnecessary and Excel can also be sufficient and thus given a try.

What if the customer wants to have full control, and number of programmers is huge, then we need to look for a system, which could suite clients as well as programmers. Nothing can have a better solution than TrackStudio.