Project Management — An Introduction

A. Structure — Breaking Down the Work

"Even the longest journey is done step by step."

The most important skill in project management is breaking big, ambitious goals into smaller, manageable pieces. Without structure, you're staring at a mountain of work with no idea where to start. With structure, you have a staircase.

Start with a Brainstorm

Before any structure exists, dump everything out of your head. What needs to happen? What's the end result? What are the big chunks? Write it all down — Post-its, a whiteboard, a brain dump tool. Don't organize yet. Just capture.

Then group, order, and refine into a hierarchy. Alone, or better, with those involved.

The Hierarchy

Every project follows a simple top-down structure. Rocket Project supports two naming conventions — choose the one that feels natural for your project:

Milestones vs. Epics — What's the Difference?

Both live at the same level, but they slice the work differently:

• Milestones are usually time-bound — steps on the road toward a goal. Think of the Roman milestones marking distance from A to B. For Victoria's mansion: Ground Floor Done → First Floor Done → Roof On → Interior Finished.
• Epics are usually topic-bound or team-bound — clusters of deliverables that require the same competencies or belong together. For Victoria's mansion: Foundation & Site Prep, Structural Framing, Plumbing & Electrical, Windows & Doors, Interior Finishing.

You can mix them. Some goals have milestones, others have epics. Pick what makes the work clearest for your team.

The Work Item (Story) — Where Value is Delivered

This is the most important level. A work item describes what needs to be done and why it matters. In agile, it's called a "Story" because it's told from the perspective of the person who benefits:

The "in order to" part is crucial — it forces you to think about the purpose of the work, not just the activity.

B. Planning — Putting Work on a Timeline

Structure tells you what needs to happen. Planning tells you when and in what order. The two main approaches handle this very differently.

Conventional Planning (Waterfall)

Plan all the work upfront. Estimate how long each piece takes, figure out who's available (capacity), account for dependencies ("the roof can't go on before the walls"), and work backwards from the deadline to calculate start dates. The result is typically a Gantt chart — a long bar chart showing what happens when.

Works well when the work is predictable and changes are unlikely. Less useful when requirements evolve or surprises are common.

Agile Planning (Sprints)

Instead of planning everything at once, you plan in short, fixed cycles called Sprints. A sprint is typically 2–3 weeks. The question that defines the sprint length: "In what timeframe can we realistically deliver something of value?"

Before each sprint, you choose which work items to commit to. At the end of the sprint, you deliver working results. Then you plan the next sprint. This creates a continuous flow of value — instead of one big delivery at the end.

The Backlog

The Backlog is simply the list of all work that still needs to be done. Think of it as a prioritized to-do list for the entire project. There are two flavors:

• Product Backlog — everything that still needs to happen, ordered by priority. This is the full wish list.
• Sprint Backlog — the subset of work items selected for the current sprint. This is the team's commitment for the next 2–3 weeks.

Sprint Planning

At the start of each sprint, the team picks items from the product backlog and moves them into the sprint backlog. The key question: "What can we realistically finish in this sprint?" Not: "What do we wish we could finish?" Honest planning beats optimistic planning.

C. Ceremonies — The Music We Play to Dance the Dance

"Ceremonies" is a fancy word for meetings with a purpose. They exist to make sure everyone knows what to deliver, how it will be done, and who does what. In the meeting: the people doing the work, the one organizing and responsible for progress, and the one(s) receiving. They are the rhythm that keeps the project moving.

You don't need all of them. Use what helps, skip what doesn't. A solo project might only need sprint planning and a weekly self-review. A team of 13 probably needs the full set.

D. Progress & Results

How do you know where you stand? By looking at statuses. Every item in the project has a status that tells you whether it's waiting, in progress, or done.

Statuses and Their Meaning

Statuses aren't bureaucracy — they're communication. A quick glance at a project board should tell anyone: "Where are we? What's moving? What's stuck?" The typical progression:

"Done" means the work is finished. "Closed" means it's been reviewed and accepted. There's also "Waiting" (blocked on something) and "Cancelled" (decided to be not needed anymore).

Manual and Automatic Statuses

Work items (stories) and tasks have manual statuses — a person responsible for delivery sets them. The status of milestones (epics) and goals (initiatives) are determined by the status of their children. When all work items under a milestone are done, the milestone becomes "done" — without anyone clicking a button.

Why? Because the milestone status should reflect reality, not someone's optimistic interpretation of it. If three out of five work items are done, the milestone is "in progress" — period.

Sprint Evaluation

At the end of each sprint, the team reviews: What was delivered? What wasn't? Why not? What can we improve? This is not about blame — it's about learning. Each sprint should be a little better than the last. This is a great way to improve "flow", the effectiveness within the project.

A Word on Sprint Points

Some teams assign "points" to work items to estimate effort. This effort can be based upon capacity needed, complexity, or both. Beware: this means that time needed in capacity, and time in duration are mixed, leading to fuzzy information. If you use points, use them honestly. If they create more confusion than clarity — skip them. They're optional, not essential.

E. Constraints — The Boundaries You Can't Ignore

Every project operates within boundaries. Understanding them — and managing the trade-offs between them — is perhaps the most important job in project management.

The Devil's Triangle

The classic model: Scope, Time, and Budget. You can optimize for two, but the third will suffer. Want more features (scope) in less time? It'll cost more. Want it cheap and fast? You'll have to cut scope. This isn't pessimism — it's physics.

The Devil's Square

A more realistic version splits Scope into Quantity and Quality, adding a fourth dimension. Now the trade-offs are between Quantity, Quality, Time, and Budget. Want to deliver everything on time and within budget? Quality might drop. Want top quality within budget? You'll need more time or less quantity.

How to manage them: Be explicit. At the start of the project, decide which constraints are fixed and which are flexible. If the deadline is immovable, scope becomes your pressure valve. If quality is non-negotiable, time or budget must flex. Knowing this upfront prevents painful surprises later.