Assigning tasks to multiple people....where we're at....

This is by far the most popular request and one that we get at least 3 emails a day about. I have even needed it myself lately.

There are some interesting questions posed from a development point of view. What seems like such an easy thing to add actually is quite complicated and requires LOT'S of thought and careful planning.

Let's talk first about what the feature actually does and why it isn't in the app right now.

You want to create a task and assign it to multiple people. What does this actually mean?
  • Does it mean:
    • Assign this task to 5 people but anyone of those 5 people need to complete it. When it's complete, it's done. Finito.
      • Example: Take out the office trash. There is only 1 trash can, when it's emptied, it's done.
  • Does it mean:
    • Assign this task to 5 people and all people need to complete this task.
      • Example: Take out your office trash. There are 5 cubicles in the office, all trash cans must be emptied.

Let's talk about the User Interface (UI) for this

We need to keep the adding of tasks fast and lean as this is the most frequent use of the app. Right now we have broken the Task form into tabs with the important bits on the first tab and any additional functionality hidden away in the other tabs. What do we do when you need to select multiple people?

We don't want to make a select list that requires ctrl+click to select multiple people. It needs to be fast and intuitive.

We have some ideas on this:


Basically, by using the drop-down select in combination with another button (icon to be decided) a quick menu is displayed allowing quick checking-off of people. This works well on the calendar for notifying multiple people but is not the best looking fish in the world so it'll get a lick of paint and some TLC.

Lets talk about the impact this has on the app and current architecture..switch off if you're not a nerd

Everything right now works around optimised queries looking up tasks based on the current user. It's a simple LEFT OUTER JOIN. We'll need to now hold another look up table in the database mapping tasks to users. This normally would be OK except tasks are tied to task lists which are tied to milestones and the date of a task can be inherited up the chain. Couple this with a lookup table for people attached to the task and it gets fairly hairy.

 (So what? I hear you say, feed the monkeys more peanuts and it'll get done)

Well, this affects everything. It affects the Dashboard, Project Overview, API, Everything Tab, Task listing page, Daily Report, Export, Reports, RSS.....ugghhhhhh

So, it's hard. We need to spend alot of time and lucozade on this one.

Lets talk about the listing of tasks

The last bit that this impacts is the actual listing of tasks. We have the name of the person as the first segment of each individual task.

This will have to change and again, we have some ideas on this....

So, to recap, we have alot to do to add this feature but as always (and along with everything else on the Roadmap) we are working away on it.....

Dan.
Upvote Upvoted 0
10 responses
Although this is obviously a pain to implement, I too have run across this need as well. I would venture to say that most users would benefit from it. Thanks for your work on this guys. I use both Basecamp and Teamworkpm, and this would be yet another feature that I think would set teamworkpm apart as a superior project management application.
— Paul Sedy
Could a solution be to have the task assigned to 'Multiple', and have each person have a check box of their own to click off, before the actual task is clicked off.

Not sure if I'm explaining that correctly... but it would be like each task 'completed' checkbox had 'sub task' check boxes for each person.

So at the top level it still only has one check 'completed' box. But one layer down there is a 'completed' check box for each.

— Simeon
Surely this should be about assigning the same task to multiple people, one or all who need to complete it. In your example above with the rubbish bins, the task should be to empty the rubbish bin. If it is to empty a specific bin of the 5 in the second example it should be 5 tasks, each assigned to a specific person (or to everyone) so that all five bins are in fact emptied.

In my world this will be useful for creative teams answering a brief. Often multiple teams will work on the brief, but I only need one team to crack it. Usually there is a team who is responsible with others assisting, but that level of detail doesn't need capturing past maybe be able to order the people assigned to the task- first more responsible etc. That doesn't need to be a rule for you.

If I have multiple briefs they would be separate tasks if not projects.

Are you thinking of implementing groups as part of this? Teams are two people in my world and I'd love to be able to have them individually identified but working together. At the moment I do this with hybrid users who are both members of a team. That doesn't always work when individuals work on tasks with other individuals, who are also part of a team.

Hope that makes some form of sense...

— Conan Gorbey
This is an important implementation point and something that could make TeamworkPM even more wildly useful than it already is. Basically, if you score a big goal with this, it will be hard to replicate in other systems and make a nice selling point. I had a think about the scenarios that might surround such functionality:

* you know a team has to work on a task, but you are not sure who will do what yet or even what is required, other than knowing the general idea. However, you want to mark down what has to be done in general so you can go back and define it. This would be nice for those times when you are on the phone defining the tasks in a project and just getting started. In this case you know there are certain groups of people who have to work on tasks, and would like to simply say "this one's to be done by team Red" and so forth. Picking group "Red" assigns the people in that group to the task.

* you have been discussing your meta-task, and now know who will do what. Either you want to break it down into assigned subtasks, or leave it in a state that you describe in this post - assigned to multiple people, with some way of toggling the completion behavior of the task (any-complete vs all-complete). That being said, it would be good if there were an easy way to segue from the undefined state, to a defined one with separated-out tasks. For instance if you had team Red assigned, and now you know Jane will do X and John will do Y, the system makes it simple to drop down into that extra level of detail. Perhaps, there could be a "break up task" button, that makes a task for each member of the assigned group, so that you could then quickly fill in the details.

* when you assign a group of people to a task as individuals, the display or printout behavior is going to have impact in meetings. Psychologically you want the leader's name visible. If "Experienced Ellie" is the leader, and one of the group members is "Greenhorn Greg" you don't want the task list to say "Greenhorn Greg and 5 others". Perhaps the first person you pick is the leader, but this changes. Perhaps that means there needs to be a pick for the leader or a way to indicate the leader. Also, printing a report that you will show to people on a screen or send via email cannot say "Me and 3 others". The resource has to be named, or that CFO you sent the report to is going to think you're soft in the head. :-)

* another area of impact is repeated tasks. The structures you build would need to be repeatable, for tasks like a Finance group's "month end close" or an IT group's "review SOX compliance" tasks. This would be a nice feature for long projects or just general operations.

* currently, updating tasks is a serial activity, though you are touching upon the concept of what I think is needed in your "create multiple milestones" UI. Because we need a way to PDF a report for whomever we're reporting to at our clients, we use the task, tasklist and milestone Description fields to write down a little bit of detail about the task, and what the status is. I think the UI should let us edit these things in a bulk, ajaxy way. Basically, a 'grid' of all the main information in your tasks, so you can whip down it and update all the fields in one go, rather than the current idea of going one-by-one in serial.

* regarding current status, off topic for this discussion but I wish for a quick current status field that lets you add a carefully-crafted current status note, shows the latest one, and lets you get a report of all of them for continuity. Showing the latest message would not work, since anyone can add them and it would be hard to yell out to a distributed team "nobody update while I make this PDF!"

While these overlap some with what other posters commented I think it's some food for thought.

As always, I am sure it will turn out awesome.

Best regards,
Rick Cogley

— Rick Cogley
Hi Rick,
These short comments of yours don't really help, what we need is more detail.... :-p
— Sam Kidd
I’ll work on that! :-D

— Rick Cogley
Another thing I remembered. I know when you assign a task to multiple people without saying who will do it, in many cases people will just assume everyone else will do it, and nothing gets done.

Similarly, when there is an accident and you are administering aid to the victims, bleating out "call an ambulance" does not necessarily have that effect. They say, you should specifically point to people and tell them "you sir, call an ambulance now" and so on.

Just a thought that might be relevant when assigning multiple people.

— Rick Cogley
Rick that is a very good point and something that we will have to look at. I didn't think of that but I could see this type of situation arising on a task and everyone else pointing the finger at everyone else on the team......and there I was thinking you were just a pretty face ;-)
— Sam Kidd
Heh, thanks.
— Rick Cogley
Seems to me a simple workaround is to create a group of users and change the code to allow a task to be assigned to the group, but not be closed out unless an individual has taken ownership.
— Jason