Every time we got in a company with our software, we had planned to show how the software worked, how to optimize its configuration, how to integrate it with existing software. But we actually did so in the last moment of our visit, if ever.

But when we got in we always ended up in meetings after meetings where the topic was not specifics of Teamwork, but questions of work management, and how to best “map and structure” these, so that project trees, sets of issues, workflows and so on could be used in a coherent matter.

And we’ve learned a lot about which mappings work, and which not.

This need for conceptual mappings is teaching something, that is, where is the real value for the customers, what users need.

We progressively realized that the value of software like Teamwork can be simply in the introduction of more structuring, more quality in work. This can be much more than actually using the software – taking it to the extreme, one could simply read this guide, reform practices in the company and forget about the software

And more people and companies we met, more we appreciated the way we had structured Teamwork from the very beginning to be very, very flexible. A group of fashion designers, a company doing production, a team of software developers, an IT group, hardware engineers, event organizers, all these have different needs. And these groups may be in the same company, and different models need to co-exist.

Meeting diverse needs made Teamwork evolve so that it is an even more powerful mapping tool. Though it is extended, it still is an organically integrated tool.

Modeling company needs for organizing work always implies going beyond the scope of a single application: Teamwork is always used in an applicative context, and so its openness to external integrations is something that in our concrete experience has made a successful adoption possible.

In the user guide for version 4.5 you find also some of our experiences of “map and structure”, some gained by “boot camps” in companies, some by giving web support. You also find the definitions of some concepts related to work management that are not directly linked to software usage.

Some say that all companies need is a to-do list; this is for us just a symptom of scarce experience in what people do at work, of how complex are the needs of a productive company. We hope that the new guide can be of help in understanding which map best fits your organization.

Some of the stories titles:

How do I begin project management?
Managing with lists vs. managing with trees
Overcoming opposition
A critical moment: change
Migrations
Public projects
A design & production company
To Gantt or not to Gantt
Social tools for work management
iPhones for all
A distributed research group
Agile methods
Working by “pomodoros”
Kanban like management
Simplistic cost/benefit evaluations of organizational tools adoption
Worklog validation
Deep IT integration
Work management and games
How Teamwork is made with Teamwork
Teamwork and multilinguism
Business processes
Help desks
Company structure
Different Teamworks, same data bucket
Teamwork and your company’s worth

Teamwork webinars now available

We have just activated the possibility of delivering webinars to customers to remotely supply instruction from our instructors. This is at a fraction of the cost of a bootcamp, and may be all you need. Details can be found here:

http://www.twproject.com/webinar.page

The worklog day on my dashboard nicely filled.

Yesterday I was about to go home and before leaving on my Teamwork dashboard I noticed that my worklog was already all there without me having to insert it: I just opened and closed issues all day (one click for any of these) and.. the log was all already there!

I don’t love recording work logs, actually, I hate it and often just don’t do it; but since issues are just so easy to add/close, and they really help me “get things done”, I’m now getting work log recorded for free: nice!

In other words, with the effort of a to-do list I’m filling the requirements of a project-management app. What made a difference is that the in-line multi edit of issues is so fast to operate, and so easily linked to my different tasks, that it is my sole entry point in Teamwork, where I insert all my work. It was also important that even if issues come from different tasks, as long as I am focused on myself I can sort them, and give my chaotic day an order, with very very little effort. In this, Teamwork version 4 really solved the problem.

Teamwork 4 has won the long-standing war with paper. We have to confess that for some short-lived issues, some of us (including me) were still using post-its and notes on paper as an integration of issues. But Teamwork 4 won: the Ajax issue multi-editor is just too practical. There is no more paper on our desks; add Balsamiq mockups for replacing paper interface drafts, and the coverage is complete.

We cross post issues and bugs, which we get notified thanks to the subscription engine.

Teamwork worklogs are inserted with help from Twitter and Subversion logs, which Teamwork 4 does natively.

A section which is widely used is the agenda integrated with meetings, which as it synchronizes with our e-mail clients, is quite practical.

We use boards too, for example to collect notes for our technical meetings. Careful collection of worklogs allows to monitor costs, and also comparison between releases, cost per team etc. .

For authentication, our Teamwork is integrated with our Active Directory. As we are  “advanced users” , we have added to the scheduled jobs a “SiteAliveTester” job which tests that our servers are up and sends e-mail alerts.

We have added some parts to the defaults, such as RSS reader, user voice reader.

Of course we also use news, for example to publish scores of our table-tennis tournament!

Teamwork 4 interface in German

Teamwork’s translation in German is almost ready, thanks to Koelnticket, in particular Andreas Nebinger (thank you Andreas!). Let’s see a bit in detail how we dealt in general with internationalization issues in Teamwork; actually this set of problems will have to be met by any sufficiently powerful web application.

There are many senses in which an application might be said to “support multi-languages”, or be “internationalized”:

Interface. Labels and messages of the web interface are available in several languages. Teamwork contains a label editor, where you can create a new language and also modify existing labels.  Teamwork is used in 43 countries, almost all using it in English; actually some project managers like to have it English as teams are made from people from different countries, so it encourages communication.

But as usual Teamwork does more: it lets you change labels on the fly in the web interface, saving them on the database so that you don’t lose customizations on application update.

Data. Data inserted in the application can be inserted in any language. We have been careful about the encoding (always a problem in web applications), so that the full spectrum of UTF-8 supported languages is included, which means also Greek, Cyrillic, Arabic, Japanese… . This also assumes that the database on which Teamwork is running supports Unicode or UTF-8 data. THen you have the further problem that labels and data you have on the interface may need to be channeled on a different mean, e.g. exported in an Excel file, or in a PDF, and there again you may be plagued by encoding problems.

Search. (This is often forgotten) Full-text search requires multi-language stemming of contents: this is from our technical contribution, which is in the context of Hibernate (an object/relational tool) and Lucene (an indexing engine):

You need to know the language in which a document is written, in order to correctly index it; once you know the language, you can instantiate say the Snowball analyzer with the correct language stemmer. To make a practical system, you will need to guess the documents language from its content. We have found a very simple and effective solution [...].
In order to make a content “findable” also when searching from a language (say, German) a document in another language (say, English), we actually double indexed the content field, once with the nowball analyzer and once with the simple StopAnalyzer; so that if you are searching from German and you search “Telefunken”, which stemmed would be searched as “Telefunk”, will find also “Telefunken” in English documents ? .

See http://twproject.blogspot.com/2007/11/using-hibernate-search-with-complex.html and http://www.hibernate.org/432.html

So Teamwork’s full text search is language-aware. Actually search in Teamwork is much smarter than that, but this is a topic for another post.

Documentation. Documentation may be provided in several languages. In Teamwork’s case, as it is by now in 99% of the web applications, it is provided only in English. We also believe that it will be the “power user” of the application that will mostly need documentation, and we assume that she/he can read English.

So how can we evaluate Teamwork w.r.t. all these aspects?

A F.A.Q. on Teamwork’s site talks about changing labels: http://www.twproject.com/configurationFaq.page#conf5