Updated
On this page
Narrowing projects and programs
How overlapping projects and programs are tidied into a smaller set without deleting anything.
Over time, project and program records can overlap: several generations of taxonomy, duplicate names such as "General", near-duplicates such as "Knowledge Base" and "Knowledge", and one-activity programs that only repeat their activity's title. Narrowing brings them down to a set that is easy to read.
Narrowing proposes lists. Nothing is deleted, activities are moved before any container is retired, and every retired record leaves a pointer to its survivor.
Seven groups
| Group | What it covers | Action |
|---|---|---|
| General | Several projects and programs all named General | Keep the pair that holds the activities; fold the others in |
| Near-duplicate names | Knowledge Base family, Apps Framework variants | Keep the one with the most linked activities; the rest become Merged redirects |
| Empty shells | Active projects with no linked activity | Close with a tombstone line after a link sweep |
| Micro-programs | A program, project and activity sharing one title | Collapse into the owning activity |
| Overlapping generations | Two taxonomy generations both Active | Choose one taxonomy first, then re-parent activities |
| Stale Active shells | Projects untouched since an earlier re-bucket | Confirm against the taxonomy, then close or merge |
| Client one-offs | Closed single-activity client projects | Keep as history, no action |
The target shape
A program exists only if at least two live projects belong to it. A project exists only if it holds two or more activities or has its own phases. A project with one activity collapses to a plain activity.
A three-theme spine fits the observed work: System, Apps, and Business and personal, with methodology and governance, clients and a single General mapped beneath it.
No numeric target is fixed. An early estimate of "about a third fewer programs and half as many projects" had no measured basis and was not adopted. The target is computed after the clear cases are removed and the counts are re-measured.
The procedure
One table per group, with each record, its linked activity count and the proposed action. You answer per group.
For the overlapping generations, you choose the spine.
Activities are re-pointed to their new project and program, marked as manually allocated. Membership counts are re-run.
Retired records are marked Merged or Closed with a pointer. They are moved to the deletion bin only after a link sweep and on your say.
The inventory and the master and portfolio membership checks are re-run.
Re-parenting an activity is allowed whenever the master rule or the taxonomy requires it. See The master rule.