⌘K
Proposal Demo
Core Workflows

Change Request Workflow

1. Objective

The change request workflow controls changes made after a requirement version has been approved.

Key principle: TeamFlow does not prevent requirement changes. It ensures that each change is documented, assessed, approved, planned, implemented, tested, and closed.

2. Change Request Lifecycle

Primary states:

DRAFT
  ↓
SUBMITTED
  ↓
IMPACT_ANALYSIS_REQUIRED
  ↓
UNDER_REVIEW
  ↓
APPROVED
  ↓
PLANNED
  ↓
IN_IMPLEMENTATION
  ↓
IMPLEMENTED
  ↓
QA_VERIFIED
  ↓
CLOSED

Alternative states: CHANGES_REQUESTED, DEFERRED, REJECTED, CANCELLED

3. Change Request Creation

A change request must reference:

  • Project, requirement, current approved requirement version
  • Requested change description
  • Business reason, requested by, requested date
  • Urgency, consequence of not implementing
  • Desired release or date
  • Initial affected modules

Important: The original approved requirement version remains unchanged.

4. Submission Validation

Before submission, the system validates:

  • A current approved version exists
  • The requested change is described
  • A business reason is supplied
  • The requester is authorized
  • The request is not a duplicate of an open change request

5. Impact Analysis

The system assigns impact sections to relevant roles:

5.1 Business Impact (BA/Product Owner)

  • Business value, user impact, compliance impact
  • Operational impact, urgency
  • Consequence of rejection, affected business process

5.2 Project Impact (PM)

  • Affected sprint, milestone, release
  • Timeline impact, resource impact
  • Dependency impact, delivery recommendation

5.3 Technical Impact (Technical Lead/Developer)

  • Frontend, backend, database, integration effort
  • Architecture impact, migration requirement
  • Security and performance impact, technical risk
  • Rework effort estimation

5.4 QA Impact (QA)

  • New test cases required
  • Existing test cases requiring review
  • Regression scope, test data impact
  • Environment and automation impact, QA effort
  • Quality risk assessment

6. Risk Classification

Risk levels: LOW, MEDIUM, HIGH, CRITICAL

Risk factors include:

  • Production data migration
  • Security changes
  • External integration impact
  • Regulatory impact
  • Release deadline proximity
  • Large regression scope
  • Architecture changes
  • Cross-project dependencies

7. Review and Approval

Reviewers may:

  • Approve
  • Reject with mandatory reason
  • Request more information
  • Request revised estimates
  • Defer to a later release
  • Split into multiple requests
  • Escalate for management approval

Approval Levels (Example)

  • Low impact: PM + Technical Lead
  • Medium impact: PM + Technical Lead + QA Lead
  • High impact: CTO approval required
  • Critical: CTO and Management approval required

Separation of Duties: The requester must not provide the final approval when separation of duties applies.

8. Approval Results

Approved for Current Sprint

The system:

  • Creates a new draft requirement version
  • Copies the previous approved version
  • Applies the accepted change proposal
  • Links the new version to the change request
  • Marks affected tasks and tests for review
  • Updates planning information
  • Records approval history

Approved for Future Release

The change request becomes DEFERRED or PLANNED for the selected release.

Rejected

The original approved requirement remains active. Rejection reason is mandatory.

9. Affected Work Handling

When a change is approved:

  • Completed tasks may become IMPACT_REVIEW_REQUIRED
  • In-progress tasks receive a change notification
  • Linked test cases become REVIEW_REQUIRED
  • Planned release readiness is recalculated
  • Related defects remain attached to the correct version
  • New tasks may be created
  • Existing estimates remain historically visible

10. Implementation and Closure

A change request may close when:

  • New requirement version is approved
  • Implementation is complete
  • QA verification is complete
  • BA acceptance is complete where required
  • Release assignment is confirmed
  • Final impact metrics are recorded

11. Key Metrics

The system calculates:

  • Number of post-approval changes by project and source
  • Rework time and QA retesting time
  • Average approval and impact-analysis time
  • Changes deferred or rejected
  • Tasks reopened, test cases requiring review
  • Delivery days affected

Note: Metrics should be used to improve process, not create personal harassment rankings.

Next: Review Functional Requirements →