Capabilities
GS / 02Application engineering, cloud platforms and service operations. Define what changes, what your team receives and how you will know the work is complete.
Prepare a project briefCapability / 01
For teams replacing a manual process, connecting disconnected systems or improving a service that must keep running.
Scope this workWork we can scope
Define who can submit, review, approve and change a record. Build the screens, permissions, validation and status transitions around those tasks. Include error and exception paths in the backlog.
Specify payloads, authentication, ownership and versioning. Define behavior for missing fields, duplicate messages, unavailable dependencies and retries. Add logs that let the operator trace a failed exchange.
Map the components and business rules before selecting a replacement boundary. Test existing behavior, isolate one change and agree on data reconciliation, cutover and rollback. A rewrite is a scope decision, not the default.
Link requirements to tests and demonstrations. Include keyboard and assistive-technology checks where relevant, review dependencies and record unresolved defects before a release decision.
Deliverables to agree
Example acceptance evidence
A user completes the agreed workflow; access controls and exception paths behave as specified; an integration handles a failed dependency; the receiving team can build the documented release.
System documentation, representative test data, access to integration owners, identity requirements, supported browsers, data retention and the release approval process.
Capability / 02
For teams provisioning cloud resources manually, maintaining inconsistent environments or depending on fragile deployment procedures.
Scope this workWork we can scope
Describe account or project boundaries, network paths, identity roles, secrets and environment ownership. Record the workload and operating constraints before choosing services or proposing a migration.
Manage resource definitions and configuration in version control. Include review, state handling, drift checks and recovery instructions. Separate environment-specific values from the reusable configuration.
Connect code review to build, test, package and deployment steps. Define artifact versions, promotion approvals and rollback. Keep the evidence needed to identify exactly what ran in each environment.
Where containers and Kubernetes fit the workload, scope configuration, deployment policies, resource limits, upgrades and recovery. Establish a support owner and operational requirements before adding platform components.
Deliverables to agree
Example acceptance evidence
Provision the agreed environment from versioned configuration. Run a release through its checks and approvals. Demonstrate a rollback or recovery path without relying on undocumented console changes.
The target cloud, existing standards, access permissions, network connectivity, identity integration, availability needs and ownership of platform upgrades. AWS, Google Cloud and Kubernetes work should be scoped to the specific environment.
Capability / 03
For teams inheriting a service, dealing with recurring incidents or preparing for a change in support responsibility.
Scope this workWork we can scope
Identify applications, jobs, data stores, external dependencies and owners. Record which team approves a change, responds to an incident and maintains each component.
Choose service signals tied to user impact. Give alerts a severity, responder and response procedure. Review recurring failures and separate immediate recovery steps from work that prevents recurrence.
Agree on recovery targets and test conditions. Walk through restore and recovery procedures in an approved environment, record the result and identify unresolved dependencies.
Prepare the inventory, decision history, access transfer, runbooks and open-issue register. Have the receiving team execute the agreed procedures and record questions before the handover closes.
Deliverables to agree
Example acceptance evidence
The receiving team locates the right logs, follows an incident procedure and completes the agreed recovery exercise. Remaining gaps have named owners and a documented next action.
Access to the current operator, existing service agreements, support hours, recovery targets, the quality of operational records and the proposed receiving team. Ongoing support coverage is agreed separately; 24/7 coverage is not assumed.
Engagement shape
Choose the smallest scope that resolves the next meaningful question. Timing and commercial terms follow the requirements, access and dependencies.
Useful when documentation is thin, dependencies are unclear or the proposed solution has not been tested.
Useful when a workflow, integration, environment or release process has an agreed owner and boundary.
Useful when ownership is changing or the people supporting the service need a repeatable operating process.
Technical review
The applicable requirements belong in the scope and acceptance plan. These are examples of the evidence a project may need, not a claim of certification or authorization.
| Review area | Evidence to define |
|---|---|
| Software security | Design risks, reviewed changes, dependency and code findings, and the owner and disposition of unresolved vulnerabilities. |
| Accessibility | Critical user journeys, test methods, keyboard and assistive-technology results, defects and retest evidence. |
| Operations | Deployment and restore procedures, service signals, access ownership and the result of a recovery exercise. |
| Release decision | The release identifier, acceptance results, open issues, approving authority and conditions for rollback. |
References for planning
NIST secure development guidance ↗GSA accessibility testing lifecycle ↗NIST describes secure development practices across the software lifecycle. GSA’s guidance covers planning, testing, reporting and remediation. Select applicable requirements with the project’s responsible stakeholders.
Scope the work
Start with the current system, the change you need, and the date that matters.
Prepare a project brief