When is it good to start using project management applications?

Question

Hello, I was wondering, when is the right time or the correct project size to start using project management applications ( like Redmine or Trac ).

I have a serious project, for now it's only me developing, but I use redmine to set my project versions, issues, and estimations. I think it's a good idea, because you never know when somebody else is going to join the team, and also allows me to organize myself effectively.

I ask this question because I was Teaching Assistant at my university for one year in a row for a course, and I got questions about this very very often. While I'm a believer of the KISS principle, I think that learning to use this tools early is a win-win most of the time.

I really believe that we can avoid this question to become argumentative, and that there's somewhat of a consensus about this issue, which I consider quite important in todays software development world.

So, when is the right time ? what is the correct project/team size ?

Answer 1

I'm not familiar with redmine, but assuming it has functionality and complexity comparable to trac, I would recommend "going for it" earlier rather than later -- and I wouldn't really call trac a "project management" tool (a term which makes me think of Microsoft Project, GANTT charts, etc, and whose appropriateness to software development projects is much iffier and debatable), but rather an "issue tracking" tool.

If you have a simple project there will be fewer and smaller issues (feature requests, bug fixes, ...), but there's no harm and definitely some good in tracking them -- it helps organization even in a single-person project to easily determine and tweak what areas the problems or desires are in, their relative priorities, etc.

There are other approaches to tracking (e.g., Pivotal's tracker) that may even more appropriate to projects run along agile lines, at least in theory, but personally I've always liked a trac-like system whatever other tools and approaches I'm using (if I can get it to integrate with my code management system -- track changesets automatically wrt what issue or feature they target, etc, etc -- then I'm a really happy camper).

Some tools and approaches that help with big complex projects don't "scale down" well to simpler, smaller ones (because there's a minimum threshold of complexity or rigidity in the approach or tool that makes it too heavy to bother for small-enough projects), but, in my experience, some tools and approaches (a version control system, an issue tracker, code reviews if I can get them and automatic "programming style" checkers in any case, etc) scale down sweetly and I'm always happy to have them in my toolbelt, simple as a project may be!

Answer 2

When the project has reached a complexity level, either in management or code requirements, that all the members of the team cannot give instant answers to stakeholders about the status (immediate or projected) of the project.

What this means: you can start using management tools or the equivalent at any stage you like (here 'equivalent' means using a tool like Excel along with a burn down chart or similar). There is no line in the sand that somebody can draw and then say "once you cross this line you must use a management tool".

You don't have to justify using management tools, you simple have to justify the expense of them. Do they give you enough efficiencies to be worth what you paid for them, the time you invested in training, or the time it takes to use them?