Interacting with clients using project management systems

Question

I work in web development, that involves a lot of smaller custom projects rather than one large product. Requirements and specifications are always coming from outside the company.

We've setup a ticket tracking system (Active Collab, which is rubbish compared to redmine btw) and given access to clients so they can submit issues. The idea being that less time is taken up with long phone conversations and emails. I think it can work really well if done right.

However I'm not so sure it's always a good thing. Feature requests have gone up a lot on some projects. The system also needs to be friendly to non-developers while having the many features that developers use. Developers' tickets do not always map 1-to-1 with the tickets clients will create.

So the requirements and broader tickets need to be separated from the more specific developer (specification) related tickets. Perhaps we could use two systems, one for clients to submit their requirements or describe a bug, and one for developers to create tickets like implement method x in class y. Maybe this can be achieved by structuring tickets into more appropriate categories or creating sub-tickets under a feature request ticket. I've briefly looked into Pivotal Tracker and it has a fundamentally different workflow.

tl;dr How do you keep technical tickets (developer jargon) separate from client tickets (layperson language).

Answer 1

The Two System Approach

I currently use the two system approach. We use

• OTRS - Help desk so users can submit issues. Many of them aren't very technical, so there are issues coming in that could be a bug or could be user error that we can just tell them how to do what they can't seem to figure out. (There are much better ticket systems out there. Use what flavor suits you.)
• Team Foundation Server 2010 - This is our bug tracking/task/feature request server. If an issue comes in via OTRS, then we create a new bug in TFS and note the associated OTRS ID (and copy the history into the bug description/notes). If the OTRS ticket is something that looks like a feature, then we pursue that in the ticket. Once we have enough information to properly create a bug, task, or feature request in TFS and understand how critical it is, due dates, and have enough requirements, then we create one.

We keep users up to date through the ticket system along the way as needed. Once we've completed a bug fix or feature and release it, then we update the ticket system as completed.

This works well for my team, as we only have a small handful of developers. However, this hides technical details from users that might get see it and mentally "check out", while at the same time allowing a technical filter so that "silly" requests don't make it into the true feature tasks (and so a developer doesn't accidentally work on something that hasn't been approved).

Answer 2

Tell them to use the tracker as their wishlist.

I have actually used Redmine and given access to clients so they can use it as their wishlist, it has worked with some, but not with all, and it generally depends on their enthusiasm/involvement with the project.

Another recommendation for a simpler and perhaps more engaging tracker is PivotalTracker. The interface is basically one dashboard with drag & drop for tasks. Very scrummy.

Finally, you could try looking for scrum based project management tools (scrum is an agile project development methodology that puts special attention on communication with the client), such as Agilo and have them create "user stories".

Use a simpler customer feedback application

Another apporach I've used is to put an UserVoice tab in the frontend and/or backend, and this generally works better since it is a simpler interface (seems that Redmine can be too complex for some). The good thing about UserVoice is that you can actually handle items as tasks/features, giving "planned", "under review", "started", etc.