Organizational chart
Show roles and relationships with an explicit line meaning, keeping project coordination, personnel reporting and decision rights distinct.
Use an organizational chart to explain which roles exist and how reporting or coordination works. Define the scope before choosing a hierarchy or matrix. This example is a proposed project-coordination tree, with personnel lines recorded separately. Task responsibilities require a separate agreement.
The organization or project scope, roles, supported duties, reporting and coordination relationships, staffing status and uncertain authority.
A role chart with defined lines, an authority and interface note, unconfirmed relationships and a review plan.
How to use it
- Define the audience, scope and actual or proposed status.
- List roles, duties and known rights, separating roles, headcount and available effort.
- Draw and label relationships, distinguishing project coordination, personnel reporting and consultation where needed.
- Retain cross-role interfaces and unconfirmed authority rather than inferring them from position.
- Ask the roles to confirm the chart and its maintenance, then agree task responsibilities separately.
Keep its limits in mind
Position is neither a measure of ability nor a grant of budget or approval rights. Separate proposed lines, actual reporting and personnel management. Retain cross-functional relationships rather than forcing them into a tree. Confirm R/A/C/I for individual deliverables separately.
Mapping project coordination for the booking pilot
Fictional teaching example: Pinebridge is preparing a booking-service pilot. Packet F0 records one mature W0 cohort: 100 eligible requests, 60 confirmed bookings and 48 completed services within those 60. The future pilot, staffing and plans are unapproved and unexecuted.
On a small screen, scroll across the diagram to read it.
Select the scope: The diagram concerns project preparation, not the whole company. Lines propose coordination through the Lead; personnel relationships are deliberately not inferred.
Preserve authority: F0 assigns the pilot decision to the Sponsor. The Lead prepares and coordinates, while Analyst, Builder and Ops have specialist work. A higher position does not create a new approval right.
Result: The output is a proposed role chart and an interface check. Role acceptance, staffing, capacity, personnel lines and budget rights still need confirmation; no authorization has been added.
This is proposed project coordination, not a confirmed staffing structure or approval chain. Five roles do not establish five available people.
Next step: The Lead should confirm role interfaces and the distinction between project and personnel reporting, then agree responsibilities for A–E.
Three reasons a clear-looking tree can mislead
First, pause if the lines have no declared meaning. Personnel reporting, project coordination, specialist advice, and approval authority are different relationships. A simple tree can be appropriate for one of them while concealing another. State the scope and line meaning before arranging the boxes, and retain cross-team relationships that the tree cannot show.
Second, do not interpret a box as a staffed person. A role may be vacant, shared, or proposed for someone who has not accepted it. Keep role definitions, named appointments, availability, and acceptance separate. Five role boxes cannot establish five available people or a full working week for each.
Third, stop when vertical position is being used to infer permission. Coordinating a developer does not automatically grant authority to approve a pilot, spend a budget, or change someone’s personnel reporting. Check the actual decision right and record it explicitly. A chart can help people find the right conversation; it cannot create an authorization that the organization has not given.
Choose relationships, task responsibility, stakeholders, or capacity
Use an organizational chart to explain a defined set of role relationships. It can accompany other records, but each must retain its own purpose and confirmation status. Do not make a more elaborate diagram stand in for missing agreement.
| Material and question | Method | Output and boundary |
|---|---|---|
| Roles need a declared relationship within a scope | Organizational chart | A scoped role map; not every approval right or actual staffing. |
| Deliverables need execution and approval assignments | RACI matrix | Task responsibilities to agree; not inferred from hierarchy. |
| Affected people and decision interests are unclear | Stakeholder analysis | An engagement and authority investigation; not a reporting tree. |
| Work has durations, dependencies, and resource assumptions | Gantt chart | A conditional schedule and capacity checks; not a personnel structure. |
Read Pinebridge’s proposed chart with the role card beside it
The fictional Pinebridge packet concerns preparation for a booking pilot. Its mature W0 cohort has 100 eligible requests, 60 confirmed bookings, and 48 completed services within those 60. Those service records are background, not a staffing calculation. The future pilot and the proposed role arrangements remain unapproved and unexecuted. The chart is a project-coordination tree from Sponsor to Lead to Analyst, Builder, and Ops; personnel reporting is not supplied.
The role card assigns the pilot scope and authorization decision to the Sponsor. The Lead prepares decision material and coordinates A–E. In the shared teaching plan, A concerns definitions, B configuration, C the operating checklist, D joint rehearsal, and E the pilot decision. The Lead’s place above the specialists does not transfer the Sponsor’s decision right. Preparing E and deciding E are different contributions.
The Analyst’s A work is estimated at eight hours. Builder and Ops each have an assumed four hours per working day in this chart’s preparation notes; those availabilities are unconfirmed. The notes propose Builder work on B and D and Ops work on C and D. Do not turn these assumptions into accepted assignments or use another role’s daily availability to convert the Analyst’s estimate into a promised duration.
| Role | Supplied role or proposal | What the chart does not establish |
|---|---|---|
| Sponsor | Decides pilot scope and authorization | No pilot approval, budget delegation, or accepted attendance supplied. |
| Lead | Coordinates A–E and prepares decision material | Cannot decide for Sponsor; personnel authority unknown. |
| Analyst | Proposed A definitions; eight-hour estimate | Named person, accepted work, and actual capacity unconfirmed. |
| Builder | Proposed B configuration and D rehearsal | Four hours per workday is an assumption, not a commitment. |
| Ops | Proposed C checklist and D rehearsal; booking-rule checks | Capacity and handoffs need agreement; personnel line unknown. |
Confirm interfaces before calling the team ready
The output is a proposed coordination map plus an interface check. Ask the relevant people to confirm what each relationship means, which role they would accept, and who holds specific decision rights. Record actual answers separately from the proposed boxes. If one person would fill more than one role, check conflicts and total capacity instead of treating the five boxes as five independent resources.
For the proposed deliverable review, connect each A–E output to the people preparing it, reviewing it, and deciding it. Confirm how Builder and Ops coordinate the joint rehearsal and who resolves an unresolved booking rule. Use an agreed responsibility record where appropriate; do not silently assign the approval column to the highest box below Sponsor. Budget rights and external interfaces remain separate checks.
At review, distinguish a corrected chart, accepted roles, confirmed capacity, and actual pilot authorization. Each needs its own evidence. A beautiful chart with unaccepted work is still a proposal, while a confirmed project role need not change anyone’s personnel manager. No staffing acceptance, successful rehearsal, or pilot result is supplied here. Update the map with its scope, status, and reason for changes rather than retrospectively presenting the proposal as the organization that already existed.
Check your work
- Scope, status, roles and line meaning are clear.
- Project relationships, personnel relationships and authority boundaries remain separate.
- Roles and effort are not presumed accepted; delivery responsibilities are maintained separately.
Framework references
References explain the framework and its scope; they do not validate the fictional example's results.
Put the framework to work
Copy the outline and add your question, evidence, and open questions.