Archive for the ‘project management’ Category
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 release 4.3 available for download
Filed under: IT integration, issue tracking, news, project management, releases, time recording, work logging, usability | Tags: multi Gantt
Leave a Comment 
Teamwork 4.3 multi-Gantt view.
A free upgrade release for all users of version 4.0-4.2, this release includes some major extensions of functionality; while there is no “revolution”, this kind of release makes your “Teamwork life” more comfortable. Several features requests from the feedback service have been fulfilled. Also the user guide has been updated.
Download this release here.
Multi-Gantt support
This was motivated by this request: “Manage graphical Gantt-type overview of all projects”. We then realized that all it needed was the filtering power of projects search together with a Gantt style visualization. So this is what we’ve done: we added an additioanl visualization of the search results. So for example you can see all your root open project closing in 2 weeks in a Gantt style view.
Also all the Gantt scales have been extended to 5 years.
Import from CSV – Bugzilla
Import of issues and resources from CSV files: issues get imported from the Bugzilla CSV export format, but of course in this way you can import from anything.
Collapsible project trees
Projects trees can be collapsed and there are options to keep them open by default etc. . This was this request; thanks to Halil for the first implementation.
More Twitter integrations
Twitter integration with any action and there is a new portlet for filtering tweets on any topic: see the user guide, section 8.3.3.
Little improvements
- All notifications have in the subject the task they refer to, if it exists (this request).
- Display log on descendants (this request).
- Balloons have no more the confusing Roman number.
- Use darker gray on Gantt duration background – better prints.
- Search analysis worklog: make the field “action” larger.
- In resource list there is no more the bothering default filter by company.
- Snapshot of a task can be edited.
- Search analysis worklog: make the column “action” larger.
- Issue multi editor: if there is a task on the issue and you have an assignment on it, let the watch icon appear even if the issue is not assigned to you.
- Experimental: supporting SSL over LDAP (LDAPS)
Bug fixes
- Issues didn’t get indexed any more for full text search.
- Order in company news doesn’t work.
- Portlet news doesn’t show news ordered by order factor.
- Resource hourly cost sometimes gets set to zero.
- Meeting: drag&drop multi editor doesn’t work for the just inserted.
- The link to resource drawn by the smart combo if the resource is from another area on which you have no right you see the link but you get an error.
- Search of a string containing ” in issues looped the application.
- Sometimes the rollover menu opened in the wrong direction.
- If you change the allowed file storage roots, disable links to old locations.
Technical notes for upgrade
This release build is 11250; it contains no database schema changes for all users of 4.2.10080 and following. As it contains an issue full-text indexing fix, you should reindex your data: see 17.4 of the user guide.
| try darker gray on gantt duration background |
New multi Gantt support
Filed under: IT integration, project management | Tags: multi gantt view
Comments (1) Forthcoming Teamwork 4.3 release will support a way of “managing a graphical Gantt-type overview of all projects“, actually, more than this: simply any filter on the project list can be seen in a Gantt-like way, and also printed. The need for this new implementation was suggested on our feedback service and got many votes from our users.
Until now the powerful search filter, which lets you compose complex search criteria, gives as result a simple list of tasks. From 4.3 Teamwork will layout the results also in Gantt graphical style. In the picture below you see an example of it.
Gantt view for Teamwork task's list
In the example above I’ve searched all the active tasks opened after the first of June and with a progress over 50%. Simply picking the “view as Gantt” button I’ve changed the view modality in order to compare the filtered tasks in time.
This cross-project comparison in a unified view is practically impossible (in Microsoft Projects, insert as subprojects etc.) in file-based project management, it is easily accessible in Teamwork instead.
The result of the search will be shown in temporal interval which goes from the minimum start date to the maximum end date, in order to cover all the tasks filtered and to get a global timeline view. Also progress andmilestones are shown. Moreover this page includes the possibility to move in time and to change scale.
So we keep implementing requests from our feedback service: thanks for the ideas, keep voting there!
What you get with Teamwork and what you don’t
Some project management applications provide minimal functionality: just a Gantt drawer. Some, more groupware oriented, provide a vast spectrum, including e-mail and chatting. While developing Teamwork, we made several choices about what to include and what not. The choice for Teamwork has been guided by this simple princliple: include only what will not sharply conflict with acquired user habits, and will have a rich integration with the rest of the system.
Examples of what we did include:
- “boards”
- sticky notes
- to-dos
- a calendar
All these have a natural integration with project management, bringing together personal and team management. So we put them together in a unique, integrated solution; you don’t have to get three separated products from us to get this functionality.
Examples of what we didn’t include:
- e-mail client
- chat services
- file management
The three integrations above are probably used by most in standard ways, and happily too: you are not going to change those user habits with the new project management software; so the work we have and are doing is to integrate with the existing applications, as smoothly as possible.
Notice also that probably most users already have a calendar application, and others that may overlap with what we provided built-in, and for that we are working so hard in extending seamless integrability (most previous posts talk about this in fact).
Current and future developments
Wikipedia logo
This is for the actual situation; but usage of the web is evolving all the time, and more integrations are now needed: in Teamwork we always assumed that the contents and documents related to projects and work which would not be articulated in tasks, issues and to-dos would be handled by other document management software, and then somehow connected to projects (say for example with file storages). But with wiki and blogs, content is more and more inserted directly online, and we should support this also inside Teamwork. One can currently do this by simply creating custom portlets connected to a Wiki service. But as with most of our solutions, we would like something organically integrated with the rest of Teamwork functionality; for example, content editing would naturally blend with exposure of Teamwork objects to REST and similar services, and in-place customizations of pages. So this is one of the (non trivial) directions we are now exploring.
If there is an organic integration that we are missing, just post it on our feedback service!
The quoted products, services and images may be registered trademarks of their producers. Images that require attribution are linked to their source.
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
Oh no, not another Scrum tool!
Filed under: project management, work management | Tags: Scrum software, Scrum tool
Comments (3) 
- Image from Flickr – attributed following link.
When we came back to Teamwork version 4 after reviewing some literature on agile methods, and in particular re-considering the Scrum perspective, it became progressively clearer that mapping Scrum ideas to this or that functionality of a software is inevitably a simplification and maybe even a betrayal of the agile philosophy: as these methodologies concern the way you approach problems, and have great variations in detail when it comes to each particular case; see
Agile Project Management with Scrum by Ken Schwaber, Microsoft Press
which is filled of examples.
From this perspective, the main point is not and should not be the management software you are using. We’ll get back to this in the final considerations.
We’re assuming here familiarity with concepts from agile methodologies and Scrum. Also the examples are tuned to software development, but the line, if valid, is valid in general.
Mapping examples
If one does decide to use a management software to manage agile procedures, one should be careful not to take simplistic decisions.
Consider for example backlog: collecting a backlog is the most basic step; how do you collect the backlog? It may be say a shared Google document; so from the PM software point of view, your backlog is a non structured document that the software does not manage. It may be a set of separate entities, say issues? It may be made of tasks with detailed descriptions and work estimations; and so on.
In many examples of teaching Scrum we see cards sticking on boards, and some software just use that idea for the user interface. People seem simply to be missing the fact that a development project may simply have like 800 “cards”. How the heck am I gonna stick those on a board??? It can’t work. You need something more flexible and powerful than a concrete or digital board.
Stand-up meetings: why is backlogging the subject of management-by-software and meetings aren’t? This is a typical and mistaken hacker’s perspective, because some people focus their management more on their agenda than on their to-do list, if they have such a thing. And you will have projects with both kinds of people (and many more).
Why recording the activity on the assigned tasks has to be done by scaling down hours on the selected items of the backlog? Wouldn’t it be more practical if say one could record activity in the Subversion commits? Or in your Twitter feed? Here too, you need an open ended tool, which collects data from many sources in different ways.
An example: let’s see a sample project and assignment structure: suppose you have a customer, a lead developer, and a set of developers, D1, D2, D3; you want to collect the backlog, and basically your main aim is to let the developers work in quiet conditions and with a stable set of requirements for a month. Well to model that in Teamwork is no big deal, you can support this procedure in several ways; for example you may have a root project ROOT, on which everybody is assigned as “reader”, and lead developer as project manager; you have a child BACKLOG, where the customer is assigned as “worker”, so she can contribute inserting backlog; the backlog is inserted as issues on this BACKLOG task.
You then create a new ROOT’ child task called FIRST SPRINT, move the subset of issues which constitute its effort to it, and assign D1, D2 and D3 as “workers”, so they can edit and close the issues, but nobody externally will change the set of issues. That’s it.
On this structure, Teamwork gives you many, many, many tools to go on, work comfortably, connect this project with others differently structured; it may even be a child of a completely different structured project. You may structure the BACKLOG task itself as a tree; you may have several sprints going in parallel; you may have after the spring a workflow of approval, and again here Teamwork supports you with task as processes. More examples could be made.
Final considerations
A most important consideration is that particular methodologies, say Scrum, help solving some class of problems, but will never cover the totality of the working activity of a company, not even the totality of projects of a company. Actually, the original Scrum texts are written in full consciousness of this limitation.
So it would be extremely non-agile to have specific software to follow the “agile” projects, and another one for the “others”. And even the “agile” projects will have so many variations, that they will fit in the agile metaphors at different levels, and hardly fit in a single “Scrum software model”.
So in the end we realized that the mapping between the methodology and the software (or paper) requires great flexibility; agility is in the methodology, not in the software. If you want to use a software, it should be flexible enough to let you map projects, tasks, issues to people and customers, in infinitely many different ways, but so that all data from the different projects and methodologies ends up in the same place.
So no, Teamwork is not yet another Scrum tool, it is a management tool that can help also those that decided to use Scrum for some projects, if they don’t prefer to use paper cards 
Managing with lists vs. managing with trees
Filed under: project management, work management | Tags: basecamp, list management, tree management
Comments (3) 
The field of “software aided project management”, which should by now more aptly named “web based work management” today can be divided by two basically different approaches to management: list based, and tree based. There are also other approaches, like “let’s just use a blog/a wiki”, or “e-mail is the way to go”, but I believe these to be simply a bit too naive.
The reference application for “managing with lists” is Basecamp, an excellent “work management” application built by 37Signals, which became famous by building RubyOnRails, a web development framework.
Basecamp is considered a prime example of a “project management 2.0″ application, changing the old approach to the problem: purely online (but this is not such great news), and based on the idea of to-do list, with a very very very simple user interface. This in contrast with more classical Gantt-based planning. It also looks so simply done that it has also uncountably many clones, see e.g. this discussion and links, but the original is probably better, and keeps improving.
Before releasing Teamwork 4, we studied (among many other usability books) Defensive Design for the Web: How to improve error messages, help, forms, and other crisis points, a book still by 37Signals, which gave us some good ideas which you see for example in Teamwork 4 error page.
Teamwork could hardly be more different from Basecamp, as we disagree on the basic philosophy: we still think that the good way to model management problems is with the project tree / assignment notion (though not necessarily presented through a Gantt graph), and not with to-do lists. We share with 37Signals the idea that the user interface should be as simple as possible, and that usability concerns should be at the center of development. But we also believe that usability is not necessarily synonymous with poverty of features and integrations.
The difference between lists and tree based management may seem misleadingly small: notice that for example it touches on whether the order of things to be done is just as the order in the list, or is linked to dates. There are far-reaching consequences of this assumption: it is difficult to imagine how ordered lists can be the source of a shared organization, instead of being the result of a shared planning tree of events and dates. These results in completely different applications: Basecamp with a universal dashboard, Teamwork with dates, projects, and different views for different users. And it would be a big mistake to think that one can be somehow transformed in the other.
You may ask: why can’t I have both? In fact, both applications do some of both approaches, but it is a general philosophical choice that has been done: Basecamp has a minimal modeling structure, Teamwork tries to keep it maximal, giving all options to the users. If you are familiar with Teamwork, “trees” (projects) do indeed “manage” lists (issues and to-do’s), but you can’t do without the central notion of assignment, linking “branches” to “leafs” (people).
Teamwork also tries to embrace the existing IT infrastructure (so it can become complex to configure), and hence it is not necessarily an online service: not a purely “web 2.0″ service in this.
On how to improve usability, without impoverishing the model, see for example this blog post. Also if you want to try switching from lists to trees, Teamwork provides an import from Basecamp, see the user guide, section “Escape from Basecamp”.
So, between lists and trees, the choice is yours…
The name and logo for Basecamp and 37signals are registered trademarks of 37signals, LLC. Teamwork and Open Lab are in no way affiliated to Basecamp or 37signals, LLC.
Smarter search and recent object functionality
Here we examine a technique to improve usability in complex applications by introducing smarter search and “recent objects” functionalities. As usability becomes more and more a crucial feature of applications, helping users with full-text search and recent object lists may still prove insufficient. You may need to go beyond these features, by having a way to keep track of “most used” objects, which will help to:
- guess what you are looking for
- find what you are searching for
The problem
Lets see an example.
In these weeks you are working on items A, B and C of your favorite web application. Friday, you actually briefly worked on X, Y and Z before going home, as you had these for quite a while in the bottom of your to-do list. Now, you get back to work on Monday, and what you have in your “recent objects” list? Well, X, Y,Z. Useless. But you have full-text search. You search for the name of A, which actually hundreds of other objects share, and which maybe there are far more occurrences than in A, even if nobody has been using them for quite a while, so they fill results on top of your A. Useless. There is no easy way to get back to A: something here is not working.
This is a usability problem; in order to make your application more helpful, you should somehow keep track of what is being used most often by the users. How to do that? A complete answer is not trivial: as often happens in usability problems, what looks simple from the point of view of the user, is actually complex to solve and render. In the end, all complexity should be hidden, but the solution is not trivial.
- Area of focused interest in time.
What is relevant to you is not just stuff that you occasionally visited, but say projects or documents to which you recently returned to again and again: you need to keep in focus a window of attention. See it in this way: you want the projects or documents to which you are frequently linking to. You need a sort of personal page rank.
Recording hits
Well, the way to go is record what are doing; you have to record it somehow as a parallel, probably de-normalized table of “hits”, keeping it very simple, as you will probably get quickly really a lot of records there.
|
In the picture you see an example “hit”, when a user looks and/or works on something. Notice that as you will collect a lot of data, you will need to filter out in function also of your security model: that is why we have the “areaId” field there. |
Now however you decide to collect hits, you will have to meet the problem of how to weigh them, that is, have a hit rank function defined on users, objects and time.
In our implementation, we created a function that for every Teamwork user and every entity (be it task, issue, diary entry, document, worklog action) computes the user hit rank for the entity; if the entity is relevant for the user, the hit rank will be high. Rank gets high by “hitting” i.e. visiting an entity.
As we said before, interest is assumed to fade in time, otherwise you’d end to have too many entities with high rank: so you have to define a sort of window of attention, with a degradation of relevance.
 |
 |
You need a way to compute degradation of relevance; we defined degradation with the rigth side of a Gaussian curve with the constants in the code.
Hit rank can be refined to group rank notion, if your application has a notion of workgroup, so that you could define the activity of the group. Another benefit of hit rank is that you can efficiently monitor your application usage, or “activity”, and could lead to introducing badges et cetera.
Example implementation
An example implementation is in Teamwork: as it includes project management, business processes and groupware, there are many objects around. Hit rank has proven useful in a number of ways to improve usability, without impoverishing the model.
“You mostly visited” is a portlet which you may have on your dashboards, and you also see search results ranked:
 Your highest ranked entities. |
 Configuration of rank portlet. |
 Search results ranked. |
In this way you should always have “at hand” what you’re really working on: you should be able to access your most relevant objects with one click.
References
Google’ page rank paper: The Anatomy of a Large-Scale Hypertextual Web Search Engine
A discussion on badges: http://stackoverflow.com/questions/135647/how-do-badges-work-in-stackoverflow
An introduction to full text search: http://www.javaworld.com/javaworld/jw-09-2006/jw-0925-lucene.html
Hibernate full-text search: http://www.hibernate.org/410.html
Our contribution to Hibernate full-text search: http://www.hibernate.org/432.html
See hit rank in action in the demo or by installing the web app.
