Change Management Standard

Change Management Standard

Role note: The CISO role is currently pending formal appointment. Until then, the CTO acts as interim CISO for change approvals that carry security weight.

1. Purpose

Implements the Change Management Policy (POL-003). Describes the concrete 8-stage process every change follows — from initial feedback through deployment and post-implementation review — plus the tooling, cadence, and emergency / scope-change procedures.

2. Process Flow

flowchart TD
    A[Partner Feedback / Business Need] --> B[Business Team Analysis]
    B --> C[Requirement Shared with Product Manager]
    C --> D[PM Collaborates with CEO/CTO]
    D --> E[Requirement Document Created]
    E --> F{Design Required?}
    F -->|Yes| G[Design Team → Figma]
    G --> H[Design Review & Approval]
    H --> I[Stakeholder Review]
    F -->|No| I[Stakeholder Review]
    I --> J[Planning & Resource Allocation]
    J --> K[Planning Frozen]
    K --> L[Development Begins — Plane tasks]
    L --> M[Weekly Sprint Cycle]
    M --> N[Sprint Review & Demo]
    N --> O{Feature complete?}
    O -->|No| M
    O -->|Yes| P[QA & Testing]
    P --> Q[Deployment & Release]
    Q --> R[Post-Implementation Review]

3. Stage 1 — Requirement Intake

Responsible: Business team (Operations / Support / Tech)

Feedback sources: partner feedback, business analysis, customer support tickets, compliance-driven changes, market analysis.

Outputs: initial requirement summary, business impact estimate, stakeholder list.

4. Stage 2 — Requirement Documentation

Responsible: Product Manager (with CEO / CTO)

4.1 Review with leadership

PM reviews the requirement against product strategy; CEO / CTO weigh in on business alignment, technical feasibility, and architectural implications.

4.2 Design collaboration (when applicable)

For UI / UX changes:

• Design team consulted at requirement stage
• Figma mockups + prototypes created
• Design system alignment verified
• Figma links attached to the requirement document

4.3 Requirement document contents

1. Executive summary — business need, success metrics, timeline
2. Functional & non-functional requirements — user stories, acceptance criteria, performance / security / compliance constraints
3. Design references — Figma links, design system components, responsive breakpoints
4. Implementation plan — architecture, phases, milestones, risk / mitigation
5. Testing strategy — unit, integration, UAT, performance, security, rollback
6. Deployment plan — rollout strategy (phased / full), monitoring, success metrics, comms, docs

5. Stage 3 — Review and Approval

5.1 Reviewers

5.2 Approval workflow

1. Document distributed to reviewers
2. 5-business-day review window
3. Review meeting to resolve feedback
4. Document revised
5. Formal approval recorded

Approval authorities — see the Change Management Policy §4 (POL-003).

6. Stage 4 — Planning and Resource Allocation

6.1 Development planning

• Break requirements into engineering tasks
• Estimate effort and timeline
• Assign teams (Backend, Frontend, Mobile, DevOps)
• Identify external dependencies and infrastructure needs

6.2 Planning freeze

Once approved:

• Requirement document marked final
• Scope and timeline locked
• Further changes go through the Scope Change procedure (§12)
• Teams and stakeholders notified

7. Stage 5 — Development Implementation

7.1 Task management in Plane

Wealthy uses two Plane projects for traceability:

7.2 Task creation flow

1. PM creates high-level feature in Roadmap Project
2. PM discusses with CEO/CTO — business alignment + technical approach + resources
3. PM discusses with engineering — detailed technical scope
4. Design integration (if UI/UX) — Figma links added to Roadmap feature + requirement doc + Engineering Board tasks
5. Engineering teams break feature into tasks in Engineering Board
6. All Engineering Board tasks link to the parent Roadmap feature — aggregated progress rolls up

8. Stage 6 — Sprint Cadence

Sprint duration: 1 week

8.1 Sprint Planning (every Monday)

• Participants: PM, Engineering Teams, QA
• Duration: ≤ 2 hours
• Agenda:
  • Previous sprint review (accomplishments from Engineering Board)
  • Current sprint status and blockers
  • Upcoming sprint tasks and priorities
  • Roadmap update
  • Dependencies and resource needs

8.2 Sprint Execution

• Daily coordination via Slack + ad-hoc meetings
• Real-time task updates in Engineering Board
• Feature progress auto-rolls-up to Roadmap Project
• Blockers escalated immediately to PM

8.3 Sprint Review

• Completed features demo-ready
• Sprint completion rate tracked in Engineering Board
• Roadmap updated
• Outstanding items re-prioritised into next sprint

9. Stage 7 — Quality Assurance and Testing

9.1 Development testing

• Unit tests, integration tests, code review (peer)

9.2 QA testing

• Functional, UAT (business validation), performance, regression

9.3 Compliance testing

• Regulatory, security, data privacy validation (where relevant)

10. Stage 8 — Deployment and Release

10.1 Deployment

• Dev environment for final validation
• Production via CI/CD pipeline (ArgoCD GitOps)
• Real-time monitoring of performance and error rates
• Documented rollback capability

10.2 Release communication

• Internal teams notified
• Partners informed
• Customer-facing comms (where applicable)
• Documentation updated

11. Stage 9 — Post-Implementation Review

11.1 Success metrics

• Business metrics vs target
• Technical metrics (performance, reliability)
• User adoption / usage
• Partner satisfaction

11.2 Lessons learned

• Process review
• Team retrospective
• Procedure updates where improvement identified
• Best practices shared

12. Scope Change Procedure

For changes to an already-approved requirement:

1. Change Request document created (what, why, impact)
2. Impact assessment — schedule, resources, budget
3. Re-approval from affected stakeholders per §5.1 (same reviewers as original change)
4. Project timeline and milestones updated
5. Communication to all affected teams

13. Emergency Change Procedure

For production outage, security incident, regulatory deadline:

1. Escalation: CTO (interim CISO) + PM notified directly
2. Authorization: CTO authorises implementation
3. Log: Change record created in tracking system immediately (may be concurrent with fix)
4. Risk assessment: brief impact + rollback documented
5. Resource reallocation: temporary reallocation from other projects as needed
6. Post-hoc ratification: within 5 business days — full retrospective documentation and ISRMC awareness
7. Frequency monitoring: emergency-change rate reviewed quarterly at ISRMC — excessive use = finding

14. Tools and Systems

15. Metrics

Reported quarterly to ISRMC:

16. Related Documents

• Change Management Policy (POL-003) — parent policy
• Exception Management Policy (POL-013) — when an exception is needed
• Incident Response SOP (SOP-004) — security incidents that trigger emergency changes
• Incident Management SOP (SOP-003) — operational incidents
• Log Management Standard (STD-012) — change-record retention

Reviewed quarterly. Last revision: April 2026. Contact: security@wealthy.in.