02How it works
From empty workspace to a reviewed team
How does work move from a requirement to an accepted allocation?
- Inputs
- A project's technologies and team roles, and the organization's people, skills and capacity.
- Governed decision
- A department manager accepting or rejecting a specific request for specific hours.
- Output
- An allocation on the project team, or a rejection with a reason recorded against it.
The flow, drawn
Five stages, and the two line styles that carry the whole distinction.
Project requirements produce evidence, evidence ranks candidates, a proposal goes to the owning department for review, and only an accepted proposal becomes part of the active team. Three candidates are ranked by score; the highest, Mert Aydogan at 80, is marked with a bar beside the row and is the one proposed. Proposals are drawn as dashed lines and accepted allocations as solid lines.
- An accepted allocation is drawn solid. It is the only line that means somebody is on a project.
- A proposal stays dashed until the owning department accepts it. Dashed means asked for, not agreed.
- Nobody joins a team silently. There is no path from a ranking to an allocation that skips the review.
Five stages
One sequence, with the same five stages every time, and a named owner at the point where a decision is actually made.
- 01
Requirement
Technologies and team roles a project needs, with hours.
- 02
Evidence
Skills, past projects and current capacity, read from the record.
- 03
Ranked candidates
A score out of 100 the project manager can read line by line.
- 04
Department review
The department that owns the person accepts or rejects.
- 05
Accepted allocation
Only an accepted proposal becomes hours on a project.
Seven steps, and who answers for each
The sequence an organization actually performs, with the record each step leaves behind.
- 01
Create workspace
One organization, with the first administrator who owns its structure.
- Owner
- Organization admin
- Produces
- An organization, and its first administrator.
- 02
Organize departments
Departments hold people and review the staffing requests made against them.
- Owner
- Organization admin
- Produces
- Departments, each with a manager to appoint.
- 03
Build skills
A curated catalogue, so two people describing the same ability agree.
- Owner
- Department manager
- Produces
- A shared catalogue of categories and skills.
- 04
Define requirements
Technologies and team roles a project needs, and how many hours.
- Owner
- Project manager
- Produces
- Technologies and team-role requirements on a project.
- 05
Run Team Finder
Candidates ranked against those requirements, the same way every time.
- Owner
- Project manager
- Produces
- Ranked candidates. Nothing is written.
- 06
Review staffing
The owning department accepts or rejects, against real capacity.
- Owner
- Department manager
- Produces
- An acceptance, or a rejection with a reason.
- 07
Team updated
Only an accepted proposal becomes an allocation on the project.
- Owner
- Department manager
- Produces
- An allocation — the only way onto a team.
A worked example
Illustrative data, not a customer or a production result. It is the same example the diagram above draws.
- RequirementProject Orion needs Java, PostgreSQL and React, and is short two Backend Engineers.
- EvidenceSkills matched, past projects checked, current capacity read.
- Ranked candidatesThree candidates scored; the highest scores 80 out of 100.
- Department reviewPlatform Engineering weighs the request against that person's real week.
- Accepted allocationSix of eight hours a day, recorded against Project Orion.