25 Questions for Ground Truth for an Intervention
25 Questions for Ground Truth for an Intervention
The conversation a deployed-team engineer has on day one. Not an audit. Not a test. A working session that makes it easier for everyone to say what is true.
What this is
If you had ninety minutes with the team around a possible intervention, and you needed to understand whether engineering can actually help, how would you open the conversation?
This is that conversation guide. Twenty-five prompts, grouped into four things you need to know before a recommendation hardens: the business requirement, the money path, the procurement path, and the technical reality.
The prompts are deliberately conversational. They are meant to be asked out loud, in a room or video call, with the people who actually own the work. The point is not to score the team. It is to leave the room with a shared picture both sides can build on.
What this is not
It is not an audit. The agency has not done anything wrong by not having perfect answers.
It is not a test. “I do not know” is often the most valuable answer in the room because it tells you where the intervention depends on memory, heroics, or a person who is not in the conversation.
It is not a verdict. By the end, both sides know what is true today. The decision about what to do next happens after, with more time and better information.
Running the conversation
| Field | Value |
|---|---|
| Time | 90 minutes |
| Who is in the room | Agency tech owner, program lead, budget owner or delegate, procurement partner, MDDS engineer facilitator. Optional: vendor PM. |
| Output | A shared picture of the current state, the biggest unknowns, and one next conversation worth having. |
| Time | Block | What happens |
|---|---|---|
| 0:00-0:05 | Open | Read the opening script below out loud. Sets the tone. |
| 0:05-1:20 | The prompts | Ask each prompt and listen. Note what is said and what is not. Keep a steady pace so the whole picture comes into view. |
| 1:20-1:28 | What we learned | Read back what you heard. Name the unknowns. Do not try to solve them yet. |
| 1:28-1:30 | What is next | Agree on one next conversation. Name who owns setting it up. |
Opening script
Read this out loud at the start. It tells the room what kind of conversation this is, which prevents people from going defensive when the harder prompts land.
“This is not a form or an audit. We are going to talk through twenty-five prompts about the intervention in the next ninety minutes. The goal is for both of us to leave with the same picture of what is actually going on: the business need, the money, the procurement path, and the technical reality. ‘I don’t know’ is a valid and useful answer. We are not solving everything today. We are finding the honest starting line.”
How to use the listening cues
Each prompt has a few bulleted cues underneath. These are not a form to fill out. They are what to listen for. If the answer reveals one of those things, you have learned something. If the room cannot speak to it, you have also learned something.
You are not grading the intervention. You are noticing what is known and what is not.
When an answer opens a rabbit hole
If a prompt surfaces something big, such as a major risk, an unspoken disagreement, or a critical unknown, do not chase it in the room. Note it and move on. Use this line:
“That sounds important. I want to make sure we have time to get through the whole picture, so I am going to note it and we will come back to it after.”
This keeps the conversation from collapsing into one topic and missing the rest of the intervention.
The four things you are trying to learn
Every prompt ladders up to one of these. If you only had fifteen minutes instead of ninety, ask one from each row.
| Area | Questions | What you are trying to learn |
|---|---|---|
| Business requirements | Q1-Q5 | Whether the intervention has a real problem, owner, success measure, and constraint set. |
| Budget and financing | Q6-Q10 | Whether the money exists, can legally be used, and can sustain the work after handoff. |
| Procurement path | Q11-Q15 | Whether there is a viable buying lane, named procurement ownership, and realistic timing. |
| Technical ground truth | Q16-Q25 | Whether the system can be understood, changed, shipped, observed, and supported. |
The 25 prompts
Business requirements
Q1. Take me back to when this first landed on your desk. What problem were people hoping this intervention would solve, who feels it most, and has the ask changed since then?
Listen for:
- An outcome, not only a deliverable
- The primary user, worker, resident, or program group affected
- What changed since the request first appeared
- Whether the answer starts with a tool or vendor instead of a problem
Q2. If this goes well, what will be different in the real world, and how would we know?
Listen for:
- A measurable target such as time, volume, error rate, cost, compliance, or user completion
- A current baseline or a plan to get one
- A timeframe for seeing the change
- Agreement on who decides whether the intervention worked
Q3. What is making this urgent now? If we all walked out and did nothing, what would break, for whom, and by when?
Listen for:
- A concrete driver such as a deadline, audit finding, service failure, user harm, budget event, or leadership priority
- A specific consequence of doing nothing
- A clear sense that the cost of inaction is bigger than the cost of acting
Q4. Help me put names to ownership. Who can say yes, who has to live with the outcome, and who owns it after we leave?
Listen for:
- A named decision owner with authority
- A named outcome owner who will live with the result
- A named handoff owner after the deployed team leaves
- Any gap where the answer is a committee, role, or agency instead of a person
Q5. What constraints should we respect from the start, and which ones might be negotiable with the right person in the room?
Listen for:
- Constraints separated from preferences
- Which constraints are fixed and which can be changed with approval
- The person or body that can grant an exception
- Hidden constraints the team is worried about saying out loud
Budget and financing
Q6. Where would the money come from if this moved forward? Is it already identified, or are we still looking for it?
Listen for:
- A named funding source, budget line, grant, or program allocation
- A dollar range, even if it is rough
- Whether money is already available or only hoped for
- Any expiration date, fiscal-year constraint, or use-it-or-lose-it pressure
Q7. What kind of money is this, and what is it actually allowed to buy?
Listen for:
- Whether the funds are operating, capital, grant, federal, special, reimbursable, or another category
- Restrictions on software, services, staffing, hardware, cloud, training, or maintenance
- Any match, reporting, reimbursement, or period-of-performance rules
- Whether the finance team has confirmed the proposed use
Q8. Beyond the first purchase, what will this really cost to stand up, run, renew, and support?
Listen for:
- Implementation, integration, migration, security, training, support, hosting, and maintenance costs
- Recurring licenses, renewals, cloud usage, vendor support, or staff time
- Costs that move from MDDS to the agency after handoff
- A clear distinction between one-time and ongoing cost
Q9. Before anyone can spend or obligate funds, what approvals have to happen, and who owns each one?
Listen for:
- A named budget owner or finance reviewer
- The approval chain and expected timing
- Any executive, legislative, grantor, finance, or Board of Public Works dependency
- Whether the budget gate can run in parallel with procurement or security review
Q10. After our engagement ends, how does this keep getting paid for?
Listen for:
- A sustainment funding source for year two and beyond
- A named owner for renewals, support, hosting, and maintenance
- Whether the agency can absorb the ongoing cost without MDDS
- A six- or twelve-month budget check after handoff
Procurement path
Q11. Is there already a lawful path we can use: an enterprise agreement, active contract, agency license, or statewide vehicle?
Listen for:
- An existing lawful path the team has already identified
- An agreement, contract, license, or statewide vehicle that is named
- Confidence that the existing vehicle actually covers this specific need
Q12. What are we really buying here: software, services, hardware, cloud, staffing, or a contract modification?
Listen for:
- An explicit classification of the need
- A procurement and spending model that fits the need type
- Awareness of which option is in scope for this engagement versus a bigger change
Q13. If procurement started tomorrow, which lane would we probably be in: RFI, PORFP, TORFP, RFP, existing contract, or enterprise agreement?
Listen for:
- A likely lane named with rationale
- The lane tied to this request, urgency, budget, and risk
- Alternatives the team can describe if the lane assumption changes
Q14. Who needs to be in the chain from recommendation to use: procurement officer, contract owner, security reviewer, and agency owner after handoff?
Listen for:
- A named procurement officer
- A named contract or vendor relationship owner
- Named security and agency handoff owners
- Honest acknowledgment of any role that is not in place yet
Q15. Looking at the last few similar procurements here, what did they actually take from first request to usable award?
Listen for:
- Three comparable procurements the team can name
- Actual timelines documented from request to award
- Approval, security, and contract steps included in the timeline
- Historical data used instead of quoted estimates to set expectations
Technical ground truth
Q16. Walk me through what is actually running in production right now: languages, frameworks, databases, hosting, identity, and integrations
Listen for:
- Languages, frameworks, databases, hosting, identity, and integration points
- Versions running in production, not just what the docs say
- Anything critical past end-of-life or on a deprecated support track
Q17. If a sharp engineer joined tomorrow and had a week to understand this system, what would you hand them first?
Listen for:
- Current architecture diagrams, data flow diagrams, runbooks, or onboarding docs
- Docs that match production reality
- Known gaps where understanding still lives in someone’s head
Q18. Every system has a room nobody likes to enter. What is that room here, and who still knows how it works?
Listen for:
- Fragile areas named without hedging
- The original author or current expert identified
- Recent evidence that someone on the current team has touched the risky area
Q19. Walk me through the path from a local change to production. Where does it get smooth, and where does it still depend on a person?
Listen for:
- An automated path with minimal manual handoffs
- Who can deploy and who holds the keys
- Roll-forward recovery through the same controlled path
Q20. How often do you really ship, and when something breaks at the worst possible time, how do you recover?
Listen for:
- Actual release frequency, not the intended cadence
- Emergency recovery using the same path as normal change
- Any approval chain, change window, or person dependency that slows response
Q21. Tell me about your environments. Do dev, test, staging, and prod all exist, and does staging tell the truth about production?
Listen for:
- Environments that exist and are maintained
- Reasonable parity in operating system, runtime, configuration, data shape, and integrations
- Examples where staging did or did not predict production behavior
Q22. When someone opens a pull request, what happens automatically, and what actually stops a bad change from shipping?
Listen for:
- Unit, integration, accessibility, security, or end-to-end checks that run automatically
- Protected branches and review requirements
- Failing checks that block merge in practice
- Any bypass path that is common enough to matter
Q23. When a real user cannot complete the thing they came to do, how quickly do you know, and who finds out first?
Listen for:
- Monitoring that covers user-facing behavior, not only infrastructure
- Alerts that reach a person or channel someone watches
- Enough signal quality that people still trust the alerts
- A way to connect incidents back to affected users or programs
Q24. Think about the last real incident. Who responded, what got written down, and what changed afterward?
Listen for:
- A documented on-call or escalation path
- Runbooks for common failure modes
- Written post-mortems for significant incidents
- Action items that were completed or actively tracked
Q25. What does this system depend on outside the team, and what would you do tomorrow if the most important dependency failed?
Listen for:
- A written inventory of external dependencies
- Named owners for vendor relationships and integrations
- SLAs, support paths, and escalation routes that the team has used
- Fallback or accepted-risk plans for the most critical dependency
After the conversation
The last ten minutes of the session are the most important. Here is what to do with them.
Read back what you heard
Take three to five minutes to summarize the picture you now have. Use the team’s words. Name the things you heard clearly, and name the things that were thin or absent. The goal is for them to either say “yes, that is right” or “no, you missed this.” Either response is useful.
“Here is what I heard. The problem is X, and the affected users are Y. The success measure is Z. Funding appears to exist for the first year, but sustainment is still unclear. The likely procurement lane is a PORFP, but we have not confirmed whether the existing vehicle covers the implementation services. Technically, the system has an automated deploy path, but staging does not reliably predict production. Did I get that right?”
Name the unknowns
You will have answers for some prompts and silences for others. The silences are not failures. They are the most important output of the session because they tell you what the next conversation should be about.
A useful framing:
“Three things I think we do not know yet: whether the money can pay for ongoing support, who owns this after the engagement ends, and whether the procurement path can move inside the timeline. Each of those is worth its own conversation.”
Agree on one next step
Not a list of next steps. One. The single most useful next conversation, with a named person who owns setting it up.
“The thing I would want to know next is whether the funding source can cover sustainment after handoff. Can [name] set up a 30-minute conversation with [budget owner] and [procurement officer] in the next two weeks so we can find out?”
One real follow-up beats five committed-to but ignored.
What this gives you
By the end of ninety minutes, the deployed-team engineer should have:
- A shared picture of the intervention that both sides agree describes reality today
- A short list of unknowns worth surfacing in the next conversation
- One named next step with one named owner
- The honest starting line: not a verdict, not a score, just the place to begin from
That is the goal. Not certainty. Just enough shared ground to keep moving.
See also
- Engineering Intro to Deployed Teams - why this conversation matters and how it fits the Deployed Team’s operating model.
- Procurement 101 - the procurement context behind Q11-Q15.
- The Delivery Service Model - how to judge whether capability actually transferred after the intervention.