Project templates: charter, RACI, checklists, launch and handover
This page is for project managers who want to start an Exponential project with good paperwork instead of a blank
page. It holds five fill-in templates. Copy a block into your own document or ticket system, replace every
<placeholder>, and delete what does not apply.
The templates are generic where they must be (your goals, your people, your dates) and specific where the product gives you something to check: each line that names a feature points to the page that describes it, so the person who fills it in knows where to look.
Contents
- How to use the templates
- Project charter
- RACI matrix
- Requirements checklist
- Launch checklist
- Handover document
How to use the templates
- Copy the text block; it is plain text so that it pastes anywhere.
- Fill in every
<placeholder>. Leave nothing as a placeholder in a signed document; write "not applicable" instead. - Name roles, not only people. People change during a project; roles stay. Use the role names of your organization, and keep a separate list of who holds each role.
- Keep versions. Put each filled template under version control next to the project's code, or in your document system with a date.
- Do not paste secrets. Passwords, keys and host credentials never go into these documents. Write where they are kept, not what they are.
Project charter
The charter is the agreement at the start: why the project exists, what it delivers, and how everyone will know it is done. Fill it in during discovery (Planning an Exponential project) and have it signed before the build starts.
PROJECT CHARTER
Project name: <project name>
Version / date: <version>, <date>
Sponsor: <role of the person who funds and decides>
Project manager: <role>
Product owner: <role of the person who accepts the result>
1. Purpose
Why this project exists, in two or three sentences:
<purpose>
2. Goals and measures of success
| Goal | Measure | Target | Where it is measured |
|------------------------------|----------------------------------|----------|-------------------------------|
| <goal> | <measure> | <target> | <page, log or report> |
(For measures the product can report itself, see "Measuring a project: KPIs from the
product's own logs and audit trail".)
3. Scope
In scope:
- Sites (siteaccesses): <list>
- Languages: <list of locales, e.g. eng-US, ger-DE, ara-SA>
- Content classes (first model): <list or "see content model document">
- Features: <multisite, layouts editor, shop, newsletter, REST API, ...>
- Extensions: <list, own and third-party>
- Content migration: <source, volume, method>
Out of scope:
- <item>
4. Platform decisions
Exponential version: <release tag, e.g. v6.0.14, or main with reason>
PHP version: <version>
Database: <MySQL/MariaDB | PostgreSQL | SQLite | MongoDB | Oracle>
Operating system: <OS>
Web server / engine: <Exponential Velocity | Apache with PHP-FPM | FrankenPHP | nginx with PHP-FPM>
Hosting: <self-hosted / provider>
Code in Git: <repositories, site branch name>
Configuration from version control (ManagedByDeployment): <yes/no per siteaccess>
5. Deliverables
- <deliverable> Owner: <role> Due: <date>
6. Milestones and gates
| Gate | Date | Checks | Owner |
|--------------------------|---------|-----------------------------------------|--------|
| G1 Change ready | ongoing | <definition of done> | <role> |
| G2 Staging ready | <date> | <checks> | <role> |
| G3 Acceptance | <date> | <acceptance checklist signed> | <role> |
| G4 Live | <date> | <launch checklist done> | <role> |
7. Quality requirements
Accessibility: <standard and level, e.g. WCAG 2.x AA; how it is checked>
Security: <hardening checklist, CSP mode, two-step sign-in for administrators>
Performance: <how measured, e.g. exp:benchmark baseline>
Privacy: <questions answered with the organization's data protection contact>
8. Assumptions and constraints
- <assumption>
9. Risks (top five; full register separate)
- <risk>: <mitigation>
10. Communication
Weekly status: <day, audience> Steering: <rhythm> Channel: <tool>
11. Contribution to the open source project
Policy: <link to the team contribution policy> Time reserved: <hours per sprint>
Signatures: Sponsor <name/role, date> Product owner <name/role, date> Project manager <name/role, date>RACI matrix
R = Responsible (does the work), A = Accountable (one per row, decides), C = Consulted, I = Informed.
The rows name the real areas of the administration and the real tasks of an Exponential project. Who may do a task in the product is set by roles and policies (Users > Roles and policies, Roles and policies); this matrix is the organizational side. Keep them in agreement: someone who is "R" for a task needs a role whose policies allow it, and nobody should hold the Administrator role only for convenience.
RACI MATRIX: <project name> Version: <date>
Columns: PM = project manager PO = product owner ED = editors AD = administrator
DEV = developers DES = designer SM = sales and marketing HOST = hosting provider
| Task | PM | PO | ED | AD | DEV | DES | SM | HOST |
|-------------------------------------------------------------|----|----|----|----|-----|-----|----|------|
| Project charter and plan | A | C | I | C | C | I | C | I |
| Requirements and scenarios | R | A | C | C | C | C | C | |
| Content model (classes, attributes) | R | A | C | | R | C | | |
| Sections, object states and workflows | C | A | C | R | R | | | |
| Roles and policies | C | A | C | R | C | | | |
| Siteaccesses, languages and URLs | C | A | | R | R | | C | |
| Design and templates | C | A | C | | R | R | C | |
| Layouts (layouts editor) | I | A | R | | C | C | C | |
| Extensions: choice and installation | C | A | | R | R | | | |
| Own extensions: build, test, release | I | I | | C | R/A | | | |
| Content migration | A | C | R | C | R | | | |
| Server, PHP, database, web server | I | I | | A | C | | | R |
| Deployments (staging, production) | I | I | | R/A| C | | | C |
| Cronjobs | I | | | R/A| C | | | |
| Backups and restore tests | I | I | | R/A| | | | C |
| Security hardening and CSP | I | C | | R/A| R | | | C |
| Audit trail: alerts, recipients, review | I | C | | R/A| | | | |
| Accessibility checks | C | A | C | | R | R | | |
| Acceptance | R | A | R | C | C | C | C | |
| Launch go/no-go | R | A | I | C | C | I | I | C |
| Launch announcement | C | A | I | | | | R | |
| Editor training | A | C | I | C | R | | | |
| Upgrades | A | I | I | R | R | | | C |
| Bug reports to the Exponential project | I | | C | R | R | | | |
| Handover document | R/A| C | I | R | R | | | |Pages for the rows: Content model and editing, Sections, Object states, Workflows, Roles and policies, Templates and design, The layouts editor, Extensions, Deploying, Cronjobs, Operating a site, Security and audit, Upgrading, When something goes wrong.
Requirements checklist
Go through it with the product owner in discovery. Each line is a question; the last column names the page where the team finds how Exponential answers it. Mark each line Need, Nice to have or No.
REQUIREMENTS CHECKLIST: <project name> Date: <date> With: <roles>
Mark: N = need, H = nice to have, - = no
Content
[ ] _ Structured content types of our own (classes with fields) -> guides/content-model-and-editing.md
[ ] _ Versions, drafts, preview, going back to an older version -> help/publishing-and-versions.md
[ ] _ Approval before publishing / scheduled publishing -> guides/workflows.md
[ ] _ Editors build pages from blocks themselves -> help/layouts-editor.md
[ ] _ Rich text editing -> help/editing-content.md
[ ] _ Images and files, uploads in bulk -> help/media-and-uploads.md
[ ] _ Tags / keywords -> features/6.0/extensions/eztags.md
[ ] _ Search -> help/searching.md
[ ] _ RSS feeds / podcasts -> guides/rss-feeds.md
[ ] _ PDF export -> guides/pdf-exports.md
[ ] _ Help writing and translating content (Exponential Intelligence) -> features/6.0/extensions/expai.md
Sites and languages
[ ] _ Several sites from one installation (siteaccesses) -> leadership/multisite-and-multilingual-planning.md
[ ] _ Content in several languages: <list> -> guides/content-languages.md, languages.md
[ ] _ Right-to-left languages -> features/6.0/right-to-left.md
[ ] _ Administration in a language other than English: <language> -> languages.md
Users and access
[ ] _ Editor roles with limited rights -> guides/roles-and-policies.md
[ ] _ Visitor registration -> guides/roles-and-policies.md
[ ] _ Two-step sign-in -> guides/two-factor-login.md
[ ] _ Record of who did what (audit trail) -> features/6.0/audit-trail.md
Commerce and communication
[ ] _ Shop: products, basket, orders -> features/6.0/store-dashboard.md
[ ] _ Newsletters -> features/6.0/extensions/cjw_newsletter.md
[ ] _ Notifications by e-mail -> guides/notifications-administrator.md
[ ] _ E-mail preferences and consent -> features/6.0/mail-preferences.md
Integration
[ ] _ REST API for apps or other systems -> guides/rest-api-v1-and-v2.md
[ ] _ API keys -> guides/api-keys.md
[ ] _ Remote services -> guides/remote-services-and-apps.md
Operations
[ ] _ Database: <engine> -> help/database-support.md
[ ] _ Operating system: <OS> -> help/os-support.md
[ ] _ Web server / Velocity -> guides/deploying.md
[ ] _ Configuration only from version control -> features/6.0/managed-by-deployment.md
[ ] _ Maintenance page during work -> features/6.0/maintenance-mode.md
[ ] _ Backups and restore -> guides/operating-a-site.md
[ ] _ Monitoring and health checks -> guides/system-information.md
Quality
[ ] _ Accessibility level: <level> -> leadership/accessibility-security-and-compliance-checklists.md
[ ] _ Content Security Policy enforced -> features/6.0/content-security-policy.md
[ ] _ Security hardening checklist -> help/security-hardening.md
[ ] _ Performance measured -> guides/benchmarking.md
Open questions (answer with the organization's own experts)
[ ] Privacy: which personal data is stored, for how long, who may see it?
[ ] Legal: accessibility obligations, imprint, consent requirements?
[ ] Hosting: where must data be stored?The paths are relative to doc/ in the repository; in this help each one is a page you can open from the search.
The links: content model and editing,
publishing and versions, workflows,
layouts editor, editing content,
media and uploads, eztags,
searching, RSS feeds, PDF exports,
expai, multisite and multilingual planning,
content languages, languages,
right to left, two-step sign-in,
audit trail, store dashboard,
cjw_newsletter,
notifications, mail preferences,
REST API, API keys,
remote services, database support,
OS support, deploying,
ManagedByDeployment, maintenance mode,
operating a site, system information,
compliance checklists,
Content Security Policy, security hardening,
benchmarking.
Launch checklist
The checklist combines the go-live checklist of the installation book, the first-week checklist and the security checklist of the help. Where a line comes from a page, the page is named after the arrow.
LAUNCH CHECKLIST: <project name> Launch date: <date> Go/no-go: <role>
Two weeks before
[ ] Acceptance signed -> Quality gates and acceptance
[ ] Launch window and rollback decision owner agreed
[ ] Editors trained; each has a personal account with the right role -> Roles and policies
[ ] Content migration finished; content checks show nothing unexplained -> Content checks
[ ] Security hardening checklist worked through -> Security hardening, Checklist
[ ] Go-live checklist of the installation book worked through -> 13.16 Go-live checklist
[ ] CSP reports reviewed; mode decided (report-only / enforce) -> Content Security Policy
[ ] Performance baseline saved (var/benchmark/) -> Benchmarking; 10.15
[ ] Announcement prepared -> Sales and marketing
One day before
[ ] Backup of database and files taken and restored on another machine -> Operating a site, Back up and restore
[ ] Upgrade check (files and database) run and saved -> The upgrade check
[ ] System information: no failure; warnings explained -> System information
[ ] Crontab ready: frequent, the default part, infrequent, cache_cleanup -> 10.15, Cronjobs
Launch
[ ] Maintenance mode on if the switch needs it -> Maintenance mode
[ ] Final deploy done; every step PASS (exp:velocity deploy) -> Deploying, section 7
[ ] Administrator password changed; var/log/initial-admin-password gone -> 10.15
[ ] Debug output off, display_errors=Off -> 13.4
[ ] HTTPS everywhere; secure cookies -> Security hardening, Checklist
[ ] AdminEmail and mail transport set; a test mail arrived in a real inbox -> 10.4, 10.15
[ ] SiteURL set per siteaccess -> System information, Health checks
[ ] Search index complete -> 10.8
[ ] Maintenance mode off
[ ] Smoke test: front page, every siteaccess, every language, sign-in, publish a test item
First week
[ ] Cron logs grow; System information shows recent cronjob runs -> Cronjobs
[ ] Audit: frequent group runs; alert recipients are real people; chains intact -> Audit trail
[ ] Error digest read daily; security.log looked at -> Log viewer, Request logs
[ ] Logs rotate -> 10.15
[ ] Lessons learned recorded; handover document updatedPages: Quality gates and acceptance, Roles and policies, Content checks, Security hardening, 13.16 Go-live checklist, Content Security Policy, Benchmarking, 10.15 A checklist for the first week, Sales and marketing: start here, Operating a site, The upgrade check, System information, Cronjobs, Maintenance mode, Deploying, 13.4, 10.4, 10.8, The audit trail, Log viewer, Request logs.
Handover document
The handover document lets a new team, or the customer's own staff, run and change the site without asking the people who built it. Start it in the first week and keep it current; a handover written in the last week is a memory exercise.
HANDOVER DOCUMENT: <site name> Version: <date> Prepared by: <role> Received by: <role>
1. Overview
Purpose of the site: <one paragraph>
Sites (siteaccesses): <name: address, language(s), design>
Administration address: <address of the admin siteaccess>
Owners: Product owner <role>, technical owner <role>
2. Versions (check: Setup > System information; Setup > Extensions)
Exponential: <version as System information shows it>
PHP: <version> Database: <engine and version>
Web server / engine: <Velocity / Apache with PHP-FPM / ...>
Extensions: <name: version, own or third-party, repository>
3. Code and repositories
Kernel branch: <branch name>, based on <tag or main>
Own repositories: <list with purpose>
Local patches still carried: <list with reason and upstream issue, or "none">
Release owner per repository: <role>
How to deploy: <command and order, e.g. exp:velocity deploy>
4. Configuration
Settings in version control: <where> ManagedByDeployment: <per siteaccess>
Where secrets are kept: <place, never the values>
Audit keys: settings/override/audit.ini.append.php backed up to <place>
5. Content model
Classes and their purpose: <list or link>
Sections, object states: <list>
Workflows: <list>
Languages: <list, main language>
Layouts: <shared layouts, rules>
6. Users and access
Roles and what they are for: <role: purpose, assigned to which groups>
Administrators: <roles of people, personal accounts only>
Two-step sign-in: <who must use it>
Break-glass procedure: <where it is written>
7. Operations
Cronjobs: <crontab lines or groups, schedule>
Backups: <what, when, where, retention>; last restore test: <date>
Logs: <rotation, who reads the error digest, how often>
Audit: <alert recipients (roles), sinks, verify schedule>
Monitoring: <checks and who receives alerts>
Mail: <transport, sender>
8. Quality
Tests: <suites or test files that cover own code>
Performance baseline: <file and date>
CSP: <mode per siteaccess>
Accessibility: <what was checked, when, result>
9. Known issues and decisions
| Issue / decision | Status | Upstream link | Owner |
10. Upgrades
Next planned upgrade: <target version, date>
Notes to read: <changelogs and behavior change notes since the running version>
11. Where to get help
This help (Help in the administration), the forums, the issue trackers -> When something goes wrong
Security problems: privately, as SECURITY.md describes
Sign-off: Handed over by <role, date> Received by <role, date>Pages for the sections: System information, Extensions page, Running a team on Git, ManagedByDeployment, The audit trail, Roles and policies, Cronjobs, Operating a site, Release and upgrade planning, When something goes wrong.
Related pages
- Planning an Exponential project, Project managers: start here
- Risk management for Exponential projects: a register to copy
- Quality gates and acceptance: definition of done and acceptance checklist
- Working together: handoffs between roles
- Measuring a project: KPIs from the product's own logs and audit trail
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.