OPS.2 - Select Work-Management Views and Coordination Methods

OPS.2:0 - Use This When

Use this pattern when the same continuing Work is being called a project, process, case, workflow, queue, programme, or control loop and that choice changes coordination. Enter when one view hides a decision that another exposes: a process map may not show a permissible next action for an exceptional case, a project plan hides recurring service, a case file hides aggregate load, a queue hides commitments and subject state, or a loop diagram hides the operating account.

The first useful move is a question-to-view decision:

For decision D about subjects S at grain G, use view V and coordination Method M under conditions C; relate it to views V2... through these subject correspondences, commitments, handoffs, coexistence rules, and stop conditions.

This result need not select one permanent mode. It may choose one view, several compatible views, or no new view when the existing coordination already answers the question.

Recognition is cheap: enter when practitioners disagree about “what kind of Work this is” or cannot answer a current question from the existing view. Assurance is heavier: selected structures, direct relations, Work, Methods, planning claims, control claims, rates, authority, safety, and evidence keep their own FPF or specialist tests.

Do not use OPS.2 to classify Work into a universal natural kind, infer performed Work from a plan, select a structure by diagram appearance, or prescribe one lifecycle. If the question concerns only the identity of an already selected structure, mathematical lens, or architecture view, use A.22, C.29, or C.30.LCA directly.

OPS.2:0.1 - Working Distinctions

Name used here	Meaning
Work	Intended or performed activity under its governing FPF pattern. A management view describes or coordinates Work; it does not create another Work occurrence.
viewpoint question	The exact question a view must answer for a named user and decision, such as dates and allocation, repeatability, changing subject state, aggregate waiting, or feedback and rate separation.
Work-management mode	The selected use of one or more descriptions and coordination Methods for the current Work and questions. It is a decision result, not a Work kind or maturity stage.
project view	A description emphasizing a time-bounded undertaking, commitments, intended results, decisions, dates, WorkPlan content, allocation, dependencies, and closure conditions.
programme view	A description coordinating several projects or change commitments and their dependencies or intended contributions. The label does not create a containing System, benefit, or authority.
process view	A description emphasizing a recurring Method, inputs, results, repeated order or constraints, and control points. It does not prove that every occurrence follows the description.
case view	A description organized around a changing subject, current facts, commitments, discretionary or constrained next Work, exceptions, and closure conditions. The case is not its file.
queueing view	A description of eligible items, membership, order or service relation, waiting, arrival, departure, resource demand, and policy for one receiving question. The queue is not a board column.
control-structure view	A current FPF description of one selected control structure and its actual observation, actuation, reference, supervision, feedback, and rate-relevant relations. It is conditional, not an Operations default.
coordination Method	A reusable way of coordinating the Work under stated conditions. A view can expose what the Method needs without being that Method.
mixed-mode decision	An explicit co-use account stating subject correspondence, scope and grain, commitments, handoff or coexistence conditions, decision rules, conflicts, and stops among unlike views and Methods.

OPS.2:1 - Problem Frame

Project, process, and case management are often offered as competing descriptions of reality. Operations practice then chooses a tool or school and lets its default object model decide what exists. Yet one release operation can have a project for platform migration, a recurring process for validation, cases for field incidents, a queue for a scarce test rig, and a control view for observation and intervention at unlike rates.

These views are useful when they supply information needed by the receiving decision. They need not be isomorphic. Select each for the question it can answer and preserve correspondence where decisions cross them.

OPS.2:2 - Problem

One-mode selection loses information. A process-only account can force evolving cases through a route whose next Work depends on new facts. A case-only account can hide repeatable validation and shared capacity. A project-only account can treat continuing service as a temporary deliverable. A queue-only account can optimize waiting while breaking a commitment. A control-only account can turn observation and actuation into a complete management Method.

The opposite failure is an ungoverned hybrid: every tool and view is kept, but subjects, grains, states, and decisions disagree. Participants spend more effort reconciling records than coordinating Work.

OPS.2:3 - Forces

Force	Tension
Familiar methods	Teams can act quickly with a known project or process Method, while familiarity can hide the wrong question.
Several truths	Unlike views can all be useful, while their subjects and state claims may conflict.
Runtime discretion	Some Work can be planned, while new facts require case-responsive continuation.
Aggregate coordination	Individual cases need attention, while shared queues and resources require a population view.
Control language	Feedback and rate distinctions can change coordination, while a loop diagram can overclaim stability, safety, or authority.
Affordability	A full multi-model account is expensive, while one view may omit the next decision.

OPS.2:4 - Solution

Select views and coordination Methods from the operating questions they must answer. Preserve Work identity across views, select actual structures independently, and combine only those views whose distinct information changes the decision.

OPS.2:4.1 - Pattern-Use Unfolding

Recover the operating input. Start from the OPS.1 operating System, continuing result, commitments, subjects, units, horizon, and decision. Stop if the mode question is only a label preference.
List the viewpoint questions. Name each user, decision, subject, grain, horizon, and missing information. Separate planning, recurring execution, case continuation, aggregate waiting/capacity, and control questions.
Generate serious view candidates. Include project or programme, process, case, queueing, and control-structure views only where their questions are current. Include the incumbent as the no-change option, and a simpler view when it is a plausible alternative.
Compare fit to the current Work. Examine predictability, recurrence, subject identity, decision latency, runtime discretion, plannability, shared-resource coupling, exception frequency, evidence refresh, and authority. These are comparison prompts, not a universal scoring formula.
Select the coordination Method separately. State which reusable coordination Method is used with each view, its applicability, burden, evidence, and stop. A notation, board, model, or view does not establish a Method.
Select actual structures independently. Use A.22 when a transformation-flow, queue/resource-dependency, commitment, event, case-state, control, or other actual structure changes the decision. A mathematical graph or diagram remains a representation.
Use the control branch conditionally. When observation, decision, actuation, supervision, feedback, or rate separation changes coordination, use A.22 and C.30.LCA to identify one selected control structure and recover the needed view. Use B.2.5 only for an obtaining two-sided supervisor relation and C.27.TA, C.27, or A.3.3 for the exact rate, temporal, or dynamics claim. Stop without a control view when no control relation changes the decision.
Compose views explicitly. State subject correspondences, scope and grain, governing commitments, state correspondence, handoff or coexistence conditions, decision rights, update rules, conflicts, and stop conditions. Do not rely on a “hybrid” label.
Test with a changing case. Ask what happens when new evidence defeats the plan, a case crosses a process boundary, queue delay changes a commitment, or control evidence arrives at a different rate. Repair only the affected view or correspondence.
Return and reopen. Record selected and rejected views, coordination Methods, unresolved correspondences, next subject-account need, and one observation that reopens the decision.

OPS.2:4.2 - Record the Result

Result position	Required content
use boundary	Users, decisions, subjects, grains, horizons, and useful stop.
viewpoint questions	The planning, recurrence, case-state, aggregate waiting/capacity, control, or other exact questions that remain current.
candidate views	Incumbent (no change), serious alternatives, selection reasons, rejected uses, and missing evidence.
coordination Methods	Named Methods, applicability, burden, evidence, authority, and stops; no identity with the view or tool.
selected structures	Exact actual structures and direct relations relied on, plus representation and mathematical-lens boundaries.
mixed-mode correspondences	Subjects, grains, commitments, state correspondence, handoffs/coexistence, update and decision rules, conflicts, and stops.
control branch	Selected FPF control view and relied-on relations/rate claims, or an explicit `not current` or return result.
continuation	Inputs supplied to OPS.3/OPS.4 and an observable reopen condition.

OPS.2:4.3 - What Changes in Practice

The team stops asking whether Work “is” a project, process, or case. It asks which descriptions and coordination Methods answer each decision, then relates them through exact subjects and commitments. A view can be added, narrowed, or retired without retyping the Work or rebuilding every other view.

OPS.2:5 - Archetypal Grounding — PumpWorks Mixed Operating Views

PumpWorks-ControlServiceOps coordinates several unlike questions:

Current question	Selected view and Method contribution	Boundary
How should `FieldIncident-I73` continue after new field evidence?	Case view over the field installation, incident state, commitments, evidence, authority, and permissible next Work.	The ticket is a record; safety and product decisions retain their owners.
How is release evidence repeatedly produced and checked?	Process view of the recurring validation Method and its input/result relations.	A process description does not establish that an occurrence happened or conformed.
How is a time-bounded provider-platform migration coordinated?	Project and, when several projects are coordinated, programme views of commitments, WorkPlan content, decisions, allocations, and closure.	The plan is not performed Work, adoption, or benefit.
How is scarce rig access coordinated across eligible requests?	Queueing view over exact request membership, order/service relation, waiting, resource access, and policy.	Establish request membership, service order, and resource access for this queueing view; a board column alone does not establish them.
Which observations and interventions matter at unlike rates?	Conditional control-structure views for the product-side plant/controller/observer/supervisor relations and the operating-supervision relation.	FPF owns the generic structures and rate claims; the diagram is neither the account nor the Operations Method.

The views preserve correspondences to ReleaseCandidate-R42, FieldIncident-I73, SafetyQuestion-S19, ProviderChange-P8, the test rig, commitments, evidence results, and decisions. The incident case can request a validation-process occurrence; that occurrence can consume rig capacity; its evidence can inform the weekly release decision; a platform-migration project can change provider access. None of these relations makes the views one structure.

The product-control structure has FieldPumpInstallation-P4 as plant, FieldTelemetryObserver-O4, DeployedController-C17, and FieldModeSupervisor-S1 only where their direct relations obtain. The operating-supervision structure has ReleaseSupervisorTeam-S2 receive operating-state reports and return release, hold, rollback, or permitted-mode constraints to the operating System. The timing claims remain separate: sub-second product control, minute-to-hour field observation, daily incident triage, weekly release, and slower provider change. OPS.2 selects their use; it establishes no feedback closure, stability, safety, or authority.

Reopen the mode decision when a new subject cannot be related across views, a plan repeatedly fails after new facts, queue policy changes a commitment, a control relation becomes decisive, or maintaining one view costs more than the decision value it supplies.

OPS.2:6 - Bias-Annotation

Recurring bias	Likely drift	Repair
one-true-kind bias	Work is declared inherently project, process, or case.	Recover the question, subject, and selected view; preserve Work identity.
tool ontology bias	The tracker schema decides which objects and states exist.	Identify subjects and relations first; treat the schema as representation.
hybrid-label bias	“Hybrid” hides missing correspondences and decision rules.	State subject/grain mappings, commitments, coexistence, conflicts, and stops.
process-normality bias	Exceptions are forced back into the designed route.	Use a case view when new facts change permissible next Work.
project-temporariness bias	Continuing operation is treated as a project deliverable.	Keep the time-bounded change view separate from ongoing service Work.
loop-as-method bias	A feedback diagram becomes the whole Operations Method.	Use the conditional FPF control branch and retain the operating decision separately.

OPS.2:7 - Conformance Checklist

The decision begins with an OPS.1 operating focus and exact viewpoint questions.
Work identity is preserved across every selected view.
Project, programme, process, case, queueing, and control are selected for questions rather than declared natural Work kinds.
Coordination Methods, views, actual structures, diagrams, and tools remain distinct.
Selection considers predictability, recurrence, subject identity, decision latency, runtime discretion, plannability, and relevant coupling without pretending to use a universal score.
Every mixed-mode use states subject and grain correspondence, commitments, coexistence or handoff, update and decision rules, conflicts, and stops.
The control branch names actual participants and direct relations only where they obtain and returns rate/dynamics claims to their FPF owners.
A changed case or cross-view probe can expose a failed selection or correspondence.
Rejected views, unresolved gaps, next inputs, and a reopen condition are explicit.

OPS.2:8 - Common Anti-Patterns and How to Avoid Them

Anti-pattern	Repair
“Everything is a process.”	Identify changing subjects and ask whether discretionary or constrained case continuation is needed.
“Every initiative is a project.”	Separate time-bounded change commitments from recurring and continuing operation.
“Case management means no process.”	Retain reusable Methods and recurring subwork while letting subject state govern permissible next Work.
“Put all work in one queue.”	Name eligibility, service/resource relation, commitment effects, and the subjects that must remain separate.
“Use one integrated model.”	Preserve non-isomorphic views and relate only the claims the decision consumes.
“The loop proves control.”	Recover actual relations and use direct rate, dynamics, evidence, safety, and assurance patterns.

OPS.2:9 - Consequences

The pattern lets an operation combine familiar management practices without letting any one practice define the ontology. It makes view debt visible: missing correspondences, duplicated state, stale mappings, and coordination cost become explicit decision inputs.

The cost is maintaining subject and state correspondence where several views are genuinely useful. Some integrations are rejected because the views answer no different question or cannot preserve identity and commitments reliably.

OPS.2:10 - Rationale

Different views earn their place by changing a decision. Project, process, case, queueing, and control descriptions foreground unlike structures, times, and questions. Treating them as views preserves their strengths and avoids a false taxonomy of Work. Explicit mixed-mode rules then make coexistence testable without requiring one universal model.

OPS.2:11 - SoTA-Echoing

Practice question	Selected current line and serious alternative	Defect overcome and governed loci	Source roles and limits	Reopen condition
Which management views should coordinate one operation when project, process, case, queueing, and control questions coexist?	The selected current line is question-relative multi-view selection with explicit subject, state, commitment, and decision correspondence. The serious alternatives are one canonical project/process/case taxonomy and an ungoverned overlay of tool views.	A single view suppresses questions it cannot answer; an ungoverned overlay produces incompatible status, identity, and authority claims. Adapt: `OPS.2:4.1` selects each view from its question, `OPS.2:4.2` records correspondence and unresolved conflicts, `OPS.2:4.3` permits local addition or retirement, and `OPS.2:5` tests coexistence. Reject: treating a view name as the Work’s ontological kind or combining views without a receiving decision.	Select each view of Work for its question, using FPF distinctions for actual structures, representations and control. CMMN, DCR, Kanban and layered-control sources address different case, workflow and control questions; compare their contributions for the views needed by the operation.	Reopen if a current integrated Method answers the unlike questions with no worse subject/state correspondence, authority clarity, repair locality, and application effort, or if repeated use changes a view’s decision contribution or the minimum correspondence rule.

The selected comparison is supported by the following bounded source roles and limits.

Project, process, case, queueing and issue-tracking descriptions can provide different views of the same Work. Select the views for their practical questions and preserve the correspondences needed to use their answers together.

Source line	Retained contribution	Use boundary
Current FPF `A.22`, `C.29`, `C.30.LCA`, `B.2.5`, `C.27.TA`, `C.27`, and `A.3.3`	Select actual structures and views, keep mathematical representations distinct, recover control relations, and govern rate/dynamics claims.	FPF does not choose the Operations questions, domain coordination Methods, commitments, or service consequences.
CMMN 1.1 and DCR	Case planning, runtime discretion, declarative conditions, milestones, and responses can support continuation after new facts.	The specifications supply different case and constraint formalisms, not one complete Operations Method or universal case ontology.
The Kanban Guide 2025.5	Define a workflow, Work items, states, active-item management, and flow measures for a bounded Kanban use.	Kanban is one Method that can coexist with project, case, control, or other views; it does not establish comparative dominance.
Layered-control and LCA sources, see the source account	Make observer, controller, plant, supervisor, observation, actuation, feedback, and unlike rates visible.	Current FPF owns the generic control structure and claim discipline; source labels establish neither operating Method nor stability or safety.

OPS.2:12 - Relations

OPS.1 supplies the operating System, continuing result, commitments, subjects, units, horizon, and control concern.
A.22 governs selected structures; C.29 governs mathematical-lens use; C.30.LCA, B.2.5, C.27.TA, C.27, and A.3.3 govern the conditional control branch.
OPS.3 receives selected subjects, grains, view correspondences, direct-relation questions, and representation gaps. OPS.4 receives the selected participant views and their state-correspondence obligations.
OPS.5 later consumes the selected coordination form for admission. OPS.6 later consumes case-state and continuation needs. OPS.8–OPS.11 later consume queue, constraint, capacity, and interacting-structure questions without making those structures values of one mode taxonomy.
Project Management, case management, BPM, Kanban, SRE, and other practices offer candidate coordination Methods. Select a particular Method using its applicability conditions and evidence.