# Project model theories

## Areas of Operation (AOs)

The system divides out the roles and responsibilities to specific individuals:

1. Designate sub-leaders who are exclusively responsible for specific, non-overlapping domains.
   - The domains can be contiguous (shares a boundary with other sub-leaders) or non-contiguous (not sharing a boundary).
2. That sub-leader is responsible for that domain, and their management performance is defined by their results.
   - If any members fail, that sub-leader is exclusively responsible.

While the system works *very* well for clearly defined goals with clearly-defined actions (e.g., military activities), it's very inflexible to changes and doesn't accommodate the individuals' situations or ideas.

## The Waterfall model

The system step-by-step sequence across 5 phases to carry the project to completion:

1. Requirements - outline the high-level conditions that determine a project's success.
2. Design - create solutions that meet the requirements, often considering backup plans as well.
3. Implementation - pick a design and use [technology](technology.md) to apply it.
4. Verification - test whether the implementation worked.
5. Maintenance - keep testing and [fixing anything that breaks](https://adequate.life/fix/).

It requires specific goals from the very beginning.

- It works on hard deadlines and treats every task as "final".
- Any failures from previous process steps roll into later process tasks.

This system doesn't handle unexpected problems very well.

## Objectives and Key Results (OKR)

The system is designed to achieve clearly-understood purposes:

1. Make an objective that is significant, concrete, and clearly defined.
   - Further, the objectives should inspire everyone working toward them.
   - Avoid a "business as usual" attitude, which means avoiding vague words like "help" and "consult".
2. Each objective should have 3-5 key results, which are measurable either as 0-100% or a numerical value.
   - Aim to measure leading indicators (readily measurable things) instead of lagging indicators (things that measure after a lead time).
   - The target success rate for key results should be 70%, since it encourages competitive goal-making.
   - If the key results are consistently hit at 100%, they should be re-evaluated.
3. If necessary, objectives can be supported by initiatives, which are plans and activities that help move forward the objectives and key results.

One of the downsides of the system is that on the individual level the entire project simply looks like a task list, which makes it very easy for managers to conflate OKRs with performance reviews.

## Agile methodology

The system is designed for when project goals aren't entirely clear:

1. Break the project into sub-projects, called "sprints".
2. At the end of a sprint, everyone reviews the work and makes adjustments for the next sprint.
3. In difficulties come in the middle of a sprint, make smaller sub-projects within that sprint with newer, smaller goals.
4. Repeat until complete.

The original idea was from [software development](computers-programming.md), where the goals and possible risks aren't always perfectly clear.

- The system revises every development stage as the situation changes.
- Other variations of Agile like [Scrum](https://www.scrum.org/) or [Lean](https://www.lean.org/WhatsLean/) add more structure.

## Holacracy

[The system](https://www.holacracy.org/) is a very flat management structure designed around a constitution made of 5 modules, which everyone is expected to follow:

1. Organizational structure
   - Defines an exact format for roles, responsibilities, and rules.
2. Rules of cooperation
   - Defines what everyone should expect from each other.
   - Clarifies duties involving everyone being transparent with each other, how they process others' requests, and how everyone should prioritize work.
3. Tactical meetings
   - Gives specific standards for how to run meetings and keep them efficient.
   - Also prevents from anyone dominating the meeting or distractions about unrelated discussions.
4. Distributed authority
   - Speeds tasks up by granting partial autonomy without needing prior approval.
   - Creates constraints to prevent abuse of that autonomy.
5. Decentralized governance process
   - Creates a process for making improvements or changes within the scope of each person's work.
   - Gives limits to prevent anyone abusing the governance process.

The system gives everyone power to self-manage, which is a very effective system if everyone is trustworthy to self-direct.

- If everyone depends heavily on each other, though, it can cause severe breakdowns in communications and activities and be *worse* than micromanagement.