none
what are the advantages of linking between risks and tasks? RRS feed

  • Question

  • when we add new risks we can use "custom commands> link Items" and link tasks or documents or issues to risks.and we can set the relation type between them such as : risks affect task or task trigger risk ,...

    now I was wondering what are the advantages of setting relationship and it's type?

    does it affect on my schedule or cost because of "cost exposure?

    it's sort of confusing

    Saturday, January 19, 2013 12:59 PM

Answers

  • As with so many features, it's only useful if you use it. And this depends on your business processes. Let's suppose you have a reasonably mature issue management process:

    • Whenever someone identifies an issue, it is categorised as to which deliverable or part of the project it affects (e.g. vendor announces a delivery delay for a piece of equipment - this would affect the installation task).
    • You update the Issue list in the Project Workspace with the issue including an explanation, ownership, severity, etc. - and which project task it affects.
    • The task owner in the project may change the duration of the task - and update the issue to explain the delay.
    • The Issue owner (possibly a different person than the task owner) may update the issue with up-to-date info on the status from the vendor.
    • The project manager now has a picture of which tasks are affected by which issues and can work on high level causes. At the regular status meetings, the issue list is reviewed and the tasks affected can be shared.

    This is a very short example. You can imagine that as well as tasks that would be affected by an issue, there could also be tasks which are designed to address or anticipate such issue (e.g. a vendor communication task for our example above) and this kind of task would also be identified for the issue (as a task to address the issue). Then looking from the Vendor Communication task angle, you could see what issues the task owner had to deal with.

    The picture is similar with Risks - which tasks would be affected, which tasks anticipate and would avoid the occurrence of the risk, which tasks would address the outcome if the risk occurs, etc. Again, you need a reasonably consistent business process to exploit the feature.

    Graham

    • Proposed as answer by Kashif Nizam Saturday, January 26, 2013 10:55 AM
    • Marked as answer by Sam-Net Monday, January 28, 2013 5:56 AM
    Saturday, January 19, 2013 2:25 PM

All replies

  • As with so many features, it's only useful if you use it. And this depends on your business processes. Let's suppose you have a reasonably mature issue management process:

    • Whenever someone identifies an issue, it is categorised as to which deliverable or part of the project it affects (e.g. vendor announces a delivery delay for a piece of equipment - this would affect the installation task).
    • You update the Issue list in the Project Workspace with the issue including an explanation, ownership, severity, etc. - and which project task it affects.
    • The task owner in the project may change the duration of the task - and update the issue to explain the delay.
    • The Issue owner (possibly a different person than the task owner) may update the issue with up-to-date info on the status from the vendor.
    • The project manager now has a picture of which tasks are affected by which issues and can work on high level causes. At the regular status meetings, the issue list is reviewed and the tasks affected can be shared.

    This is a very short example. You can imagine that as well as tasks that would be affected by an issue, there could also be tasks which are designed to address or anticipate such issue (e.g. a vendor communication task for our example above) and this kind of task would also be identified for the issue (as a task to address the issue). Then looking from the Vendor Communication task angle, you could see what issues the task owner had to deal with.

    The picture is similar with Risks - which tasks would be affected, which tasks anticipate and would avoid the occurrence of the risk, which tasks would address the outcome if the risk occurs, etc. Again, you need a reasonably consistent business process to exploit the feature.

    Graham

    • Proposed as answer by Kashif Nizam Saturday, January 26, 2013 10:55 AM
    • Marked as answer by Sam-Net Monday, January 28, 2013 5:56 AM
    Saturday, January 19, 2013 2:25 PM
  • As with so many features, it's only useful if you use it. And this depends on your business processes. Let's suppose you have a reasonably mature issue management process:

    • Whenever someone identifies an issue, it is categorised as to which deliverable or part of the project it affects (e.g. vendor announces a delivery delay for a piece of equipment - this would affect the installation task).
    • You update the Issue list in the Project Workspace with the issue including an explanation, ownership, severity, etc. - and which project task it affects.
    • The task owner in the project may change the duration of the task - and update the issue to explain the delay.
    • The Issue owner (possibly a different person than the task owner) may update the issue with up-to-date info on the status from the vendor.
    • The project manager now has a picture of which tasks are affected by which issues and can work on high level causes. At the regular status meetings, the issue list is reviewed and the tasks affected can be shared.

    This is a very short example. You can imagine that as well as tasks that would be affected by an issue, there could also be tasks which are designed to address or anticipate such issue (e.g. a vendor communication task for our example above) and this kind of task would also be identified for the issue (as a task to address the issue). Then looking from the Vendor Communication task angle, you could see what issues the task owner had to deal with.

    The picture is similar with Risks - which tasks would be affected, which tasks anticipate and would avoid the occurrence of the risk, which tasks would address the outcome if the risk occurs, etc. Again, you need a reasonably consistent business process to exploit the feature.

    Graham

    thanks Graham,

    as you mentioned it seems there is no actual relation between tasks and risk and this is kind of categorization

    please correct me if I'm wrong

    when I saw some expressions like :risks affect task , task trigger risk,... I supposed that there might be some functional relationship between them 

    risks is more important than issues for me in this thread

    Sunday, January 20, 2013 6:23 AM
  • Yes, you're right - there is no specific link between entries in the Risks list and those in the Issues list. Any link would be indirect - e.g. through a shared task or owner. In particular, if your processes treat a risk as an issue that has not yet occurred - then if the risk does occur you would need to make an entry as an Issue which is actively tracked and inactivate the risk which no longer needs to be tracked.

    Graham

    Sunday, January 20, 2013 4:19 PM
  • not only there is no relation between risk and issues, but also there is no relation between tasks and risks.when we identify risks in EPM, in section trigger description we entry some values and set "trigger" to one of these valuse: 1- date 2- exposure from threshold 3- task not completed 4- other

    is this just kind of categorization? or there is specefic relation between these items

     
    Monday, January 21, 2013 6:12 AM