1. Incident vs. Problem Management (The Break-Fix Boundary)

Do not treat every recurring outage as a standalone emergency. As a Consultant, you are expected to elevate the operation from reactive firefighting to proactive root-cause resolution.

  • Incident Management: The goal is to restore normal service operations as quickly as possible. Workarounds are entirely acceptable here. (e.g., “The user’s Teams desktop app is crashing; clear the cache and have them use Teams on the Web so they can join their current meeting.”)
  • Problem Management: The goal is to identify the root cause of one or more Incidents to prevent them from happening again. (e.g., “Why are 50 users experiencing Teams desktop crashes after the latest Intune deployment? We need to analyze the deployment logs and correct the packaging.”)
  • The Consultant Pivot: When you see Helpdesk logging the same Incident multiple times, step in, declare a “Problem,” and lead the root cause analysis.

2. Navigating Change Management (The CAB)

Never walk into a Change Advisory Board (CAB) meeting with a “we’ll figure it out” attitude. You are dealing with business-critical M365 infrastructure. You must accurately classify your changes and prepare the necessary documentation.

  • Standard Change: Pre-approved, low-risk, and follows an established Standard Operating Procedure (SOP). (e.g., Creating a new SharePoint site using an existing provisioning template, or adding a verified vanity domain.)
  • Normal Change: Requires formal CAB approval, scheduling, and impact assessment. (e.g., Deploying a net-new Conditional Access policy targeting all mobile devices, or enabling external sharing globally.)
  • Emergency Change: Expedited changes required to resolve a Major Incident (Sev A). (e.g., Pushing an emergency Exchange mail flow rule to block an active phishing campaign.)

3. The CAB Package Template

To get a Normal Change approved swiftly, provide the CAB with a concise, confidence-inspiring package. Anticipate their questions before they ask them.

  • Implementation Plan: Step-by-step technical actions. (e.g., “Run script X to enable sensitivity labels; apply label Y to the HR site.”)
  • Impact Assessment: Who will notice this, and what will they see? (e.g., “Users will see a new drop-down menu in Word. No downtime is expected.”)
  • Testing Plan: How did you validate this? (e.g., “Successfully deployed to the Dev tenant on Tuesday; UAT signed off by the HR Lead.”)
  • Rollback/Back-out Plan (Crucial): Never submit a change without a way to undo it. (e.g., “If the sync fails, we will disable the new Entra Connect Synchronization rule and trigger a delta sync to revert to the previous state.”)

4. Deflecting Service Requests vs. Consultancy

Guard your time strictly. Do not accept operational ‘Service Requests’ disguised as project consultancy.

  • Service Requests: Routine, user-initiated requests for something provided by IT. (e.g., “Please add John to the Finance Teams channel,” or “Assign a Visio Plan 2 license to Sarah.”)
  • The Pushback: Generally a Consultant should not be executing Service Requests. If these land on your desk without a reason justifiably within your agreement’s scope, politely redirect them to the Helpdesk or Tier 1 Ops, noting that executing routine requests detracts from the strategic architectural work you were brought in to deliver.

5. Release Management in an Evergreen World

M365 does not wait for traditional ITIL release cycles; it is continually updating.

  • Message Center Triage: You cannot apply heavy ITIL Change Management to every minor Microsoft update. Establish a weekly rhythm to review the M365 Message Center.
  • Assess vs. Inform: Differentiate between Microsoft updates that require configuration (Assess) and those that just change the UI (Inform). Ensure the Service Desk is briefed on UI changes so they aren’t flooded with false “Incidents” when a button moves in Outlook.