So, after a lot of selecting and trialling (thanks Dave!) we've managed to get Mantis accepted as the company bugtracking system. It has had an immediate effect on project management, making the large number of small projects and tasks appear to be manageable. However, it isn't just a case of having a system in place, it needs to be fully accepted as the central source of information and the way it is used has to be sorted out.
I have been edging towards an Agile Development process as we have lots of fast moving projects with changing client needs. The first way this is implemented is by releasing more frequently and by making each release meet a specific client need. E.g. from a list of stories/aims the client decides that 'being able to share content between users' is the most important, the next version number is given this as a description and issues that need to be completed to make it happen are linked to the version. Mantis has a 'Fixed in Version' field. This gives simple project planning, e.g. which issues are intended to be completed to reach this goal? or by planning what future releases will achieve plus project tracking after the release, e.g. which issues made up version 1.0.2? or when was xxx fixed?
Clients are quite positive about this approach because it bridges the gap between technical issues and what they want the system to do. It gives them quicker time-to-market and allows them to adjust the development path as the world changes around them.
Developers get a sense of achievement by reaching a release, and they get this motivational boost more frequently. The project timescales are decided for each new target release, so the clock can start again for the developers rather than being constantly late.
Problems can occur if issues are allocated to a Developer too soon. I believe that the issues should only be allocated when they are required to be done (it is linked to the next release) and that the developer is free to work on it. In this way the Developers' task lists remain short and manageable. Allocating an issue required in the future can demotivate a Developer as they can never clear it from their list. There can also be a demotivating effect if developers are allocated to do an issue immediately after they themselves have reported it. Developers don't want to own all of a system's faults, they hope that others will be able to join in when the time comes for that issue to be looked into.