Funding Peer Assist Versus a Lessons-Learned Repository Under a 30% Cut
Meridian Engineering is a 2,400-person infrastructure consultancy with 14 offices. Two years ago it launched KnowledgeHub, a lessons-learned repository now holding 9,000 documents. Monthly active use is 12%, and search logs show engineers mostly look for colleagues, not documents. A separate peer-assist pilot in three delivery teams reached 60% voluntary use in 90 days; requests were typically resolved in 2.1 days, and participants report avoiding rework. The executive committee has cut the KM budget by 30%. The CEO's priority is fixed-price bid accuracy: 7 of the last 10 bids exceeded estimate, by an average of 18%. The KM sponsor wants a single KM program and a dashboard by quarter end. There is pressure to scale peer assist globally and to keep KnowledgeHub because $800,000 has already been spent on it. The KM lead must recommend what to fund, what to stop, and how to show value.
1. The sponsor frames the decision as 'scale peer assist or keep KnowledgeHub.' What is wrong with that framing, and what portfolio decision would you recommend against the CEO's bid-accuracy priority?
Read the worked answer
The framing treats two delivery channels as the strategy. Neither is the outcome; bid accuracy is. KnowledgeHub's 12% usage is not primarily a communications problem. The repository has a supply and workflow problem: lessons are stored away from the bid decision, authors get no pull, and search intent is people-facing. The $800,000 is sunk and should not drive the decision.
Recommendation:
- Stop KnowledgeHub as a standalone destination. Keep only documents required by policy or client contract, and migrate them to the records system. Embed lessons capture into bid closeout and project gate reviews so content is produced where decisions are made.
- Scale peer assist first in the bid and estimating community, not globally. Fund two part-time coordinators, use a structured request template, and set a five-business-day response expectation. Global self-serve scaling would turn it into an unanswered inbox.
- Add a bid post-mortem that produces estimate adjustments, assumptions, and risk-register entries, not narrative essays.
The rationale is causal: fixed-price accuracy depends on estimate assumptions, risk pricing, and exception handling held by people. Peer assist connects estimators to that experience; a repository helps only if its content is decision-grade. Set a two-quarter stage gate: if peer assist does not improve estimate variance or rework, revisit the portfolio.
2. Design a 90-day measurement plan the sponsor can defend to the CFO. Include at least one outcome measure, one adoption measure, and one counter-metric.
Read the worked answer
The CFO will distrust a dashboard built on page views. Use a small set of measures tied to bid decisions, with a clear statement that 90 days is too short to prove reduced overruns.
Outcome measures:
- Estimate variance at bid approval versus actual, for new fixed-price bids, tracked against the 18% average overrun baseline. Report as a trend, not a single-quarter proof.
- Percentage of bids with documented assumptions and risk-register changes arising from peer assist or post-mortem. This is a leading indicator that the knowledge is entering the estimate.
Adoption measures:
- Number of requests per eligible estimator, repeat use, and time to first substantive response. Also track the percentage of requests that receive a response from someone outside the requester's team.
Counter-metric:
- Senior-estimator response burden and concentration of requests. If five people absorb most requests, the model is fragile and may burn out the experts.
Use a matched comparison where feasible: bids that used peer assist versus similar bids that did not, with explicit caveats about sample size. Present the dashboard as a learning instrument with a decision rule, not as proof of ROI.
3. What would you stop, and what risk does stopping create? How would you mitigate that risk?
Read the worked answer
Stop maintaining KnowledgeHub as a general-purpose library and stop the proposed global peer-assist rollout. The risk is not zero.
Risks of stopping:
- Loss of compliance or client-contract evidence if repository content is simply abandoned.
- Loss of legacy documents that still have reference value.
- Perceived devaluation of prior investment, which can reduce trust in the KM function.
- Overload of the small group of experts if peer assist is the only channel.
Mitigations:
- Apply retention and legal-hold review before archiving. Move required records into the records system; keep the rest read-only for a fixed period.
- Publish a short 'what changed and why' note to sponsors and contributors. Acknowledge the investment and explain the workflow reason for the change.
- Keep a thin lessons-capture step in bid closeout so the organization does not lose the habit entirely.
- Cap peer-assist request volume per expert and rotate responders. Track unanswered requests as a service risk.
The judgment is to stop the channel that is not tied to a decision and constrain the channel that is demand-led but unscalable without coordination.