Features that encourage use of project management software

Question

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?

Answer 1

"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.

Answer 2

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.

Answer 3

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.

Answer 4

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!!

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

Programmers just want to code. That is why they hire management to deal with housekeeping tasks around coding.

If a programmer uses a tool, it is because that tool offers some value to its work: compiler, IDE, DVCS, issue tracker, Google, Stackexchange...

If a tool has value only for management (i.e., time tracker), programmers won't adopt it or will use it reluctantly.

Introduce tools to programmers only if they can benefit from them.

Answer 9

Look, Project Management Software has the same problem that has plagued CRM since it began: lack of simplicity. For the last decade, CRM has had adoption rates lower than 50%. It's ridiculous, and it's all because the software makers have feature heavy apps, but provide very little in terms of usable user interface.

Solution? Unfortunately, this is mostly in the court of the makers to fix their software, but what you can do is look for simple project management software. If you're using a software that's hard to use, complicated, or just a pain to navigate, this is a huge deterrent, especially if you are forcing it on somebody else who isn't already chomping at the bit to use it.

Look for software that doesn't just get the job done, but does it with finesse and ease. Give the software a good first and second look, and ask yourself, "if somebody told me to use this, would I be able to learn it? Use it? Would I like it? Would it be easy?"

Put yourself in your developers' shoes. Consult with them before jumping head first into a product. Show it to them, get their feedback on what they like, what they don't, and what they think would motivate them to use a software. Your team is probably just as able to tell you their opinion on that as they are at getting their jobs done. Listen to them, and you'll get some good advice to take to the market.

Hope you find a software that works.

Brad Hodson / Director of Marketing / JobNimbus