1. Why do you need BC Program Support Log?
2. What is the Incident Status and what does it mean?
3. Types of Incidents
4. How Are Incidents Managed?
5. Adding A New Incident
6. Analyzing an Incident
7. Analyzing an Incident: Impact Score (Impact/Risk Level)
8. Analyzing an Incident: Impact Groups
9. Analyzing an Incident:  Approval Authority
10. Resolving an Incident
11. Resolving An Incident – The End
12. What Else Can Happen?
13. What Else Can Happen – Merged
14. What Else Can Happen – Cancelled
15. What Else Can Happen – Deferred
16. What Else Can Happen – Monitor

Answers:

1. Why Do You Need BC Program Support Log?
    

• All projects have planned and unplanned events.

• The unplanned events consume a tremendous amount of resources.  They are often the source of project failure.
• The Program Support Log is for tracking and controlling unplanned events, known as incidents.

top
 

2. What is the Incident Status and what does it mean?

   The Incident Status identifies an incident's position within it's life cycle. The different Status types are:
   
   New
   All newly created Incidents are automatically assigned a status of New. In general, an Incident should not have a status of New for more than one week.
   
   Withdrawn
   Prior to the Analysis step, the originator of an incident may decide to withdraw it. An Incident cannot be withdrawn after the analysis has begun.
   
   A Withdrawn Incident requires:

   • All the fields completed for a New Incident

   • The Reason why it was withdrawn in the Description Status Text field.

Analysis
The Analysis is also known as the Detailed Analysis. The Analysis must have a Target End Date.

The person assigned to the analysis is expected to:

• Update the Analysis Start Date

• Add any notes to the Status Text.

• Determine the Ranking by completing the Impact Score (Impact/Risk Level)

• Select the Impacted Groups

• Select an Approval Authority

• Make a Recommendation.

Analysis Complete
The analysis of an Incident is complete if:

• It is ranked (Urgent, High, Medium, Low)

• Impacted groups have been selected

• An Approval Authority has been selected

• A Recommendation is made

• The Analysis Actual End Date is completed

An Incident cannot go on for resolution with any of the above missing.

In Progress
By definition, when the resolution begins, the status is In Progress.

An Incident In Progress must have a Resolution Target End Date.

The person assigned to the resolution is expected to:

• Update the Resolution Start Date

• Add any notes to the Resolution Status Text documenting the resolution

• Select the Approval Authority. The Approval Authority can be different than the Approval Authority for the Analysis.

• Notify the Approval Authority when the resolution is finished

Completed
The resolution of an Incident is ready to be approved if:

• It is ranked (Urgent, High, Medium, Low)

• Impacted groups have been selected

• A Recommendation is made

• Resolution Status Text indicates what has been done to resolve the issue

• Approval Authority selected

If the Approval Authority is satisfied with the above he or she:

• Checks the Approved box

• Enters the Resolution Actual End Date

• Add any notes to the Resolution Status Text field (if required)

• Change the Status to Completed

Deferred
An Approval Authority may Defer an incident at any time after the analysis has begun.

A Deferred incident must have:

• The Approval Authority;

• The Recommendation - the reason why it was deferred

• The Date of re-activation
  
  - If the decision to defer an Incident occurred during the Analysis step, the Analysis Target End Date becomes the deferral date.  
  
  - If the decision to defer an Incident occurred during the Resolution step, the Resolution Target End Date becomes the deferral date.

It does not require:

• The Ranking;

• The Status Text;

• The Impacted Groups.

An Incident cannot have an Actual Resolution End Date if it is Deferred.

Merged
An Approval Authority may merge an incident at any time after the analysis has begun.

Incidents may be merged if:

• They are dealing with similar topics

• It makes sense to group some incidents together as a single work package

• If the incident is just a piece of a larger incident

A Merged incident must have:

• The Approval Authority

• An End Date

- If the decision to merge an Incident occurred during the Analysis step, the Analysis Actual End Date becomes the merge date.  

- If the decision to merge an Incident occurred during the Resolution step, the Resolution Actual End Date becomes the merge date.

• The Recommendation (It should state with which incident it was merged).

It does not require:

• The Ranking

• The Status Text

• The Impacted Groups.

Monitor
An Approval Authority may set a status to Monitor for an incident at any time after the analysis has begun.

A Monitored incident must have:

• The Approval Authority;

• An End Date
  
  - If the decision to monitor an Incident occurred during the Analysis step, the Analysis Target End Date becomes the monitor date.  
  
  - If the decision to monitor an Incident occurred during the Resolution step, the Resolution Target End Date becomes the monitor date.

• The Recommendation - It should state why it is being monitored.

It does not require:

• The Ranking;

• The Status Text;

• The Impacted Groups.

An Incident cannot have an Actual Resolution End Date if it is being monitored.

Cancelled
An Approval Authority may Cancel an incident at any time after the analysis has begun.

A Cancelled Incident means that work had started on the incident (either Analysis or Resolution) but the Approval Authority stopped it before it was completed.

A Cancelled incident must have:

• The Approval Authority;

• An End Date
  
  - If the decision to cancel an Incident occurred during the Analysis step, the Analysis Actual End Date becomes the cancel date.  
  
  - If the decision to cancel an Incident occurred during the Resolution step, the Resolution Actual End Date becomes the cancel date.

• A Recommendation with the reason for cancellation

It does not require:

• The Ranking

• The Impacted Groups
  
   

top

3. Types of Incidents

    

   • A Risk is something negative that may happen.
   • An Issue is something that has to be done but there is not a final decision on what to do.
   • A Change Request is seeking permission for a specific course of action which will change the project's schedule, cost or functionality.
   • A Discussion Item usually precedes a categorization of an Issue, Risk, or Change request.
     
      

top

4. How Are Incidents Managed?

   Every type of incident has three basic steps; open, analyze and resolve.

   • New Incident Form - identify a new incident
   • Analyze Incident - the incident must be reviewed.
   • Resolve Incident - Once the analysis is complete a course of action is decided upon.  
     
      

top

5. Adding A New Incident

    

   • Provide an incident title
   • Provide a short description.  The objective is to give enough information to understand the incident.
   • Attachment supporting documentation if necessary.
   • Select the type of incident ex. Change Request, Issue, Risk, or Discussion Item.
     
      

top

6.  Analyzing an Incident

    

   • When an Incident is opened, it is:

     • Assigned by either a Manager or Project Leader

     • Assigned at a Joint Project Leader Meeting

     • Rejected

   • You must put in a Start Date and a Target End Date if you are analyzing an incident

   • The Status should be "Under Investigation" unless instructed to do a Preliminary Analysis.

   • An Analysis must be ranked, the impacted groups selected, Approval Authority selected and a recommendation entered.

   • If you need information from an Interface Partner, you must go get it!

   • When complete, the status is changed to Analysis Complete and the Actual End Date entered.
     
      

top

7. Analyzing an Incident: Impact Score (Impact/Risk Level)

The Impact Score sets the ranking. The ranking (or the Impact/Risk Level) is automatically calculated. See Risk - Impact Analysis for details.

Possible Rankings are; Not Ranked, Low, Medium, High, and Urgent.

• The Risks Score is based on four factors:

  • The Scope (Schedule, Resources, and Project Phase)
  • Cost

  • Quality

  • Probability (Likelihood and Resolution)

• The Issue and Change Request Scores are based on three factors:

  • The Scope (Schedule, Resources, and Project Phase)
  • Cost

  • Quality

Note that Discussion Items are not ranked.

 

top

8. Analyzing an Incident: Impact Groups

    

   • Select the groups impacted by an incident.

   • The groups listed are controlled by the Program Support Log Administrator.
     
      

top

9. Analyzing an Incident:  Approval Authority

The Approval Authority is usually selected based on the Impact Score and the Impact Groups.

• Low = Project Leader, Manager, Director

• Medium = Manager, Director

• High or Urgent = Director
  
   

top

10. Resolving an Incident

     

    • After the Analysis, the Approval Authority will either Cancel the Incident or assign it for Resolution.

    • If assigned for Resolution, the Status is changed to In Progress.

    • You must put in a Start Date and a Target End Date if you are resolving an incident

The person assigned to the analysis is expected to add any notes to the History Log or attachment

top

11. Resolving An Incident – The End

     

    • An Incident can only end if the Resolution is complete and has been approved by the Approval Authority.

    • The status is changed to Completed.

    • The actual End Date in entered.
      
       

top

12. What Else Can Happen?

     

    • An Approval Authority may Cancel, Defer, Monitor or Merge an incident at any time after the analysis has begun.

    • Any Incident with a status of Merged, Cancelled, Deferred, or Monitor requires an Approval Authority.
       

top

13. What Else Can Happen - Merged

     

    • Incidents may be merged if:

– They are dealing with similar topics

– It makes sense to group some incidents together as a single work package

– If the incident is just a piece of a larger incident

• If it occurred during the Analysis step, the Analysis Actual End Date becomes the merge date.

• If it occurred during the Resolution step, the Resolution Actual End Date becomes the merge date.
  
   

top

14. What Else Can Happen - Cancelled

     

    • A Cancelled Incident means work had started (either Analysis or Resolution) but it was stopped by the Approval Authority.

    • All Cancelled incidents should have the reasons in the Recommendation field.

    • If it occurred during the Analysis and/or the resolution step, the end date becomes the cancel date.
      
       

top

15. What Else Can Happen – Deferred

     

    • If it occurred during the Analysis and/or the resolution step, the end date becomes the deferral date.

    • An Incident cannot have an Actual Resolution End Date if it is Deferred.
      
       

top

16. What Else Can Happen - Monitor

     

    • Monitor means halting activity but not canceling the incident.  Most commonly used with Risks

    • If it occurred during the Analysis step, the Analysis Target End Date becomes the monitor date

    • If it occurred during the Resolution step, the Resolution Target End Date becomes the monitor date.

    • A monitored Incident cannot have an Actual Resolution End Date.