Archive for the ‘work management’ Category
How do I begin project management?
Filed under: project management, work management | Tags: project management, work management
Leave a Comment 
In “Making things happen”, the author (Scott Berkun) states that he assumes that the reader is not stupid, is curious and pragmatic, does not like jargon or big theories, and does not take herself, software, or management too seriously. Well, we do the same in Teamwork.
Still, you may have no or little experience in managing team work. Whatever work you will be doing, you may have some requirements, and some dates. if your company has no notion of project / task / issues, you can start this way: list all the things you are doing in your organization. You could separate internal work / external work. In the list obtained, group dependant activities: each group can be called a project, and the people that should work on it are the assignees.
You may notice that when you are listing “thing that we are doing”, you may also include “things we should be doing”. Notice which of these are stated in the form of concrete actions, like “call X”, or “write Y”, and which are still to be transformed in actions. You should try to transform everything into actions, and get rid of the rest. And still among actions there are simple, brief ones, and others that group many others: you could model the simple ones as issues, and the ones comprising others as tasks (that is, projects which are child of other projects). This is a start of management.
Often we get asked by people evaluating Teamwork:
How do companies really use Teamwork?
In the new user guide you will now find several examples. Here are also some good books where to start learning about personal and project management.
Some reference books:
This book by Berkun is our main reference:
Making Things Happen
Mastering Project Management
By Scott Berkun, publisher O’Reilly Media, 2008
http://oreilly.com/catalog/9780596517717
From a personal productivity perspective:
Getting things done
By David Allen
On the Agile/Scrum theme:
Agile Project Management with Scrum
By Ken Schwaber
http://www.amazon.com/Agile-Project-Management-Microsoft-Professional/dp/073561993X
Teamwork 4.5 released: a major free upgrade
Filed under: issue tracking, news, project management, releases, usability, work management | Tags: kanban tool, teamwork issues, Teamwork 4.5
Comments (1) We are really happy to announce this major release update. As you may guess from the length of this announcement, this update will improve your Teamwork in almost every section, providing more modeling tools and functions. The web browsers’ enhanced capacities (in particular those of Firefox, Safari and Chrome) are used in depth to give users a better experience.
This is a free upgrade for all users of version 4. Get the installer / upgrader here: http://www.twproject.com/download.page
The main features of this release are:
- Issue managing by dragging – “kanban” like.
- History of issue assignee, status and task change (better help desk and issue scaling support).
- Customizable issue statuses.
- Better graph and agile / scrum handling.
- Cross links between tasks / issues / resources / agenda events / meetings / boards.
- In-place popup editors.
- Operator load computation has become much smarter.
- Greatly extended user guide with real case work “mappings” to Teamwork, and a new section on performance optimization.
Layout changes
Several pages that up to now were popup windows are now windows in place, which improves their usability: issue editor, custom forms, workgroup selector.
Several text areas now support internal links (e.g. T#MYCODE#), web links (http://www.twproject.com), smiley’s, absolute URLs to images.
New features
Issues.
Issue statuses – customizable. New issues statuses can be created. There is a page for managing issue statuses (which before version 4.5 were fixed):
And for every status not only its color, but most importantly its business logic behavior is determined from this editor:
Whether it should “behave” when asking user feedback as an open status, as close, whether it should ask for comments and / worklog when entering a status.
So typically if your status is something in which the issue enters at “end of life”, it should be marked “as close” and “ask for worklog” too should be enabled.
Issue change history. When changing a status, task or assignee on an issue, the editor will ask for a reason, and the change will be recorded on the issue. And in fact there is an additional tab on the issue editor, “history”.
Issue organizer “Kanban”. Issues can be now be organized in a completely visual way by dragging and dropping them: filter the issues in which you are interested in, and then select the “organizer” button.
Now you can also enable use of external codes on issues (admin -> default for projects).
Dashboards.
The usability of the “customize this page” function has been improved: all portlets are always visible:
And it’s easier to drag them in the dashboard. Moreover it is easier to access the general page / portlet disposition page: just click “all users”. 
There is a new additional starting page: help desk support.
Operator load and planning. This was the user request:
“refine the operator load showing the effective load taking in consideration worklog done. E.g: 100h estimated on 20 days, done 10h in 10 days the resting 10 day must have a load of 90h not 50h like now”
Also take care of unavailability.
Use the new operator load on plan, load by day, end wherever it is meaningful
Operator load textual: put worklog with totals and pink holydays. Use striped background
Advanced users
- The examples in the distribution and the documentation now cover also “custom wizards”: see section 14.4 Custom wizards of the user guide.
Minor improvements
- More kinds of documents are now full-text indexed; these are the extensions now supported:
“.txt”, “.rtf”, ”.log” “.pdf”. “.htm”, “.html”, “.zip”, “.war”, “.jar”, “.xls”, “.xlsx”, “.xltx”, “.xlsEmb”, “.doc”, “.docx”, “.dotx”, “.docEmb”, “.ppt”, “.pptx”, “mpp”, “mpx”, “.msg”, “.msgEmb”, “.vsd”, “.pub”.
Also custom fields are full-text indexed.
Here are several user requests fulfilled:
- “Add worklog approval monthly screen” -> We will add bulk status change in worklog search / analysis (http://feedback.twproject.com/forums/6995-suggest-features/suggestions/305194-add-worklog-approval-monthly-screen?ref=title).
- Expose issue id in editor and list (http://feedback.twproject.com/forums/6995-suggest-features/suggestions/257395-expose-an-issue-id).
- LDAP authentication cascades to system one (http://feedback.twproject.com/forums/6995-suggest-features/suggestions/265843-login-with-ldap-for-external-users).
- Develop a resource snapshot (http://feedback.twproject.com/forums/6995-suggest-features/suggestions/348397-develop-a-resource-snapshot).
- Sort File Storage Document Listing (http://feedback.twproject.com/forums/6995-suggest-features/suggestions/369822-sort-file-storage-document-listing).
- Make “add document content” in a rich text editor (http://feedback.twproject.com/forums/6995-suggest-features/suggestions/239855-make-add-document-content-in-a-rich-text-editor).
- Please put a link to a task on the agenda event (http://feedback.twproject.com/forums/6995-suggest-features/suggestions/223380-please-put-a-link-to-a-task-on-the-agenda-event): we actually did much more by having full internal links.
- Need to add subscription event for when a new version of a document is uploaded (http://feedback.twproject.com/forums/6995-suggest-features/suggestions/624803-need-to-add-subscription-event-for-when-a-new-vers).
- Display agenda items in planByResource like in worklogWeek (http://feedback.twproject.com/forums/6995-suggest-features/suggestions/142356-display-agenda-items-in-planbyresource-like-in-wor).
- Search for specific custom fields.
- You can have a customized help message in the “help” page, just add in the labels CUSTOMIZED_HELP_CONTACT (http://feedback.twproject.com/forums/6995-suggest-features/suggestions/599247-add-a-customizable-area-on-the-help-page-so-local-)
- Notes on issues are on the main tab and self-resize.
- Issue assignee selector got simplified.
- Now you can create subtasks as sub-fluxes.
- Counters can now be reset and deleted.
- When changing a task on an issue, notify the new assignees.
- Since version 4.5 custom fields support also “typing” of data. E.g. “cost,20,java.lang.Double” will add a custom field of length 20 and type “double” (a floating point number).
- Holiday settings: now you have year-specific settings.
- In issue list you can now filter by task type.
- Resource print includes my assignments.
Bug fixes
- Check why in the assignment notification we add a link to the task even if the resource has not the rights to read task … .
- Meetings are not full-indexed.
- Index custom forms data.
- Create issue from task editor menu does not launch creation nor filters???
- Issue multi edit: bulk change gravity do not close actions clicking “close”.
- Fixed MIME for teamworkMenuPlusCss.jsp,
- Issue cloning did not raise events,
- Fixed various combo positions in bulk update screens in case of scroll.
- Summa is not saved on document link and file storage on tasks and resources.
- A fix for Oracle on Resources with no surname.
- An operator may change his own password even if cookies are enabled.
- Do not notify disabled users.
Technical points
- In order to optimize memory usage,
If you log as administrator and go to the label management section, open the “label rules” container (it is closed by default), and say if you want to have only English as language, type EN in the enabled languages field and select SAVE.
- Teamwork 4.5 is no more on quirks mode – we dropped support for Internet Explorer 6 – and pages are in HTML 5
Important for upgrades. Several JARS have been updated, added and removed. If they are present these JARs should be deleted by hand from WEB-INF/lib:
o commons-collections-2.1.1.jar
o commons-logging-1.0.4.jar
o poi-3.0.1-FINAL-20070705.jar
o jcaptcha-all-1.0-RC3.jar
- Added -server configuration to the Java JVM distributed.
- If using HsqlDB you can make a dump of the current log by hand from system check instead of having to wait Teamwork restart:
Notes for updating to 4.5:
Any custom filter on issues will need to be redone as the issue statuses are a lookup field.
Unfortunately all document list attached to discussion points of meetings will be reset.
P.S. We’re building the beta of a new online service – called Licorize – a cocktail of Delicious bookmarking and light to-do management. If you’d like to beta-test it, just send an e-mail to info@twproject.com with “Licorize” in the subject or body – we will soon give you access and also a year of free usage to your entire group.
Stories of work management
Filed under: IT integration, project management, usage, use cases, work management | Tags: management stories
Comments (1) 
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
A critical moment: choosing or changing a project management tool
Filed under: project management, work management | Tags: reselling Teamwork
Comments (2) Healthy companies, groups which are self-critical tend to periodically reorganize themselves. It is an opportunity to improve both productivity and quality of work. In these moments, software surveys are done to select new software for project and more in general work management. It is in these phases that sometimes Teamwork is chosen. In the choice what most matters is how the software can “unobtrusively” map to the new organizational practices, and Teamwork in this can be great, because of its flexibility, scope, and the wide fit to the IT infrastructure. All this is explained in detail in the user guide.
Now it frequently happens that some software houses (which are about 8% of the companies that use Teamwork) like Teamwork so much that they consider distributing Teamwork themselves to customers, and contact us for that; we always say “fine”, but none has been very successful, and this is quite easily explained: if you have say 20 companies to which you provide software services, what is the chance that that very company will want to buy Teamwork?
About 2% of the companies that visit Teamwork site get to try it; and about 2% of those that try it get to buy it. And consider that all those companies are already in the critical situation of choosing a PM tool. So calling a company at random, what are the chances that they will be searching right then a PM tool? Slim, very slim. And the chances that Teamwork will fit them? 2% of 2%. So how many companies will you have to contact in order to have a good chance of making one sale? Many. Too many.
All this because in this scenario we are not using the power if internet of being found, instead of contacting known ones. If someone wants to offer software like Teamwork to customers, the best idea is to get a good presence on the web, maybe in a localized / specialized part, so that companies in search of PM solutions can get competent help. Just my two cents.
Teamwork’s philosophy: a short story
Filed under: project management, work management | Tags: teamwork software
Comments (1) 
There were once two brothers and a sister, and they were managers at three companies.
The first brother was called Micro Manager, and he picked the most complex and integrated management tools, which were entrenched in the technical staff IDEs and into all their network activity, so that not a single line of code could be written without it being carefully logged. Not an hour could pass without justifying time spent; not a file could be opened without explaining why. Not a project could be created without designing a 100 leafed Gantt. And after a week everybody hated the system, and then they hated Micro Manager, and everybody was unhappy.
The second brother was called Over Simplify, and he didn’t want any kind of management apart from to-do lists. And everybody just had to-do lists, and for the first week everybody was happy. Then many started having long to-do lists, and some started worshipping them, and instead of working, they were compiling longer and longer personal to-do list. And every list was different from any other, and nobody knew what, when, how, and why, and everything was in a mess. And then they hated Over Simplify, and everybody was unhappy.
Their sister was called Reasonable Modesty, and she had minimal goals, had always clear that what matters is how people work and interact, and that software is always secondary, and should be flexible, not do too much, and not get in the way. She started evaluating Teamwork.
Doing better than the usual project management software?
Filed under: IT integration, project management, usability, work management | Tags: personal productivity software
Comments (3) 
How can we improve Teamwork, and more in general, how can we help people and teams manage their work better and better?
Teamwork today is a stable, well known and widely used application – its sales getting better every month. We are always improving it and searching for new ways to make it better. The feedback given by users through the feedback service and the answers Q&A gives us a lot of ideas.
But people’s way of work change evolve all the time. With software we should try to foresee changes, and in the case of structuring work, be compatible with new ways of working. Now, project and work management is a field where there is a lot of competing software, and new solutions are created quite often. So in the last weeks I checked competitors for new ideas and evolution that would cover the recent trends in ways of working, like for example having the browser as the “operating system” where more and more applications operate, and so in many organizations a considerable amount of activity is on applications in the browser. Yes, of course Teamwork is web based, but one can do much more than that today. New ways of working need new ideas, sometimes radically new ones. Is anyone proposing different models, or reacting to new working ways?
Well, to my surprise, no. The same mistakes are simply repeated, again and again, like trying to “trap” user communication flows and other user usages in the project / work management software; development is done under wrong beliefs like “using e-mail is wrong, and users should be ‘educated’ to centralized communication systems”. Such tasks are destined to fail: it is simply assumed that users will happily and daily spend a considerable and growing amount of time on your specialized project / work management application because of their stakanovistic dedication to organization, which is the opposite of what is happening: people use more and more different, specialized applications for their tasks, and dislike and refuse single, centralized “monster apps” which attempt to replace all others.
In my review of “solutions” I’ve even seen a specific content manager connected to a popular issue tracking system that offers users a blogging platform. Now, how likely is that? How happy will employees be of being forced to blog in that corner of the bizarre issue tracking software instead of using their preferred blogging platform? This kind of ideas just don’t make sense: you have to improve work management without directly impacting software usage, and without trying to replace high quality specialized solutions with centralized (low quality) ones.
We have learned a minimalistic, relational approach and deposited it in Teamwork years ago. Now what about going beyond that? Well, no concept evolution is happening in direct competitors.
So in my search, I ended looking at personal productivity software, after seeing this nice presentation by Scott Hanselman, and there indeed there are some original ideas; consider for example Evernote ©.
The high level of interactivity, openness to devices and compatibility with user habits of this application is striking. The aim of Evernote seems not as much managing work, as simply collecting notes for personal usage. But there is a lot of stuff to look and learn. And many users will start work management from a personal perspective, and then will try to propose it as a shared approach: I believe this is a path that currently lacks appropriate tool support. There is a divide between project / work management tools and personal productivity ones that should not be there. On one side project / work management tools still pursue the centralized application option, on the other the sharing features of personal productivity tools are weak.
So we decided to open an experimental platform where to try and test different approaches to managing work, in particular starting from the personal / to-do point of view. In the meantime, Teamwork will keep evolving and improving, eventually getting new features and improvements from this experimental platform. We will blog about our experiments here in the coming months. If you any suggestion to make, post it on the feedback service: thanks!
P.S. Teamwork release 4.4 should be out in a couple of weeks (a free upgrade to all users of version 4), and will introduce the notion of “public” project – keep in touch.
Open Lab and Teamwork are not associated with Evernote in any form.
Teamwork webinars
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:
“Adding a wiki” to Teamwork
The meaning of “adding a Wiki”
The most voted request on our feedback service is “Integrate a wiki in the dashboards”:
I think that what actually users mean is “integrate Wiki functionalities in Teamwork”, but this is one of the requests that can be interpreted in several different ways: it probably implies a feature set, and some of such features make sense for the Teamwork context, and some may not.
Some example features:
- Let any user have a portlet on her home page that is actually the home of a company Wiki
- Let people edit any Teamwork page layout of in a Wiki way
- Have for any object a history of changes on that object
- Use Wiki syntax for any content
- Pages are created by just creating links to them
A different, more radical interpretation could be “change completely the management philosophy and let there be no user rights and pages and contents be just contributed by users”. In fact there are even applications for issue management that actually are just a wiki. Well now, I think that it may be useful to try to clarify what is the usefulness of work management software. It must be something that makes you work better; it’s quick to insert the essential work data, and that done, it does a lot of work for you. Inserting work data in a Wiki just doesn’t give any specific support. A Wiki is meant as a tool to manage a documentation body contributed by several people; that is just not what work management is about; and using the wrong software for the just, will just increase confusion in your company, make people frustrated and make them waste more time. Wrong software, sorry.
Implementing a Wiki engine
This does not mean that the Wiki’s logic can’t inspire some really good ideas that can be included in any kind of software. This is the perspective that we’ve taken on the “Wiki integration” subject, and there are many subtle problems involved, like:
- If you want to write contents with links to objects, it would be nice to have a RESTful API in Teamwork in order to write links simply
- Should we use the TinyMCE editing which we started using in some places (and users are pushing for more), or switch to Wiki syntax in contents?
- Up to today documents are typically linked in Teamwork, but contents lives outside (and this is generally a wise choice), but with this extension it should become really nice to write contents in Teamwork for specific projects
Given the deep integration of the Wiki features and Teamwork’s, we are building our own Wiki engine; its persistence is Hibernate based, and there is none available that does that, so this may become of general interest.
One of the considerations that convinced us to write it from scratch is that several Wiki applications functionalities are already available in Teamwork, often more refined than those built in Wikis. Like full text search, subscriptions and e-mail integrations and recent pages.
If you’d like to suggest some particular feature of the Wiki integration, you can post it on the feedback service (yes, we do check it out).
Simplistic cost/benefit evaluations of organizational tools adoption
Filed under: project management, work management | Tags: benefits of project management
Comments (1) 
Cost/benefit analysis of PM software adoption
I’ve recently received yet another request of a cost-benefit analysis given by the adoption of Teamwork, in general, of project and groupware management software. Not always in those exact terms, but we do periodically receive such requests. One may rephrase the question as “what is the exact economical gain given by adopting Teamwork”?
Very superficially, this looks like a clear question, which requires an exact answer. Let’s take a closer look.
What does it mean “adopting Teamwork”? If one takes even a cursory look at Teamwork user guide, one should quickly realize that for a tool that can integrate at so many different levels with IT infrastructure, this may mean all sorts of different things: one may be handling just high level projects, sharing them on the web, or one may have integrated it from intranet authentication and certification forms, following every little action in the company.
One may be using the exchange function with Subversion, Google calendars and Twitter, so even the boundaries between what is done in the company by Teamwork and what is done by other applications is blurred. So “adopting Teamwork” has different meanings for each adoption process.
But there is an even bigger conceptual mistake that is lingering here, given by the first part of the question, “exact economical gain”: i.e. that taking steps in improving quality of work, by implementing software aided organizational procedures, is a purely economical gain that can be accounted for say is a year after the reorganization. Anybody that has experience in reorganization and working on quality of work and communication knows that consequences cannot be evaluated so simplistically, though they can be great, and span an entire work life.
This said, the benefit that one will have basically depends on the plan and determination of the leader that is introducing innovation, by her/his culture, open mindedness and experience in the field and in human relationship, and the respect that she gets from the team; and we believe that in some cases (not all), Teamwork can be of help for such individuals, more structured help than just a to-do list shared online. But don’t ask us to fool you with numbers thrown at random; you should probably be very suspicious of vendors that promise X% “gains in efficiency” by doing this or that. Our customer list is partly public, the best way is to ask them, and everybody will give a different answer. Just my two cents.
Pietro Polsinelli
How (not) to evaluate project management software
Filed under: project management, usability, work management | Tags: evaluating project management software
Comments (5) 
Evaluating Project Management software is a delicate matter, as it potentially involves changing deeply rooted companies’ habits; in general, this holds for all work management software. Being the subjects of such scrutiny, we experience that most companies fortunately take the right way right from the start, which is, trying the software, inserting in it some real project and people data, and seeing whether it works. In the case of Teamwork, this can be done quickly, and there is both a demo online and an easily installable version, and considerable support readily available online to all.
But unfortunately not all companies take this “hands on” approach: some take the path of putting together list of requirements, and instead of testing the software against those, ask the software producers “whether their software meets these requirements”.
Now imagine that this was the way you chose to buy a house: you went to the seller, with a list of features, and you never go to actually see the house. You buy it because the seller tells you that the house fills your requirements. Nobody would do anything so foolish, no?
Putting together requirements and testing the software against them is actually a good idea, if handled properly: testing will at times show that the requirements are contradictory, or need refinement, and that the software models problems actually better than how imagined in the requirements. This is not surprising, as widely used software includes a lot of experience in management, often more than the users have. So the initial requirements should be only a first indication, and not something that is the main criteria for the final choice, which should be led by the usability and coverage or real problems offered by the software at hand.
Unfortunately there are producers of PM software and consultants that encourage users along the foolish path: they give formal answers to formal requirements, do demos themselves instead of letting the customers do that, make phone calls to facilitate over-priced sales, and all the usual bad practices.
Well, we don’t do that. We concentrate all our energies in developing a better product, and in producing publicly accessible documentation; we want customers to have software that really works and is usable, not just to close formal deals.
One can make software that satisfies long lists of requirements, but is totally unusable, will be hated by users, and will lead to user rejection, and hence to a huge waste of company’s money and people time. We really hope never to take that path.
Silvia Chelazzi - Pietro Polsinelli
