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)PMApproved Client
SOW milestones + delivery budget — entered in EunoPM
Team staffed with start/end datesPMApproved PM
1Planning 5 deliverables · gate: Client ▾
Deliverables 5
ResponsibleProject plan✓ Client sign-offPMApproved Client
Tenant access request placed for the team — entered in Euno Access ManagementPMApproved PM
Kickoff meeting (client · owners · internal team)PMApproved PM
Weekly touch-bases (client + internal)PMApproved PM
Tenant strategy — discussed & publishedSAApproved Client
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/BAApproved PM
Requirements document (internal review → client → revisions)✓ Client sign-offBAApproved Client
Wireframes (internal review → client → reconcile)BAApproved Client
Design document✓ Client sign-offSAApproved Client
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 · unit test cases)• SA approvalTLApproved SA
Development plan (detailed, internal — granular build & test items)TLApproved PM
Dev plan presentation to development teamTLApproved TL
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 executionDevApproved TL
Code & design review (app code + design reviewed before unit testing)• TL reviewTLApproved TL
Unit testing execution & results (devs follow the unit test cases in the tech spec, right after development)• SA sign-offDevApproved SA
Integration testing• SA sign-offQAApproved SA
Test case communication to client (after SA approval — heads-up + UAT foundation)PMApproved SA
UAT readiness coordination (client UAT plan, cases, team)PMApproved PM
UAT tenant setupSAApproved PM
Performance testing (load & response-time checks per the technical spec)• SA sign-offQAApproved SA
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 EunoClientApproved Client
UAT executionClientApproved Client
Fixes from UAT ticketsDevApproved TL
UAT touch-base calls (communication strategy)PMApproved PM
Migration strategy & cutover plan (dates · tenant refresh · open issues)PM/SAApproved Client
Migration checklist• TL + SA approvalDevApproved TL + SA
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 productionDevApproved TL
Production enabling stepsDevApproved TL
Data refresh back to sandboxDevApproved TL
Sanity testing in productionQAApproved TL
Technical go-live communicationPMApproved Client
7Warranty & Support 3 deliverables ▾
Deliverables 3
Warranty support briefing (period + end date)PMApproved Client
Warranty bug fixes (deployed bugs only, not new requirements)DevApproved TL
Support decision (ongoing support or knowledge transfer)PM/ClientApproved 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.