Projects

Purpose

The Projects domain describes the organization's projects and coordinated initiatives, including how projects are planned, executed, delivered, and connected to the systems and people involved in their work.

Projects provide an organizational context for work that has a defined objective, owner, lifecycle, and expected outcome.

The domain connects project information across coordination, engineering, delivery, and operational systems without making any single platform the source of the entire project record.

Scope

The initial scope includes:

• Projects
• Project owners
• Project status
• Project timelines
• Milestones
• Tasks
• Deliverables
• Project risks
• Project documentation
• Project teams
• Project resources
• Project repositories
• Issues
• Pull requests
• Deployments
• Project related services
• Project events

The domain may later expand as additional project management and delivery information is identified.

Project Identity

A project should have a stable internal identity independent of the systems used to manage or execute the project.

A project may be represented as:

Project
├── project_id
├── name
├── owner
├── status
├── start_date
├── target_date
└── milestones

External platform records are linked to this project rather than becoming the project's identity themselves.

Project Systems

Project information may be distributed across several systems, each remaining authoritative for the information it produces.

Project
    │
    ├── Coordination
    │   └── Mattermost
    │       ├── Team
    │       ├── Channel
    │       ├── Board
    │       └── Playbooks
    │
    ├── Engineering
    │   └── GitHub
    │       ├── Repository
    │       ├── Issues
    │       ├── Pull Requests
    │       ├── Commits
    │       └── CI/CD
    │
    └── Runtime
        ├── Services
        ├── Environments
        └── Telemetry

Mattermost provides the human facing coordination and workflow surface.

GitHub provides the authoritative record of source control and software delivery activity.

Runtime systems provide evidence about what happens after software is deployed.

The Projects domain connects these records around the project rather than replacing their system specific responsibilities.

Project Work

A project contains planned and active work.

A Board represents the current state of that work.

TODO
    ↓
IN PROGRESS
    ↓
REVIEW
    ↓
DONE

Project work may be connected to engineering execution:

Board Task
    ↓
GitHub Issue
    ↓
Pull Request
    ↓
Commits
    ↓
CI
    ↓
Deployment
    ↓
Verification
    ↓
Task Completion

These relationships allow the organization to understand how planned work progresses into implemented and deployed work.

Milestones

Milestones represent significant project outcomes or delivery points.

A technical deployment does not automatically constitute milestone completion.

For client projects, a milestone may require verification, testing, evidence, and approval before it is considered achieved.

A completed milestone may therefore become an organizational event that can be consumed by other domains.

For example:

Deployment
    ↓
Verification
    ↓
Approval
    ↓
Milestone Completed
    ↓
Finance

The Projects domain establishes that the milestone has been achieved.

Other domains remain responsible for their own downstream activities.

For example, Finance remains responsible for invoicing rather than the Projects domain becoming responsible for financial processing.

Project Events

Project execution should increasingly be represented through observable events rather than manual duplication.

Examples include:

project.created
mattermost.task.created
mattermost.task.updated


github.issue.created
github.pull_request.opened
github.pull_request.merged
github.workflow.completed


deployment.started
deployment.completed
deployment.failed


milestone.completed

These events provide evidence from which the project lifecycle can be reconstructed.

Cross Domain Relationships

Projects are expected to interact with other organizational domains.

Examples include:

Projects
    ↓
Milestone
    ↓
Finance

Projects
    ↓
Product
    ↓
Release
    ↓
Runtime

Projects
    ↓
People
    ↓
Project Team

Projects
    ↓
Observability
    ↓
Service Performance

The Projects domain provides the project context while the related domains remain responsible for their own concepts and measurements.

Initial Concepts

The existing organizational ontology already provides several concepts that are directly relevant to Projects:

• Organization
• Person
• Team
• Product
• Process
• System
• Document
• Metric
• KPI

The Projects domain additionally requires project specific concepts such as:

• Project
• Milestone
• Task
• Deliverable
• Project Risk
• Project Event

These should not automatically be promoted into the core ontology.

They should first be treated as domain concepts and promoted only if their semantic scope proves to extend beyond Projects.

Data and Knowledge

The Projects domain is expected to connect structured project information with operational evidence and project documentation.

Project
    ↓
Work
    ↓
Execution
    ↓
Delivery
    ↓
Operational Evidence

This allows the organization to understand not only what a project contains, but how the project actually progresses.

The initial operational data model emphasizes evidence and relationships rather than analytics or intelligence.

Metrics, KPIs, and Data Assets

Canonical metrics and KPIs for this domain are now maintained in the Data Dictionary and published at:

• Projects metrics
• Current Definitions

KPIs currently defined for this domain: Project Delivery Performance, Project Delivery Risk, and Project Schedule Performance.

The underlying data is maintained as Project Management Records.