Team Tools
Team tools should be determined by the project's needs (including regulatory compliance requirements), constrained by the budget and labor costs to create and maintain it, and ultimately selected from the field of choices by the team members that will be using it on a daily basis.
"Thou shalt use work-flow X!" is rarely met with enthusiasm, and unless you have a background is designing IT controls, you may have a hard time actually enforcing the use of your top-down tool-chain. Organic, bottom-up tool-chaining is generally a closer fit for the team's current work-flow, and documenting what people actually do (rather than what you wish they would do) automatically results in higher compliance levels.
Alternatives to Completely Rolling Your Own
Even if you decide to bypass commercial or widely-used tools, there are work-flows that don't require quite so much "winging it" on your part. For example:
Don't use carbon-copy (CC) addresses for team communications. If tracking team emails is important, use a mailing list or web-based forum. Google Apps provides both types of functionality, but you also have a wide variety of alternatives such as Mailman, Majordomo, ezmlm, and whatever group mail features MS Exchange has sprouted for its current "pay to play" upgrade cycle.
Even if you bypass enterprise source control or full-fledged document management systems for documents, you still have many choices other than a shared-folder dumping ground. Some examples include:
- Automatic versioning with Git, Apache, and WebDAV.
- Versioning and edit tracking with Google Docs or LibreOffice.
- Use Markdown and Pandoc to put documents under plain-text version control.
- Use AsciiDoc to put complex documents under plain-text version control.
- Use a wiki that versions binary blobs or attachments (e.g. GitHub wiki pages) so that you can attach some context to your files.
Consequences of Rolling Your Own
If you use an enterprise-class tool, or at the very least a commonly-used solution, then you can expect a high bus-factor for its use and maintenance. Custom, in-house solutions must be maintained in-house, and are more likely than not to become both unmaintained and unmaintainable over time--especially if the care and feeding of the system is not a formal part of someone's job, nor part of the job description of the person that will eventually replace him.
In addition, in-house tools often require written documentation on how they were setup, how to fix common issues with the tool chain, and written procedures about how to use the tools in accordance with the team's work-flow. As a worst-case example, you will need to clearly proceduralize naming conventions and "who's got the file" processes for managing serial or concurrent access to team documents in a shared folder. If you think this is trivial to do, or not really necessary in a small team, then I applaud your sense of adventure in going where angels fear to tread.
That doesn't mean in-house solutions are bad. Sometimes, they fit the work-flow better than COTS solutions. However, they are not free: there is always a labor cost to design and maintain them, and ongoing process overhead that will vary based on the work-flow and tool-chain, and the tools may represent a form of technical debt that will need to eventually be paid off before the TCO exceeds any up-front cost savings you may (or may not) receive.
The Best Solution of All
The best solution of all is to allow your team to self-organize around a set of requirements. Build a user story around the requirements, and then let the team figure out what tools they need and how to adapt the tool and work-flow to fit one another. As a rough example:
As a team member,
I want to be able to search all project-related emails for a six-month period
so that I can find free-form project-related information using complex search queries.
Focus on who and what, rather than how. Make this user story a priority for the project, and then let the team figure it out. Regardless of the constraints in time, budget, or functionality, you will generally get better results with this approach than with infrastructure-by-fiat.
YMMV.
