I had a small telecommuting team once, and what helped us a lot were two pieces of technology around which our development process was built.
The first one was a simple issue tracker. The 'nudging' and 'motivating' bit became almost redundant. There always was a list of issues that needed to be addressed one by one, and the employees could work on the simplest ones, or on the complex ones, depending on their skill level and personal energy level at the time.
The second piece was the idea of short 'sprints' we borrowed from the Scrum process. Each week we aimed to deliver something that worked, so there was a set of issues that needed to be addressed as a matter of a priority. In this way the team stayed motivated and saw results of their work, i.e. there was an (almost) instant gratification.
Interestingly, one of my developers was a 'star', and another was a 'rookie', but they found a happy balance under this system. The experienced one tackled complex/architecture related issues and avoided the boring simple tasks which the less experienced employee was happy to do because that kept him feeling productive and contributing.
The management process consisted of a weekly skype conference call where we would agree on a issue set for the next 'sprint', and then we simply communicated through email to check on the progress during the week and to address problems. Obviously, I had to write up the requirements (in the form of issue tickets) as well.
Again, a simple issue tracker (we used Roundup) was the single most useful management tool for that project.
We do many of these, however we don't focus on weekly tangible results which is a really important point and can motivate the team a lot. One of the problems that we don't do web startup which means whatever we do, it'll be generally delivered to the end user at least 2 months later, but still seeing something get done is a good way to be motivated.
I've done similar. Last couple of years I've been using Redmine for issue tracking. (Hint: Run under JRuby with glassfish gem and don't use sqlite.)
IM has generally worked better than email, prefering to keep useful chunky data in redmine as a "knowledge base". IM has also worked to keep the users involved.
Do you know if there are any screenshots of Roundup? Hadn't heard of it before this, and am intrigued, but the SourceForge page doesn't list any images of it in action.
The first one was a simple issue tracker. The 'nudging' and 'motivating' bit became almost redundant. There always was a list of issues that needed to be addressed one by one, and the employees could work on the simplest ones, or on the complex ones, depending on their skill level and personal energy level at the time.
The second piece was the idea of short 'sprints' we borrowed from the Scrum process. Each week we aimed to deliver something that worked, so there was a set of issues that needed to be addressed as a matter of a priority. In this way the team stayed motivated and saw results of their work, i.e. there was an (almost) instant gratification.
Interestingly, one of my developers was a 'star', and another was a 'rookie', but they found a happy balance under this system. The experienced one tackled complex/architecture related issues and avoided the boring simple tasks which the less experienced employee was happy to do because that kept him feeling productive and contributing.
The management process consisted of a weekly skype conference call where we would agree on a issue set for the next 'sprint', and then we simply communicated through email to check on the progress during the week and to address problems. Obviously, I had to write up the requirements (in the form of issue tickets) as well.
Again, a simple issue tracker (we used Roundup) was the single most useful management tool for that project.