I'm a student and I work as an undergrad in an IT department. They are very effective programmers, but as far as documenting what they do and tracking what time is spent on specific tasks - not so much.

I was put in charge of setting up project management software. So far, I've created a satisfactory solution with Trac. But still, programmers use it because "the boss says so" and do so grudgingly.

No one likes having to go to a separate webpage, logging what they did, checking boxes, and what not - so my question is this:

As a programmer, what incentives or features in project management software would encourage you (or least make it more bearable) to use it?

  • I've never seen time tracking being done anything other than grudgingly. Other results of using such software may be much more rewarding: seeing progress towards a defined milestone/release. Being able to check why a given commit was done (because it's linked to a ticket with the relevant discussion). Having a place to document what does not belong in the code (well, documentation is not really a favorite activity either, but having to do it in a Wiki is less pain). – Joachim Sauer Feb 14 '13 at 7:38
  • 3
    The reason people use this grudgingly is because management is going to use these figures in all the wrong way. In 99% of the cases in my book management isn't even qualified to judge these numbers because they're not qualified statisticians. – Pieter B Feb 14 '13 at 7:44
  • 2
    I find that this question, and all answers to be valuable, and that the downvotes seem to be not deserved. I guess the downvotes simply reflects that the topic being asked here evokes the frustration of the downvoters' everyday work. – rwong Feb 15 '13 at 13:20
  • Consider using game theory to encourage adoption in the scenario you mentioned. Give rewards or recognition for the most tasks completed/bugs fixed/etc as reported by the project management software. – George Cummins Mar 13 '14 at 12:48

"The boss says so" is actually a good reason, which is why it works. As you've noticed though, it isn't great for morale. If you want to encourage programmers to use it, look for ways it can make their lives easier. The main ways it can do that are:

  • It can stop you forgetting things. Anybody who has had a last-minute panic before (or after!) release would rather not repeat the experience. As long as all the tasks/bugs go in there, it should be impossible to forget about things. Having everyone use the same system means things don't get forgotten even when people leave the company/go on holiday/are off sick/etc.
  • It makes for better scheduling. Nobody likes crunch periods. If you've got a deadline looming and you aren't going to get things done in time, then the sooner you (and your boss) know about this the better. You can cut features, assign more resources, or just spread out the extra hours over a longer period (8 45-hour weeks are probably better than 1 80-hour week).
  • The little things. A lot of PM tools can do various little things to make your developers' lives easier: If it integrates with your wiki, that can make it easier to keep it up to date. If it integrates with your source control system, it makes it easier to quickly find the commit where you fixed that niggly UI bug which has suddenly appeared in a different part of the application.
| improve this answer | |

It's unclear in your question what exactly you're using the software for, and I think that's the central point, not features.

You need to formulate clear and concrete goals: what do you want to achieve with this software? And how specifically does this software help achieving those goals?

If the goals are shared by the programmers, making them understand these points should help convincing them to use the software (or prompt them to point out specific problems with the software that can be fixed).

If the goals are not shared by the programmers (such as micro-managing their "productivity" as measured by some artificial metric), then the only way to make them comply is to outright order them, and punish those who don't comply. I hope I don't need to point out that this is a very bad idea.

| improve this answer | |

We're not using Trac, but Bugzilla in Combination with ScrumWorks. We've introduced it, after a few incidents where features/bugs have been forgotten to fix or under-priorized, and led to a hurry in the end - and therefore resulting in bugs, stress, etc. Now we adopted the new working style of

  • turning on the computer
  • check new bugs/requested features
  • fix/implement it
  • check in with bugzilla, mark it as solved
  • repeat

I, and this is an absolute personal opinion, find this very comforting, because at the end of the day, you see what you've achieved and what you have to do tomorrow. It took a while to get used to the extra steps, but it was worth it.

Regarding to you question, what features would it make more encouraging, i would say integration with the IDE. No additional programs/webpages, just a few more clicks every day.

| improve this answer | |

I'm one of the developer of Teamwork, for those that did not know it, it is a quite famous project management software. As you may guess, for us, understanding which are the features that make the difference in the adoption is one of the main points. In my experience the adoption of a pm software is very hard, basically because people are lazy to change their routine, moreover because they do not have any benefits in using it. And this has been our focus: we tried to add a lot of features that give benefit not only to the pm but also to the worker. I could list these features but it could not be so important because they depends on how your team works, my suggestion is to find the tool that give as much benefits as possible to the worker. For example, if your team works with issues, try to find the best tool for managing it in a friendly way for the user and so on. Hope it helps!!

| improve this answer | |

One feature that worked well for me was a taskbar applet, or whatever a program running hidden with a small icon on the taskbar is called, that was always running on my machine and letting me know about events in the tracking system relevant to me. It would show a little reminder when I had a new bug or a new task assigned to me. It was also caching and refreshing queries in the background, so when I needed to see the list of my bugs, it was ready and appeared immediately after I clicked (no waiting for a web page to render, login, etc.).

Something like this could also be used to quickly report time allocation. Just double-click the item, and report today's progress within two clicks, assuming it would pre-populate the reporting form with yesterday's values and good defaults.

It was an internal tool, and I don't know which of the tracking systems offers such feature.

| improve this answer | |

Asking about features

Asking about features is the wrong question, because most of the features mentioned don't help its users reach the end goals.

Whose tool is it?

There are two major confusions:

  1. Individual team members confusing project management tool with personal productivity tool.
    • Personal productivity tool is a personal choice, i.e. each coworker may have different choices. It's what works best for an individual.
    • Personal productivity tool can't help reach the end-goals below. To reach the end-goals, the whole team must agree on some shared Project management tools that everyone will use.
    • Good project management tools should improve personal productivity, but that's a side-effect, not an end-goal. On the other hand, bad project management tools that impede personal productivity will impede its own adoption.
  2. Managers seeing project management tool as their tool to manage people.

What are the end goals

Visibility of work - allowing everyone to know what each coworker is going to work on. If two coworkers' work is going to conflict with each other, or if one has a good suggestion to offer to another, then having this visibility will encourage the dialogue to happen.

Status of project - exposing impediments; warning about impossible-to-meet deadlines or features that are too hard to implement; to indicate a project's readiness

Change control - making sure that changes to the production system, or to the source code, or to the hardware are well-documented, and that potential conflicts are prevented from happening.

Knowledge management - make note-sharing, record-keeping and searching easy. Anyone may share anything learned from the work - it could be some Heisenbugs, some online tutorials, or someone's hunch that a few issue tickets have a common underlying cause. Casual observations must be gathered so that patterns can be mined out.

These are just a few examples of end goals. None of these are "software features" per se. They are features (characteristics) of productive teams.

But some people say the best project management tool is a whiteboard

Judging from the end-goals, I cannot refute that.

| improve this answer | |

Link it to source control, and require a task ID on commit. The time spent on the task is assumed to be the time between commits. If a dev stops working on a task to start another, they should commit to a work in progress branch.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.