Comparable Past Scope Retriever

A comparable-scope retriever is only useful when it returns what similar work actually took, not what the last partner sold. If you embed past statements of work and stop there, you recycle the commercial fiction: the tidy diagnostic that ran long, the fixed-price implementation that ate a change order every month. Partners remember the sold number. Delivery remembers the overrun. The index has to remember both.

Most firms do not have clean actuals attached to old SOWs. Hours live in the professional services automation tool or in finance. The signed SOW lives in a SharePoint dump named by client and year. The join key is a project code typed two ways, or a folder name someone invented at close. Until that join exists, retrieval will tell you the firm has done this before and hide how long it really took.

The speed is real: you stop pinging three partners for a remembered analog. The cost is a confident wrong match, same sector, different problem, sold hours treated as truth. Do not hand those comps to a pricing model. Hand them to a human who still owns the next fee. Effort estimation from historical actuals is the downstream job.

Embeddings on a junk folder produce junk comps. Index only closed, signed scopes plus the hours that actually posted against them. Drafts, redlines, kickoff decks, and the long client exhibit with an org chart do not belong in the vector store.

Every reusable closed engagement needs one record that holds:

• The signed SOW, not the proposal. Phases, workstreams, deliverables, and the sold hours or fee that went out the door.
• Delivered hours, at workstream grain if the time system has it, otherwise at engagement grain with a note that the split is missing. Sold hours and delivered hours must both be visible. If you store only one, partners will treat it as the other.
• Problem type, named by the practice, not inferred from the industry field. "ERP recovery after a failed cutover" is a problem type. "Life sciences" is not.
• Industry and date as filters, not as the match key. Show the date so a partner can discard a comparable from a different delivery era.
• Overrun reasons, even a short close note. Without that, an expensive comparable looks like a staffing template instead of a warning.

If the join between SOW and actuals is missing, stop. Do not index SOWs alone as a first version. That version trains the firm to trust sold scope. Build the join first, even if half the closed jobs cannot be included. A smaller, honest index beats a large one that lies.

A project knowledge base ingestion agent at close is how this stays current. Retrofitting years of folders is a cleanup, not a search project. Enterprise search and RAG products in this class (Glean, Hebbia, SharePoint Copilot) and knowledge tools such as Guru retrieve against whatever you give them. They will not invent the actuals join, tag problem type, or hide another client's exhibit unless you set access that way. None of these is a ranking. Pick the system your PMO will keep clean.

Retrieval on industry plus a familiar phrase will pair jobs that only look alike on the cover. Take a mid-size firm scoping an ERP recovery for a life-sciences manufacturer: failed go-live, dirty masters, plant-floor workarounds, and a new operating cadence so the weekend war room can end. The PMO searches past SOWs for "ERP recovery" in manufacturing.

The match you want

One closed job is a pharma plant that also blew a cutover. The signed SOW sold a tidy recovery: stabilize, clean masters, stand up a cadence, hand back. Delivered hours ran heavy in data cleanup and in the weeks the client would not freeze the old process. Problem shape is the same: failed cutover, master-data debt, shop-floor shadow systems. That is the comparable. Show sold versus delivered by workstream, the date, and the overrun note.

The match that will mis-scope you

The same search returns a discrete manufacturer's "ERP recovery" from the year before. The industry family looks close enough. The phrase is in the title. The work was a greenfield implementation sold under a recovery narrative because an earlier program had been paused, not a failed go-live. Staffing mix, duration, and risk belong to a build, not a recovery. If that file is nearest-neighbor because embeddings like "ERP" and "manufacturing," the next SOW will be staffed for the wrong job.

The pharma file still has a client-confidential data-model exhibit in the same folder. That exhibit must never come back in the retrieval payload for a partner who is not on that account. Hours from either job are evidence for a conversation, not a fee table.

Same industry is not the same problem. Two supply-chain diagnostics in the same sector can be different jobs: a short current-state versus a network redesign with a standing data team. If industry is the primary key, you will keep retrieving the wrong analog and calling it close.

Match on problem type and workstream shape first. Use industry as a filter the partner can tighten. A short diagnostic and a long implementation in the same sector should never be nearest neighbors.

When discovery is still in flight, run an assumption gap detector on the draft scope against the comparable you are about to trust. If the new client will not freeze master data, and the analog assumed a freeze, the actuals will not transfer. Retrieval cannot see an unstated assumption unless you put it in the query.

Reusable method (how you run a cutover war room) can be stripped and reused. Client-specific exhibits cannot. A reusable IP extraction agent is the place to separate those, so the retriever indexes method and actuals, not another company's process map.

Access control is a scoping control, not an IT afterthought. The person asking whether the firm has done this is often a partner, contractor, or alliance staffer who was never on the analog account. They should see enough to judge comparability: problem type, industry, year, workstream list, sold versus delivered hours, overrun note. They should not see the other client's org chart, data model, named employees, or commercial exhibits.

Inherit engagement access rules into the index. Everyone in the practice is the wrong default. Conflict walls and client limits on reuse apply to embeddings the same way they apply to a shared drive. If that partner cannot open the file in the source system, it cannot be chunked into their search result.

Default the payload to metadata plus a redacted SOW spine. Pointers to full files open only for people already cleared on that engagement. Named-entity stripping is not enough: an identifiable anecdote in a lessons-learned paragraph is still a leak.

This job is retrieval of comparable scopes and actuals. It is not automatic pricing. The output is a short list a partner can read in one sitting: a handful of closed jobs, why they matched, where they differ, sold versus delivered, and what the close note said. Discard the discrete-manufacturer build. Keep the pharma recovery. Then a human writes the next hours.

Do not generate a fee, a rate card, or a staffing grid from the nearest neighbor. Do not let a SOW drafter from discovery transcript pull workstreams from an analog until a partner has accepted that analog. Generation will copy the shape it is given, including the wrong duration and the leftover exhibit.

Score the retriever on partner accept or reject of the top matches, not on how fast it returns. If partners keep throwing out the first result, you are matching on industry language instead of problem type, or you are indexing sold hours without actuals. Fix the corpus.

The system is doing its job when scoping starts from a handful of honest comps, with actuals attached, and nobody had to open a client folder they should not have opened.