Infinite Work, Finite Words: The Art of Labeling IT Delivery

I didn’t plan to write this post. Actually, I had an entirely different topic in mind. But as I started drafting it, I stumbled upon an unexpected question: What word should I use to describe how IT work starts in a corporate environment? A simple question, right? Well, not exactly.

As I thought more about it, I grew increasingly confused. Should I call it a project, an initiative, or maybe an increment? I’ve encountered all of these terms (and more) throughout my career, each with its own flavor depending on the company, the team, and the mood of the leadership. So, instead of pushing through my original topic, I decided to pause and unpack this.

If you’ve worked in IT across different companies, you’ve probably noticed that no two organizations speak the same language when it comes to planning and executing work. Here are some of the terms I’ve come across:

• Project: In traditional, waterfall-oriented environments, everything is a project. A project has a clear start and end date, defined scope, budget, and resources (usually not, but let's ignore that for the sake of the argument). It's finite, with success measured against timelines and deliverables.
• Initiative: Enter the agile-adjacent companies. Here, projects morph into initiatives. The term sounds more dynamic, less rigid. An initiative often represents a broader business goal, possibly consisting of multiple projects or streams of work.
• Increment: In organizations that take Agile (with a capital “A” /s) seriously, you’ll hear about increments. It’s all about delivering value in small, manageable chunks. Unlike projects, increments imply continuity - the work never truly “ends” because there’s always another increment.

But just when you think you've wrapped your head around the terminology, corporate structures add another layer of complexity. As organizations grow, so do the ways they categorize and manage work, leading to even more terms that aim to capture strategic, operational, and everything-in-between efforts.

• Programs, Portfolios, and Strategic Somethings: When you zoom out to the enterprise level, things get even more layered. Programs bundle related projects. Portfolios manage multiple programs. And then there’s always that one term someone made up last quarter - “strategic initiative” or “value stream optimization” - just to keep things interesting.
• Mixed Terms: Sometimes, an initiative contains projects or even programs. Portfolios can include initiatives or whatever the big C* thought made sense during a strategic meeting. And with the invention of OKRs, things just became even fuzzier.

But here’s the thing: do all these different terms really matter?

At first glance, it might seem like pointless corporate jargon. Just different ways of labeling work, right? But here’s the thing: the words we use shape how we think about the work.

• Projects promote a finite mindset: There’s a beginning, a middle, and an end. You deliver, you close, you move on. This works well for clear-cut deliverables but can create rigidity in fast-evolving environments.
• Initiatives suggest flexibility and strategic alignment: They can evolve over time, adjusting to shifting priorities. But they can also become vague if not anchored by clear goals.
• Increments foster a continuous delivery mindset: The focus is on iterative progress and constant feedback. Great for adaptability, but sometimes challenging when stakeholders expect big, shiny milestones.

You might be wondering, should you even care about any of this? If you’re not a CEO, CFO, or some other C-something, does this terminology really matter? I think it does, and here’s why:

• Clarity in Communication: When you and your team talk about an “initiative” or a “project,” are you aligned on what that means? Misalignment here can lead to confusion, mismatched expectations, and even failed deliveries.
• Impact on Work Culture: Terminology reflects the company’s approach to work. Are you operating in a task-oriented, deadline-driven environment (project)? Or a continuous improvement culture (increment)? Knowing this helps you navigate the system more effectively.
• Strategic Thinking: Understanding these nuances helps you see the bigger picture. It’s not just about the work you do, but how that work fits into the organization’s goals and structure.

At the heart of all this terminology is a deeper tension between two ways of thinking about work:

• The “Everything Should Have an End” Mindset: This is the traditional, project-based approach. It provides closure, clear assessment points, and accountability.
• The “Work Is Never Done” Mindset: This leans towards Lean and Agile philosophies, focusing on continuous delivery, constant feedback, and perpetual improvement.

But here’s the twist: "Infinite games" are not in contrast with project thinking if the finite part is just a phase. Even if you call it a project, there’s often another project that picks up where the last one left off. Don’t fool yourself into thinking a project has a clear end and nothing comes afterward. There is always a “next” project.

And when work doesn’t get finished? It gets replanned, discarded, or "parked" - that fancy corporate term meaning we’ll never do this, but let’s not say it out loud - but that's a topic for another post.

Agile frameworks often emphasize continuous delivery without formal closure - work flows in an endless loop of iterations, feedback, and refinements. In theory, this means there’s no ‘final’ version of anything. But in corporate environments, that’s a luxury we can’t afford. Budgets close, fiscal years end, and someone in finance needs to know if we hit our targets. The reality? Even infinite games need checkpoints when money, resources, and accountability are on the line.

So, how do you navigate this sea of corporate jargon without getting lost?

Agile purists might argue that labels like ‘project’ or ‘initiative’ are irrelevant - it’s the outcome that matters. But try telling that to a corporate PMO that needs to file quarterly reports. In the real world, these labels aren’t just about semantics; they’re about aligning work with budgets, compliance, and executive dashboards. The key isn’t to reject these terms but to use them without letting them dictate how we think.

While understanding these terms is useful, don’t get too caught up in the jargon. Use whatever term helps you plan, communicate, and deliver effectively. Whether it’s Lean, Agile, or a continuous delivery mindset, you still need closure. Milestones, phases, and deliverables aren’t relics of the past; they’re essential for tracking progress and assessing outcomes.

On the other hand, think that work is rarely truly finite. Even if you're a contractor hired for a single job, there’s always a next phase, the next iteration, the next challenge. But while it’s okay to set things aside for "Phase 2," never start without a clear point of closure. Not just an Agile feedback loop, but a corporate closure - a checkpoint where deliverables are reviewed, budgets reconciled, and progress assessed.

In the end, it’s not really about the label; it’s about the clarity behind it. Whether you call it a project, initiative, or increment, the name won’t deliver the work - clarity and shared understanding will.

So, plan for continuity, but anchor your work with review points and tangible outcomes. That’s how you navigate both the infinite and the finite in corporate life.

• D. Scope