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