- Identify Project Phase
- Check If Request Is in Scope
- Determine Urgency/Priority
- Decide if an Estimate/Change Request is Required
- Check Team Capacity
- Communicate with Client
- Assign Work or Draft Change Request
- Identify Request Details
- What is being asked?
- Is it a new feature, a bug fix, or a change to existing functionality?
- Determine Priority
- Is it a critical/urgent request (e.g., severity 1 or “fire burning” scenario)?
- Is the client on PTO or is there an immediate deadline that affects priority?
- Confirm Project Status
- Which phase is the project currently in?
- Development
- Development with UAT
- UAT Only
- Post-Go-Live (check if an SLA applies)
- Compare to Current BRD/Requirements
- Is it covered by the existing scope/requirements, or is it net new scope?
- Is it a modification of existing functionality or brand-new functionality?
- Net New vs. Modification
- Net New: Requires formal estimate and potential change request.
- Modification to Existing Requirements: Typically also requires change request, with clear outline of scope changes.
- Check Phase-Specific Guidelines
- During Development:
- Almost all new requests (net new or modification) require a change request and estimate.
- Compare against the BRD; if not in scope, it’s a change.
- Development + UAT:
- If the request is simply feedback on something already built, confirm whether it’s in scope or needs adjustment.
- If net new or a significant modification, proceed with estimating and drafting a change request.
- UAT Only:
- Minor tweaks/feedback might be directly assigned, if there is still capacity and the request is within scope.
- Significant changes still require estimates and change requests.
- Post-Go-Live:
- Check if there’s an active SLA or support agreement.
- If covered by SLA, the PM can assign tasks directly based on the SLA terms.
- If out of scope of the SLA, proceed with estimates and approvals.
- Determine If Architecture/Technical Review Is Needed
- If unclear, consult with technical lead (TPP or Dev Manager) to decide if the request needs deeper architecture review or immediate estimate.
- Review Current Team Allocation
- Check the current sprint backlog or task list.
- Identify whether the team has capacity or if re-prioritization is needed.
- Communicate Priorities to the Client
- Outline what the team is currently working on and what’s in the backlog.
- Ask the client to confirm if the new request should displace existing priorities or be queued for the next sprint.
¶ 5. Decide and Communicate Next Steps
- If a Change Request/Estimate Is Required
- Prepare a formal estimate or scope change documentation.
- Obtain client approval before assigning work to the team.
- If the Work Can Be Assigned Directly
- Confirm available hours and developer bandwidth.
- Create a task or user story, add it to the backlog/sprint, and ensure the client is aware of any timeline impacts.
- If Further Triage Is Needed
- Set up an internal chat or schedule time in the next architecture/technical stand-up to clarify scope, technical implications, or approach.
- Revisit Priority and Scope as Needed
- If the request is time-sensitive and escalates to a top priority, re-check resources and timelines.
- Keep a record of all requests that became change orders, so the team has clear visibility into scope adjustments.
- Document Everything
- Update project documentation (BRD, backlog, change logs) with new requests and decisions made.
- Ensure the client has formal confirmation of any scope or schedule changes.