Organizational Theory

Resource technique · See it on the map

Runnable here

Using known patterns of how people and teams behave to decide how to lead the project team.

When to use it

Reach for it when a real structural decision is on the table: whether a cross-functional team should report through the PM or stay embedded in their functional department, how a distributed team's reporting lines should work, or why a team that was productive last month has stalled — a known stage of team formation (forming/storming/norming/performing) explains that far better than a guess about individual performance.

When to avoid it

This is the entry easiest to over-apply. A small, single-team, single-department project doesn't need a theory of organizational design — the reporting line is the department, full stop, and reaching for organizational theory here is over-thinking a question the org chart already answered. Use it when a structural choice genuinely has more than one reasonable answer, not to justify a decision that was obvious anyway.

Steps

1. Name the actual structural question: reporting line, incentive design, or team-stage diagnosis — organizational theory answers different questions differently, and a vague "team isn't working" isn't yet one of them.
2. Check what Driftless's model already fixes for you: a task has exactly one assignee and a project has one accountable department (driftless/models/hierarchy.py), so a matrixed dual-reporting structure is something you manage in conversation and documentation, not something the tool represents.
3. Apply the relevant known pattern — a forming team needs explicit norms more than it needs a pep talk; a team split across two departments needs an explicit escalation path because informal resolution won't cross the department boundary on its own.
4. State the structural decision and the reason for it in the plan, so it can be revisited when the project's shape changes rather than silently persisting past the point it stopped fitting.

What it produces

• A stated, reasoned decision about team structure, reporting, or the team's current developmental stage
• An explicit escalation path for anything Driftless's single-assignee, single-department model doesn't represent on its own

Common pitfalls

• Using organizational-theory language to dress up a decision that was really just convenience, which makes the decision harder to question later because it now sounds authoritative.
• Diagnosing a team as "storming" and treating that as an explanation that excuses inaction, instead of the trigger for the specific facilitation a storming team actually needs.
• Applying a structure that fits a large multi-team program to a five-person project, adding coordination overhead a team that size never needed.

Worked example

A craft brewery's packaging-redesign project pulls two people from marketing and one from operations. Three weeks in, the operations person keeps missing meetings because their department head is unaware they were ever committed. The PM recognizes this as a reporting-line gap rather than a motivation problem, and sets up a standing biweekly check-in with the operations department head — not more meetings for the assignee — to close it.

Source

• PMBOK-6 §9.1.2.3

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.