Lifecycle

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)

Print Article