Friday, October 12, 2007
.. and they lived happily ever after
Having seen and helped thousand of users installing and trying Teamwork, I have began noticing recurring patterns, leading to happiness or ruin in the Teamwork experience. I can now often predict which path the user will take, right after her/his preliminary steps.
So here I hope to give some hints to avoid the path to ruin. I think that it can be of help even if you don't understand all technical details.
Choosing the online service
I have become a fan of the online service, at least for an evaluation (in which you should discard speed considerations, as you can always end up with a local installation): it works well and there are no systemic worries for the customers. Sometimes users underestimate the complexity of installing, exposing and protecting a server database application accessible via http; by using the online service, you are free of all that.
There are of course good reasons for choosing instead to install Teamwork locally, among which there are speed and power; but among them there aren't concerns for privacy. It may sound rude, but we are not at all interested in customer's data, and actually the European Union laws protecting privacy are terribly serious (actually, too restrictive IMHO), so we don't want to know anything about your data.
The paths to ruin in case of the online service are few:
(ruin) Real production data gets inserted online with the idea of "transferring" it in some uncertain future to a local database.
Not in all cases this can be done, and in all cases, it is a non trivial task: Teamwork’s data is structured, databases have with referential integrity.
(ruin) First things the main user does is fiddling with security settings.
By main user we mean the one who created the account, which is by default the area manager, i.e. the admin of the account, e.g. creates the other users.
This attitude actually is a sure path to ruin also in case of a local installation. Default security settings are fine for the vast majority of situations; while little Teamwork-specific competence is needed to start using it, in depth confidence with the application is needed to set up a different security model; it is best done in a later stage.
(happiness) Leave security as it is found after installation, work on projects, resources and assignments, security will be eventually handled once familiar with the basic work management features.
Installing Teamwork
If this is the choice, there are several ways that lead to ruin:
(ruin) Launch the installer not as root while not logged as root.
The installer must rename files, create others, and launch Tomcat, and there operations normally require administrative rights.
(ruin) Not using the installer.
While it is true that Teamwork is just a web-application, the installation process is not entirely trivial: the graphical installer does some job for you, which is not always easy to do “by hand”, for example, testing the JDBC-connection to the database, or that the HTTP port is free.
(happiness) Install as root in a graphical environment on the real, final database, and when happy move the web app on the "text only - only for experts" linux server.
Updating Teamwork
The fastest path to ruin is
(ruin) Not having done a complete backup of the web application and database before upgrade.
Another sure way to ruin is:
(ruin) Tomcat is not really down while doing the upgrade.
Tomcat notoriously has problems in shutting down, so check in the services (via ps -ax or Task Manager or whatever your OS uses) that it is really down before upgrading.
Using Teamwork
(ruin) Start with the ambitious plan of inserting in Teamwork all projects modeled with very fine grained tree structures.
This is a path to ruin because it will be hard to keep up to such standards. Users will feel the interface as cumbersome, and teamwork will be slowly abandoned.
(happiness) Start with a very simple set of tasks, mostly just roots, and few assignments per each user. Use massively stickys, boards, subscriptions to give a feel of the advantages of the software.
If the entire workgroup gets quickly a feel for the application, it will be more likely that they will keep using it in time.
So here I hope to give some hints to avoid the path to ruin. I think that it can be of help even if you don't understand all technical details.
Choosing the online service
I have become a fan of the online service, at least for an evaluation (in which you should discard speed considerations, as you can always end up with a local installation): it works well and there are no systemic worries for the customers. Sometimes users underestimate the complexity of installing, exposing and protecting a server database application accessible via http; by using the online service, you are free of all that.
There are of course good reasons for choosing instead to install Teamwork locally, among which there are speed and power; but among them there aren't concerns for privacy. It may sound rude, but we are not at all interested in customer's data, and actually the European Union laws protecting privacy are terribly serious (actually, too restrictive IMHO), so we don't want to know anything about your data.
The paths to ruin in case of the online service are few:
(ruin) Real production data gets inserted online with the idea of "transferring" it in some uncertain future to a local database.
Not in all cases this can be done, and in all cases, it is a non trivial task: Teamwork’s data is structured, databases have with referential integrity.
(ruin) First things the main user does is fiddling with security settings.
By main user we mean the one who created the account, which is by default the area manager, i.e. the admin of the account, e.g. creates the other users.
This attitude actually is a sure path to ruin also in case of a local installation. Default security settings are fine for the vast majority of situations; while little Teamwork-specific competence is needed to start using it, in depth confidence with the application is needed to set up a different security model; it is best done in a later stage.
(happiness) Leave security as it is found after installation, work on projects, resources and assignments, security will be eventually handled once familiar with the basic work management features.
Installing Teamwork
If this is the choice, there are several ways that lead to ruin:
(ruin) Launch the installer not as root while not logged as root.
The installer must rename files, create others, and launch Tomcat, and there operations normally require administrative rights.
(ruin) Not using the installer.
While it is true that Teamwork is just a web-application, the installation process is not entirely trivial: the graphical installer does some job for you, which is not always easy to do “by hand”, for example, testing the JDBC-connection to the database, or that the HTTP port is free.
(happiness) Install as root in a graphical environment on the real, final database, and when happy move the web app on the "text only - only for experts" linux server.
Updating Teamwork
The fastest path to ruin is
(ruin) Not having done a complete backup of the web application and database before upgrade.
Another sure way to ruin is:
(ruin) Tomcat is not really down while doing the upgrade.
Tomcat notoriously has problems in shutting down, so check in the services (via ps -ax or Task Manager or whatever your OS uses) that it is really down before upgrading.
Using Teamwork
(ruin) Start with the ambitious plan of inserting in Teamwork all projects modeled with very fine grained tree structures.
This is a path to ruin because it will be hard to keep up to such standards. Users will feel the interface as cumbersome, and teamwork will be slowly abandoned.
(happiness) Start with a very simple set of tasks, mostly just roots, and few assignments per each user. Use massively stickys, boards, subscriptions to give a feel of the advantages of the software.
If the entire workgroup gets quickly a feel for the application, it will be more likely that they will keep using it in time.
Labels: teamwork installation configuration
# posted by Teamwork's Blog @ Friday, October 12, 2007 
