Workday Project & Change Request Lifecycle
This article defines the standard lifecycle used by the Business Process Management (BPM) team to intake, evaluate, prioritize, deliver, and close Workday-related projects and change requests. The lifecycle provides consistency, governance, and transparency for both campus partners and BPM staff.
1. Intake
Purpose: Capture, review, and appropriately route incoming Workday-related requests.
Key Activities:
- Receive and log the request in TeamDynamix
- Validate scope, ownership, and completeness
- Confirm alignment with BPM-Workday supported work
- Identify whether clarification or redirection is needed
Outcome: Request is accepted for Discovery, redirected, or closed.
2. Discovery
Purpose: Develop a clear understanding of the business problem before defining solutions.
Key Activities:
- Provide Pre-Discovery Workbook to Requester
- Review the current-state business process
- Identify pain points, gaps, and inefficiencies
- Clarify desired outcomes and success criteria
- Gather supporting documentation, examples, or data
- Engage stakeholders through meetings or working sessions
Outcome: Consultation Metric Report and Discovery summary with a recommended path forward.
3. Prioritization
Purpose: Determine if and when the request should be worked based on impact, effort, and capacity.
Key Activities:
- Evaluate business impact and urgency
- Assess level of effort, complexity, and risk
- Identify dependencies and cross-functional impacts
- Compare request against active and planned work
- Engage leadership as needed for review
Outcome: Request is approved to move forward, scheduled for a future timeframe, or closed as out of scope.
4. Planning
Purpose: Translate an approved request into a structured, actionable plan.
Key Activities:
- Define scope, assumptions, and success measures
- Identify stakeholders and required involvement
- Establish a high-level timeline and sequencing
- Determine whether the work proceeds as a project or change request
- Confirm readiness to move into solution design
Outcome: Approved plan ready for solution design.
5. Solution Design
Purpose: Define the detailed functional approach before configuration work begins.
Key Activities:
- Document proposed business process changes
- Define Workday configuration requirements
- Identify security, reporting, and downstream impacts
- Validate design with stakeholders and obtain approval
- Prepare artifacts required for Workday Support Services
Outcome: Approved solution design ready for WSS submission.
6. Ticket Submission
Purpose: Initiate Workday configuration work through Workday Support Services (WSS).
Key Activities:
- Submit Jira ticket with finalized requirements and design
- Respond to clarification requests from WSS
- Coordinate configuration activities and timelines
- Track progress and maintain functional oversight
Outcome: Configuration completed and ready for testing.
7–8. Testing & Testing Completed
Purpose: Validate that the configuration meets business and functional requirements and confirm readiness for deployment.
Key Activities:
- Conduct BPM functional testing
- Perform User Acceptance Testing (UAT), when applicable
- Validate business process steps and outcomes
- Identify, document, and resolve defects
- Obtain functional and UAT sign-off
- Confirm training or communication needs
Outcome: Approved for production deployment.
9–10. Deployment & Stabilization
Purpose: Move approved changes into Production and confirm the solution functions as expected after go-live.
Key Activities:
- Coordinate production migration with WSS
- Confirm go-live timing and readiness
- Release communications or job aids, if applicable
- Validate production availability post-deployment
- Monitor for early issues, feedback, or defects
- Determine whether follow-up enhancements are needed
Outcome: Solution confirmed stable and adopted.
11. Closure
Purpose: Formally close the request and capture completion artifacts.
Key Activities:
- Finalize documentation and knowledge resources
- Capture metrics and lessons learned, if applicable
- Close the TeamDynamix ticket
- Archive the request for reporting and audit purposes
Outcome: Request closed and work formally completed.
Default Milestones Framework (Timelines)
The milestone frameworks below provide typical duration ranges for change requests and projects. Actual timelines vary based on scope, dependencies, stakeholder availability, and Workday Support Services (WSS) configuration scheduling.
Change Requests (Small Enhancements or Configuration Updates)
| Milestone |
Aligned Phase(s) |
Description / Responsibilities |
Typical Duration |
| Intake & Triage |
1. Intake |
Log in TDX, validate scope/completeness/ownership, confirm alignment, and route for next steps. |
1–3 business days |
| Targeted Discovery |
2. Discovery |
Focused clarification to confirm the need, impacted process, and desired outcome. |
1–3 business days |
| Prioritization & Routing |
3. Prioritization |
Assess impact/urgency/effort/risk; determine proceed-now, schedule later, or close as out of scope. |
1–3 business days |
| Lightweight Planning |
4. Planning |
Confirm scope/assumptions/stakeholders and validate readiness for solution design. |
1–2 business days |
| Solution Design |
5. Solution Design |
Define configuration/report changes and confirm impacts (security, reporting, downstream). |
2–5 business days |
| Ticket Submission |
6. Ticket Submission |
Submit Jira to WSS and coordinate clarifications and timing. |
1–2 business days |
| Functional & User Testing |
7. Testing |
BPM testing + requester/UAT testing; document defects; retest fixes. |
3–5 business days |
| Testing Sign-Off |
8. Testing Completed |
Confirm no blocking issues; validate readiness; confirm comms/training needs. |
1–2 business days |
| Production Deployment |
9. Deployment |
Coordinate migration and validate production availability post-deployment. |
1–3 business days |
| Post-Go-Live Stabilization |
10. Stabilization |
Monitor early issues and feedback; confirm expected behavior in Production. |
2–3 business days |
| Closure |
11. Closure |
Finalize documentation, close TDX ticket, and archive for reporting/audit. |
1–2 business days |
Typical Timeline: 2–4 weeks total
Projects (Full Discovery and Implementation Initiatives)
| Milestone |
Aligned Phase(s) |
Description / Responsibilities |
Typical Duration |
| Project Intake & Initiation |
1. Intake |
Validate request, confirm project type, define initial problem statement, identify stakeholders. |
2 days |
| Discovery & Current State Analysis |
2. Discovery |
Pre-Discovery Workbook, Discovery sessions, current-state documentation, pain points, gaps, success criteria. |
2–4 weeks |
| Prioritization & Governance Review |
3. Prioritization |
Impact/effort/risk/dependencies review; leadership engagement to approve timing and priority. |
1–2 weeks |
| Project Planning |
4. Planning |
Define scope, assumptions, success measures, roles, milestones, and sequencing. |
1–2 weeks |
| Solution Design & Future State Definition |
5. Solution Design |
Future-state definition, config/security/reporting impacts, and design approval. |
2–4 weeks |
| Ticket Submission & Configuration Coordination |
6. Ticket Submission |
Submit Jira to WSS; coordinate configuration activities; respond to clarifications; track progress. |
5 days |
| Testing (Functional & UAT) |
7. Testing |
Structured testing and UAT; issue logging, resolution, and retesting. |
2–3 weeks |
| Testing Completion & Readiness Review |
8. Testing Completed |
Confirm approvals, address training/communications, verify deployment readiness. |
1–2 weeks |
| Production Deployment |
9. Deployment |
Coordinate go-live activities, migration, and communications/KBAs. |
5 days |
| Stabilization & Adoption Support |
10. Stabilization |
Monitor post-go-live performance and feedback; support adoption. |
5 days |
| Project Closure & Lessons Learned |
11. Closure |
Finalize artifacts, capture metrics/lessons learned, formally close and archive. |
5 days |
Typical Timeline: 8–16 weeks total (scope-dependent)