Project IT versus continuous IT — which one is your team actually running
Most mid-market IT teams describe what they do as "running IT." It isn't. It's project IT — and it produces different outcomes, different costs, and different team experiences than the alternative.
Walk into any mid-market IT organization on any given day and ask what they're working on. The answer is almost always a list of projects. The refresh project. The new-clinic standup. The HIPAA audit prep. The Intune migration. The acquisition integration. The compliance review. The vendor consolidation. Each project has a sponsor, a timeline, a budget, a steering committee, and a finish line.
Between projects, the team handles normal operations. Tickets get answered, devices get fixed, accounts get provisioned, problems get put out. This work doesn't have a sponsor or a finish line; it just happens, in the gaps the projects leave behind.
Most IT teams describe this as "running IT." It isn't. What they're describing is project-driven IT — a model where the strategic work happens in projects, and operational work fills the spaces between them. There's an alternative model — continuous IT, where the operational discipline is the strategic work and projects are mostly absent. The difference between the two models matters, because they produce different outcomes, different costs, and different team experiences over time.
This piece is about the structural differences between project-driven IT and continuous IT, why one of them is dramatically harder to scale, and how to tell which one your team is actually running.
What "project IT" actually looks like
Project IT is the dominant model in mid-market organizations and most enterprises. It's the natural shape of how IT evolves: a new requirement appears, the team scopes a project to address it, the project runs, the project ends, and the team moves on to the next project.
The structure is recognizable. Every major IT change happens as a discrete initiative with start and end dates. The team's calendar is organized around project timelines. Budget is allocated project-by-project. Strategic conversations with the business are framed as "what's our next IT project?" Operational improvements — process changes, automation, documentation, capability development — happen as side effects of projects, not as ongoing work.
The strengths of project IT are real. Projects are easier to fund because they have defined scope and defined cost. Projects are easier to communicate to executives because they have visible milestones. Projects are easier to staff because the work has a beginning and an end. For organizations early in their IT maturity, project IT is often the right model — it's how new capabilities get built.
The weaknesses of project IT show up later, and they show up the same way every time.
Where project IT breaks down
Three structural problems are intrinsic to the project model. They're not problems of execution; they don't get better with a more disciplined team or a better project management office. They're problems of model.
The first is that projects don't compound. Every project is its own start. The successful refresh project this year doesn't make next year's refresh easier — the team has to rebuild context, re-scope, re-plan, re-staff. The clean audit this year doesn't make next year's audit lighter, because the evidence-collection process was a project deliverable, not an operating discipline. Each project produces an outcome and then ends, leaving the operational baseline approximately where it started.
Continuous IT compounds. Every cycle of operations teaches the operating model something. The persona map gets refined. The deployment process gets faster. The audit evidence accumulates as a natural byproduct of normal work. After three years of continuous lifecycle management, the team is operating at a level that no amount of project execution could have produced.
The second is that projects can't be sized accurately. Most projects come in over budget and over schedule, not because the team is incompetent but because the unknowns in any specific project are inherently larger than the knowns. The refresh project that's supposed to take three months takes seven. The audit prep that's supposed to take a week takes a month. The acquisition integration that's supposed to take a quarter takes a year. Anyone who's run mid-market IT for more than a few years knows this pattern. It's not a bug in the planning process; it's the nature of project work.
Continuous operations are different. The work is the same every day. The cost is the same every month. The budget for next year is the budget for this year, plus some growth factor. Predictability comes from running the same operating model repeatedly, not from planning more carefully.
The third — and the most damaging — is that projects burn people out. The IT team that runs a major project every quarter is the IT team that loses senior people. Project mode is constant fire-drill mode: extended hours during execution, deferred normal work that creates ticket backlog, the cycle of crash-and-recover that nobody can sustain indefinitely. The best IT operators leave for organizations that don't run this way, which makes the next project harder, which accelerates the burnout, which produces more departures. The cycle is self-reinforcing.
Continuous IT puts the engineering work upstream of the events. The persona model is defined once, then maintained. The deployment automation is built once, then operated. The compliance documentation accumulates as a byproduct of normal work. The team running this model isn't firefighting; they're operating. The work is sustainable in a way that project mode never is.
What continuous IT actually looks like
Continuous IT replaces the project list with a defined operating model. Instead of "the new-hire onboarding project," there's a daily onboarding process triggered by HR — every new hire goes through it, in sequence, without anyone calling it a project. Instead of "the refresh project," there's a continuous fleet refresh function — devices age out on a known schedule, replacement orders are placed automatically, swaps happen on a continuous cycle. Instead of "the audit prep project," there's a documentation discipline that produces audit evidence as a byproduct of normal operations.
In a continuous IT shop, the team's calendar isn't organized around projects. It's organized around operating cycles — the weekly fleet review, the monthly compliance check-in, the quarterly persona reassessment. Big initiatives still happen — a new site standup, an acquisition integration, a major platform migration — but they're handled as scaled extensions of the operating model, not as bespoke projects.
The work that used to be a project becomes the background hum of normal operations. The team that used to be in fire-drill mode is now in operating mode. The CFO who used to see lumpy capital requests every quarter now sees a predictable operating cost. The CIO who used to defend project after project to the executive team now defends a model — once — and then operates it.
This isn't a small change. It's a fundamental restructuring of how IT relates to the business. Most organizations never make this transition; they continue to run project IT indefinitely, even as the costs of doing so accumulate. The ones that do make the transition often describe it the same way: things just get easier in a way that's hard to explain to anyone who hasn't done it.
How to tell which model you're running
A few honest diagnostic questions:
How does your team describe what they're working on this week? If the answer is a list of projects, you're running project IT. If the answer is a description of operating cycles ("we're in the middle of the monthly fleet review and finishing this quarter's persona reassessment"), you're running continuous IT.
What happens when someone joins your organization? If a new hire's device readiness requires a project — even a small one — you're running project IT. If a new hire's device is on their desk on day one, triggered automatically by HR, without anyone touching a project plan, you're running continuous IT.
What happens when an auditor shows up? If your team scrambles to assemble evidence, you're running project IT. If the evidence is already documented as a byproduct of normal work, you're running continuous IT.
What does the IT budget conversation look like? If next year's budget is a list of proposed projects, you're running project IT. If next year's budget is the operating cost of the existing model plus a defined growth factor, you're running continuous IT.
Most mid-market IT shops will fail all four of these diagnostics. That's not a moral failing; it's the natural shape of how IT has evolved over the past few decades. But it's worth knowing what model you're running, because the model is what determines what comes next.
The path from one to the other
Most organizations don't move from project IT to continuous IT all at once. They move one operating discipline at a time — first lifecycle management for endpoints, then compliance documentation, then network operations, then identity and access management. Each transition replaces a category of project work with an operating model. Each one produces compounding benefits that fund the next transition.
Endpoint lifecycle management is usually the first transition for a reason. It's the most visible — every employee in the organization touches a device. It's the most consequential — devices are how work happens. And it's the one where the project-to-operations savings are most obvious in the first year. An organization that runs continuous endpoint lifecycle for twelve months sees the savings on hardware acquisition, on labor, on help-desk volume, on compliance posture, and on the team's calendar. Those savings, properly captured, fund the next transition.
This is what Surya runs. Continuous endpoint lifecycle management as a productized operating model — one operating model, every device, every site, every day. The same model that makes the refresh project disappear into the background hum of normal operations makes every other piece of endpoint operations work the same way.
For organizations still running project IT, the transition starts with the next refresh. The refresh is the moment when the fleet is being touched anyway, and the right refresh program leaves behind an operating model that doesn't end when the refresh ends.