Engagement Lifecycle Manager

Great technology fails
without great execution.

The project management wrapper around every Raksha deployment — from first handshake to steady-state operations. Six phases, zero ambiguity, complete accountability.

⚙ Companion Tool: Zero-Touch Deployment Framework →
The Journey

Six Phases, One Goal: Flawless Delivery

Every Raksha engagement follows this lifecycle. Each phase has clear deliverables, quality gates, and handoff criteria. No phase begins until the previous gate is cleared.

Phase 1
Initiation
Phase 2
Planning
Phase 3
Pre-Config
Phase 4
Deployment
Phase 5
Hypercare
Phase 6
Steady-State

Two tools, one methodology

📋
This Tool
The project management wrapper — who does what, when, and how the engagement is governed.
Deployment Framework
The technical playbook — what data to gather, what to configure, what to integrate.
🤝
Together
Complete delivery methodology — no gaps between project management and engineering execution.
Phase 1

Initiation & Kickoff

The foundation. Get stakeholder alignment, set expectations, define scope, assign resources, and establish governance before a single config line is written.

✅ Pre-Kickoff Checklist — Before You Schedule the Meeting

Purchase Order / Contract Signed
Confirm PO number, contract terms, SLA commitments, payment milestones, and warranty start date.
Gate Requirement
Scope of Work (SOW) Reviewed & Signed
Detailed SOW with inclusions, exclusions, assumptions, deliverables, timelines, and acceptance criteria. Both parties sign.
Gate Requirement
Delivery Manager Assigned (Raksha)
Single point of accountability from Raksha. This person owns the engagement end-to-end.
Raksha
Technical Lead Assigned (Raksha)
The architect/engineer who will own the technical design and zero-touch configuration.
Raksha
Client SPOC Identified
Client's single point of contact for day-to-day coordination. Should have authority to make operational decisions.
Client
Client Stakeholder List Collected
CISO, CTO/IT Head, Network Admin, Security Admin, Compliance Officer, Server Admin — names, roles, emails, phone numbers.
Client
Procurement Lead Time Confirmed
Expected hardware delivery date. This determines how much pre-configuration time is available.
Timeline Critical
NDA / Confidentiality Agreement
If not already covered in MSA — sign before any technical data exchange. Protects both parties.
Gate Requirement
Communication Channels Established
Shared email DL, Teams/Slack channel, shared drive/folder for project docs, ticketing queue if applicable.
Kickoff Meeting Scheduled
Send calendar invite to all stakeholders. Attach agenda (see below). Allow 90 minutes. Book conf room + bridge.
Within 3 days of PO

📅 Kickoff Meeting Agenda — 90 Minutes

0:00–0:10
Welcome & Introductions
Both teams introduce themselves — name, role, and what they're responsible for in this engagement. Set the tone: this is a partnership, not a vendor-client transaction.
Owner: Delivery Manager
0:10–0:25
Scope & Objectives Walkthrough
Review the SOW together. Confirm what's in scope, what's out. Align on success criteria — what does "done" look like? Clarify any assumptions that may have changed since proposal.
Owner: Delivery Manager + Client SPOC
0:25–0:40
Architecture Overview & Solution Design
Technical lead presents the solution architecture. Topology diagram, product placement, integration points, HA design. Confirm this matches what was proposed.
Owner: Technical Lead
0:40–0:55
Deployment Methodology & Timeline
Present the Zero-Touch approach. Explain parallel processing during procurement wait. Walk through the 6-phase lifecycle. Share milestone dates. Highlight client dependencies — data they need to provide and by when.
Owner: Delivery Manager
0:55–1:05
Roles, Responsibilities & RACI
Walk through the RACI matrix. Ensure every stakeholder knows what they own, what they're consulted on, and what they'll be informed about. Avoid the "I thought you were doing that" moment later.
Owner: Delivery Manager
1:05–1:15
Governance & Communication Plan
Weekly status cadence, escalation matrix, change request process, risk reporting. Agree on tools (email, Teams, shared drive). Set recurring meeting slots.
Owner: Delivery Manager
1:15–1:25
Risks & Dependencies
Present known risks. Identify client dependencies (data, access, approvals). Discuss constraints (maintenance windows, blackout periods, compliance deadlines). Log all action items.
Owner: Technical Lead + Client IT Head
1:25–1:30
Immediate Next Steps & Action Items
Summarise every action item with owner and due date. Confirm next meeting date. Share Forward Integration data request with client team. Start the clock.
Owner: Delivery Manager

📨 Post-Kickoff Actions — Within 24 Hours

Send Meeting Minutes (MOM)
Documented decisions, action items with owners + deadlines, parking lot items. Send to all attendees + stakeholders who couldn't attend.
Share Forward Integration Data Request
Use the Deployment Framework's Forward Integration Checklist. Send as a structured form/document — not a casual email. Set deadline: 5 business days.
Set Up Shared Project Workspace
Create shared folder structure: /01-Contract, /02-Architecture, /03-Data-Collection, /04-Configs, /05-Runbooks, /06-Reports, /07-Handover
Schedule Recurring Status Meetings
Weekly 30-min status call. Same day/time every week. Calendar invite to all RACI stakeholders.
Create Project Tracker
Gantt chart or Kanban board with all phases, milestones, dependencies. Tools: Excel, MS Project, Asana, Jira — whatever the client prefers.
Log Initial Risk Register
Capture all risks identified in kickoff. Assign owners. Set review cadence. See Risk Register section below.
Phase 2

Planning & Resource Allocation

Detailed project plan, resource mapping, dependency tracking, and quality gates. This phase runs parallel with data gathering from the Forward Integration checklist.

👥 Resource Planning Matrix

Map every role needed across the engagement. Identify resource gaps early — finding a certified engineer 2 days before deployment is not a plan.

🔵
Raksha Team
Internal resource allocation
Delivery Manager / Project Manager
Effort: 15-20% through engagement. Owns timeline, status reporting, escalations, client communication.
Solution Architect
Effort: 30-40% during design/pre-config, 10% during deployment. Owns technical design, config review, best practices.
Implementation Engineer
Effort: 60-80% during pre-config, 100% during deployment. Hands-on-keyboard for configs, testing, deployment.
QA / Peer Reviewer
Effort: 10-15% spot checks. Independent config review before golden config export. Second pair of eyes.
Support Engineer (Post-Deploy)
Effort: 20-30% during hypercare. Handles Day 2 issues, fine-tuning, log validation, performance optimization.
🟢
Client Team
Client-side resource requirements
Project SPOC / IT Manager
Effort: 15-20%. Coordinates internal teams, provides data, arranges access, drives internal approvals.
Network Administrator
Effort: 20-30% during data gathering + deployment. Provides network data, assists with VLAN/routing changes, switch configurations.
Security Administrator
Effort: 20% during policy review. Validates security policies, reviews firewall rules, approves access controls.
Server / Infra Administrator
Effort: 10-15%. Provides server details, assists with agent deployment, configures log forwarding from servers.
Change Management Approver
Effort: 5%. Reviews and approves change requests for CAB. Must be available for emergency approvals during go-live.
Site Engineer (for on-prem)
Effort: 100% during deployment day. Handles racking, cabling, power. Follows the deployment runbook. May be a junior resource.

📊 RACI Matrix — Who Does What

R = Responsible (does the work)   A = Accountable (owns the outcome)   C = Consulted   I = Informed

Activity Raksha DM Raksha Tech Client SPOC Client Net Admin Client CISO Vendor/OEM
Project Planning & TimelineA/RCRIII
Forward Integration Data GatheringARRRCI
Solution Architecture DesignIA/RCCCC
Lab Configuration & TestingIA/RIIIC
Config Peer Review & QAARIIII
Change Request SubmissionRCACAI
Hardware Racking & CablingICARII
Config Import & CutoverARCRIC
Backward Integration (SIEM, Ticketing)IA/RCRII
UAT / Sign-OffRCARAI
Knowledge Transfer & TrainingARRRIC
Hypercare SupportARCCIC
Project Closure & HandoverA/RRAIAI

🏁 Milestone & Quality Gate Tracker

Every milestone has a quality gate — a deliverable or sign-off that must be completed before moving forward. No shortcuts.

PhaseMilestoneQuality GateOwnerTypical Week
P1Kickoff CompleteMOM distributed, action items logged, recurring meetings scheduledDelivery ManagerWeek 0
P2Data Collection CompleteGATE All Forward Integration data received and validatedTech Lead + Client SPOCWeek 1-2
P2Architecture Sign-OffGATE Solution design document approved by Client CISO/CTOTech LeadWeek 2
P3Lab Config CompleteAll policies, rules, integrations built and documented in labImpl. EngineerWeek 3-5
P3Config Peer Review PassedGATE Independent review completed, all findings resolvedQA / ArchitectWeek 5-6
P3Golden Config ExportedConfig + firmware + certs + runbook packaged in deployment kitImpl. EngineerWeek 6
P3Change Request ApprovedGATE CAB approval for production deployment with rollback planDM + Client SPOCWeek 7
P4Hardware Racked & PoweredPhysical installation verified, management access confirmedClient Net AdminWeek 8
P4Config Imported & VerifiedGolden config loaded, basic connectivity tests passImpl. EngineerWeek 8
P4Production CutoverGATE Live traffic flowing, no critical issues for 4 hoursTech LeadWeek 8-9
P4Backward Integrations LiveSIEM logs flowing, ticketing connected, monitoring activeImpl. EngineerWeek 9
P5UAT Sign-OffGATE Client confirms all scope items functional, acceptance document signedClient CISO + DMWeek 10
P5Knowledge Transfer CompleteTraining sessions delivered, runbook handed over, L1/L2 team certifiedTech LeadWeek 10-11
P530-Day Hypercare EndsGATE No open P1/P2 issues, performance baselines stable, client self-sufficientDM + Support EngWeek 12
P6Project ClosureClosure report, lessons learned, warranty/AMC handover, project archivedDelivery ManagerWeek 13
Phase 3   Phase 4

Pre-Configuration & Deployment

This is where the Deployment Framework takes over. The technical playbook drives the work — this tool tracks the project governance around it.

Handoff to Deployment Framework
Phases 3 & 4 are driven by the technical playbook

The detailed checklists for data gathering, lab configuration, config export/import, and forward/backward integrations live in the Deployment Framework. During these phases, the Engagement Lifecycle Manager tracks:

Weekly status reports to stakeholders
Risk register updates
Dependency tracking (client data, approvals)
Change request submissions to CAB
Milestone sign-offs at each quality gate
Resource availability confirmation for go-live
Go-live readiness review (checklist below)
War-room setup for cutover day

🚀 Go-Live Readiness Review — The Final Gate Before Cutover

This review happens 2-3 days before scheduled cutover. All items must be green. If any item is red, delay the cutover — it's always cheaper to reschedule than to recover from a failed deployment.

Golden config tested and exported
Config validated in lab, peer-reviewed, exported, and stored in deployment kit
Must be Green
Hardware delivered and verified
Correct model, correct license tier, serial numbers match PO, firmware version verified
Must be Green
Change request approved by CAB
Approved for specific date/time window with documented rollback plan
Must be Green
Rollback plan documented and tested
Exact steps to revert if cutover fails. Rollback criteria defined (what triggers a rollback decision).
Must be Green
Deployment runbook reviewed by all parties
Step-by-step guide shared with site engineer, network admin, and tech lead. No ambiguity.
Rack space, power, and cables confirmed
Physical readiness at site — U-space allocated, power outlets available, cables procured and tested.
All team members confirmed availability
Raksha tech lead, client net admin, site engineer — all confirmed for cutover window. Phone numbers exchanged.
War-room / bridge line set up
Conference bridge or Teams meeting for real-time coordination during cutover. All stakeholders have the link.
Communication sent to affected users
Email to all users about maintenance window, expected downtime, who to contact for issues.
Vendor TAC case pre-opened (if available)
Some vendors allow pre-opening a support case for go-live support. Priority escalation path confirmed.
Post-cutover verification checklist prepared
List of tests to run after config import: connectivity, HA failover, log forwarding, rule hits, performance baseline.
Phase 5   Phase 6

Hypercare, Handover & Closure

The engagement doesn't end at go-live — it ends when the client is self-sufficient and the investment is delivering measurable value.

🩺
Hypercare Period (30 Days)
Intensive support post go-live
Daily health check for first 7 days
CPU, memory, sessions, logs flowing, no errors, HA state normal, no false positives blocking business
Policy fine-tuning based on live traffic
Adjust rules that are too strict/loose, tune IPS signatures, whitelist legitimate false positives
Weekly hypercare status reports
Issues found, issues resolved, pending items, performance trends, recommendations
P1/P2 issue response within SLA
Track all issues with severity, response time, resolution time. Log in ticketing system.
Performance baseline established
Document normal operating parameters — CPU baseline, session counts, traffic patterns, log volume. Deviations from this are investigated.
📦
Knowledge Transfer & Handover
Making the client self-sufficient
Admin training delivered
Hands-on training for client's L1/L2/L3 teams. Cover daily operations, common tasks, troubleshooting. Record the session.
Operational runbook delivered
Day-to-day operations guide: how to check health, add rules, review logs, handle common issues, reboot procedure, backup restore.
Vendor support handover
TAC contact details, support portal credentials, how to raise cases, entitlement ID, SLA terms, escalation path.
Credential handover via vault
All admin credentials transferred securely — via password vault entry, not email. Client changes passwords immediately.
As-built documentation package
Final architecture diagram, IP allocations, rule logic documentation, config backup locations, license details, warranty info.

📋 Project Closure Checklist

UAT Acceptance Document Signed
Client confirms all scope items delivered and functional. Formal sign-off from CISO/CTO and project SPOC.
Required for Closure
All P1/P2 Issues Resolved
No open critical or high-severity issues. Any remaining P3/P4 items transferred to BAU support with documented plan.
Required for Closure
Knowledge Transfer Confirmed
Client team confirms they are capable of Day 2 operations. Training attendance recorded.
Lessons Learned Session Conducted
30-minute retrospective: what went well, what to improve, client feedback. Document for internal knowledge base.
Project Archive Created
All project documents, configs, runbooks, meeting minutes, emails archived in structured folder. Accessible for future reference.
AMC/Warranty Handover to Support Team
Warranty start/end dates, AMC terms, renewal dates, support team contact. Set calendar reminders for 60 days before expiry.
Customer Satisfaction Survey Sent
Short survey to key stakeholders: delivery quality, communication, technical competence, overall satisfaction, NPS.
30/60/90-Day Health Check Scheduled
Post-closure check-ins to ensure everything remains stable. Brief call with client SPOC. Proactive, not reactive.
Risk Management

Common Risk Register

Risks that appear in nearly every cybersecurity deployment. Start with these, then add project-specific risks during kickoff and throughout the engagement.

Client Data Delays
High
Client fails to provide Forward Integration data (IPs, VLANs, policies) on time, blocking pre-configuration.
Mitigation: Set hard deadline at kickoff. Escalate to CISO/CTO after 48hrs overdue. Have Delivery Manager call, not email. Track in weekly status.
Scope Creep
High
"Can you also configure X while you're at it?" — uncontrolled scope expansion without corresponding timeline/budget adjustment.
Mitigation: Formal change request process. Any out-of-scope item requires written CR with effort estimate and timeline impact. Never say yes on a call — always go back to SOW.
Hardware Delivery Delay
Medium
Vendor/distributor delays hardware shipment beyond expected delivery date, compressing deployment timeline.
Mitigation: Zero-touch approach decouples config from hardware. Track PO weekly. Have vendor provide tracking number. Adjust deployment date with 1-week buffer.
CAB Approval Delay
Medium
Change Advisory Board delays approval for production cutover, pushing go-live date.
Mitigation: Submit CR 2 weeks before planned cutover. Pre-align with CAB chair. Include detailed rollback plan to de-risk the approval.
Inaccurate Site Data
High
IP addresses, VLAN IDs, or routing info provided by client is outdated or wrong, causing config failures at site.
Mitigation: Validate all data with a discovery scan or live SSH/SNMP pull. Cross-reference with network diagrams. Never trust a spreadsheet blindly — verify against the actual network.
Key Person Unavailable
Medium
Client's network admin or Raksha's tech lead is unavailable during critical deployment window.
Mitigation: Identify backup for every critical role. Cross-train within team. Confirm availability 1 week before cutover. Have phone numbers, not just emails.
Vendor Licensing Issues
Medium
License activation fails, feature tier doesn't match, or license is bound to wrong serial number.
Mitigation: Verify license details against PO before deployment. Request license keys 1 week early. Test activation in lab if possible. Have vendor TAC pre-opened.
Integration Failures
Medium
Backward integrations (SIEM, ticketing) fail due to version incompatibility, API changes, or missing credentials.
Mitigation: Test all integrations in lab with actual client SIEM/ticketing endpoints. Get API keys and service accounts before deployment. Have manual fallback procedures.
Business Disruption During Cutover
High
Cutover causes unexpected application outage, blocking critical business operations.
Mitigation: Schedule during lowest-traffic window. Test rollback procedure in advance. Keep old device on standby for instant revert. Pre-define rollback trigger criteria (e.g., >15 min outage = rollback).
Governance

Communication Plan

Structured communication eliminates surprises. Every stakeholder knows what to expect, when, and from whom.

Recurring
Weekly Status Report
Frequency: Every Friday by 4 PM
Format: Email with 1-page PDF attachment
Audience: All RACI stakeholders
Owner: Delivery Manager
Content: Progress vs plan, milestones hit, risks/issues, next week plan, blockers, action items
Recurring
Weekly Status Call
Frequency: Same day as report, 30 minutes
Format: Teams/Zoom call with screen share
Audience: DM, Tech Lead, Client SPOC, Client Net Admin
Owner: Delivery Manager
Content: Walk through status report, address blockers, take decisions, log action items
Milestone-Based
Steering Committee Update
Frequency: At each quality gate / monthly
Format: 15-min exec briefing or 1-page summary
Audience: CISO, CTO, Raksha Account Manager
Owner: Delivery Manager
Content: Phase progress, gate status, budget tracking, key decisions needed, escalations
Event-Driven
Go-Live Communication
Frequency: Pre-cutover (48hrs), during cutover, post-cutover
Format: Email + war-room bridge
Audience: All stakeholders + affected end users
Owner: DM (email) + Tech Lead (war-room)
Content: Pre: maintenance window details. During: real-time status. Post: confirmation + issues if any.
Event-Driven
Escalation Communication
Frequency: When risk materialises or blocker exceeds 48hrs
Format: Phone call followed by email documentation
Audience: Next level in escalation matrix
Owner: Whoever identifies the escalation
Content: Issue, impact, what's been tried, what's needed, deadline for resolution
Recurring (Hypercare)
Daily Health Check Report
Frequency: Daily for first 7 days post go-live
Format: Email with dashboard screenshot
Audience: Client SPOC, Net Admin, DM
Owner: Support Engineer
Content: System health, issues found/resolved, performance metrics, recommendations
Escalation Matrix
When and who to escalate to
TriggerTimelineRaksha EscalationClient Escalation
Blocker unresolved > 24hrsDay 1Delivery ManagerClient SPOC
Blocker unresolved > 48hrsDay 2Raksha Practice HeadClient IT Head / CTO
Critical risk materialisesImmediateRaksha Account DirectorClient CISO
Milestone delayed > 1 weekAt 1-week markRaksha Practice HeadClient IT Head
Go-live failure / rollback triggeredImmediateRaksha CTOClient CISO + CTO
Client satisfaction issueAt discoveryRaksha Account DirectorN/A (Raksha-initiated)
Templates

Weekly Status Report Template

A consistent format builds trust. Every weekly report follows this structure — no surprises, no missing information.

Weekly Status Report — [Client Name] — [Product Name]
Week of [Date]  |  Report #[X]  |  Phase: [Current Phase]

Overall Status

🟢 On Track  |  🟡 At Risk  |  🔴 Delayed    [Select one and explain in 1-2 sentences]

Completed This Week

[List 3-5 items completed with brief description]

Planned for Next Week

[List 3-5 items planned with owners]

Risks & Issues

[List any new risks, open issues, or blockers with severity and owner]

Client Dependencies / Action Items

[Items pending from client with due dates — this is where gentle pressure lives]

Key Decisions Needed

[Decisions required from client stakeholders — be specific about who needs to decide what by when]

Raksha Technologies — Cybersecurity Procurement Advisory Platform

Engagement Lifecycle Manager v1.0  |  Companion to Zero-Touch Deployment Framework

Engagement Lifecycle — The project management wrapper for every deployment
⚙ Deployment Framework