Is the system configured to do what we bought it to do?
SDB is the practice Sentinel created to close that gap. We embed inside the vendor’s deployment as the agency’s professional voice. We coordinate with the vendor as peer professionals, not as customers. And we leave the agency with artifacts that belong to them.
Deployments do not fail for lack of software. They fail for lack of an owner on the agency’s side of the table. The vendor configures to their defaults. The agency signs the acceptance form without fully understanding what it is accepting. Go-live happens. Modules that were in the RFP quietly get abandoned. Workarounds replace workflows.
Super Users become the institutional memory of why things are configured the way they are, and when they leave, that memory walks out the door. SDB is the practice Sentinel created to fill that gap.
We own the business process redesign, the functionality matrix, the completion criteria, and the documentation discipline that turns a deployment into a defensible operational asset. We leave the agency with artifacts that belong to them, not to the vendor.
We have seen these patterns across nearly two decades of mission-critical deployments. They are not rare. They are the default outcome when no one owns the configuration on the agency’s side of the table.
Every SDB engagement follows the same four-phase structure. Duration varies by deployment. The structure does not.
Phase 01 — Discovery and Decision Architecture. Deep stakeholder interviews across every functional area the system will touch. Current-state documentation produced from direct observation. Gap analysis against procurement requirements. A capability matrix mapping vendor features to agency priorities. Every configuration decision captured with its author, its rationale, and its cross-module impact before any configuration work begins.
Phase 02 — Configuration Authority. Sentinel sits inside the configuration process as the agency’s authority. We govern how business processes are translated into system settings, how completion criteria are defined, and how vendor deliverables are accepted. Every decision made during configuration traces back to the Decision Architecture captured in Phase 01.
Phase 03 — Validation and Transfer. Independent validation of configured functionality against procurement intent. Formal completion-criteria signoff. Authorship of the three permanent artifacts that transfer to agency ownership. Test protocols executed. Acceptance documented with the evidence that makes future disputes unnecessary.
Phase 04 — Post-Go-Live Stewardship. Living-document maintenance of the transferred artifacts. Continuous decision logging as configuration evolves. Coordination with the vendor on optimization and change requests. The natural bridge into Sentinel Value Assurance and Sentinel Sustain.
Authored to publication quality. Formally transferred to the agency as their property. These three artifacts are what distinguish SDB from every competing service offering.
The configuration authority document. Every business process, every decision, every configured module, every cross-module dependency, captured in one governing document that the agency owns in perpetuity.
Role-specific training materials written to the way the agency actually configured the system, not to the vendor’s generic documentation. Reusable for new hires, refreshers, and system evolution.
The internal runbook the agency’s administrator uses to maintain, modify, and defend the configuration after Sentinel departs.
Behind these three artifacts sits the full operational toolkit: capability matrix, decision architecture log, current-state documentation, completion criteria protocols, vendor acceptance ledger, and the configuration-impact map. Supporting tools are Sentinel’s. The three signature artifacts are yours.
Configuration fidelity is measurable. SDB tracks every decision from procurement intent through post-go-live drift.
The earlier SDB enters, the more of the original procurement intent survives into production.
SDB is where the configuration of the system meets the realities of the agency that will use it.
SDF runs the program at the executive and schedule layer. SDB runs the craft at the configuration layer. SDF surfaces the risks. SDB resolves the configuration-specific ones.
SDB governs what the system becomes. SRM prepares the people who will use what it becomes. The Decision Architecture captured in Phase 01 feeds the role-based readiness strategy directly.
SDB produces the baseline. SVA measures what that baseline delivered. The three signature artifacts SDB transfers are the evidentiary foundation SVA uses to measure realized value over time.
SDB is commercially viable because it redirects spend agencies are already committing, and delivers a better outcome than the spend would otherwise produce.
Agencies entering a deployment typically contract for a block of vendor Professional Services hours at $200 to $400 loaded rates. SDB’s commercial pitch: descope a portion of those hours from the vendor contract and redirect the spend to Sentinel. The vendor is retained for product engineering, interface construction, and escalation support. Sentinel occupies the configuration-and-provisioning authority seat the vendor’s Software Specialist would otherwise hold.
Why it works for the agency: Fewer vendor hours at lower effective cost. Higher-quality discovery from deeper subject matter expertise. Configuration that survives turnover. Training that works because it was built against the final system. A Blueprint the agency owns.
Why it works for the vendor: The vendor is freed from configuration work they are structurally mismatched to perform well. Deployment timelines tighten. Acceptance arrives cleaner. Post-go-live escalations drop.
SDB is, by design, an engagement that begins with its own discovery phase. When Sentinel is engaged mid-deployment, Phase 01 adapts to reconstruct Decision Architecture from existing vendor artifacts, acceptance documents, and stakeholder interviews.
The phase still produces a governing document. It just starts from a different origin. Sentinel does not pretend to govern configuration decisions we did not witness. We reconstruct the record first.
Then we govern forward.
Sentinel Deployment Blueprint is delivered by Sentinel practitioners. It is not offered as a training course. The methodology is codified. The execution requires practitioner expertise across five disciplines, business analysis, configuration engineering, vendor coordination, documentation authorship, and stakeholder governance, that cannot be transferred through a classroom.
Sentinel Sustain keeps them current across the life of the investment. Configuration evolves. The Blueprint evolves with it.
Annual Blueprint refresh cycle. Quarterly decision logging review. Standing access for vendor-driven change requests.
Core plus monthly configuration drift check. Training Curriculum updates as modules evolve. System Administrator coaching on request.
Active plus embedded part-time configuration steward. Annual full Blueprint audit. Priority response on any vendor upgrade event.
Ready to own your configuration, not rent it from your vendor?
Talk to a Sentinel practitioner