Skip to end of banner
Go to start of banner

SOP - Major Incidents

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

STANDARD OPERATING PROCEDURE

Title

Major Incidents

Effective Date

April 2020

Department

eBusiness

Business Owner

Farid Mokraoui


Purpose 

This document outlines how several groups in eBusiness should handle Major Incident projects as they arise.

Policies and Procedures 

  1. Receiving the Request
    1. IT communicates to Lorrie Carter in a Teams channel called _ that either Ferguson.com is down, has limited availability, or there is a breach of some sort.   
    2. Lorrie Carter then reaches out to the Manager and Project Manager of the DXT and requests a kickoff meeting to be scheduled quickly.  
    3. A kickoff call meeting is sent out to the following teams:
      1. DXT
      2. Analytics
      3. Communications
      4. Email
  2. Creating the Project(s)
    1. DXT and Email projects are handled separately.
      1. If Analytics and DXT are involved in communication around the Major Incident, tasks for Analytics will be included in the DXT project.  
      2. If there are DXT deliverables, Lorrie will create the project and apply the following template: https://ferguson.my.workfront.com/template/5e98bef800d37751a596fa97e5508346/tasks?activeTab=tab-template-updates
    2. Messaging and direction are fine tuned, proofed and approved in Teams.  This information is then posted into the Workfront project so that DXT can begin work.
  3.  Hosting the Kickoff Meeting
    1. The Project Manager of the DXT hosts the kickoff meeting
    2. Details of the Major Incident are discussed
    3. Tasks, predecessors and timelines are confirmed/adjusted in WorkFront
    4. Approvers for design and messaging must be identified
    5. The Point-of-Contact must be identified (this is the person who will ensure that the final and approved (F/A) information gets posted to the Workfront project to clearly communicate the actual work that needs to be done)
    6. Backup plans are created in case the Major Incident happens longer than expected
  4. Proofing the Work (It is important to take the time up front to ensure that everything is final and approved before it is posted over to Workfront)
    1. A testing link is posted in Workfront with approvers tagged
    2. Approvers can discuss anything that needs to be changed with other involved using the Team chat.
    3. Any changes in direction or messaging need to be collected from the Teams chat, approved by the appropriate people, and posted into the Workfront project.  Once posted, the Designer must be notified via Workfront tag for those changes to be made.
    4. Example of what should be posted in Workfront:
      1. F/A - "Learn about Ferguson's response to COVID-19.  Read message.   All Ferguson counter locations will be pick-up and delivery only. Order ahead (call or online) and pick-up at store.  "
      2. F/A - Add tracking code to "Read message" https://www.ferguson.com/content/corporate-information/covid-19?icid=cont_hmpg_home_homepage_covid-19
    5. Workfront is the official record of the decisions that were made and what was posted to the site.

Expected Turnaround Time

Everyone involved with any emergency project should make this their top priority until the work is complete.  Everyone should be monitoring the Workfront project, their email for notifications, and the Teams chat set up for the project.  If you must be away during this time, you must let everyone know and assign a backup for your work.

Questions/Feedback

If you have any questions, feedback or suggestions for this process, please let the DXT Project Manager know.    

Discussion Topics

  • Capture all types of issues (COVID all the way down to a feature not working on the site - all levels by category)
  • Availability, On-Call, Responsiveness, Teams on your phone
  • Benchmarking, what does timing look like by category (can lead to quarterly wins, improvements)
  • The idea of having a point-of-contact for final and approved copy/changes
  • RACI chart
  • Identify character count/limitations for banners (160)
  • Correct copywriters for the job, try to limit participants
  • Rules around length of stay on production - changing things out with varied messaging, don't want things to become stale
  • Automation of the process



  • No labels