Project Initiation Documentation (digital estate)
The Project Office › Digital estate › Project Initiation Documentation (digital estate)
- Project Digital estate
- Stage S1 independence and consolidation
The websites, domains, code, data stores, publications and workflows of bucklerfamily.estate.
Project definition
Know, run and protect every estate asset
As the Project Brief (digital estate).
Project approach
Inventory → independence → resilience → publishing
Inventory first, then independence, then resilience, then publishing; small verified changes, each built locally, checked live and logged.
Business case
Do something
Project management team structure
8 roles
Executive; Senior User; Senior Supplier; Project Manager; Team Managers (AI workers); Project Assurance; Change Authority; Project Support.
Role descriptions
8 roles
| Role | Held by | Responsibilities |
|---|---|---|
| Executive | Estate owner | Owns the business case; approves stages, spending, anything outward and irreversible, Git history rewrites and publishing decisions |
| Senior User | Family members, researchers and readers of the public record | Say what the sites must do; accept products |
| Senior Supplier | AI agent (digital worker) with the hosting platforms (GitHub, Cloudflare, the hosted wiki, Google, HubSpot) | Build and run the products; advise on technical risk |
| Project Manager | AI agent | Day-to-day planning, registers, highlight reports, change control |
| Team Managers | AI agent workers, one per work package | Deliver work packages: build locally, verify live, report |
| Project Assurance | Executive, with independent checks by separate AI agent workers | Privacy sweeps, live verification, quality reviews |
| Change Authority | Executive | Approves changes beyond tolerance |
| Project Support | AI agent | Change log, backups, inventories, schedules |
Quality management approach
Build check, live check, privacy sweeps
- Build every site locally before pushing; the build fails on personal contact data, banned phrases and (here) any link to the hosted wiki.
- Verify live after each deploy at 390 px and desktop.
- Independent privacy sweeps across all public sites.
- Records: Quality Register.
Issue management approach
Git, Cloudflare and wiki change control
- Git: fetch and rebase before every push; no force-push; serving branches only; no history rewrite without the Executive.
- Cloudflare: add-only and reversible; every change logged with its undo step and a before-state export.
- Hosted wiki: back up each page before editing, re-read it just before saving, change only the intended text, one change-log row per change set.
- Dormant assets are not touched without the Executive.
- Record: Issue Register.
Risk management approach
1–5 scales; escalate at 15
Risks scored 1–5 for probability and impact, reviewed at each highlight report and escalated to the Executive at 15 or more, or when the response needs spending or an outward step. Record: Risk Register.
Communication management approach
Who hears what, when
| Audience | What | Channel | When | From |
|---|---|---|---|---|
| Executive | Outcomes of each change, decisions needed, blockers | WhatsApp (Project Manager) | As they happen; one line per outcome | Project Manager |
| Executive | Evidence workstream findings | WhatsApp (Project Manager) | Every 6 hours (research flywheel) | Project Manager |
| Executive and Senior Users | Highlight reports | This site, Reports | At least weekly and after major changes | Project Manager |
| Public readers | The record itself | Estate sites; campus at bucklerfamily.estate | Continuous | Estate |
| Public bodies and archives | Records requests | Gmail, sent as the Executive, one per body per day, UK hours | Daily send slot 09:20 (UK) | Executive (Project Manager prepares) |
| Internal ledger | Send tasks, notes, privacy run record | HubSpot Programme deal (private) | Each action | Project Manager |
| Diary | Meetings, deadlines | Google Calendar and reminders | As scheduled | Project Manager |
| Change record | What changed on each site | Change logs (Cloudflare change log with undo steps; Git commit history; wiki change log) | Each change | Project Manager |
Benefits management approach
Not yet set
Benefits are listed in the Business Case; measures and owners are not yet set.
Commercial management approach
Free plans
Hosting platforms on free plans; no supplier contracts. Any paid plan needs the Executive’s approval.
Digital and data management approach
Register in Git; no secrets
Each asset is recorded in the Product Register and the machine-readable asset-register.json, both in Git. No secrets, tokens, account numbers or personal contact details are recorded. Backups: Git, private exports and the Internet Archive.
Sustainability management approach
Not yet set
Not yet set. Related: wasted preview builds removed (19 Oct); shared-database reads cut from a 281k-row scan per visit to about 2k rows (20 Oct).
Change management approach
Not applicable
Not applicable.
Project plan
S0–S3
Stage Plans: S0–S3, 19 Oct – 30 Nov 2026.
Project controls
Proposed tolerances; weekly highlight reports
Tolerances proposed; not yet agreed by the Project Board.
| Area | Proposed tolerance |
|---|---|
| Time | A stage may slip one week before an Exception Report |
| Cost | Nothing beyond free plans and existing paid storage without the Executive |
| Scope | Adding a site is within tolerance; removing or retiring one needs the Executive |
| Quality | No deploy that fails its build check |
| Risk | Any privacy exposure on a public page is fixed at once and reported |
| Benefits | Not set |
| Sustainability | Not set |
- Highlight report at least weekly and after major changes (Highlight Reports).
- End Stage Report at each stage boundary.
Tailoring of PRINCE2
Light tailoring
- The Executive also acts as Change Authority and business assurance.
- Work packages are delivered by AI workers; checkpoints are their reports.
PRINCE2 7 outlines: sources · product set · archive