Cross-Time-Zone Knowledge Sharing in an ERP Rollout
A global ERP rollout has six workstreams, 140 team members across four time zones, and 40% contractors. Each workstream runs its own weekly meeting and stores decisions in different tools: one uses chat, another spreadsheets, another a wiki. When the finance workstream resolved a chart-of-accounts mapping issue, the supply-chain team repeated the same analysis three weeks later. Recorded meetings exist but are rarely watched; the wiki has 600 pages, many stale. Contractor turnover is high, and exit knowledge is often lost. The program director wants a single collaboration platform, but team leads say adoption is already low and another tool will not help. The next global design freeze is in six weeks, and dependencies between workstreams are increasing.
1. Design a layered knowledge-sharing approach for this program. Explain which mechanisms you would use for different types of knowledge and why a single platform alone will not solve the problem.
Read the worked answer
Use layers matched to knowledge type and urgency. For durable explicit knowledge-design decisions, mappings, standards-create a small curated decision register with owner, date, status, rationale, affected workstreams, and links to evidence. For emerging or tacit knowledge-trade-offs, emerging risks-use short cross-workstream design clinics with named delegates and a rotating facilitator. For time-zone coverage, require a written decision note within 24 hours of any significant meeting, plus a two-minute video or recorded walkthrough only where nuance matters; always pair recordings with a searchable summary. For contractor onboarding and turnover, use buddy pairs, a role-based onboarding page, and exit handover checklists tied to access removal. For cross-cutting themes, seed a community of practice with a monthly agenda drawn from live dependencies. A single platform helps only if it has clear spaces, owners, and templates. The current problem is not tool scarcity but fragmentation and lack of curation. Standardize the minimum: one decision log per workstream, one dependency board, one curated wiki entry per reusable solution, and meeting notes that state decisions and actions rather than transcript-style records.
2. Team leads resist another platform and say adoption is already low. How would you improve sharing without relying primarily on top-down mandates?
Read the worked answer
Start with the work people already do and remove friction. Identify two or three high-value recurring exchanges-chart-of-accounts mappings, interface decisions, and cross-workstream dependencies-and design a lightweight routine around them. For example, require a one-paragraph decision note linked from the dependency board, not a new meeting. Make the benefit visible by closing a real duplicated analysis: show the supply-chain team the finance mapping and calculate the avoided effort. Recruit respected workstream leads as knowledge brokers rather than appointing compliance monitors. Give them a small amount of time and recognition for curation. Reduce the wiki to a curated front page with owners and review dates; archive stale pages visibly. For contractors, put knowledge-transfer deliverables and exit checklists in statements of work and onboarding, because voluntary sharing is fragile when turnover is high and incentives are short-term. Use leadership behavior: ask for the decision record in reviews, not just status. Avoid launching a platform-wide mandate before the routines work. Mandates without usable routines produce compliance theater-documents uploaded once and never maintained.
3. Propose measures to test whether cross-workstream knowledge sharing is actually reducing duplicated work and dependency risk before the design freeze.
Read the worked answer
Measure reuse and rework, not activity. Track the number of cross-workstream dependencies resolved without a repeat analysis; the time from a decision in one workstream to visibility in dependent workstreams; and the number of reopened or contradicted decisions. Sample a few high-risk mapping and interface decisions and verify that dependent teams can find the rationale and current status without asking the original author. Track onboarding time for new contractors and whether exit handovers are completed before access removal. For the wiki, measure the percentage of pages with a named owner and a review date rather than page count. Add a qualitative pulse check with workstream leads on whether the routines are useful or burdensome. Set a baseline now and review weekly until design freeze. Guard against gaming: a rising number of decision records is not success if duplicates continue. Pair volume metrics with a short audit of actual reuse, and be willing to stop mechanisms that add no value; a lean set of routines that people trust is better than a full platform with low adoption.