Today we deployed Teamwork as a war on JBoss 4.4.2, and it works fine; only take care about the Hibernate release, as it should be compatible (for Teamwork 3.2.1, its Hibernate 3.2.4 with Annotations 3.3.0 and Search 3.0). Given our minimal requirements, it's no surprise that it runs fine, but its good to be sure.

Labels: Teamwork JBoss

Spaghetti Project Management
Thanks to several examples provided by our customers (for debugging purposes, or because of mehodological questions), I've started to acquire a certain experience in how Microsoft Project is really used, and what one should do when moving to web based project management.

Some users were setting in Microsoft Project everything as a task: micro management issues, meetings in the agenda, points to discuss; this seems practical, as everything is in one file, as long as one does not have to share such information.
This habit brings about also other problems: it shows an unrealistic assumption about work, as every little detail, like a quick meeting, has to be planned in advance, and by a single person; but this is not how work (and life) goes.
Such unreadable and excessively detailed plan is bound to be at best ignored by the rest of the team, if explicit refusal is impossible due to authority.
So, users search for more "acceptable" solutions, and start by... importing the original project tree! So the initial situation is even worse, because a web based application can't compete with a client in managing complex trees.

Agile, practical management
The way to agile, practical management is to have simple trees and few assignments; you have to distribute the original tree information in the appropriate, confortable places you find in Teamwork, which does a lot of work to help you. Getting users to insert their worklog is always a hard-won victory, and a great result for the company, which will gain more and more value in time . We on the software side are working really hard to release ever lmore friendly software, without loosing power available to project managers and the system integrators. I recently realized that the simplest "worklog" software of all is Twitter; the only problem is.. that it does nothing.

Pietro Polsinelli

Labels: microsoft project web based management

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.

Labels: teamwork installation configuration