In Open Lab we’ve been developing Teamwork and consulting on project and work management software since 2003.
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
One thought on “Stories of work management”
Comments are closed.