in

 

Tasks versus Issues

Last post 06-14-2006 9:42 AM by John Filicetti. 6 replies.
Page 1 of 1 (7 items)
Sort Posts: Previous Next
  • 04-28-2006 11:18 AM

    Tasks versus Issues

    I would like feedback on how other users take advantage of using the Issues application. More specifically, what criteria do you use internally to decide when to make something an issue versus a task?

    Just to note, I'm fully aware of the differences between the two from a technical standpoint (i.e. work can't be estimated for issues etc.). But it seems to me there is a bit of a grey area where an item could be one or the other (task or issue) and I'd like to establish a set of criteria to eliminate confusion.

    Thank You
  • 04-28-2006 11:26 AM In reply to

    Re: Tasks versus Issues

    Here's a real world example. Let's suppose I have 10 items that I need to make sure get addressed by outside subcontractors. For those subcontractors they ARE tasks. BUT, I could care less about whether they take 1 day or 3 days to complete (within reason of course) and mainly want to maintain a list of them and keep following up on them to make sure they get done. Are those tasks or issues?
  • 04-28-2006 2:26 PM In reply to

    Re: Tasks versus Issues

    David,

    Great question.  If you don't have a date constraint and just want to track completion, you can use the issue application.  You won't have the same reporting available and won't track utilization.

    I have also worked with groups who Tasks for everything including issues so they can track all activities. 

    I have actually created a "super" report I use.  I have put an example in the files section.  It is a RAIDCBT document or spreadsheet (Risk, Action Item, Issues, Decisions, Change, Business Process, and Training Needs).  I like to keep everything in one place and I can notify/assign from there if needed. 

    John F. Filicetti, PMP, MBA
  • 04-28-2006 11:27 PM In reply to

    Re: Tasks versus Issues

    That`s a criteria that has to be stablished for each organization you work for. I had worked with companies that all their tasks, from their point of view are issues. Others where no issue is created. Everything is a task.

    From my point of view, the simple definition is:

    TASKS. Put everything you planned to do and all the changes during the way.

    ISSUES. Put everuthying that is a obstacle to get tasks done. Or situations that may not be task related, but are an obstacle for the project.

    For example, if a task called Test Software and you need a simulatio software to get it done. If for what ever reazon the software is not available, create an issue and have someone to take care of it. Or if the person supposed to do the task is on vacation, create an issue to have someone to make sure you have a new resource by the time the first one is gone. Or if there is a delay on a vendor, that will affect the hole project, you could create an issue to have someone start searching for a new one.

    Regards¡

    Raul Cardenas

    Raul Cardenas
    Director de Operaciones.
    Implementación y Resultados / Daptiv CP
    Av. Paseo de la Reforma 450, Piso 10 y 11, Col. Juárez
    México, DF, CP 06600
    Tel: 01 (52) 55 91 71 20 59
    Fax: 01 (52) 55 91 71 14 99
    http://www.imr.com.mx http://www.daptiv.com
    raul.cardenas@imr.com.mx
    Soluciones integrales en Administración de Proyectos.

  • 05-08-2006 10:51 AM In reply to

    Re: Tasks versus Issues

    I usually state that our Issues application is used to track any unplanned event that negatively impacts the budget or timeline of a project.  The reality is that each client must define what they consider an issue to be and then we work to resolve how to track it.  The Issues app may meet the need of most but here are some other scenarios I've experienced:

    Long term issues have been converted into tasks to be managed and the original issue was linked to its associated tasks in the schedule.  Through ARE you can connect the two in reports for visibility.

    The issues application was enhanced via custom fields to capture more specific information although not to the detail of resource/cost per resource requirements.

    The Risk application was modified to incorporate the Issues data as well, usually a custom field (a picklist) was set for the item that said if it was a "Risk" item or an "Issue". For those risk items that came to fruition you could switch its type. Oh, and the Issues application itself was disabled to prevent confusion.  You may also do the opposite and modify the Issues Application to pull in Risk data.


    Steve Thompson | Solutions Consultant
    Daptiv


  • 06-05-2006 8:37 AM In reply to

    Re: Tasks versus Issues

    John:

     

    I am not a current eproject user, but evaluating the software.  When you say report are you saying that you are able to generate this information automatically from data in eproject?

    Thanks

    Dan.

  • 06-14-2006 9:42 AM In reply to

    Re: Tasks versus Issues

    Dan,

    Sorry for the late reply.  In PPM6, you are able to create views across your applications for all projects.  If you create a view from your Tasks or Issues tab (remember, it goes across all projects); you can create and print your view to PDF for all projects or filter by project.  The views are now MUCH more powerful than the reports used to be.  Of course, you can also create reports, but I am really getting to like the views better. 

     

    John F. Filicetti, PMP, MBA
Page 1 of 1 (7 items)

Navigate: Home | Blogs | Forums | Solution Library  Get Help:  Contact | Feedback | FAQ   Terms of Use:  Terms & Conditions | Privacy Policy