Most organisations run their projects on a project management framework, their software on DevOps, and their processes on lean or ISO. Then they run everything between those islands, the everyday cross-team work that actually moves the business, on improvisation and goodwill.
That gap has a cost, and in most companies nobody owns it. This article makes the case for treating work itself as something worth a framework, shows where the established frameworks stop, and explains what WorkOps covers, and just as deliberately, what it does not.
Companies still operate in chaos between teams
You can recognise the gap by its symptoms. Four of them show up in almost every organisation past a certain size:
- Fragmented work tools. Teams use disconnected systems for projects, tasks, clients, communication, and reporting, with no single source of truth.
- Manual, repetitive tasks. People spend hours copying data between systems, chasing statuses, and assembling reports the system could generate on its own.
- No real-time visibility. Leaders make decisions on outdated or partial data because current data lives in five tools and two inboxes.
- Inefficient handovers. Work waits in unowned queues between departments. Marketing finishes, then the request sits for four days before sales even sees it.
Notice what these four have in common: none of them happens inside a team. Teams are usually fine. Work fails in the space between them, and that space is exactly what no established framework owns.
What frameworks are actually for
“Framework” has a bureaucratic reputation it does not deserve. A good framework is not paperwork. It does three jobs that improvisation cannot:
- Shared language. You cannot improve what you cannot name. Before DevOps, “the wall between development and operations” was a thousand local complaints; after DevOps, it was a named problem with named practices against it.
- Decision rules. Work is full of collisions between two right answers: planning against delivery, speed against control, one team’s convenience against everyone else’s visibility. Principles decide those collisions consistently instead of re-arguing them weekly.
- Repeatable improvement. A framework gives you a loop, measure, adjust, repeat, so improvement compounds instead of depending on whoever cares most that quarter.
The precedent is strong. DevOps unified a fragmented software lifecycle through automation and shared ownership, and the gap it opened was measurable: DORA’s State of DevOps research found elite teams deploying on demand while low performers waited between one and six months between deploys. Agile did the same for iteration inside product teams. Both proved the pattern: name the layer, give it principles, automate the repetitive part, measure the flow. (We traced that lineage in detail in From DevOps to WorkOps.)
The open question is why nobody applied the same pattern to everyday cross-team work, the largest layer of all.
The most popular frameworks compared
Start with the term most people search for. A project management framework is a structured set of processes, roles, and practices for taking one project from initiation to closure: it defines how you scope work, plan the schedule and budget, manage risk, and report progress. Prescriptive frameworks such as PMBOK and PRINCE2 specify phases and governance in detail; agile methods such as Scrum and Kanban replace fixed phases with short iterative cycles. If you run projects without one, you should adopt one; nothing below argues otherwise.
The point of this comparison is different: every framework family, project management included, is good at its job and stops at a boundary.
| Framework family | What it governs | Where it stops |
|---|---|---|
| PMBOK, PRINCE2 (project management frameworks) | Individual projects: scope, schedule, budget, risk | Ends when the project ends; silent on operations and cross-project flow |
| Agile methods (Scrum, Kanban, and others) | Iterative delivery inside a product team | Team-level by design; scaling attempts add ceremony fast |
| DevOps | The software lifecycle from build to release to operate | Engineering-only; the rest of the company falls outside its scope |
| Lean, Six Sigma, operational excellence frameworks | Quality and waste in defined, repeatable processes | Needs a stable process to optimise; weak on novel, cross-functional work |
| ITSM, ITIL | IT service delivery, incidents, requests | IT services only |
Read the right-hand column top to bottom and the pattern is hard to miss. Every framework stops at a boundary, and the boundaries do not touch. A framework governs projects, sprints, pipelines, processes, and services. Nothing governs the everyday work that flows between them: a customer escalation crossing support, engineering, and account management; a launch crossing product, marketing, and legal.
WorkOps: the framework for the gaps
WorkOps is the framework for that unowned layer. The WorkOps Playbook defines it as a framework in the full sense: a culture, methodology, and set of practices that integrate work planning, execution, automation, and performance optimisation into a unified, continuously improving system. The name itself says the scope: Work + Operations.
A culture, methodology, and set of practices that integrate work planning, execution, automation, and performance optimisation into a unified, continuously improving system. See the full framework.
451 Research analyst Chris Marsh gave the term its first structured definition in 2018; the WorkOps.org team developed today’s framework on that foundation. Four shifts make it practical now rather than in 2018:
- Tool fragmentation became the norm, so orchestration across tools beats consolidation into one.
- Hybrid and remote work made informal coordination in hallways impossible; teams now have to design flow deliberately.
- The AI revolution supplied the missing engine: automation that can reason across processes, not just execute rules.
- Speed became the competitive variable. As DevOps redefined how fast software ships, WorkOps redefines how fast organisations deliver results.
Structurally, WorkOps runs on a single continuous cycle, the WorkOps Infinity Loop, with two domains: Work (planning, delivery, quality, reports) and Operations (automations, integrations, support, knowledge), with AI at the centre as the intelligence layer for the whole lifecycle.
What separates it from the frameworks in the table is that it spans levels instead of siloing them. The same loop applies at four zoom levels: the whole organisation, a cross-team stream, a single team, and one person’s working day. A developer using AI agents to prepare tests and a COO looking at organisation-wide flow are looking at the same model at different magnifications.
What WorkOps is and is not
A framework that claims everything governs nothing, so WorkOps publishes its boundaries.
What it is: the discipline of planning, coordinating, delivering, supporting, automating, and continuously improving work across teams. It improves the flow of work, the quality of handovers, the visibility of execution, and the consistency of delivery.
What it is not. WorkOps is not a framework for managing the entire company. It explicitly does not own:
- sales strategy, commercial management, pricing, and revenue ownership
- corporate finance, accounting, treasury, and tax
- HR administration, compensation, payroll, and people governance
- corporate strategy formulation and portfolio governance
- brand, positioning, and marketing strategy
- legal management and corporate governance
- procurement, sourcing, and vendor management
Their functions keep owning these domains, and each one connects to WorkOps without WorkOps absorbing it: CRM data informs delivery priorities, budgets shape execution decisions, strategic priorities decide what enters the pipeline.
And WorkOps is not a tool. It is tool-agnostic by design: it starts with the stack you already run, treats one platform as an orchestrating layer at most, and outlives any specific tool generation. Adopting WorkOps does not start with buying software.
Are your teams collaborating? Let's find out
A framework without metrics is an ideology. WorkOps ships its scoreboard, six measures, and you can run the first pass on your organisation in an afternoon:
- Cycle time. How long from request to delivery, across teams, not within one?
- Automation rate. What share of recurring work runs without a human copying data?
- Work visibility index. What share of work in progress is visible in connected systems, regardless of which tool it lives in?
- Cross-team efficiency. How long does work wait, on average, at each handover between teams?
- Knowledge readiness. Could a new joiner, or an AI agent, find the current version of how you work? (The Playbook’s checklist sets the bar at 5 of 7 criteria.)
- Ownership coverage. What share of your processes, automations, and AI agents has a named owner and a traceable record?
If you cannot answer three or more of these, that is not a criticism of your teams. It is evidence that no one manages the between-teams layer in your organisation, which is precisely the layer a work framework exists to manage.
Key takeaways
- Established frameworks (project management frameworks, agile, DevOps, lean, ITSM) each govern one bounded layer; none of them owns everyday cross-team work.
- The symptoms of that unowned layer are universal: fragmented tools, manual busywork, outdated reporting, and slow handovers.
- WorkOps applies the proven framework pattern, shared language, principles, automation, metrics, to work itself, with AI as the engine that finally makes it practical.
- WorkOps earns credibility by publishing its boundaries: seven management domains it explicitly does not own, and no claim to be a tool.
- Six metrics let you test the state of your own between-teams layer this week.
Start where you are
WorkOps deliberately does not begin with a transformation programme. Its own principle, “Fit, Don’t Force”, says it directly: “WorkOps adapts to the structure, tools, and culture you already have, enabling gradual improvement without disruptive reorganisation.”
The practical entry point is the WorkOps maturity model, five levels from tool fragmentation to a self-optimising organisation. Most companies discover they are at level 1 or 2, and that the next level is reachable with the stack they already own. The maturity model, the metrics, and the knowledge readiness checklist all live in one document.
Download the WorkOps Playbook and run the assessment on your own organisation this week. For the model behind it, see the WorkOps framework and the eight principles.
WorkOps.org stewards the framework as an open methodology. The comparison above names established frameworks fairly and within their documented scope boundaries.