Skip to main content

GUIDEcx Object Hierarchy

Learn how each object within GUIDEcx relates to another. Also learn how dependencies can work

Elan Maynez avatar
Written by Elan Maynez
Updated over 2 weeks ago

1. Project Structure

Effective project management hinges on clear structure and well‑defined relationships between work items. In this article, we’ll explore a five‑level hierarchy—Project, Phase (Template), Milestone, Task Group, and Task—and explain how dependencies fit into the picture. By the end, you’ll have a solid grasp of where everything lives and how to coordinate work so nothing falls through the cracks.


The Five Levels of Structure

1.1 Project

The Project is your top‑level container. Think of it as the overall initiative—whether you’re launching a new product, running a marketing campaign, or implementing a software upgrade. Everything else nests inside the Project.

1.2 Phase (Template)

A Phase (also called a Template) represents a major stage of work. Examples include “Discovery,” “Design,” “Development,” and “Launch.” You can create as many Phases as your project needs. Phases help you map out the big-picture roadmap.

1.3 Milestone

Within each Phase, you define Milestones—key checkpoints or deliverables that mark progress. For instance, under a “Design” Phase you might have “Wireframes Approved” or “Style Guide Finalized.” Milestones give you concrete targets and help you measure progress.

1.4 Task Group

A Task Group sits under a Milestone and organizes related Tasks. If a Milestone is “API Ready,” you could have Task Groups like “Authentication Endpoints,” “Data Validation,” and “Error Handling.” Task Groups keep large sets of Tasks from becoming overwhelming.

1.5 Task

At the bottom of the hierarchy is the Task, the smallest unit of work. Tasks might be “Implement login endpoint,” “Write unit tests for data models,” or “Deploy to staging.” Tasks can belong to a Task Group OR exist alone under its parent Milestone and Phase.

PROJECT
├── Phase (aka Template)
│ ├── Milestone
│ │ ├── Task Group
│ │ │ ├── Task
│ │ │ └── Task
│ │ └── (more Task Groups)
│ └── (more Milestones)
└── (more Phases)

2. Why This Structure Matters

  1. Clarity: Everyone knows exactly where their work fits.

  2. Accountability: Tasks roll up into Groups, Milestones, and Phases, making it easy to see who’s responsible for what.

  3. Scalability: Whether your project has 10 tasks or 1,000, you can maintain order by grouping and nesting.

  4. Reporting: You can track completion at the Task level, then see aggregate progress at Milestones and Phases.


3. Task Dependencies: The Rules of Engagement

Dependencies ensure work happens in the right order. In our model:

  • Only Tasks can have dependencies.

  • A Task can depend on:

    • Other Tasks (today it's just tasks that are in front of the task)

    • Entire Task Groups (which implicitly means all Tasks in that group must finish first)

    • Milestones (all Tasks under that Milestone)

    • Phases/Templates (all Tasks in that Phase)Example:

  • Task “Deploy to Staging” can’t start until Milestone “Code Complete” is reached.

  • Task “User Testing” can depend on the entire “Build” Phase.


4. How to Use Dependencies

  • Sequencing: If “Deploy to Production” can’t happen until “User Testing” is done, set the former Task to depend on the latter.

  • Bulk Blocking: To pause a set of tasks until a Phase completes, have each Task depend on that Phase.

  • Milestone‑Level Coordination: If Milestone B shouldn’t start until Milestone A is reached, add dependencies from each Task in B to Milestone A.


5. Best Practices

  • Define clear Milestones: Keep them outcome‑oriented (e.g., “Beta Release” vs. “Complete Task List”).

  • Limit Task Group size: Aim for 5–10 Tasks per group for manageability.

  • Review dependencies regularly: As priorities shift, update or remove outdated links.

  • Use naming conventions: Prefix Tasks with their group or milestone code to speed up searches and filtering.


6. Putting It All Together: A Sample Workflow

  1. Project “Website Redesign”

  2. Phase: Design

    • Milestone: Wireframes Approved

      • Task Group: Homepage Layout

        • Task: “Draft homepage wireframe”

        • Task: “Review wireframe with stakeholders”

      • Task Group: Navigation Menu

        • Task: “Design menu mockup”

        • Task: “Incorporate feedback”

  3. Phase: Development

    • Milestone: Front‑End Complete

      • Task Group: HTML/CSS

        • Task: “Convert wireframe to HTML”

        • Task: “Add responsive breakpoints”

      • Task Group: JavaScript

        • Task: “Implement menu toggle”

        • Task: “Write unit tests”

    • Milestone: Back‑End Ready

      • (And so on…)

In this workflow, if you want Development to wait until Design is fully approved, you’d set each Task in the Development Phase to depend on the “Wireframes Approved” Milestone (or the Design Phase itself).


Conclusion

By structuring your work into Project → Phase → Milestone → Task Group → Task and applying Task‑level dependencies, you gain clarity, control, and flexibility. Whether you’re coordinating a small team or a large organization, this model scales—and keeps everyone aligned on what needs to happen, when, and in what order.

Object

Contains

Can Depend on (via Tasks)

Project

Phases (Templates)

NA

Phase (Template)

Milestones

NA

Milestone

Task Groups + Tasks

NA

Task Group

Tasks

NA

Task

NA

Tasks, Task Groups, Milestones, Phases (Templates)

Did this answer your question?