Introduction: why this action matters for adoption
A change wiki is not just a place to store documents. Used well, it becomes adoption infrastructure: a single, searchable source of truth that helps impacted people understand what is changing, why it matters, what they need to do, and where to get help. This matters because change communication is not complete when a message is sent; it is effective when people hear it, interpret it correctly, and can act on it. Prosci recommends that change messages address the business “why,” personal impact, and “what’s in it for me,” while PMI identifies communication plans, sponsor engagement, ownership, and metrics as important change management practices [Prosci, 2025; PMI, 2014]. (prosci.com)
Wikis are especially useful when information will evolve. Unlike a one-time email, a wiki can hold current guidance, decision history, FAQs, job aids, role-specific impacts, and links to training. Research on organizational wikis shows that they can support open knowledge management and collaborative knowledge creation, but adoption also changes work routines and can create confusion or resistance if purpose and governance are unclear [Brainin & Arazy, 2016]. (mdpi.com)
What this action is and when to use it
Publishing wikis during a change means creating or updating a curated set of wiki pages that communicate change information to impacted groups and support adoption. It sits in the change communication and engagement category, but it should connect to training, sponsor messaging, manager enablement, and feedback loops.
Use a wiki when the change affects multiple roles, locations, processes, systems, or policies; when employees and managers need repeat access to guidance; when FAQs will grow over time; or when adoption leads need one place to point people. Do not use a wiki as the only intervention for high-resistance, emotionally charged, or ambiguous changes. Gallup emphasizes that manager conversations help employees personalize the change, and CIPD recommends two-way communication methods and follow-up to show how employee voice influences change [Gallup, 2024; CIPD]. (gallup.com)
The timing matters. GOV.UK guidance advises publishing change guidance in advance only when the change is certain or very likely, affects decisions users must make now or very soon, and requires users to do something differently now [GOV.UK, “Help users prepare for change”]. (guidance.publishing.service.gov.uk) For internal change, the same principle applies: do not publish a detailed wiki before leaders are aligned and people know what action is required.
Preparation: inputs, stakeholders, materials, timing, and decisions needed
Start with the change impact assessment, stakeholder map, implementation timeline, training plan, process maps, policy decisions, and known resistance points. Gather sponsor messages on the business reason for change, manager talking points on personal impact, and employee-facing instructions on what to do next. Prosci’s preferred-sender guidance distinguishes senior leaders for organizational messages and people managers for personal impact messages [Prosci, 2025]. (prosci.com)
Make key decisions before publishing: who owns the wiki, who approves factual content, who can edit, how often pages are reviewed, how version notes are handled, when outdated pages are retired, and how questions will be routed. GOV.UK content guidance emphasizes that content should start with user needs, be clear and accessible, and be kept up to date [GOV.UK Content Guidance]. (guidance.publishing.service.gov.uk)
Step-by-step facilitation guide
Define user needs by audience. For each group, write a simple user need: “As a field supervisor, I need to know how the new scheduling process changes approvals so that I can coach my team before go-live.” GOV.UK recommends starting content with user needs and designing content to help people complete tasks [GOV.UK Content Guidance]. (guidance.publishing.service.gov.uk)
Design the wiki around adoption tasks. Structure pages around what people need to do, not around project workstreams. A practical structure is: overview, why now, what is changing, what is not changing, role impacts, timeline, actions by date, FAQs, training, support, and version history.
Draft the core pages. Keep the writing concise and direct. Include the business reason, the risk of not changing, the personal impact, and the required next action. These align with Prosci’s guidance to answer “why,” “why now,” and “WIIFM” early and often [Prosci, 2025]. (prosci.com)
Review with the people closest to the work. Ask managers, change champions, SMEs, and a few impacted employees to test whether the wiki answers real questions. This is also a resistance check: if reviewers cannot explain what to do next, the page is not ready.
Publish with a clear launch message. The sponsor should explain why the wiki exists and why it is authoritative. Managers should reinforce how their teams should use it. The wiki should not replace meetings or manager conversations; it should support them.
Maintain the wiki as the change evolves. Add new FAQs, update decisions, remove obsolete instructions, and show what changed. Organizational wiki research highlights versioning and collaborative editing as important wiki features, while knowledge-reuse research suggests that revision and shaping can improve knowledge integration [Brainin & Arazy, 2016; Majchrzak et al., 2013]. (mdpi.com)
Measure, learn, and adapt. Review analytics, questions, support tickets, and adoption indicators weekly during active rollout. Prosci recommends surveys, focus groups, and interviews to evaluate whether audiences are hearing and interpreting messages as intended [Prosci, 2025]. (prosci.com)
Example: how this could be applied in a real change initiative
A company is replacing its expense management system. The change manager creates a wiki four weeks before pilot go-live. The first version includes the business reason, pilot scope, what employees must do before launch, manager talking points, training links, and role-specific FAQs for employees, approvers, finance partners, and executive assistants.
During the pilot, employees ask whether old receipts can be uploaded after cutover. The change manager adds the answer to the FAQ, tags it as updated, and includes it in the next manager briefing. After go-live, search data shows many employees looking for “mobile receipt.” The team adds a short mobile upload guide and links it from the home page. This turns the wiki from a static announcement into a practical adoption tool.
Roles and responsibilities
Role | Responsibility |
Change manager | Owns the wiki strategy, audience needs, message consistency, adoption measures, and update rhythm. |
Sponsor | Approves and reinforces the business reason, urgency, and expected behavior change. |
Project lead or product owner | Confirms timeline, scope, decisions, and dependencies. |
SMEs | Validate process, policy, system, and training accuracy. |
People managers | Translate wiki content into team-level impact and collect questions. |
Adoption leads or champions | Test content, surface resistance, and promote practical use. |
Content owner or communications partner | Edits for clarity, accessibility, navigation, and governance. |
Impacted employees | Use the wiki, ask questions, and flag unclear or outdated guidance. |
Common mistakes to avoid
The first mistake is publishing a wiki as a dumping ground for project documents. Employees need actionable guidance, not governance artifacts. The second is publishing too early, before decisions are stable; premature guidance can create rework and distrust. The third is creating duplicate pages in multiple channels. GOV.UK warns that duplicated guidance can make users think there is no single version of the truth and can reduce trust [GOV.UK, “Help users prepare for change”]. (guidance.publishing.service.gov.uk)
Another mistake is assuming the wiki will create engagement by itself. Gallup’s research on disruptive change emphasizes trust and communication, and specifically notes that managers help personalize what the change means for employees [Gallup, 2024]. (gallup.com) Finally, avoid leaving the wiki ownerless after launch. Outdated change guidance is worse than no guidance because people may act on obsolete instructions.
Measures of success or adoption indicators
Measure whether the wiki is being found, understood, used, and improved. Useful indicators include page views by impacted group, repeat visits, search terms, unanswered searches, FAQ submissions, broken-link reports, manager confidence pulse scores, support-ticket themes, training completion, process compliance, and adoption of the new behavior.
Also measure interpretation, not just traffic. PMI recommends monitoring the gap between current and target stakeholder attitudes to decide whether communication is working or needs adjustment [PMI, 2010]. (pmi.org) Prosci recommends post-communication surveys, focus groups, and interviews to test whether audiences are hearing and interpreting messages as intended [Prosci, 2025]. (prosci.com)
Checklist for the change manager
Confirm the wiki is the right channel for the change phase and audience need.
Define the impacted groups and their top adoption tasks.
Secure sponsor, SME, manager, HR, legal, and communications review where needed.
Write the core message: why, why now, what changes, what stays the same, what to do next.
Create role-specific pages or sections for high-impact groups.
Assign page owners, approvers, edit rights, and review dates.
Add a visible “last updated” note and version history.
Launch through sponsors and managers, not only through a system notification.
Provide a way to ask questions and show how questions are answered.
Review analytics, questions, and adoption data on a set cadence.
Retire or archive outdated pages after the change stabilizes.
Optional reusable wiki message outline
Section | Prompt |
Page title | Name the change in the words employees use. |
Summary | In two or three sentences, explain what is changing and who is affected. |
Why this is changing | State the business reason, urgency, and risk of not changing. |
What it means for you | Describe role-specific impact and “WIIFM.” |
What you need to do | List required actions, owners, and due dates. |
Timeline | Show key dates, decision points, training, go-live, and support windows. |
FAQs | Answer real questions; mark new or changed answers. |
Support | Link to training, office hours, manager guidance, and help channels. |
Version history | Show last updated date, what changed, and who owns the page. |
References
Prosci. “Communications Checklist for Change Management.” Published October 27, 2022; updated August 5, 2025. https://www.prosci.com/blog/communications-checklist-for-change-management
Project Management Institute. “Enabling Organizational Change Through Strategic Initiatives.” March 2014. https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/organizational-change-management.pdf
Gallup. “Disruptive Change Is Hitting Leaders and Managers Hardest.” May 23, 2024. https://www.gallup.com/workplace/645152/disruptive-change-hitting-leaders-managers-hardest.aspx
CIPD. “Employee voice.” No publication date shown on accessible page. https://www.cipd.org/en/views-and-insights/cipd-viewpoint/employee-voice/
GOV.UK Content and Publishing Guidance. “Understand content design.” No publication date shown on accessible page. https://guidance.publishing.service.gov.uk/writing-to-gov-uk-standards/plan-manage-content/understand-content-design/
GOV.UK Content and Publishing Guidance. “Help users prepare for change.” No publication date shown on accessible page. https://guidance.publishing.service.gov.uk/writing-to-gov-uk-standards/help-users-prepare-change/
Brainin, Esther, and Ofer Arazy. “When Wiki Technology Meets Corporate Knowledge Management Routines: A Sociomateriality Perspective.” Informatics, July 28, 2016. https://www.mdpi.com/2227-9709/3/3/12
Majchrzak, Ann; Wagner, Christian; and Yates, Dave. “The Impact of Shaping on Knowledge Reuse for Organizational Improvement with Wikis.” MIS Quarterly, 2013. https://aisel.aisnet.org/misq/vol37/iss2/9/