The way we work
The test is whether it still runs after we leave.
The process is written down. The change is tested. Your team knows how to operate it and what to do when something needs attention.
Valspire Group is an operations design and automation firm in Ashburn, Virginia, working with companies across DC, Maryland, and Virginia, and remotely.
The delivery sequence
Agree on the work. Prove it works.
Every engagement runs on the same written method. Requirements before build. Current and future state mapped. Acceptance criteria agreed before anything starts. Change control when scope moves. A documented handover at the end. It is written down so the result does not depend on who happens to be doing the work.
Requirements
Write down what the work requires.
Identify the starting record, required information, responsible people and decisions. Agree the scope, assumptions and exclusions before anything is built.
- What you receive
- Written requirements with the scope, assumptions and exclusions.
- Who reviews it
- You review the requirements and approve them before the build starts.
Illustrative example
Requirement record
- Requirement
- Purchasing requests have an assigned owner.
- Assumption
- Requests arrive through the existing request form.
- Exclusion
- Supplier onboarding is outside this scope.
Acceptance
Agree how the result will be accepted.
Turn the requirements into observable checks. Name who reviews each result, what evidence is needed and what must happen before the work can be accepted.
- What you receive
- Acceptance criteria for each requirement, with the reviewer and the evidence each check needs.
- Who reviews it
- You approve the acceptance criteria before the build starts.
Illustrative example
Requirement to acceptance record
- Requirement
- Purchasing requests have an assigned owner.
- Acceptance criterion
- An agreed test confirms a submitted request reaches the assigned role.
- Reviewer
- The person you name approves this criterion.
Testing
Test the normal path and the exceptions.
Run representative work through the agreed steps. Check missing information, waiting decisions and failed handoffs. Record the result, correct defects and retest before handover.
- What you receive
- The working workflow, test evidence and items still needing attention.
- Who reviews it
- You approve the result against the agreed acceptance criteria.
Illustrative example
Test record
- Normal path
- Submit a complete request and confirm which role receives it.
- Exception
- Submit a request without a cost center and confirm it returns to the requester.
- Status
- Not run yet.
Handover
Leave the team able to operate the change.
Provide the operating instructions, ownership record and agreed training. Explain what to do when something needs attention, and confirm the handover against the agreed acceptance criteria.
- What you receive
- Documentation, training and the operating handover.
- Who reviews it
- Your team receives the handover and the training. Any continuing support is a separate agreement with defined coverage.
Illustrative example
Handover item
- Handover item
- Written steps for reassigning a request, kept by your team.
What stays with your team
Built to work. Yours to run.
A Build leaves your team with a tested workflow in your own systems, documented test results and clear operating instructions. The handover covers who owns each step, how to handle exceptions and when to ask for support.
You keep ownership. Ongoing support has an agreed scope, response windows and clear responsibilities.
Discuss your process