Cost of training
No matter how well designed the application or how good the documentation, some level of training is normally required.I agree that a certain level of training is required for any product. However, self training is more preferred than the costly training provided by a consultant. Self training is easier in the case of project collaboration if the product uses a natural work flow close to how people interact in a project.
Cost of quality
Enterprise level content management systems have complex workflow tools that prevent new content from going live until it has been checked and double checked.Teamness is not designed to be used at an enterprise level. It's meant to accommodate small teams, in which the workflow doesn't have to be "standardized", but comes as a natural way of interacting.
On one of my previous jobs, I used to work in a small team of 3 persons and our project manager implemented a transaction solution for the workflow using Aegis. The workflow was based on changes, each change going through 3 stages: development, review and integration. For each transition, a designated person from the team had to check the conditions for going into the next phase, which included code formatting, code style, compilation warnings and errors, unit tests, regression tests, integration tests and so on.
The whole procedure was dropped eventually, because instead of working on the project, we morphed into problem hunters. The tools were good, the flow was good, but the context in which they were used and applied was wrong. Quality control should be inherent in a small team.
Cost of redundancy and complexity
Unless you have a bespoke content management system, developed to your exact requirements it will probably contain functionality you do not need. That is because off the shelf solutions are designed to appeal to a wide audience.Teamness offers simple and generic type of items which my be used for a broad range of situations. A good example for this are the whiteboards.
We use whiteboards for various functions, like editing emails, but another usage we found for a whiteboards is to record a summary of the changes we make in the source code. When a new build is deployed, we easily see the changes made from the last build in that whiteboard. Simple and easy to digest, without the complexity of adding custom plug-ins for such a task, which would probably be used only by a small group of users.
Complex systems like Team Foundation Server manage this task automatically, but a consultant or a TFS/Sharepoint expert is probably needed to set up the system to map the changes made in a changeset to a list probably defined in Sharepoint. Not suited for a small team. We're happy with our solution and we find it quite flexible.
Cost of commitment
The user isn't trapped in Teamness. The data may be exported at any time in an XML file, which may be used in any way the user wants. The user owns the data. Given that the cost of training is detached from the cost of commitment, I might add that there is no commitment cost when using Teamness.
Content management systems demand a high level of commitment on many fronts. These include:
- The upfront financial investment in implementing the system
- The cost and time involved in training staff
- The substantial amount of data entered into the system
Aside from this attempt of finding the abovementioned costs in Teamness, I would add that one of the biggest advantage of Teamness is the fact that you don't have to host it, maintain it and upgrade it. For a small company this is huge.