How should we manage communication and documents for managing projects?
January 22, 2010 4:11 PM Subscribe
What's a good, free project management system for coordinating developers, product managers, QA testers, etc. in remote locations? What do you recommend for archiving correspondence, storing attachments, and communicating project status?
For several years at my company, we have primarily used SharePoint as a document repository for our projects. For some reason, people here don't seem to like it all that much. Various complaints I've heard is that it's too hard to find things, too slow, the search is broken, etc. Quite likely these are all complaints specific to our installation, but the fact is that SharePoint has very low credibility here and it's going to be hard to convince people otherwise.
We're looking to replace it with something else. Some of the alternatives being floated are a wiki (MediaWiki?), some sort of knowledgebase product, or Google Wave. They each obviously have their pros and cons.
The key problem here is that everyone prefers to use Outlook and just email stuff back and forth. It's going to be a hard habit to break. I thought maybe there'd be a product where you could store threads and attachments in the repository simply by copying a certain robot email address on the thread, to facilitate the continued use of company email.
This is for relatively small teams, but they're in remote locations and so casual conversation to update people is out. How is everyone else handling this?
For several years at my company, we have primarily used SharePoint as a document repository for our projects. For some reason, people here don't seem to like it all that much. Various complaints I've heard is that it's too hard to find things, too slow, the search is broken, etc. Quite likely these are all complaints specific to our installation, but the fact is that SharePoint has very low credibility here and it's going to be hard to convince people otherwise.
We're looking to replace it with something else. Some of the alternatives being floated are a wiki (MediaWiki?), some sort of knowledgebase product, or Google Wave. They each obviously have their pros and cons.
The key problem here is that everyone prefers to use Outlook and just email stuff back and forth. It's going to be a hard habit to break. I thought maybe there'd be a product where you could store threads and attachments in the repository simply by copying a certain robot email address on the thread, to facilitate the continued use of company email.
This is for relatively small teams, but they're in remote locations and so casual conversation to update people is out. How is everyone else handling this?
Best answer: As a product manager at my last job, I used a wiki for this, to some benefit. I can't really say that it was noticeably superior to using Sharepoint, but my company had a culture of using it, so that's what we used, and it worked. I've also talked to folks using Basecamp, and from everything I've heard, it's a great tool for this stuff. I've also use the Outlook/Notes email-palooza, and that's worked well, as well.
I think the bottom line is here is that it's not the tool that you use, as much as how deeply ingrained the culture is for using it.
posted by deadmessenger at 4:33 PM on January 22, 2010
I think the bottom line is here is that it's not the tool that you use, as much as how deeply ingrained the culture is for using it.
posted by deadmessenger at 4:33 PM on January 22, 2010
dbmcd nailed it.
People expect a tool to do the work for them. If you try to implement a tool with no process, everyone blames the tool. You end up spending all your time troubleshooting issues with the tool and work crawls. You're back where you started.
Also, the decision-makers are not the ones who have to use the tool (usually) so the teams get something foisted on them by management looking for "metrics" and "solutions." Hilarity ensues.
posted by I_Love_Bananas at 4:45 PM on January 22, 2010
People expect a tool to do the work for them. If you try to implement a tool with no process, everyone blames the tool. You end up spending all your time troubleshooting issues with the tool and work crawls. You're back where you started.
Also, the decision-makers are not the ones who have to use the tool (usually) so the teams get something foisted on them by management looking for "metrics" and "solutions." Hilarity ensues.
posted by I_Love_Bananas at 4:45 PM on January 22, 2010
When you say "we are looking to replace it," who is "we?"
I'm also leaning toward this not being a technological problem.
posted by rhizome at 5:22 PM on January 22, 2010
I'm also leaning toward this not being a technological problem.
posted by rhizome at 5:22 PM on January 22, 2010
Response by poster: "We" is the technology leadership in conjunction with project owners and so forth. Everyone is comfortable accepting change, which will most likely involve not e-mailing documents around.
So I'm not suggesting this is purely a technology problem -- but I'm not asking the process question. I'm only asking what tools others are using in their own particular processes with good results.
posted by cacophony at 5:36 PM on January 22, 2010
So I'm not suggesting this is purely a technology problem -- but I'm not asking the process question. I'm only asking what tools others are using in their own particular processes with good results.
posted by cacophony at 5:36 PM on January 22, 2010
I don't think I've seen anyone actually run it besides Ubuntu/Canonical, but Launchpad is open-sourced now. You could conceivably run it for your organization. It features the bzr revision control system for source code, a bug tracker, build farms, a helpdesk question & answer queue, and some blueprint type planning stuff. It is notably missing any form of wiki, but I gather their plan is to implement something akin to a text editor backed by launchpad hosted bzr.
The bug tracker in particular I like a lot better than bugzilla because it's got far fewer fields and better UI. But for many people the key feature is probably tight email integration. Each new bug functions like a mailing list, with new messages being emailed out to all subscribers, who can reply to generate yet another new message.
However, while it's free, I expect it's a beast to maintain. You could perhaps contact Canonical and see if they're interested in private hosting.
posted by pwnguin at 7:32 PM on January 22, 2010
The bug tracker in particular I like a lot better than bugzilla because it's got far fewer fields and better UI. But for many people the key feature is probably tight email integration. Each new bug functions like a mailing list, with new messages being emailed out to all subscribers, who can reply to generate yet another new message.
However, while it's free, I expect it's a beast to maintain. You could perhaps contact Canonical and see if they're interested in private hosting.
posted by pwnguin at 7:32 PM on January 22, 2010
Basecamp is pretty straightforward - it's a dumbed-down version of Sharepoint, and I've used it with distributed teams and large projects with short iterations - production in Tokyo, me on the West Coast, post-production in Europe.
posted by KokuRyu at 8:18 PM on January 22, 2010
posted by KokuRyu at 8:18 PM on January 22, 2010
I think you need a more compelling reason to begin a disruptive IT project than 'people don't like it'. The problem should be measurable so when the new system is up you can demonstrably show that you've solved it. Are there specific requirements not being fulfilled by the current system? What benefits will the organization receive by a new platform? Why will people like the new system?
Most of the document repostiory/collaboration tools (that are hosted internally) can be customized to do what you want them to do - i.e. automatically store email threads. Very few will do exactly what you want them to out of the box. Even if the software is free, the customization is potentially expensive.
Another issue to consider when switching platforms is data migration. Its often difficult and has the potential for disasterous results and at the end of the excersise you may be in the same boat you are in today. Namely, all content is in a bright shiny new tool and noone uses it or is happy with the new system.
Maybe you can just skin sharepoint with a new theme or masterpage, fix the search problems and people will start liking it. It will be cheaper and faster than implementing a whole new system without the headaches of content migration.
Imagine if you set up media wiki tomorrow, how would that be different or better than what is in place now? Do you think your colleauges would just start using the new tool effectively because it isn't SharePoint?
I appreciate that you haven't been tasked to address the 'process issue', but it seems that's the pressing problem that needs to be fixed. Basically a process will lead to requirements which can be mapped to platform functionality. When the new platform meets the requirements, your users should be happy (they won't, be maybe they'll be happier).
posted by askmehow at 11:53 PM on January 22, 2010 [1 favorite]
Most of the document repostiory/collaboration tools (that are hosted internally) can be customized to do what you want them to do - i.e. automatically store email threads. Very few will do exactly what you want them to out of the box. Even if the software is free, the customization is potentially expensive.
Another issue to consider when switching platforms is data migration. Its often difficult and has the potential for disasterous results and at the end of the excersise you may be in the same boat you are in today. Namely, all content is in a bright shiny new tool and noone uses it or is happy with the new system.
Maybe you can just skin sharepoint with a new theme or masterpage, fix the search problems and people will start liking it. It will be cheaper and faster than implementing a whole new system without the headaches of content migration.
Imagine if you set up media wiki tomorrow, how would that be different or better than what is in place now? Do you think your colleauges would just start using the new tool effectively because it isn't SharePoint?
I appreciate that you haven't been tasked to address the 'process issue', but it seems that's the pressing problem that needs to be fixed. Basically a process will lead to requirements which can be mapped to platform functionality. When the new platform meets the requirements, your users should be happy (they won't, be maybe they'll be happier).
posted by askmehow at 11:53 PM on January 22, 2010 [1 favorite]
The medium isn't nearly as important as the process. Just make sure whatever solution you choose is one everyone is comfortable with and doesn't put up any barriers, because you don't want to be tempted to cut corners in documentation just because your "solution" ends up becoming more work for your team.
At the financial services company I work for we use a Wiki. It's ludicrously easy to maintain. Because it's easy to use, everyone uses it. Because everyone uses it, it's actually useful.
We just finished our year-end audit and even the auditors were saying how happily surprised they were at how easy it was to get the info they needed, write up their report and go.
posted by Civil_Disobedient at 12:17 AM on January 23, 2010
At the financial services company I work for we use a Wiki. It's ludicrously easy to maintain. Because it's easy to use, everyone uses it. Because everyone uses it, it's actually useful.
We just finished our year-end audit and even the auditors were saying how happily surprised they were at how easy it was to get the info they needed, write up their report and go.
posted by Civil_Disobedient at 12:17 AM on January 23, 2010
Best answer: We use ActiveCollab at work, and are very happy with it. One of it's features is that you can reply to a message via e-mail and your reply will show up in the centralized system (this feature is also in Basecamp).
It's not free however, but asking for quality software that is free, uh, good luck with that. It's pretty cheap though.
posted by wolfr at 1:24 PM on January 23, 2010
It's not free however, but asking for quality software that is free, uh, good luck with that. It's pretty cheap though.
posted by wolfr at 1:24 PM on January 23, 2010
This thread is closed to new comments.
I've worked with Sharepoint most succesfully as a collaborative environment, where docs are store temporarily; but once 'final' or submitted, are kept in a repository elsewhere.
As a PM, I keep an Excel workbook with separate tabs for Decisions, Risks, Action Items, Issues, (or open items) etc. That way things can be linked and I can tell someone why we decided something (months after the decision was made).
There are version of Sharepoint that use workflows to enforce document submission/check-in, but they take someone skilled with Sharepoint development to implement smoothly.
As I say, what you really need is a process, then find a tool that works with that process.
Good luck!
posted by dbmcd at 4:26 PM on January 22, 2010 [3 favorites]