Why Organizations Like to Start Things—and How IT Consultants Can Help Them Finish

A consultant’s perspective on why finishing is harder than starting

Jan 12, 2026

At the beginning of a new year, many people in organizations find themselves in familiar territory. New goals, new initiatives, new tasks—sometimes even new strategies. Calendars fill up quickly, kickoffs are scheduled, and there is a sense that now things will finally move in the right direction.

Organizations are generally good at starting initiatives. A new project signals movement. It shows intent, ambition, and responsiveness. In many cases, this is exactly what is needed. Without that bias toward action, change would stall before it even begins.

This tendency doesn’t stop at strategy decks—it quickly turns into concrete work. From an IT consulting perspective, it is also practical. If organizations like to start things, there will be work to do. New initiatives, new phases, new programs—often addressing familiar problems under slightly different names. That part is not a flaw. It’s how work gets moving.

The more interesting question comes later: not why organizations start so much, but why so few things ever feel clearly finished—and what that means for IT consultants working in the middle of it.

The Real Pattern: Starting Is Rewarded, Finishing Is Not

Organizations are good at starting things because they are built to reward it. Launching a new strategy, program, or IT initiative signals action and responsiveness. It creates momentum, attracts attention, and often unlocks funding. Starting something is visible—and visibility matters in large organizations. It is far easier to justify a new initiative than to explain why an old one should be stopped.

This dynamic becomes particularly visible in IT. Strategic goals tend to materialize quickly as IT initiatives: new applications, platforms, data programs, or large-scale transformations. A kickoff meeting, a roadmap, and a target architecture create an early sense of control over complexity—even though, at that point, very little has actually changed.

Many IT initiatives don’t clearly end. They evolve into follow-up phases, extended roadmaps, or “continuous development.” Something is delivered, but rarely closed in a way that creates a shared understanding of what is done, what remains open, and what should deliberately stop. The work moves forward, but the finish line keeps shifting.

Yes, sometimes IT initiatives struggle simply because the project was poorly set up, under-resourced, or badly led. That happens. But even well-run projects are not immune to the broader pattern.

Finishing requires reflection, trade-offs, and occasionally admitting that the original goal has changed, or was never fully reachable. Those moments are less visible and less rewarding than starting the next initiative. As a result, organizations keep moving, while closure quietly fades into the background.

Why This Matters for IT Consultants

Here’s the slightly uncomfortable part: IT consultants usually recognize this pattern.

We’ve seen how projects stretch, how scopes blur, and how unfinished work quietly turns into the next phase. We also know that this tendency can’t really be fixed at the organizational level—at least not from within a single project.

But consultants do have one important advantage. The projects end for us.

Engagements have boundaries. Contracts expire. Even when the organization continues with the same themes, the consulting work eventually stops. That creates distance—and with it, perspective.

And that perspective comes with responsibility. Not to fix the organization’s structural habits, but to keep our own work honest: to be clear about what was actually done, what was left open, and what should not quietly roll forward just because it’s convenient.

Keeping Your Own Corner Clean

The realistic role of an IT consultant is not to make organizations perfect at finishing things. That would be neither feasible nor credible.

The role is smaller—and more practical. Since consultants recognize the pattern of constant starting and fuzzy endings, the responsibility is to avoid reinforcing it in their own work. Not by forcing artificial closure, but by being deliberate about what the engagement actually does and does not achieve.

In practice, this usually comes down to a few very concrete habits:

Be explicit about what this project does not resolve. Every engagement has boundaries. Naming them early and repeating them later helps prevent unfinished work from quietly turning into assumed success.
Help define what “done” means for this specific engagement, even if broader work continues elsewhere. Completion does not have to mean finality. It does have to mean shared understanding.
Avoid framing continuation as automatic success. Moving on to the next phase is not, by itself, evidence that the current one worked.
Make open issues visible instead of letting them drift silently forward.
Unresolved questions age poorly when they are left unnamed.

In short: don’t contribute to the illusion of closure—but don’t pretend everything must be closed either. Keeping your own corner clean is often the most realistic and most useful contribution an IT consultant can make.

A Modest but Meaningful Point

Nothing here is particularly dramatic. Organizations starting more than they finish is not a scandal—it’s a predictable outcome of how large systems work.

The consultant’s contribution is not to fight that tendency head-on, but to be aware of it and act accordingly. To keep at least one project, one scope, and one set of promises reasonably intact.

That may sound modest. In practice, it often makes the next start a lot more sensible.