Department Site Launch Checklist

This template covers the operational steps needed to launch a new department intranet site, from site structure and page templates to permissions, content ownership, and end-user training. It is meant to produce a clear go-live readiness checklist, not a generic project plan. Use it when the site is close to launch and you need a final verification pass. It helps the DRI confirm that the site is usable, governed, and ready for employees.

Run it before the site is published to the broader department, ideally after content migration and configuration are mostly complete. It also works well as a final pre-launch gate and again after launch for a short stabilization review. If the site is still being designed, this template is usually too early because many checklist items depend on completed structure and content decisions. The best time is when launch blockers can still be fixed without rework.

The checklist should usually be owned by the site DRI, such as an intranet manager, department operations lead, or project coordinator. Individual items can be assigned to content owners, IT admins, communications leads, or training coordinators depending on the task type. Keep the assignment_type flexible at import time so the tenant can choose the right owner model. The key is that every checklist item has one accountable person and one clear verification step.

Yes, as long as you tailor the checklist to the department's governance needs. For HR, legal, finance, healthcare, or safety-related departments, add verification steps for access control, retention, and approval workflows where needed. This template is not a legal control by itself, but it supports a disciplined launch process that makes compliance checks visible. If the site contains policy or procedural content, treat approval and version control as blocking items.

A common mistake is making items too broad, such as combining structure, permissions, and content review into one line. Another is marking everything critical, which hides the few items that truly block launch. Teams also forget to verify mobile or guest access, leaving the site technically live but hard to use. The best practice is to keep each checklist item independently verifiable with a yes, no, or N/A answer.

Customize the checklist items to match the department's pages, owners, and approval flow. For example, an HR site may need policy review and benefits links, while an IT site may need service request links and runbook pages. You can also adjust recurrence if the checklist is reused for multiple launches or quarterly site refreshes. Keep the core launch gates intact so the template still catches structure, permission, and training gaps.

An ad hoc launch often relies on memory, scattered messages, and last-minute checks, which makes it easy to miss permissions or ownership gaps. This template turns the launch into a repeatable checklist with a DRI, priority, and verification step for each item. That makes handoff cleaner and reduces the chance that employees land on an incomplete site. It is especially useful when multiple people contribute content or configuration.

Yes, it works well alongside project tasks, approval workflows, and training plans. Many teams link it to content migration tasks, IT service tickets, or a Kanban board so launch blockers are visible in one place. You can also pair it with a post-launch review checklist to capture issues after go-live. The template is most useful when it sits between build work and final release approval.