For the complete documentation index, see llms.txt. This page is also available as Markdown.

What Are Blueprints?

Understand why Blueprints exist and how they standardize delivery structure across Projects.

Overview

Blueprints define reusable structure for Project delivery work. They standardize naming, hierarchy, and reporting fields.

Key Concepts

  • Blueprint: reusable structure applied to new Projects

  • Process: business workflow, phase, or workstream tracked in a Blueprint

  • System: application or platform linked to Processes

  • Hierarchy: parent-child structure used for rollups

How It’s Used

Create one Blueprint per delivery method. For example: an ERP implementation approach.

Reuse the Blueprint to create multiple Projects with consistent structure.

Benefits

  • Faster Project creation with fewer setup decisions

  • More consistent reporting across Projects

  • Cleaner governance through standardized structure

Setup Steps

  1. Create a Blueprint.

  2. Define Processes and hierarchy.

  3. Add Systems and System Types.

  4. Define segmentation when reporting requires it.

Best Practices

  • Keep Blueprints reusable and avoid client-specific naming.

  • Use hierarchy for rollups, not for single tasks.

  • Document naming conventions in an internal SOP.

Summary

Blueprints are reusable templates for Projects. They define Processes, Systems, and hierarchy for consistent execution.

Related:

Last updated