Portfolio Structure Rationale

This note explains the logic behind the current portfolio structure.

Why the portfolio needed reshaping

The earlier version mixed together several different things:

• long-lived initiatives and short-lived projects
• internal capability-building and external offers
• concrete items and vague bucket names

That made the portfolio harder to scan and harder to maintain.

Current top-level shape

The portfolio is now structured around two main buckets:

• External Offers
• Internal Systems

This is meant to make the strategic picture legible at a glance:

• what we offer to the outside world
• what internal systems support that work

Within External Offers, we currently distinguish:

• Core Data Infrastructure
• AI-Native Offers
• Flowershow

Within Internal Systems, we currently distinguish:

• RFP and Proposal System
• Company Operating System

Design principles

1. Distinguish initiatives from projects

• An initiative is enduring. It represents an ongoing capability area, product, service, or internal system.
• A project here is bounded, core, cross-cutting company work outside routine delivery, with a clear definition of done and a parent initiative. Campaigns, releases, monthly cycles, and delivery tasks belong in execution trackers linked from the initiative.

Examples:

• Company Operating System is an initiative
• Portfolio and Plans KB rollout is a core company project
• PM Enablement / PM System is an initiative

2. Every project should have a clear parent

Projects should not float on their own unless there is a strong reason.

This makes the structure easier to understand and reduces duplication.

Examples:

• CRM Setup v0.1 belongs under Lead Flow and CRM System
• Volume and Velocity belongs under Social Media Posting
• Portfolio and Plans KB belongs under Company Operating System

3. Use concrete names instead of vague buckets

Names like Marketing Improvement or Marketing Backend are too broad unless they point to a clearly defined system.

The structure should prefer names that immediately communicate purpose:

• Company Operating System and its active child initiatives
• Management Metrics / Financial Visibility

4. Separate internal and external work clearly

The portfolio should make it easy to distinguish between:

• products and services offered externally
• internal systems that improve how the company works

This matters because they are managed differently and serve different purposes.

5. Reflect the current company strategy

The external side is not one flat list.

It currently needs to show:

• the core business we already rely on
• the newer AI-era offers we are developing
• adjacent offers that do not neatly belong in the AI bucket

That is why:

• CKAN, PortalJS, and DataHub sit under Core Data Infrastructure
• Queryless, Unlock Data with AI, and AutoClaw sit under AI-Native Offers
• Flowershow sits separately under External Offers

6. Allow hierarchy where it helps

Not all items should sit at the same level.

Some initiatives are umbrella groupings and need sub-initiatives beneath them. This is especially useful for internal work, where several related systems are part of a broader function.

CKAN delivery and community stewardship are consolidated under the CKAN initiative.

Intended outcome

The reshaped portfolio should be:

• easier to scan quickly
• easier to extend
• easier to maintain
• clearer about what kind of work each item represents

It should function as a practical navigation tool, not just a list.