Issues vs Tasks Training

[JillAc]

Hi I am trying to train our Design Director how to manage new Issues that come in from Requests. (We are not a Help Desk, we are an in-house marketing department). He is a designer, manages a team of 5 designers, not a project manager or planner. His brain works differently! I am having real trouble explaining the difference between an Issue and a Task, and between a Queue and a Project. They look exactly the same, there are no visual queues (ha ha no pun intended) so that it is clear how they act differently. I have sequestered the Queues into a Portfolio, but that's generally not how he is looking at them. And even if he is, it still doesn't really make sense, mostly because they look the same. His job is to assign staff to a new issues -- requests that come in for small things (I need a photo; I need a map; I need this thing in a different size). It's easy enough to teach him how to do it, and he gets that. What I can't seem to explain is why this isn't a Task and why they have different properties and act kind of differently with notifications, and the key strokes you take to assign a staff is different than in a Project (which he also has to do). He is confused about it, and I just can't seem to explain it with clarity. So, I reach out to the amazing people here and wonder if you've had the same experience, and how you explain it. Jill Ackerman

[VicAl]

Do you have them set up as a Team? If not, it sounds like that would help. More later on that. The way I explain it to our staff is, here is the hierarchy: Project Task Issue (depending on the audience I may go into the 4 issue Types). Work items in WF consist of Issues and Tasks and they must reside under a Project (they need a home). I tell them the term Project is used loosely in this case. Because we have virtually two types of Projects (standard PMI start and end projects, and "bucket" projects that are simply used to supply a home for random Tasks/Issues Рone for each team if you wish). I believe you're more interested in the latter. I describe the Tasks and Issues as follows: Issues (which consist of Requests) are typically considered break/fix issues or requests Рof the ad hoc nature Tasks are typically planned work The main differences between Tasks and Issues are small. They function very similarly physically, in assigning teams and people, and in notification, so I'm unclear what's happening in your instance on assignments and notifications). But here are the differences I describe: Issues can't have predecessors or subtasks They also couldn't be added to an Iteration but that changed with this last release You can convert an Issue to a Task, but not the other way around. You can convert an Issue or a Task to a Project. Tasks & Issues have slightly different Statuses (Complete vs. Closed). And you can create more for each based on your needs. The way we set up your situation is: Create a Request queue [project] (which you have) Create a Team Create a "bucket" project for that team. I use a standard name to know it's a bucket project (i.e. GIS Team Project). Alternate DVD ending: you may create another bucket project that contains just these types of requests, instead of using the Team Project. Either works, but I recommend routing them somewhere and not leaving them in the queue project (for granting access and other reasons). In the Queue project, route the requests to that Team assignment and that bucket project The team then views and works their requests in the Team View (under People > Teams > Team name). Tasks are under Backlog, Issues are under the Issues tab (which is where most of their work would be in this case). Hope that helps. Vic Alejandro, PMP, CSM | IT | Sr. IT Project Manager Denver Water | t: (303-628-7262) | c: (303-319-6473) "http://www.denverwater.org/"> http://www.denverwater.org INTEGRITY | VISION | PASSION | EXCELLENCE | RESPECT ------Original Message------ Hi I am trying to train our Design Director how to manage new Issues that come in from Requests. (We are not a Help Desk, we are an in-house marketing department). He is a designer, manages a team of 5 designers, not a project manager or planner. His brain works differently! I am having real trouble explaining the difference between an Issue and a Task, and between a Queue and a Project. They look exactly the same, there are no visual queues (ha ha no pun intended) so that it is clear how they act differently. I have sequestered the Queues into a Portfolio, but that's generally not how he is looking at them. And even if he is, it still doesn't really make sense, mostly because they look the same. His job is to assign staff to a new issues -- requests that come in for small things (I need a photo; I need a map; I need this thing in a different size). It's easy enough to teach him how to do it, and he gets that. What I can't seem to explain is why this isn't a Task and why they have different properties and act kind of differently with notifications, and the key strokes you take to assign a staff is different than in a Project (which he also has to do). He is confused about it, and I just can't seem to explain it with clarity.¬† So, I reach out to the amazing people here and wonder if you've had the same experience, and how you explain it. Jill Ackerman

[JillAc]

Hi Vic We aren't working with Teams. I don't understand the benefit of assigning Teams when in fact it's one person working each Queue. Jill Ackerman

[VicAl]

OK so don't use teams. I was going off of " His job is to assign staff to a new issues". I assumed staff was multiple people. If not, just assign it to the person. Obviously I'm not helping so I'll stop replying. Vic Alejandro, PMP, CSM | IT | Sr. IT Project Manager Denver Water | t: (303-628-7262) | c: (303-319-6473) "http://www.denverwater.org/"> http://www.denverwater.org INTEGRITY | VISION | PASSION | EXCELLENCE | RESPECT

[JillAc]

Ah ha! That was my bad language using “staff” to mean “a staff member” and now your answer makes perfect sense, though not for my specific case. He assigns one person to each task, sorry for the confusion.

[DanielCo]

One thing that has helped us is to create a custom project status called "Request Queue." This makes it easy for people to understand what they are looking at. I tell people tasks are "planned work" and issues are "unplanned work." I feel this is a helpful start to understand the purpose of each. Daniel Cooley Kenall

[SkyeHa]

I have a similar situation going on in my team from the reverse end. I have workers that are assigned tasks and requests and wondering why they have to have two different objects that behave differently, in order to manage their work. From your end (system admin) I'm sympathetic, and honestly, there really isn't a good answer. Yes, other folks are right--tasks are for X, requests are for Y. But why do they act differently? Why can't we report on them in the same way? Well... it's just the way things are. I don't know if it would be helpful in your case, but if it helps, maybe you can explain to your director that the "request" object is often used as a way to make things easier on a requestor. The object was created by Workfront to allow for a way to automatically attach approvals and custom forms to "something your requestor wants you to do" and automatically route to specific people. If you were to do this as a task, the requestor would have to fill out a lot more from scratch. As a bonus to this--it really opens up your Workfront and makes it more accessible to people with less training who don't get into your system as much. They don't need to remember to assign things to specific people, or figure out what custom forms to attach, or how long a task should take. The request object does that all for them. But yes, as a trade-off, the request object behaves differently to the task object. That's just the compromise we made for getting to use two different object types, each with its own perks. -skye