Euno · Methodology Template · v1
Project Methodology Template

Extend Platform and Workday v1

Stages, deliverables and sign-off gates applied when a project is created with this methodology.
Each deliverable shows who is responsible · each gate shows who must approve.

8 stages
0Project Onboarding 3 deliverables ▾
Deliverables 3
Estimate baseline (positions + effort + rates pulled from the estimate)PM
SOW milestones + delivery budgetPM
Team staffed with start/end datesPM
1Planning 5 deliverables · gate: Client ▾
Deliverables 5
ResponsibleProject charterPM
Kickoff meeting (client · owners · internal team)PM
Weekly touch-bases (client + internal)PM
Tenant strategy — discussed & publishedSA
Project plan✓ Client sign-offPM
Guiding principle · RAIDEveryone raises, the PM drives. Every project member is responsible for raising issues, risks, assumptions and dependencies so they can be tracked as overall RAID project items. The project manager surfaces RAID items, opens them for discussion, and explores resolution options.
Gate 1Project Plan Approval 1st client approval
required approval by Client
↓ Approved → next phase↺ Request changes(plan revised & resubmitted)
2Requirements & Design 4 deliverables · 2 gates ▾
Deliverables 4
Requirement finalization discussionsPM/BA
Requirements document (internal review → client → revisions)✓ Client sign-offBA
Wireframes (internal review → client → reconcile)BA
Design document✓ Client sign-offSA
Guiding principleRequirements must be testable. A requirement with no test cases linked to it is an untested risk and cannot be signed off.
Gate 2Requirements Doc Approval Client approval
required approval by Client
↓ Approved → next phase↺ Request changes(requirements revised)
Gate 3Design Doc Approval 2nd client approval
required approval by Client
↓ Approved → next phase↺ Request changes(wireframes & design revised)
⚡ On approval: everyone on the project is notified & the design document is attached to the email
3Technical Spec & Dev Planning 3 deliverables · gate: SA ▾
Deliverables 3
Technical specifications (business object · object model · page design · process flow · security · performance)• SA approvalSA
Development plan (detailed, internal — granular build & test items)TL
Dev plan presentation to development teamTL
Gate 4Technical Spec Approval Internal approval
required approval by SA
↓ Approved → dev planning↺ Request changes(tech spec revised)
4Build & Unit Testing 8 deliverables · 2 gates ▾
Deliverables 8
Development executionDev
Code & design review (app code + design reviewed before unit testing)• TL reviewTL
Unit test cases• SA reviewBA
Test case communication to client (after SA approval — heads-up + UAT foundation)PM
UAT readiness coordination (client UAT plan, cases, team)PM
UAT tenant setupSA
Unit testing execution & results• SA sign-offQA
Performance testing (load & response-time checks per the technical spec)• SA sign-offQA
Guiding principleResolved tickets carry evidence. A ticket may only be marked resolved when it includes a screenshot, or the specific test case and tenant, that demonstrates the fix.
Gate 5Unit Test Cases Approval Internal approval
required approval by SA
↓ Approved → test cases communicated to client↺ Request changes(test cases revised)
Gate 6Unit Testing Results Sign-off Gates entry to UAT
required approval by SA
↓ Approved → enter UAT↺ Request changes(fixes + retest)
5UAT 6 deliverables · gate: TL ▾
Deliverables 6
UAT test plan uploaded into EunoClient
UAT executionClient
Fixes from UAT ticketsDev
UAT touch-base calls (communication strategy)PM
Migration strategy & cutover plan (dates · tenant refresh · open issues)PM/SA
Migration checklist• TL + SA approvalDev
Ticket lifecycle — UAT status pipeline
Testing loggedlogged by QA
→
Reviewed by developerreviewed by Dev
→
Fixes reviewedreviewed by team member
→
Ready for retestmoved by QA only
Only the QA can move a ticket to “Ready for retest”. After retest, passed tickets are closed; failures loop back to the developer.
Guiding principleDefects are linked to requirements. A defect raised in UAT must be linked to the requirement it relates to. A ticket that cannot be linked to a requirement is a change request, not a defect — it goes through change control.
Gate 7Migration Checklist Approval Before go-live
required approval by TL + SA
↓ Approved → go-live↺ Request changes(checklist revised)
6Deployment / Go-Live 5 deliverables ▾
Deliverables 5
Code moved to productionDev
Production enabling stepsDev
Data refresh back to sandboxDev
Sanity testing in productionQA
Technical go-live communicationPM
7Warranty & Support 3 deliverables ▾
Deliverables 3
Warranty support briefing (period + end date)PM
Warranty bug fixes (deployed bugs only, not new requirements)Dev
Support decision (ongoing support or knowledge transfer)PM/Client
Project Close
The project manager navigates the close decision — communicating to the client that warranty support has ended or working with the administrative team to get an SOW issued for follow-on work
Gates block the project from advancing until approved. "Request changes" returns to the phase for revision and resubmission.
Comments0–
Not signed in
Shared comments
Enter your name and the shared passphrase to view and post comments. Comments are visible to everyone with the passphrase.