Offboarding - Launch offboarding process

User Story

As a VFS team whose contract is ending, I need to know what documentation to create or refine and where to put it, so that a future VFS team can pick up work on the same product.

As a VSP team member responsible for access management, I need to know the standard protocol for access management, so that I can enforce it and thus ensure that the only people with access to VA.gov systems are current team members building on and in support of VA.gov.

VSP Objective (Q1 & Q2 2020)

O1: Any volume of simultaneous customers have a delightful, self-service, end-to-end experience using the Platform to build on VA.gov.

Measuring Success (KRs/KPIs)

[VSP KR] Increase in customer NPS
[VSP KR] Reduction in volume of “non-human-needed” support requests month over month
Percent of teams with contracts ending who meet documentation offboarding standards
Duration of access management delay (number of days after a team member’s end date before access is revoked to all systems) — need to refine

Details and Notes

This is the super epic for defining and launching a standard offboarding process (inclusive of documentation and access management), so that we (VSP) can actually start offboarding VFS teams, as tracked in super epic #2078

Goal(s)

Minimize loss of knowledge between different teams working on the same VA.gov product over time.
Minimize security risk of offboarded team members retaining access to VA.gov systems.

Assumptions and Hypotheses

We hypothesize that if we set clear expectations regarding documentation for VFS teams throughout their contract, then we will reduce the burden of documentation offboarding at contract end.
We hypothesize that if VFS teams with contracts ending meet VSP documentation standards and undergo documentation offboarding reviews, then those teams will make it easier for future VFS teams to pick up work on the same product.
We hypothesize that if we have well documented products, then new VFS teams will begin building sooner and have a better, more self-service onboarding experience.

Areas for Discovery

What is the overlap between access management and documentation offboarding? Should these be tracked as one process (we think yes)?
How can we identify platform customers who are offboarding > 1 month in advance of contract end date, when end dates frequently change?

Per Slack convo with Leah and Patrick, this initiative has been deprioritized to allow us (VSP Content & IA) to focus on other initiatives related to documentation (such as documentation site discovery and repo migration). That message is pasted below:

What we’ve done so far: I drafted a documentation offboarding checklist here, based on transition readiness work folks had done on previous contracts: https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/platform/working-with-vsp/offboarding-checklist.md — anyone is of course free to use and iterate on this list in whatever way y’all want.

Why we’re deprioritizing: Bandwidth. As we worked on our super epics roadmap recently, we realized that we’re trying to iterate on too many products and services right now. This one (documentation offboarding) has been something I’ve been trying to push forward, but I haven’t had enough time to focus on it and do it well. Pushing this back for a couple of months will give us some time to finish up a couple of our other current initiatives (such as refining the review process) and make space to focus on this.

What this means moving forward: VSP will not offer formal documentation offboarding services in the short term to teams whose contracts are ending. We hope to pick this back up on the later side of Q1 2020.

department-of-veterans-affairs / va.gov-team