The first 90 days of a forward deployed engagement
The first quarter should answer a practical question: can your team use a working system to improve a recurring part of the business? Start with one workflow, establish what a useful result looks like, and build toward it with the people who do the work.
Use the first 90 days to choose a workflow, test a working version with its users, and establish whether it is useful and reliable enough to run. The outcome is a measured result and a clear ownership decision. Scope, access, data quality, and feedback determine the pace.
A plan for the first quarter
The timeline below is an illustrative engagement plan. Agree the milestones during scoping, including what happens if access is delayed or testing shows the approach needs to change. A narrow workflow with accessible data may move quickly. A workflow involving several vendors or a security review may need more preparation.
- Before startingScope and ownershipChoose the workflow, record the baseline, and agree access and responsibilities.
- Days 1 to 30Build and testPut a narrow working version in front of the people who will use it.
- Days 31 to 60Establish reliable useResolve exceptions, monitor failures, and train the people who will operate it.
- Days 61 to 90Measure and decideReview the result and choose a handoff, continued support, revision, or stop.
Before starting: choose one workflow and its owner
A useful first workflow recurs often enough to observe, has a person accountable for it, and creates a recognizable cost when it goes wrong. Preparing prior deal context for a meeting, routing an inbound opportunity, or assembling a reporting package can each be a starting point. Choose the one whose improvement matters to your firm now.
Write down how the work happens today: the people involved, systems they use, time spent, waiting time, and common corrections. Agree what the first version will do and what remains with a human. Your IT and security owners should approve the required systems, permissions, model providers, and data handling before production data is connected.
| Your team | Name an outcome owner, provide representative examples, and identify who can approve access and release. |
|---|---|
| Graph Advisors | Map the process, propose the first scope, identify dependencies, and agree how progress will be measured. |
| Checkpoint | A written scope, baseline, acceptance criteria, responsibility list, and plan for unresolved access requests. |
Days 1 to 30: build with the people doing the work
Walk through actual examples with the owner and initial users. Identify which records are authoritative, where information conflicts, and which decisions require judgment. Build only the connections and processing needed for the first workflow.
The aim for this phase is a working version that users can try on approved data. Compare its output with the current process. Record missing information, incorrect results, permission problems, and the work people still have to do afterward. Where an output summarizes source material, users should be able to inspect those sources.
If production access is delayed, agreed sample data may support early testing. Record that limitation explicitly. A successful sample-data test does not establish that the production workflow is ready.
| Your team | Walk through the process, review outputs, and make scope and access decisions. Agree time for these sessions before work starts. |
|---|---|
| Graph Advisors | Build the first version, demonstrate progress regularly, and maintain a visible list of issues and decisions. |
| Checkpoint | Users have tried the workflow, feedback is recorded, and the owner understands what is ready and what still needs work. |
Days 31 to 60: make the workflow dependable
Repeated use reveals the cases a demonstration misses: duplicate companies, a stale export, a missing permission, or a document with an unexpected format. Resolve the important exceptions and make failures visible to someone who can act on them.
Agree how the workflow is monitored, how a user reports a problem, and how the team falls back to the existing process. Document the operating steps and rehearse them with the person who will run it. Expand access only after the owner accepts the relevant quality and permission checks.
A second workflow is a separate scope decision. Consider it when the first is useful, support is manageable, and the next use case justifies the work. Reusing a connection can reduce effort, but it does not establish that the next workflow is valuable.
| Your team | Review exceptions, nominate an operating owner, and confirm whether the workflow is becoming part of regular work. |
|---|---|
| Graph Advisors | Address recurring failures, add monitoring, document recovery steps, and train the operating owner. |
| Checkpoint | The workflow meets its agreed quality checks, failures have an owner, and users know how to get help or revert to the existing process. |
Days 61 to 90: measure the result and decide who runs it
Compare the result with the baseline using comparable work. Include time spent checking and correcting the output, handling exceptions, and maintaining the system. Look at whether people choose to use it and whether the quality of the work holds up.
For example, a meeting-preparation workflow could be measured by preparation time, the proportion of statements linked to sources, corrections needed before use, and repeat use by the intended team. These are illustrative measures, not Graph Advisors performance benchmarks. The outcome owner should choose the measures and acceptance thresholds before testing.
The review can lead to a handoff, continued support, a narrower scope, or stopping the workflow. If the result is not useful enough, identify why before funding another quarter. If it is useful, decide who owns the next operating period and its costs.
What a usable handoff includes
- An accountable owner: someone who has run the process and knows how to respond when it fails.
- Source and documentation: the agreed code, configuration, data-source map, operating instructions, and known limitations.
- Access and dependencies: ownership of accounts, external services, permissions, and a process to remove access that is no longer needed.
- Costs and support: expected hosting, model, vendor, and maintenance costs, plus who handles support after the engagement.
- Acceptance evidence: the quality checks, user feedback, measured result, and unresolved issues the owner has accepted.
Ownership, third-party licenses, support responsibilities, and commercial terms belong in the engagement scope. Having a copy of the code is one part of being able to operate the system.
How Graph Advisors approaches the work
Graph Advisors brings operations and engineering together around the workflow. The operating work defines priorities, responsibilities, and acceptance. The engineering work connects systems, builds the workflow, and supports its use. Your firm's owner provides context, makes business decisions, and approves the result.
For an existing example of coordinating a deployment across a platform and its customer, see our startups and platforms page. The engagement plan above is illustrative and does not claim that example followed this exact timetable.
Frequently asked questions
How long until the first workflow is live?
The plan targets an initial working version during the first month. Production timing depends on scope, approved access, data quality, and acceptance testing. Agree a milestone for your workflow during scoping and revise it openly if those dependencies change.
What do we need to provide before the team starts?
Name an outcome owner, choose the first workflow, and provide representative examples of the current process. Identify the people who can approve system access, data handling, and release. Agree time for user feedback and business decisions.
Who owns the system after 90 days?
Agree ownership and handoff terms in the engagement scope. A usable handoff includes the agreed source, documentation, account ownership, operating instructions, and a trained owner. Third-party services may still have licenses and ongoing costs.
What if our data is messy?
Start by identifying the authoritative sources and the records the first workflow needs. Resolve the quality problems that affect that scope and document what remains unreliable. If the available data cannot support an acceptable result, narrow or pause the workflow before expanding it.
How much of our team's time does it take?
Agree the time commitment during scoping. The outcome owner needs time for decisions and reviews, initial users need time to test real work, and IT or security owners may need to approve access. Make those responsibilities visible in the plan.
Does the first quarter include a second workflow?
Only if it is agreed in scope and the first workflow is useful and dependable enough to expand. A second workflow is an investment decision based on user feedback, support needs, and the value of the next use case.