Platform would like to introduce a new process for Offboarding VFS teams when their contracts end. While the current individual Offboarding process ensures that individuals' access to Platform products and services is removed when they exit their contract, a team offboarding process would help ensure OCTO-DE is aware of which products are no longer being maintained and/or supported for VA.gov.
Hypothesis or Bet
How will this initiative impact the quality of VFS or Platform teams' work?How will this initiative be easy for VFS or Platform teams? Or how will it be easier than what they did before?
We will know we're done when... ("Definition of Done")
What requirements does this project need to meet for you to finish this initiative?
Known Blockers/Dependencies
List any blockers or dependencies for this work to be completed
Projected Launch Date
When do you expect to be completed rolling out this initiative*
Launch Checklist
Guidance (delete before posting)
This checklist is intended to be used to help answer, "is my Platform initiative ready for launch?". All of the items in this checklist should be completed, with artifacts linked---or have a brief explanation of why they've been skipped---before launching a given Platforminitiative. All links or explanations can be provided in Required Artifacts sections. The items that can be skipped are marked as such.
Keep in mind the distinction between Product and Initiative --- each Product needs specific supporting documentation, but Initiatives to improve existing Products should reuse existing documentation for that Product. VSP Product Terminology for details.
Is this service / tool / feature...
... tested?
[ ] Usability test (TODO: link) has been performed, to validate that new changes enable users to do what was intended and that these changes don't worsen quality elsewhere. If usability test isn't relevant for this change, document the reason for skipping it.
[ ] ... and issues discovered in usability testing have been addressed.
Note on skipping: metrics that show the impact of before/after can be a substitute for usability testing.
[ ] End-to-end manual QA or UAT is complete, to validate there are no high-severity issues before launching
[ ] (if applicable) New functionality has thorough, automated tests running in CI/CD
[ ] (if applicable) Post to #vsp-service-design for external communication about this change (e.g. customer-facing meetings)
... measurable
[ ] (if applicable) This change has clearly-defined success metrics, with instrumentation of those analytics where possible, or a reason documented for skipping it.
Problem Statement
Platform would like to introduce a new process for Offboarding VFS teams when their contracts end. While the current individual Offboarding process ensures that individuals' access to Platform products and services is removed when they exit their contract, a team offboarding process would help ensure OCTO-DE is aware of which products are no longer being maintained and/or supported for VA.gov.
Hypothesis or Bet
How will this initiative impact the quality of VFS or Platform teams' work? How will this initiative be easy for VFS or Platform teams? Or how will it be easier than what they did before?
We will know we're done when... ("Definition of Done")
What requirements does this project need to meet for you to finish this initiative?
Known Blockers/Dependencies
List any blockers or dependencies for this work to be completed
Projected Launch Date
Launch Checklist
Guidance (delete before posting)
This checklist is intended to be used to help answer, "is my Platform initiative ready for launch?". All of the items in this checklist should be completed, with artifacts linked---or have a brief explanation of why they've been skipped---before launching a given Platforminitiative. All links or explanations can be provided in Required Artifacts sections. The items that can be skipped are marked as such.
Keep in mind the distinction between Product and Initiative --- each Product needs specific supporting documentation, but Initiatives to improve existing Products should reuse existing documentation for that Product. VSP Product Terminology for details.
Is this service / tool / feature...
... tested?
... documented?
... measurable
When you're ready to launch...
Required Artifacts
Documentation
PRODUCT_NAME
: directory name used for your product documentationTesting
Measurement
TODOs