antifragile/antifragile-consulting/core/quality-management-engagement.md

Embedded Quality & Process Assurance

"You do not need another audit. You need someone to sit with your team, watch them work, and help them fix the friction that slows them down and creates vulnerabilities."

This document defines an engagement model for clients who feel they are not truly in control of their projects, teams, or operations. It is not an audit. It is not a penetration test. It is embedded process assurance: an experienced advisor joins the team, observes the reality of daily work, identifies the gaps between intent and execution, and co-creates improvements that stick.

It is designed for Heads of Security and Heads of Operations who have tools, policies, and headcount—but still feel that something is slipping through the cracks.

---

The "Not in Control" Posture

What They Actually Mean

When a Head of Security or Head of Operations says "we don't believe we are truly in control of what we have / what we are doing," they are usually describing one or more of these conditions:

Symptom	What Is Actually Happening
"We have policies but nobody follows them"	Process-theater: documents exist, behaviour is unchanged
"We bought tools but they are not configured"	Shelfware: purchased capability, never operationalized
"I find out about changes after they happen"	Visibility gap: no governance gates, no change notification
"The same incident keeps happening"	Learning failure: post-mortems are written, nothing structural changes
"My team is busy but I cannot tell you what they achieved"	Activity without outcomes: metrics measure effort, not risk reduction
"We have a project plan but it does not match reality"	Planning fantasy: Gantt charts assume perfect conditions; reality is messier
"I do not trust our own documentation"	Drift: systems were documented once; they have changed dozens of times since

The insight: These leaders do not need more tools. They need someone to help them see what is actually happening and someone to help them fix it in the context of real work.

---

What This Is Not

Traditional Approach	Embedded Quality Assurance
Audit (arrives, checks boxes, leaves a report)	Presence (stays, observes work, fixes friction in real time)
External assessment (interviews, surveys, sampling)	Embedded observation (attends standups, watches deployments, reads actual tickets)
Recommendations (list of things to do, no help doing them)	Co-implementation (suggests improvement, helps implement it, validates it works)
Quarterly review (one meeting, static snapshot)	Continuous calibration (weekly check-ins, daily Slack/Teams presence, adaptive focus)
Generalist consultant (knows frameworks, not your stack)	Practitioner-advisor (knows M365, Azure, Defender, Intune, and how teams actually use them)

---

The Engagement Model

Phase 1: Immersion (Week 1-2)

Objective: Understand the reality of how work happens—not how it is documented.

Activities:

• Attend team standups, sprint planning, retrospectives (for agile teams)
• Attend change advisory board, incident review, capacity planning (for operations teams)
• Shadow key personnel: senior engineer, security analyst, ops lead, project manager
• Review actual work artifacts: recent tickets, pull requests, incident post-mortems, change records
• Observe tool usage: how they actually use Intune, Sentinel, Defender, Azure AD—not how the manual says they should
• Map the formal process (documented) against the informal process (actual)

Deliverable: Immersion Report

• Formal vs. actual process map
• Top 5 friction points (not failures—friction)
• Top 3 "invisible risks" (things that are not tracked but should be)
• Team sentiment: what do they believe is broken that leadership does not see?

The conversation at Week 2:

"Your policy says all changes require CAB approval. In reality, 60% of Azure policy changes happen via direct portal access by two senior engineers who document them after the fact. That is not non-compliance. That is a signal that your CAB process is too slow for operational reality. We fix the process, not the people."

---

Phase 2: Friction Reduction (Week 3-6)

Objective: Fix the highest-friction gaps that create both inefficiency and vulnerability.

Activities:

• Implement fast wins that reduce daily pain:
  • Automate a manual provisioning step
  • Create a runbook for a recurring but undocumented task
  • Simplify a approval workflow that takes 3 days and 4 people
  • Standardize a configuration that is currently done differently on every deployment
• Introduce guardrails, not gates:
  • Replace pre-deployment security review with automated scanning in CI/CD
  • Replace quarterly access review with monthly automated report + exception tracking
  • Replace post-incident blame with blameless post-mortem with structural mandate
• Build visibility where there is blindness:
  • Dashboard showing actual vs. planned changes
  • Alert when configuration drifts from baseline
  • Weekly "what changed" report for leadership

Deliverable: Friction Reduction Report

• Before/after metrics: time saved, errors reduced, visibility gained
• Implemented improvements with ownership and maintenance plan
• Remaining friction points for next phase

---

Phase 3: Capability Building (Week 7-10)

Objective: Ensure the team can sustain and extend improvements without permanent consultant dependency.

Activities:

• Knowledge transfer sessions: Teach the team why each improvement was made, not just how it works
• Documentation-as-code: Move runbooks and procedures into version-controlled, executable formats where possible
• Metrics definition: Help the team define their own success metrics (not consultant-imposed ones)
• Self-assessment tools: Give the team checklists and templates to continue the work
• Mentoring: Pair junior team members with consultant for specific skills (KQL query writing, Intune policy authoring, incident response triage)

Deliverable: Capability Handover Package

• Team-owned process documentation
• Self-assessment checklist
• Metrics dashboard maintained by the team
• 90-day improvement roadmap drafted by the team (not the consultant)

---

Phase 4: Validation (Week 11-12)

Objective: Prove that the team is now in control—and that the consultant can leave.

Activities:

• Consultant steps back to advisory-only presence
• Team runs a week independently; consultant observes from distance
• Validation exercise: team handles a simulated incident, change, or deployment without consultant help
• Retrospective: what worked, what still needs work, what the team will tackle next

Deliverable: Validation Report

• Independent operation confirmation
• Remaining gaps (honest assessment)
• Recommended next module or engagement type

---

Application Contexts

Context 1: M365 Project Team

Profile: Client is deploying M365 (greenfield or migration); project is behind schedule; team is overwhelmed; quality is slipping.

Embedded assurance activities:

• Observe provisioning workflow: are users created consistently? Are licenses assigned correctly? Are permissions documented?
• Observe change control: is every tenant change tracked? Is there rollback capability?
• Observe communication: does the project team know what the security team needs? Does security know what the project team is changing?
• Implement: standard user provisioning template, automated license reconciliation, change log in shared channel

The pitch:

"Your M365 project is not failing because your team is incompetent. It is failing because the gap between what they know and what they are expected to deliver is too wide. I join the team for 12 weeks, help them close that gap, and leave them with processes they can sustain."

Context 2: Security Operations Team

Profile: SOC or security team has tools but no rhythm; alerts are ignored; incidents are reactive; burnout is high.

Embedded assurance activities:

• Observe alert triage: which alerts are ignored? Why? (False positive? No runbook? No authority to act?)
• Observe incident response: who is called? When? How is information shared? Where does the process stall?
• Observe shift handoffs: what is lost between shifts?
• Implement: alert tuning playbook, tier-1 triage runbook, automated enrichment, shift handoff template

The pitch:

"Your security team is drowning in noise. They do not need another SIEM. They need someone to help them turn that noise into signal, build repeatable processes, and regain the confidence that they are seeing what matters. I sit with them, watch their shifts, and help them build a rhythm."

Context 3: Infrastructure / Operations Team

Profile: Ops team maintains critical systems; changes are ad-hoc; documentation is stale; knowledge is concentrated in one or two people.

Embedded assurance activities:

• Observe change execution: how is a firewall rule added? A DNS record changed? A certificate renewed?
• Observe monitoring: what is watched? What is not? Who responds to alerts at 2 AM?
• Observe documentation: is it accurate? Do people use it? When was it last updated?
• Implement: change automation for high-frequency tasks, monitoring dashboard, living documentation process, cross-training plan

The pitch:

"Your ops team knows the systems better than anyone—but that knowledge lives in their heads. If one person leaves, the organization loses critical capability. I help them externalize that knowledge into repeatable, documented, automatable processes. The team becomes stronger, not more dependent."

Context 4: Development Team

Profile: Dev team ships code but security is a bottleneck; vulnerabilities found late; releases are stressful.

Embedded assurance activities:

• Observe the "security moment": when does security enter the conversation? Day 1 or day 45?
• Observe the deployment pipeline: what checks exist? Which are bypassed? Why?
• Observe the feedback loop: when a vulnerability is found, how long until it is fixed? What prevents faster resolution?
• Implement: security checks in IDE, automated SAST in CI/CD, vulnerability prioritization aligned with business impact, shared metrics

The pitch:

"Your developers want to ship secure code. Your security team wants to prevent breaches. Both are frustrated because they work in separate rooms with separate metrics. I embed with the dev team for 12 weeks, make security part of their daily workflow instead of a quarterly gate, and prove that speed and security are complements—not trade-offs."

---

Talking Points for the Head of Security / Head of Operations

When they say: "We don't believe we are truly in control of what we have."

You respond:

"That feeling is usually accurate—and it is not a tool problem. It is a visibility and process problem. You have capable people, but the gap between what is documented and what is actually happening has grown too wide. I do not audit you. I join your team, observe the reality, and help you close that gap. In 12 weeks, you will have repeatable processes, accurate documentation, and a team that trusts its own capability."

When they say: "We have tried consultants before and nothing changed."

You respond:

"Most consultants deliver a report and leave. I deliver presence. I attend your standups, read your tickets, and help fix things while I am there. The difference is not the findings—it is the implementation. You will see changes in the first two weeks, not in a final deck."

When they say: "We don't have budget for a long engagement."

You respond:

"This is 12 weeks, fixed scope. But the first deliverable—the immersion report—is available in Week 2. If you do not see value by then, we stop. Most clients see enough value in the first two weeks to justify the full engagement."

When they say: "My team will feel judged if someone is watching them."

You respond:

"I am not there to evaluate individuals. I am there to evaluate the system: the processes, the tools, the handoffs, the invisible workarounds. Every team has workarounds—they exist because the formal process does not match reality. My job is to make the formal process match reality, not to shame anyone for adapting."

---

Metrics That Prove Control

Before	After	What It Measures
"We think our config is standard"	"We can show the drift from baseline in real time"	Visibility
"Changes happen, we find out later"	"Every change is logged, notified, and rollback-ready"	Control
"The same alert fires 50 times a day"	"We tuned the alert; it now fires 3 times, and each is actionable"	Signal quality
"Incidents take 4 hours to escalate"	"Incidents auto-enrich and route in 15 minutes"	Response speed
"Two people know how to do X"	"Anyone on the team can do X from the runbook"	Resilience
"We have 20 open critical vulnerabilities"	"We have 3; the other 17 were false positives or already mitigated"	Accuracy
"I do not know what the team did this week"	"I can see risk reduction, process improvement, and blockers"	Transparency

---

Integration With Modular Engagements

This module sits naturally between technical hardening and organizational transformation:

Module 1 (Endpoint Management) or Module 3 (M365 Hardening)
              ↓ Reveals process gaps the tools cannot fix
Module 11 (Embedded Quality & Process Assurance)
              ↓ Builds team capability to sustain improvements
Module 9 (Organizational Resilience) or Module 12 (Blue/Purple Team Foundation)
              ↓ Scales the capability across the organization

It can also precede technical work:

Module 11 (Embedded Quality & Process Assurance)
              ↓ Discovers that tools are misconfigured because processes are broken
Module 2 (Identity Security) or Module 3 (M365 Hardening)
              ↓ Technical fixes now stick because processes support them

---

For the modular engagement menu, see Modular Engagements. For organizational structure transformation, see Organizational Resilience. For blue/purple team capability building, see Blue/Purple Team Foundation.