What collaboration tools are effective for working with non-technical people?

Question

For programmers working in corporate environments and outside of the start up world, there are a wide variety of non-technical people that are important stakeholders in the development process. These include other functions within the company such as marketing, finance and legal, for example, and also include customers and others outside the company.

The point of this question is not “care and feeding” of these groups, but simply what tools have been found to work to facilitate collaboration and necessary interaction? I’m thinking along of the lines of IM versus wikis versus traditional email distribution lists, or the corporate sharepoint portal, but wonder what others have found to work.

Answer 1

Basecamp is a joy to use, and its primary focus is project management through collaboration.

Answer 2

We use Quickbase here. Meets all our goals.

Answer 3

You may want to take a look at these products:

• FogBugz - The brainchild of StackOverflow co-founder Joel Spolsky. Handles bug reports, feature requests, wiki, and more. I have used FogBugz before and it has been pretty solid, despite being written in its own language.
• BaseCamp - The flagship product of 37signals. I haven't personally tried this but it has gotten rave reviews from some people I know and respect.

Answer 4

We setup a wiki for shared documents, memos, status reports, etc. It took about an hour to train the entire staff, but it was well worth it.

Answer 5

When setting up a wiki you have to agree on what sorts of information go where.

When working with a mixed audience of technical and non-technical I've found that having some sort of executive summary, overview, reader's digest version with click-throughs to more detailed info is definitely the way to go.

For statuses, e.g. daily builds, regression test results, etc., you might like to consider making a dashboard page that reports everything of interest in a RAG (red, amber, green) status at the top level. Then you can click-though to drill down to more detail if required.

I implemented this for a major project and had RAG status for continuous builds and regression tests.

Clicking on the RAG indicators brought up more detail. This was repeated for several levels so at the top level you had the RAG indicator.

For example, clicking on the indicator for the regular build took you down to see what had broken the build, clicking again took you further to see who had broken the build, clicking again brought you down to the actual error message from the compiler.

That was fun to implement.

cheers,

Rob

Answer 6

I've heard anecdotal evidence (an oxymoron surely) that they get on well with Wiki's provided they have a WYSIWYG editor.

(I used to be involved with the TWiki.org project and I know they have a WYSIWYG Plugin but I'm sure "other options are available".)