Fog Creek Software
Discussion Board

Practices for remove project management

I will have to manage a small team of developers working on several small projects in a different part of the country.
I would be interested in any suggestion for better remote management-I want to be able to track down their daily activity and to follow the development as close as I can.

At this point they don't even have a source control system, bug tracking, task management and not even a coding standard...

So the first thing i want to do is get everybody on CVS and probably install Scarab( as a issue tracking system and enforce clear coding standards.
But for tasks and tracking down their daily activities I don't yet have a solution other than Excel..

Do you have any recommandations?


Tuesday, June 3, 2003

Keep CVS task-oriented, and track checkins against tasking. Make sure they check in their code every day.

That should be all the supervision they really need...


Tuesday, June 3, 2003

I'm always amazed at the number of people posting questions like that (what bug tracking system/project management system should I use?)  When the site is backed by the Fogcreek, and their offering is FogBugz.

Its (very) reasonably priced, and from what I've seen claims to have the ability of "projects managing themselves".  Wouldn't you think to try it out - there is an online trial version...

I'd expect to see more "I tried it, and would like to see feature X" comments as opposed to "anyone used xyz competitor to FogBugz?".

Anyhow...  just puzzling. 

Nat Ersoz
Tuesday, June 3, 2003

Once you get them on a CVS and delineate how/when check-ins should occur, and after you've set up a bug/issues system you're really more than 50% of the way towards a highly functional team.

My gut feeling is that the biggest problem you'll have with any remotely managed project is the problems people see but keep to themselves because they don't have the daily "Oh, hey John - while we're waiting in line for lunch let me tell you about a problem I think I see with your interface" that coders on site have (of course being on site doesn't mean they're any less reluctant to point out showstoppers).  So open the lines of communication as best as you can (but avoid a huge meeting over the phone - we all know those bite hard).

Tuesday, June 3, 2003

You have to watch the usual people problems - the team might have old projects that they have to support locally and those could bleed their time away from your project. You won't be there to keep people away.

Ultimately, however you decide to structure your project management stuff, base it around milestones so you can track how the schedule is keeping up.

Keep an open information policy, and everythign above board, logging all bugs etc. Have everyone send you emails with their progress & issues at the end of the day. The schedule/project plan should have high visibility (Excel good, MS Project bad), the bug tracking should have high visibility, and a forum for less-specific communication would be useful. If you are subverting source control or bug tracking software for work-monitoring purposes, people can find ways to blind you.

I would ring them personally on a frequent basis at pre-scheduled times, depending on the size of the team. Being personal about it could help.

Wednesday, June 4, 2003

In my opinion, software should not be managed remotely.  I think you're signing yourself up for failure, especially for the sort of situation you describe (a multiple-project team).  So, be aware that any suggestions here will only solve some of your problems.

WikiWikiWebs allow anyone on the project to post free-form webpages that can be arranged into a mini-website.  Search Google for "Wiki Wiki" to get tons of information on this concept; there are many Wiki engines out there.

FogBUGZ looks like a good project.  Since you can't be located on-site, you certainly need something that will track the work that has to be done.

Other than that...yikes.  Best of luck.

Brent P. Newhall
Wednesday, June 4, 2003

We use FogBugz and it works well on our project.  It doesn't enforce much workflow.  We find that to be a positive because some of the other bug tracking systems we've tried required so much process that no one actually used them.

If you need lots of workflow enforcement, then it's not the product for you.  But then again, it seems like FogBugz in large part reflects Joel's take on good software development practices.  So if you're on the same page with Joel, I think you'll like it.

We used the 45-day trial as a way of selling it to management.  Toward the end of the trial period, it was a no-brainer and we bought it.

Jeremy Schertzinger
Wednesday, June 4, 2003

*  Recent Topics

*  Fog Creek Home